I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.
Pull request limits are cutting down the noise
11–20 of 56 posts
Re: Pull request limits are cutting down the noise
#12Earlier quoted context omitted.
There is also the solution of: No merge requests, just feature wishes and bug reports. All code is written solely by the maintainers (with the help of LLMs).
Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
> Add a mechanism to donate tokens
Or donate money. Crazy idea, eh?
Re: Pull request limits are cutting down the noise
#13[flagged]
Thats just a coding agent the "peopple" use via you, with extra steps.
Re: Pull request limits are cutting down the noise
#14I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.
I get a lot of emails that I want to get but never reply to. I would not want to have to remember to whitelist all of those.
Re: Pull request limits are cutting down the noise
#15Earlier quoted context omitted.
There is also the solution of: No merge requests, just feature wishes and bug reports. All code is written solely by the maintainers (with the help of LLMs).
Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
And creates a new class of problems. Why not just fork the project and modify it yourself at that point, and cut out the maintainer middleman.
Re: Pull request limits are cutting down the noise
#16I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.
I get a lot of emails that I want to get but never reply to. I would not want to have to remember to whitelist all of those.
Yeah fair, then you could set it higher, even 100. Or default it off.
Re: Pull request limits are cutting down the noise
#17also, close all issues and open them as you plan to work on them.
Re: Pull request limits are cutting down the noise
#18Earlier quoted context omitted.
Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
And creates a new class of problems. Why not just fork the project and modify it yourself at that point, and cut out the maintainer middleman.
Because it is vibecoded garbage.
Re: Pull request limits are cutting down the noise
#19Earlier quoted context omitted.
There is also the solution of: No merge requests, just feature wishes and bug reports. All code is written solely by the maintainers (with the help of LLMs).
Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
That's the same as donating money, which you can already do.
Re: Pull request limits are cutting down the noise
#20Earlier quoted context omitted.
Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
And creates a new class of problems. Why not just fork the project and modify it yourself at that point, and cut out the maintainer middleman.
[deleted]