> 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.
Yeah. Not mutually exclusive and yeah we already agree to implement it. But that is waiting for .That is waiting for my .asfyaml PR to be merged. That is waiting for my .asfyaml PR to be merged: https://github.com/apache/infrastructure-asfyaml/pull/111. I've been relentlessly pushing towards getting it merged (same a a number of other PRs) - including creating this workflow https://github.com/apache/infrastructure-asfyaml/pull/127 and this SKILL https://github.com/apache/infrastructure-asfyaml/pull/133 for the infra people to be able to test any .asfyaml changes in minutes rather than hours. The last two PRs were merged just a few days ago - and I was hoping the first PR would finally be merged quickly, especially since I tested all of them with my skill and even fixed some issues. Some of those PRs waited for > 6 months. Any nudge from people still waiting for this feature would be welcome. I can only do as much .... J. On Sat, Sep 19, 2026 at 6:44 PM Christos Bisias <[email protected]> wrote: > 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] > > > > >
