Sustainable core (and contrib) maintainership
Problem
The current method of very limited core maintainers is often viewed as very limiting by those in the community. How can we more adapt the core contribution process to not make the process funnel through a few people? Dries' core conversation at DrupalCon Denver 2012 brought up several different options but we never really got to "discuss" them as a community. Are there technical or community hurdles to these options?
Goal
To come away from the session with one or two viable alternatives of core contribution and maintainership to discuss or continue with a full proposal. Our solution should not make our current contributing processes harder. It should allow both contributors and core committers to have easier lives. Is this possible or not? We shall discuss. Can these lessons also be brought to contrib?
Proposed Solution
Community-decided.
Comments
Dries has taken a direction for core maintainership that wasn't actually discussed at Denver--more of a natural iteration on the current model than anything new--and as a result we have an active core committer group that's 50% larger than it was in Dec. (from 4 to 6 people). The model of one release manager plus (potentially) multiple committers per branch is interesting. It widens the bottleneck a little and trades having the burden for each branch on two people for a need for trust and coordination between four. Can that model be expanded? By then David Rothstein and webchick can probably update us on how well it works for them internally.
And what about topical or component maintainership; whither MAINTAINERS.txt? Would empowering subsystem maintainers with commit access, pull requests, or whatever help keep them active? And what our the implications of a model like that for our review process, QA, and consistency with the Core Gates?
Should be a really interesting session. :)