I've made this change. Welcome, new mergers! The following is repo specific info. It should live somewhere else, perhaps in https: //github. com/wildfly/wildfly/wiki, but today it's here. (Some of it may make sense for other repos, but     I've made this change. Welcome, new mergers! The following is repo specific info. It should live somewhere else, perhaps in https://github.com/wildfly/wildfly/wiki, but today it's here. (Some of it may make sense for other repos, but I'm not talking about those here, so don't assume I am.) RULES FOR MERGERS to wildfly/wildfly 1) Only one person should be merging PRs at a time. We control this via messages in Zulip in the https://wildfly.zulipchat.com/#narrow/channel/274477-Pull-requests/to.... Before merging, check the thread and if no one else is merging post: merging on <branch> :lock_with_key: When done, post :unlocked: 2) Avoid merging to a branch the week of its planned release until the release is tagged (usually a Wednesday). Let the coordinator for the release drive merging. If something really needs merging, discuss first in the release's topic https://wildfly.zulipchat.com/#narrow/channel/424923-releases channel in Zulip. 3) PRs should have satisfactory reviews from people competent in the areas it touches and it should have recent "good" CI results before being merged. There are a lot of words in that sentence that involve exercising good judgement. We're not highly prescriptive and rely a lot on good judgement. If you're not sure, ask, or just don't merge. Some details about use of judgement: a) "Satisfactory" reviews. As much as possible this means a formal GitHub approval. If someone has made a simple suggestion and you can see the author followed it but you can't get that reviewer to formally approve in a timely manner, then it's 'satisfactory'. "Timely" is a matter of judgement. b) "Competent in the areas it touches" is not defined. There is no formal rule. The wildfly-bot will request reviews from people based on its config, but that's just a suggestion. If the author requests that certain people review, respect that, unless they tell you it's ok not to. c) "Recent" CI generally means no more than a week old. Maybe less depending on where we are in the release cycle and what other things have been getting merged since the CI jobs ran. d) "Good" results means all tests executions ran (so no failures that stopped prevented executions running) and with no new failures or potentially relevant intermittent failures. Intermittent failures are a complex topic; too much to get into here. Bottom line: use your judgement and if you're at all unsure, ask about it in the main zulip channel https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-deve... 4) PR titles should mention the JIRA(s) so they end up in the merge commit message. a) Exception: dependabot PRs that don't affect production code or tooling likely to be of interest to users (e.g. Arquillian, Galleon) don't need JIRAs. 5) For dependabot PRs that impact production code, at some point I'll research what modules are affected and post a comment @ pinging the relevant people asking for input by date XXX, and otherwise it will be merged. If you see one of these and its past date XXX and someone hasn't responded, it's ok to merge. If I haven't added one of these comments, ask before adding one yourself. There are some components where we really want an explicit approval and silence isn't enough. 6) Don't use "/retest" just to get a new run of one or two failed CI jobs. Don't waste energy. If you don't have TeamCity perms to click on the link for a failed job and hit the "Run" button to make it run again, talk to Ken Wills. 7) Don't merge feature PRs unless you understand the feature development process well and are very clear that the requirements have been met. When in doubt, ask. 8) No merging of feature PRs between the tag of a Beta and the opening up of the branch for the next feature release following the tag of the Final. 9) No merging of PRs with the ##.x label on them if ## is later than the release under development. Best regards, Brian On Fri, Sep 19, 2025 at 1:36 AM Jean-Frederic Mesnil <jmesnil(a)ibm.com&gt; wrote: > > > > > On 18 Sep 2025, at 22:05, Brian Stansberry via wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; wrote: > > > > > > > > > > > > > > > > > > > > > > > I'm proposing we significantly expand the set of people who have write permissions to the wildfly/wildfly GitHub repo. The following folks are all experienced WildFly developers who act as a component lead for components in the WFLY JIRA project, but they don't have write permissions to the > > main server code repository: > > > > Tomasz Adamski > > Jean Francois Denise > > Emmanuel Hugonnet > > Rado Husar > > Tom Jenkinson > > Jason Lee > > Scott Marlow > > Eduardo Martins > > Brad Maxwell > > Matěj Novotny > > Richard Opalka > > Harald Pehl > > Flavia Rainone > > Marco Sappe Griot > > > Big thumb up for this list. > > Jeff > > > > > > -- > Jeff Mesnil > Software Engineer > Red Hat JBoss EAP > http://jmesnil.net/ > > IBM > > Unless otherwise stated above: > > Compagnie IBM France > Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex > RCS Nanterre 552 118 465 > Forme Sociale : S.A.S. > Capital Social : 664 614 175,50 € > SIRET : 552 118 465 03644 - Code NAF 6203Z -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His _______________________________________________ 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...