Looking at the list I see some people who no longer actively maintain WildFly or its components. Do we want to set some kind of time frame or some kind of way to clean up/remove maintainers who are not active? James R. Perkins Principal Software Engineer On Wed, Oct 29, 2025 at 2:24 PM Brian Stansberry <bstansberry(a)gmail.com&gt; wrote: > The GOVERNANCE.md for WildFly AS that we adopted last week includes a > "Maintainer" role. Alongside that GOVERNANCE.md we have a Team.md > where we'll list the people in the various roles. We need to populate > that document. > > I've sent up https://github.com/wildfly/wildfly-governance/pull/7 to > do that for the Maintainer role, plus a subset of those in the > 'Publisher' role -- those who publish the main wildfly/wildfly repo. > > Your inputs on this are most welcome! > > The GOVERNANCE.md defines Maintainers as: > > "Contributors eligible for write access to a code repository for a > WildFly Application Server project. Responsible for driving > initiatives and reviewing/merging contributions in their area of > expertise. Write access might be limited to particular repositories." > > So I started from the premise that our initial maintainers are those > who we've given write perms in the past. I did some tool-drive Github > inspection + discussion with various folks who deal with GH orgs where > my tool didn't work, plus some permission list cleanup discussions. > The resulting set of names is in the PR. > > Thank you to those of you who helped me with this! > > Going forward, before any grants write access to any of the dozens of > WF AS repos we should check that they are on the Maintainer list and > if not have a discussion to get them added. > > Best regards, > > Brian Stansberry > 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... > _______________________________________________ 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...

Okay, thanks for the clarification. I should have read the document again, but it was late and I'm making excuses for it :) James R. Perkins Principal Software Engineer On Thu, Oct 30, 2025 at 8:01 AM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: > During the governance discussions we discussed that people could propose > a cleanup. > > This was done to some extent as part of the work that went into the list > I submitted. It wasn't exhaustive. > > One thing though is being a Maintainer doesn't mean you have write perms > to any particular repository, or even to any repository. It means you have > the right to be given those (by the relevant repo admins) and that you can > perform the general duties of a Maintainer, e.g. "Responsible for > driving initiatives and reviewing/merging contributions in their area of > expertise". > > IOW repo admins can adjust who has write perms without removing people > from the Maintainer list. > > OTOH the opposite is not true -- repo admins cannot grant perms to > non-Maintainers; they have to start by getting people added. > > > On Wed, Oct 29, 2025 at 7:57 PM James Perkins via wildfly-dev < > wildfly-dev(a)lists.jboss.org&gt; wrote: > >> Looking at the list I see some people who no longer actively maintain >> WildFly or its components. Do we want to set some kind of time frame or >> some kind of way to clean up/remove maintainers who are not active? >> >> >> James R. Perkins >> >> Principal Software Engineer >> >> >> On Wed, Oct 29, 2025 at 2:24 PM Brian Stansberry <bstansberry(a)gmail.com&gt; >> wrote: >> >>> The GOVERNANCE.md for WildFly AS that we adopted last week includes a >>> "Maintainer" role. Alongside that GOVERNANCE.md we have a Team.md >>> where we'll list the people in the various roles. We need to populate >>> that document. >>> >>> I've sent up https://github.com/wildfly/wildfly-governance/pull/7 to >>> do that for the Maintainer role, plus a subset of those in the >>> 'Publisher' role -- those who publish the main wildfly/wildfly repo. >>> >>> Your inputs on this are most welcome! >>> >>> The GOVERNANCE.md defines Maintainers as: >>> >>> "Contributors eligible for write access to a code repository for a >>> WildFly Application Server project. Responsible for driving >>> initiatives and reviewing/merging contributions in their area of >>> expertise. Write access might be limited to particular repositories." >>> >>> So I started from the premise that our initial maintainers are those >>> who we've given write perms in the past. I did some tool-drive Github >>> inspection + discussion with various folks who deal with GH orgs where >>> my tool didn't work, plus some permission list cleanup discussions. >>> The resulting set of names is in the PR. >>> >>> Thank you to those of you who helped me with this! >>> >>> Going forward, before any grants write access to any of the dozens of >>> WF AS repos we should check that they are on the Maintainer list and >>> if not have a discussion to get them added. >>> >>> Best regards, >>> >>> Brian Stansberry >>> 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... >>> >> _______________________________________________ >> 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... >> > > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His >

