[development] Drupal development maintenance teams

[Angela Byron]

On 27-Apr-09, at 9:11 AM, Nathaniel Catchpole wrote:

> 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.

200% agreed with this. The fact that it is effectively the community  
of active participants who draws the roadmap for each release of core  
by their actions (and that anyone at all can pick up a crayon and  
start drawing their own little part as well) is key to Drupal's  
strength as a community, which ties directly to its strength as a  
platform, imo. We need to keep that barrier to contributing as low as  
possible, and eliminate it entirely where we can.

> 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.

Here's a thought. (Note: I snipped the part about better statistics in  
catch's reply because although I would *love* to have those, that's an  
implementation project that's going to take awhile and I'm always more  
interested in things we can do *right now*.)

After about 50 iterations trying to figure out a way to have some sort  
of a bottom-up "Patch Spotlight"-esque thingy that allowed the  
community of participants to escalate what they think is important in  
each of their respective areas of interest, we came up with the Drupal  
core community initiatives section of the handbook at http://drupal.org/community-initiatives/drupal-core 
. It's awesome, because it allows me as a core committer to a) see  
what is on the minds of the people who tend to usability, i18n, JS,  
etc. so I can prioritize my time accordingly, and b) help guide new  
contributors who ask "I want to help out with X. Where do I start?" to  
issues that people in that "space" have identified as those that will  
have the largest impact.

(Of course, the section has its drawbacks as well. I's not promoted  
nearly enough, maintainers of these pages don't always keep them up to  
date, there's not a lot of structure (sort of by design, since I want  
each page to work best for the group of people managing it), and there  
are no subscription tools to get e-mail notifications and such. But it  
does have the advantage of actually *existing*! ;))

So what if we simply added a "This initiative is being led by X, Y, Z"  
line at the top of each page? Then we identify who to go to if you  
want to start working on i18n stuff, we do not have the concept of  
formal "teams" to join, anyone could at any time add their own name to  
the list f people managing X initiative, and we retain the ability for  
anyone to start their own campaign around improving Blog API module,  
for example.

And FWIW, what being in MAINTAINERS.txt means to me as a committer is  
that I don't commit patches that impact your area of expertise without  
talking to you first. If you ping me wanting to bounce around ideas  
for an hour about your area, barring some sort of client/family  
emergency, I make the time to talk with you. If someone comes to me  
and wants to get involved in your area, you're the person I direct  
them to. If you ping me and say "X has to go in," I move it to the top  
of my review list (as long as I have mental energy remaining, which  
has been painfully short as of late.. sorry yched/Barry :\). And so on.

I'm definitely NOT perfect, and sometimes I get distracted by other  
things or for am traveling which means I am not being as conscientious  
about keeping on top of core as I would normally be, but in general  
that's how I try and treat it: as giving those in MAINTAINERS.txt a  
"bat phone" to a core committer (and vice-versa) so that those  
important areas don't get stalled.

-Angie