As part of our efforts to manage technical debt in Drupal 8, we would like to formalize the role of core component maintainers listed in MAINTAINERS.txt.
Current definition
The community definition of the role is listed at: https://drupal.org/contribute/core-maintainers#component
Component maintainers oversee the development of parts of Drupal (also known as "subsystems"). They can make a shorter-term commitment to maintaining a subsystem, or a longer-term commitment that spans several major Drupal versions. Responsibilities of component maintainers (which can be divided amongst the maintainers of each subsystem) include:
- Monitoring their subsystem's issue queue (also known as "issue queue farming"). When a new issue is submitted, this involves verifying that it's a valid issue and taking appropriate action (tag as "Novice", change the status if more information is needed or if it's not really a bug, change other issue parameters, move it to a different issue queue, etc.).
- Mentoring new contributors who are working on issues related to that subsystem.
- Being the point of contact for that subsystem's contributors.
- Reviewing proposed patches to that subsystem.
- Acting as an expert on the workings of that subsystem (answering questions that come up, and being involved in discussions of major overhauls and re-architecting).
- Translating strategic thinking about their subsystem into actionable items and issues.
Most component maintainers start out contributing to their component by triaging issues, supplying patches, and reviewing others' patches. Then once a pattern of contribution and knowledge of that component is established, they can apply to become a component maintainer by posting an issue at http://drupal.org/node/add/project-issue/drupal to recommend themselves for MAINTAINERS.txt under the relevant subsystem.
The list of component maintainers for a particular version of Drupal is in the file MAINTAINERS.txt in the top-level Drupal directory for that version.
Proposed definition
Per @Dries, the definition for the component maintainer role should indicate that the component maintainers act as leaders in the given area and are responsible for ensuring certain things are done. They can either choose to do these tasks themselves, or organize other members of the community to do them.
Points to cover:
- Component maintainer responsibilities
- Process for adding a new component maintainere
- Process for stepping down as a component maintainer
- Process for updating MAINTAINERS.txt as needed for each release
Related issues
- #2046081: Add issue queue integration to formalize the role of core component maintainers
- #2046091: Add a view of issues per component
- #2050477: [META] Identify component maintainers for components with no maintainer listed in MAINTAINERS.txt
- #1854480: Remove inactive maintainers from MAINTAINERS.txt
Comments
Comment #0.0
xjmUpdated issue summary.
Comment #1
xjmComment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedMay I ask what is your agenda here? Because all the points listed here, other then the last two, are *already* listed in the handbook page you linked to. The current description of the role of the maintainer is exactly the one suggested by Dries.
So... what's up?
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedComment #4
xjmTo update the role of component maintainers based on our current expectations (which do not necessarily match that handbook page), to share this information with current component maintainers and ask them if they are interested in these responsibilites, and to add the policy to the core working group.
Comment #5
xjmAssigning to myself to clarify that this is something we're in the process of drafting and that there's specifics not yet reflected in the issue.
Comment #6
sunI'm sure @Crell would have a lot to say about this one.
Comment #7
xjmYep, @Crell has expressed a lot of interest in formalizing this.
Comment #7.0
xjmUpdated issue summary.
Comment #8
xjmHey, we can close this as a duplicate of #2457875: [policy] Evolving and documenting Drupal core's structure, responsibilities, and decision-making.
Comment #9
xjm