Just an idea. We could have the concept of Historical Maintainers. Jakarta does this within its specifications https://projects.eclipse.org/projects/ee4j.jakartaee-platform/who is an example. I don't know that we plan to display this information anywhere or that we even want to do that, but just an idea.

James R. Perkins Principal Software Engineer On Thu, Oct 30, 2025 at 11:06 AM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: > No need to apologize; I'm glad you asked. I think this the most likely > discussion topic with this; whether we want to do any further review of > write perms and based on that reduce this initial list before merging it. > > We should do further review; that's good general practice. I don't know > if we'd end up wanting to remove people from this list based on that > though. I'll admit my opinion on that is based on perms scanning I and some > others did, and a tricky thing is I don't think it's good practice to > publish all those details. > > I'm also happy to answer any questions privately. > > On Thu, Oct 30, 2025 at 10:52 AM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> Okay, thanks for the clarification. I should have read the document >> again, but it was late and I'm making excuses for it :) >> >> >> James R. Perkins >> >> Principal Software Engineer >> >> >> On Thu, Oct 30, 2025 at 8:01 AM Brian Stansberry <bstansbe(a)redhat.com&gt; >> wrote: >> >>> During the governance discussions we discussed that people could >>> propose a cleanup. >>> >>> This was done to some extent as part of the work that went into the >>> list I submitted. It wasn't exhaustive. >>> >>> One thing though is being a Maintainer doesn't mean you have write >>> perms to any particular repository, or even to any repository. It means you >>> have the right to be given those (by the relevant repo admins) and that you >>> can perform the general duties of a Maintainer, e.g. "Responsible for >>> driving initiatives and reviewing/merging contributions in their area of >>> expertise". >>> >>> IOW repo admins can adjust who has write perms without removing people >>> from the Maintainer list. >>> >>> OTOH the opposite is not true -- repo admins cannot grant perms to >>> non-Maintainers; they have to start by getting people added. >>> >>> >>> On Wed, Oct 29, 2025 at 7:57 PM James Perkins via wildfly-dev < >>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>> >>>> Looking at the list I see some people who no longer actively maintain >>>> WildFly or its components. Do we want to set some kind of time frame or >>>> some kind of way to clean up/remove maintainers who are not active? >>>> >>>> >>>> James R. Perkins >>>> >>>> Principal Software Engineer >>>> >>>> >>>> On Wed, Oct 29, 2025 at 2:24 PM Brian Stansberry < >>>> bstansberry(a)gmail.com&gt; wrote: >>>> >>>>> The GOVERNANCE.md for WildFly AS that we adopted last week includes a >>>>> "Maintainer" role. Alongside that GOVERNANCE.md we have a Team.md >>>>> where we'll list the people in the various roles. We need to populate >>>>> that document. >>>>> >>>>> I've sent up https://github.com/wildfly/wildfly-governance/pull/7 to >>>>> do that for the Maintainer role, plus a subset of those in the >>>>> 'Publisher' role -- those who publish the main wildfly/wildfly repo. >>>>> >>>>> Your inputs on this are most welcome! >>>>> >>>>> The GOVERNANCE.md defines Maintainers as: >>>>> >>>>> "Contributors eligible for write access to a code repository for a >>>>> WildFly Application Server project. Responsible for driving >>>>> initiatives and reviewing/merging contributions in their area of >>>>> expertise. Write access might be limited to particular repositories." >>>>> >>>>> So I started from the premise that our initial maintainers are those >>>>> who we've given write perms in the past. I did some tool-drive Github >>>>> inspection + discussion with various folks who deal with GH orgs where >>>>> my tool didn't work, plus some permission list cleanup discussions. >>>>> The resulting set of names is in the PR. >>>>> >>>>> Thank you to those of you who helped me with this! >>>>> >>>>> Going forward, before any grants write access to any of the dozens of >>>>> WF AS repos we should check that they are on the Maintainer list and >>>>> if not have a discussion to get them added. >>>>> >>>>> Best regards, >>>>> >>>>> Brian Stansberry >>>>> 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... >>>>> >>>> _______________________________________________ >>>> 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... >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Architect, JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> > > -- > 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...