* 50 is an arbitrary number, but it seems reasonable I think this is a great proposal and surely it is a community-oriented idea. +1 to all your 6 points. However, I believe that the reasonable PR number depends on how many PRs are opened daily/weekly. What about focusing more on the time limit of a PR? Should we try to close/merge within 6 months maybe (unless exceptional reasons)? Or at least move it to draft? What about having a stricter policy on keeping a PR open for longer than 2 months or so? Old PRs create extra work: resolving conflicts + rebasing + retesting + reviewing. And that should be avoided whenever possible. I will try to make some workflow examples (which may not fit well with WildFly): * Is it still open because there is an implementation choice to make? Could we close it and discuss it in a wildfly-proposal before? * Are we still waiting for input ? Let's give a timeline to provide the input otherwise let's close the PR (for the moment) and reopen it when the input is provided, and in the meanwhile somebody else could work on the issue and open a new PR for it. * A Feature is very big and needs extra time: what about splitting the Feature PR into 2 or 3 'faster' PRs (when possible) so that we can at least merge the 'backbone' part of the feature and then adding the other parts (when modularity is possible)? Ideally WFLY Jira workflow might need a new 'Pull request parked' status next to 'Pull request sent' for PRs waiting for inputs for a long time or having 'missing-reqs' / 'core-upgrade-needed' label for a while. Marco Sappe' Griot ________________________________ From: Brian Stansberry <bstansberry(a)gmail.com&gt; Sent: Thursday, January 22, 2026 7:56 PM To: wildfly-dev(a)lists.jboss.org <wildfly-dev(a)lists.jboss.org&gt; Subject: [EXTERNAL] [wildfly-dev] 50 or less open PRs in wildfly/wildfly queue I'd love it if by the end of WF 40 development in April we could get the PR count in https://github.com/wildfly/wildfly/pulls down to 50 and then keep it there going forward. We spent much of the last year or two at around 100, which is not good for contributors or for maintainers. 50 is an arbitrary number, but it seems reasonable. For example, it would allow us to have in the queue: 10 Feature PRs 5 Dependabot PRs 10 misc non-Feature PRs that are quickly moving through a review[/update/review]/merge cycle. 10 more difficult non-Feature PRs that are taking more than a couple weeks to get in shape for merging 10 short term drafts where people using the PR queue to gather feedback on WIP Plus a 5 PR buffer for when there are randomly more of some of those types. The mix could of course be different over time. Things to do to get there: 1) My favorite -- get our Features completed. We currently have 24 PRs labeled as Feature. That is far too many. 2) My second favorite -- help review and merge PRs, particularly non-Feature PRs, and including old ones. 3) Go on an exercise to get various PRs that fell into cracks merged or closed. I made an effort on that in Nov/Dec which is one reason the queue is now 73. 4) PRs that are not mergeable because they are missing some requirement (say a WF Core upgrade) must be in 'Draft' state until whatever they are waiting on is in process to become available (e.g. the required change in Core is merged so we know it will be available within a couple weeks.). Those drafts should become mergeable or be closed within two or three weeks. 5) Resist the urge to use the PR queue to gather feedback on WIP. Are you really looking for input from random people, or do you have particular people in mind? If the latter, ask those people to look at your branch in your personal repo. I'm not saying never open draft PRs like this but don't leave them open for long periods, and definitely not if work has halted for some reason. 6) Be willing to say no and close a PR if you are the component lead for the relevant area. WDYT? Best regards, Brian _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... Unless otherwise stated above: IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20054 Segrate (MI) Cap. Soc. euro 247.656.998.20 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Società con unico azionista Società soggetta all'attività di direzione e coordinamento di International Business Machines Corporation