[development] Drupal development maintenance teams

[Nathaniel Catchpole]

On Mon, Apr 27, 2009 at 2:03 AM, Greg Knaddison wrote:

> FWIW, I really like the current (somewhat chaotic) system without
> maintainers and teams.  Teams in other projects strike me as something
> that creates a barrier to entry rather than increasing involvement. I
> like how anyone can show up and, with a few days of
> commenting/patching intelligently join a "team."

I agree with this - when I see other projects which seem to have
defined teams for different areas, it puts me off them. If I'm
interested in a couple of different areas do I have to join two teams,
and possibly issue queues, mailing lists, groups?. That's how Joomla
looks to me from the outside from what little I've seen. As soon as
you have a team, you have something which requires hurdles in order to
join - whether real or psychological.

However, MAINTAINERS.txt is about the only place you can go to find
out who's responsible for what. In reality you'd generally have to ask
on irc or spend several hours trawling through the issue queue to see
who's active in the different components - since according to our
documentation most of them don't have a specific maintainer at all.
That's also a big hurdle.

Here's how I see the main issues at the moment:

# It's hard or impossible to know who to speak to or where to start if
you want to work on core - unless you come onto irc and ask at the
right time.

# Trying to document what's happening (patch spotlight, Drupal core
initiatives) takes work to maintain, and presumably still requires a
lot of research for someone new (compared to logging onto #drupal).

# Even people who are listed as responsible already don't really know
what it means.

What I'd like to see, and this is somewhat repeating my comments on
the reviews discussion is more stats. At the moment, Greg can scrape
the commit logs and see who had the most patches committed - that's
pretty much the only core stats we have.

What'd be ideal is being able to see:

Who's submitting patches.
Who's patches are getting committed.
Who's reviewing patches.

All of these for across core and by component. Once we have that in a
database somewhere, then we could also do things like compare within
and across releases etc.

That'd then give as an idea of who the 'contact module team' is and
generally where people's efforts are focused.

Most of the people listed in MAINTAINERS.txt are spread out between a
lot of different places - this is a result both of core being very
interdependent and the way core development works overall. While it's
good that the database system has a few specific maintainers, it's
also one of our most low-level and self-contained systems (partly a
result of it being one of the newest), and it having be rewritten by
one or two people from scratch.

If you want to work on the areas which are neglected - say forum
module, then you're immediately going to get into a tangle of
dependent issues with comment, taxonomy, node, tracker, views in core.
We list people multiple times in MAINTAINERS.txt - but I don't think
this scales well, whether trying to add individual maintainers for
those modules or build teams around them. The first step would be a
more accurate picture of who's actually doing what where - if that
ends up getting codified in MAINTAINERS.txt then fine.

Nat