Josepha 12:01 am on February 3, 2021

Committers, Maintainers, and Emeriti

Every year (generally around November/December), team reps from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and related contributor teams review the list of contributors noted as committers and component maintainers. This yearly review helps keep our list of committers/maintainers current, so that any contributor can ask them for guidance and assistance.

This year, I would like to move some of the committers who no longer participate actively in core development to an emeritus status. The emeritus position has been a frequent topic of discussion in my time in the project, and I think this change would benefit WordPress in several ways.

Having a larger percentage of active contributors in these lists will help new contributors succeed in getting the help they need.
Having active vs. emeritus status for Core will let all active contributors know which areas need additional support.
Having an emeritus status shows our commitment to the idea that contributors can participate as much or as little as they are able at all levels.

Over the course of February, I will reach out to committers we haven’t seen activity from lately— e.g., those without commits in the past 12 months or activity in Make or SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.—and update their commit access in Core. If at any time in the future emeritus contributors are able to contribute actively again, then I think it would be appropriate simply to restore their commit access in Core.

Emeritus committers can, and should, feel comfortable supporting other contributors as a leading voice, since we all do benefit greatly from their long-term knowledge.

Let me know in the comments if you have any questions I haven’t answered about this process!

Jb Audras 12:28 am on February 3, 2021

Thank you for putting this together Josepha.
I believe this proposal would be a great enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to the project’s structuration and it would be a great help for release coordinators/squads.
Joe McGill 12:34 am on February 3, 2021

I think this is a great suggestion, and one that will make it easier to see which areas of WordPress are in need of new contributors to help out. One question about your proposal:

If at any time in the future emeritus contributors are able to contribute actively again, then I think it would be appropriate simply to restore their commit access in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

To be clear, are you proposing that folks who move to Emeritus status would have their commit access revoked? Or are you just meaning to imply that they would be marked as an “inactive committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.” for administrative purposes?
- Josepha 6:41 pm on February 3, 2021
  
  I had planned to revoke it, but you’re bringing up a suggestion that I hadn’t considered. Is one way safer or more secure than the other?
  - Joe McGill 9:28 pm on February 3, 2021
    
    If security is the priority, limiting commit access to only those who are actively committing code makes sense. However, I don’t think I’d frame this in terms of a “security” issue.
    
    The way I understand the proposal, the primary motivation is to make it clear who is regularly contributing and seeing where there are gaps. If that’s the objective, then I think revoking commit access could discourage people from volunteering to take on an emeritus status when they otherwise might do so—undermining the objectives of this effort.
    - John Blackbourn 10:44 pm on February 3, 2021
      
      I agree, although I think if a committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. hasn’t committed in a number of years then it’s also sensible to revoke their commit access for security purposes.
      
      But for they purpose of this exercise, which is to increase the percentage of active contributors, retaining commit access makes sense.
      - Josepha 7:59 pm on February 4, 2021
        
        For ultimate transparency, when I say “increase the percentage”, the first step is by decreasing the number of inactive folks. Next step is to add new contributors who are currently active.
        
        John James Jacoby 12:52 am on February 8, 2021
        
        Maybe it’s because I’m ripe for this list based on the current proposal, but I’m not a fan. 🤣
        
        The components I help maintain received explicit feedback that they were not priorities, that work should not be done to them, and energy should be put towards GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ instead – no one ever circled back around to unfreeze these components.
        
        I’m happy to call it a misunderstanding on my part, but my not committing is largely based on being told not to. 😅
        
        Josepha 11:42 pm on February 10, 2021
        
        There are a couple of things in there, but I do want to address one that’s probably at the front of many minds.
        
        I know that there was a collective call to work on GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, and that some of our committers (to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and elsewhere) became inactive during that time. The inactivity isn’t an indication of any committers having done something wrong, and I hope it doesn’t seem that way when I say it.
        
        I think it will be easier for folks who are active in current projects to know who can help them if we do this, though. Does the path back to committership (which is really just saying “I want to commit something”) feel like a big ask?
  - Peter Wilson 11:38 pm on February 11, 2021
    
    I think this is a good suggestion and agree with both revoking commit and listing inactive contributors as emeritus would provide clarity to newer contributors.
    
    In terms of terming someone as inactive, I’d consider tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. alongside SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., Make and the act of committing. I think it would address @johnjamesjacoby‘s concern about contributors actively providing feedback. I also suspect this was in consideration but simply missed in the text of the proposal.
    
    In an ideal world, commit wouldn’t be revoked but I think the security benefits outweigh the potential for negative perceptions. The fewer accounts with commit, the lower the chance of a successful brute-force attack, etc.
  - Drew Jaynes 1:06 am on February 12, 2021
    
    I share some of the concerns raised here by Joe and JJJ, in particular.
    
    My understanding was that commit access itself would never be revoked without cause. Remove the title or change it to Emeritus or whatever but I would expect to keep the commit privileges I earned as long as it’s not a security risk. 😉
    
    I’m hardly what you would consider to be an “active” committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. these days, though I have committed one or two docs- or tests-related changes in recent memory. I also still follow the same security guidelines that were expected of me when I was active; that’s never changed.
    
    Along the same vein as JJJ, a lot of us felt like we were asked to put our components on hold and that’s a contributing factor to why so many of the “old” coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers went silent in the first place.
    
    I think there’s definitely a case to be made for making this an administrative change only if that makes it easier to promote the cause of earning commit access. Actually revoking commit privileges I think would be a reversal from what was promised.
Mike Schroder 5:17 am on February 12, 2021

If a primary concern is security / attack surface area, I agree that it makes sense to physically remove access after some amount of time. A year or two makes sense to me.

