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