So .. as discussed in the other thread about PR limits.. This one also has one advantage, that contributors who will hit their limits will be able to run CI on their branches, by simply pushing branches to their repos (and either just looking at Actions tab or creating self-repo PRs).
I think it's largely a no-brainer. We can implement it as a next step after limiting the PR number. As discussed in the other thread, I'd prefer to first add the PR number limit and some time after, also move CI. That has double advantage - we can see impact of each of those separately, and we will have **two** opportunities to educate our contributors. First the "heavyweights," then everyone else. J. J. On Sat, Sep 19, 2026 at 7:41 PM Jarek Potiuk <[email protected]> wrote: > > 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] >> > >> > >> >
