[development] Drupal development maintenance teams

[Nedjo Rogers]

Karoly's recent post to this list about stagnation in the core issue
queue sparked a lot of good ideas and some great short term action,
including this weekend's patch review sprint (yeah participants!).

I want to follow up on one of the ideas--that we should consider new
structures in our patch management and in particular look at building
teams responsible for different areas of development. Of all the great
ideas that came up, this is the one that I find the most exciting.

In lots of ways it builds on what we're already doing elsewhere. Take
code sprints--these are short term development teams, working together
on a particular area of development. Or else consider the security team.
Formal membership, clear mandate and responsibilities, and a great track
record of members stepping up and capably doing the work.

What would the equivalent be for core development?

Here's the idea in a nutshell. Instead of the current situation, where
it's pretty much every patch for itself, we have instead a team of
maintainers for each area of core (mapped to the core "component"
identified in project issues).

For each area, we have one or two leads--an expanded version of the
"maintainers" we already have designated for different areas of Drupal
core. These leads continue to be appointed by Dries. But instead of
being individually responsible for an area, these leads select and lead
a team of maintainers. These teams are managed a lot like the current
maintainers list.

Here's an idea of how it might work. Dries appoints an lead in a given
area, e.g., internationalization. That lead invites individuals with
proven expertise and a track record to become formal members of the
internationalization maintenance team, responsible for all issues in the
"multilingual support" and locale module components. Members of this
team are listed on a drupal.org page along with members of the other
members of the team. The basic responsibility of team members is to
review, update, and refine patches in their given areas until they are
closed. They can also take a step back as needed and evaluate overall
progress and needs in an area, prioritizing patches to review and
improve or creating new ones. Patch contributors can contact team
members directly to discuss their patches and get help.

A key advantage is that this approach wouldn't rely on big process or
infrastructural changes. In many ways it's just a small step in the same
direction we've been going. But, by enabling developers and contributors
to take on formal responsibilities in patch management, it could have
the potential to harness and coordinate our currently disparate efforts.

Drupal development maintenance teams--an idea whose time has come? If
so, what are our first steps to make it happen?

Nedjo