Otherwise, this section on “Dormant Committers” is generally what I think about when considering removing commit (linked rather than quoted to avoid making this even longer).

I think it’s reasonable to consider any of the primary methods of communication when deciding someone is truly inactive/emeritus, which it sounds like what is what is being suggested. In my mind, that’d include Commit, Make, SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., and GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ in terms of deciding activity.

It might be good to reach out to folks who are on the edge to find out what their plans are, and to explain to them when they are removed how they can activate commit again if they want to.

On the first two points in the post:
It’s unclear to me whether Commit is being combined with Maintainer a little in some of the concerns listed. Is the main issue being addressed that folks don’t know who to reach out to for feedback, that folks don’t know who to contact to commit something, or both?

I think the “Maintainers” list is currently some mix of actively-involved-in-this-release folks, folks in the middle — helping out on and off, but not in a release focus, and folks that are mostly listed more for “if context is needed, I’m still willing to be contacted.”

I wonder if adding more granularity in the Maintainers list (maybe even notes from maintainers directly!) to make it clear what folks would like to be contacted about + their current involvement would help with that clarity.

On the third:

3. Having an emeritus status shows our commitment to the idea that contributors can participate as much or as little as they are able at all levels.

I don’t think I understand this point entirely. I feel like if the goal is to help folks contribute as much or little as they are able to, then access to commit shouldn’t be removed for inactivity’s sake alone. This adds another barrier to those folks for contribution.
Aaron D. Campbell 6:22 pm on February 12, 2021

I’m in favor of having an “Emeritus committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.” role. I think the biggest concern seems to be how this will affect someone’s perceived trust, reputation, authority/leadership, etc. All things that we’ve historically tied to commit. And I don’t think any of those should be affected by moving to emeritus status. You’ve earned commit and done nothing to lose it – you don’t need to re-earn it, just ask and get it back. The voices on the emeritus list should carry no less weight than they did before. For example, I think they should be able to be a second committer sign-off on a commit – these are people we trust to make those decisions and to know when they’re not informed enough to do so.

I see how this has the potential of making it easier for people looking for a committer to find someone to help them. How it could ultimately result in a more organized structure in the project – which I think we need. Organizationally I do not think any of this actually requires turning off the technical commit access – however…

Turning off commit: I definitely take a pretty security-first approach here. I don’t think this is really directly related to being emeritus, but I do think that if someone isn’t using their commit, it makes sense to turn it off. Yes there are other fail-safes in place to prevent commit alone from being able to do damage to a huge percentage of the internet (a separate access for build, and a separate access for auto-updates), but we should err on the side of caution here. This doesn’t mean that the person has lost any trust, just that we are being cautious with unused access. The process for having commit turned back on should in no way be the same as it was to earn it originally – it should just be to ask and it gets turned back on.
- Ipstenu (Mika Epstein) 8:37 pm on February 12, 2021
  
  I second what Aaron said regarding the removal from a security aspect. The ‘promise’ of commit access does come with the reciprocity of ‘it’ll be used.’ The longer anyone goes without being involved, the more likely it is that they will be making decisions and actions based on out of date methods. Our processes do change, after all, and we have a responsibility to the users of WordPress that should be above and beyond this promise. Without users, we are nothing 🙂
  
  Now that said, we should have a clearly defined definition. If we’re saying “going forward, commit access is incumbent on active participation in these ways…” then we must, out of both respect to the people with access and the promises made to them, be clear and up-front with what the project’s expectations are for this.
  
  I don’t know if there’s ever a good way to reach out to someone and ask if they’re going to come back. No matter how I think to phrase it, I look at it and know it’s going to hurt someone’s feelings. But… I believe it’s a necessary thing for both security and progress overall. (I do not envy whomever’s going to craft that email!)
  
  I’m interested to see how other open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects handle this at scale. If you’re in a company, it’s pretty easy (if you don’t work here, you don’t have access). We can’t do that with Open Source without defining what ‘work here’ means, but maybe we can glean insight as to how our friends do things, and use that as basis for change.
Kåre Mulvad Steffensen 9:20 pm on February 16, 2021

As a dormant maintainer myself, I’m happy to see a status like this.

I have no wish for keeping any type of access that I don’t actively use – and once earned rights are not forgotten if an Ex Officio title is bestowed upon the likes of me.

It holds all the meaning my work into WordPress stands for. Not for the earned power of commit rights – but for the long-lasting commitment to a platform that I acknowledge will keep growing even after I delivered my “masterpiece of work” into the machinery 😉
Andrew Nacin 7:49 pm on February 20, 2021

Denoting some committers as active and some as dormant/inactive/emeriti seems like a great idea!

I really don’t think commit access should be revoked. Even when I was active, I would routinely point to Karl Fogel’s writings on this topic, which @mikeschroder also referenced above:

“If the main criterion for granting commit access is good judgement, then why assume someone’s judgement would deteriorate just because she’s been away from the project for a while? Even if she completely vanishes for years, not looking at the code or following development discussions, when she reappears she’ll know how out of touch she is, and act accordingly. You trusted her judgement before, so why not trust it always? If high school diplomas do not expire, then commit access certainly shouldn’t.”

I also don’t know that the security argument is particularly compelling. Strengthening overall authentication on .org has been a separate priority for some time which seems important. But we also have some additional protections in place specifically for committers. That said, if we decide to want to remove an inactive committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.’s access for security reasons, then I would recommend detaching that from any other effort, and allow it to be reinstated at any time, no questions asked.

Comments are closed.

Welcome!

Communication

Committers, Maintainers, and Emeriti

Welcome!

Communication

Share this: