I agree. For bug fixes, just write a clear issue: how to reproduce it, what goes wrong, what's the root cause. As short and well written as possible, without AI fluff.

Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?

In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.

If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.

That’s what I’ve been telling my PM: I don’t need your half-baked PR you one shotted from a prompt: put that prompt in GitHub Issues for the team to use later

This has always been true to a large extent. Unless you're cleared to carve out your own space of a project, or you're working off an already detailed issue/feature request.

Do maintainers agree with this or do they feel you're just spamming them?

> The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.

My experience is that maintainers cannot do this. Or rather, that it is useless.

I agree with fellow commenter, now with LLM the forks will NOT been distinguished as much by their technical differences/features as their trustworthiness (which is already the case today, but tomorrow will be skewed even more). Massively increasing inertia and favouring initial/well-known work/founder/team.

That's not entirely true: my work might get zero traction because nobody will know about it.

Not really, even if you have a great improvement, you need to spend the overhead to keep it up to date long enough to gain traction.

Then marketing it to convince others to even try... If the idea is too niche it might never hit that threshold for uptake.

GDAL isn't too big on LLM contributions either.

You're forgetting QGIS's own plugin ecosystem, which afaik doesn't prohibit slo-... err, vibe and assisted-coded contributions.

Although that would probably change of the AI-assisted spam shifted over to it.

> make a contributor pay for the review of its PR, even a small fee

I agree!

The problem is obviously a resource allocation one. Economics solves problems like that.

To make the system viable, you need something like the free-to-play games use (shudder).

Offer a choice: user’s time and attention or money.

(This addresses the issue of excluding low-resource contributors, which we might care about for equity or because that was us when we were young.)

As an idea on the money front, you could require the contributor to pay for the tokens needed to review their PR! Maybe even let simple models review simple PRs or advanced models decide which model is needed to do the actual review.

I don’t know how the humans can contribute their time and attention effectively, but maybe we can figure that out.

It would also exclude 75% of the world.

[dead]