[wildfly-dev] Re: Additional mergers for the wildfly/wildfly GitHub repo

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/topic/... topic. 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-developers 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: -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His