Committers may add subsystem maintainers

Problem/Motivation

• Core has many subsystems, including many that have too few maintainers.
• We can support subsystem maintainers by responding quickly when they volunteer to take on responsibility for a subsystem, and respect their efforts and time commitments by responding quickly when they choose to step down.
• The BDFL cannot always commit subsystem maintainer patches in a timely fashion.
• Core committers can generally assess a potential subsystem maintainer's contributions, agreement to the governance policy, and whether they have community support.

Proposed resolution

• Allow any committer to add subsystem maintainers, so long as the other maintainers for the subsystem and the community agree.
• Allow any committer to remove a subsystem maintainer at that maintainer's own request when they choose to step down.
• Per Dries, maintainer additions that do not have consensus still should be escalated to the BDFL, as should adding topic maintainers, initiative coordinators, or committers, as well as removing maintainers when it is not at their specific request.
• As with all areas of governance, the BDFL may also still overrule any decision.

Proposed additions to the core governance

If the change is adding additional maintainers, other maintainers for that area must be given opportunity to sign off.

If the change involves adding a new subsystem maintainer, a product, framework, or release manager must approve or refuse it (depending on the subsystem). (Any may commit a change to remove a subsystem maintainer at that maintainer's own request.)

If the change is adding new full or provisional core committers, initiative coordinators, or topic maintainers, the BDFL must approve or refuse it. The same is true if there is any cause for concern with adding a maintainer, or if the change involves removing a maintainer except at their specific request.