[development] Drupal development maintenance teams
drupal-devel at webchick.net
Mon Apr 27 18:45:55 UTC 2009
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
>> 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,
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.
More information about the development