[development] Drupal development maintenance teams

[Larry Garfield]

On Sunday 26 April 2009 2:56:56 pm Nedjo Rogers wrote:
> 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

Nedjo, that's very closely related to my earlier comments.  The database 
subsystem already has this sort of setup, in practice.  (The team consists of 
myself, chx, DamZ, David Strauss, and Josh.)  However, it still doesn't 
address the point I raised before: Aside from bragging rights, what incentive 
is there for someone to want such a job?  

Let me give a concrete example:

http://drupal.org/node/432440

In that issue, we are discussing possible ways to improve schema API, 
specifically with regards to table modification statements.  There are two 
perfectly viable options available, each with pros and cons (listed).  It is a 
waste of my time or anyone else's to try to write code for it until we know 
which one we want to do, so "talk is silver code is gold" does not apply.  How 
do we decide which approach to take?

1) I, as DB maintainer, make an executive decision on which one to do and we 
do that (presumably based on what feedback we've gotten so far, which is not 
much).

2) The DB team (listed above) pow-wows somewhere and comes to a, executive 
decision, and we do that.

3) We sit and twiddle our thumbs and hope that people notice the issue enough 
to discuss it for 200 comments so that we have enough data points to be able 
to determine a majority consensus and then implement that, and pray that when 
Dries or webchick get to the issue they agree with whatever that decision was 
rather than kill the issue with the fatal "let's discuss this more" comment.

4) I kidnap webchick in IRC and talk for 2 hours, and explain every possible 
detail to her 3 times so that she groks it, then she makes a recommendation 
and I go code it and we hope that Dries agrees when he gets there.

Right now most issues follow #3.  For most of the DB layer I've tried to 
follow #4 in order to avoid the death by a thousand comments that is #3, but 
that can be quite time consuming and only works when both the branch 
maintainer (webchick) and I have 2 hours to spare in IRC.  (That's been less 
and less frequent of late.)  I really don't think #3 is going to continue to 
scale, in fact I think it has already ceased to scale.

However, I do not feel comfortable with #1 or #2 because I have no reason to 
believe that I have any actual authority, either individually or as part of 
the DB team, to make such decisions and not have to just redo everything 
later.  If that's not the case then I wish someone would tell me.

So before we talk about adding more people to MAINTAINERS.txt, we need to have 
a very clear, explicit understanding of what it means to be in 
MAINTAINERS.txt.  I am listed in there twice, and I have no clear idea what it 
actually means.  This is a problem. :-)

-- 
Larry Garfield
larry at garfieldtech.com