Based on these comments from Ash > Relevant is SQLAlchemy’s experience if trying the no pr without issue triage: https://fosstodon.org/@zzzeek/117298404897300953
and > Imagine this, someone creates a PR, it gets converted to draft, they go to all the effort of setting up GHA on their fork, a few rounds to get tests passing, and only then to get the attention of a committer to be told “sorry, no this can’t work/this is by design” and the PR gets closed. Sounds like a _perfect_ way to put people off contributing ever again. we might be able to reduce the number of unnecessary PRs by moving the discussion to issues. If there was a separate issue tracker which was meant just for contributors and proposed fixes / changes, feedback could start over there before people spend time working on something. PRs would have to be associated with an issue and be opened only after someone has looked at the issue and there was consensus that the proposed changes are valid. It's not relevant to Jarek's AIP but I'm just throwing an idea. Christos On Sat, Sep 19, 2026 at 7:38 PM Justin Pakzad <[email protected]> wrote: > Thanks for putting this together, definitely in favor of this. While > it might be a bit more time consuming for contributors, I believe it's > justified and don't see it as a big barrier, especially if the process > is as simple as you stated in one of your previous messages (e.g., no > additional PR needed against the fork). > > I noticed you mentioned the "Per-contributor pull request caps" as an > alternative. If my memory serves me correctly, there was a thread > about that a little while back and it seems a lot of people were in > favor of it. Is that an ongoing discussion or has it been ruled out? I > don't think the two are mutually exclusive. I wonder if a cap would > help encourage contributors to focus on quality over quantity and > getting contributions over the finish line before jumping to something > new. That might constitute a separate discussion though. Just my two > cents. > > - Justin P > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
