[development] Drupal development maintenance teams

Sam Boyer drupal at samboyer.org
Tue Apr 28 14:24:46 UTC 2009

On Monday 27 April 2009 22:18:05 Karoly Negyesi wrote:
> > draw a roadmap. Rather, that they would take responsibility for
> > maintaining the issue queue--reviewing, improving, and refreshing
> > patches and being available to help issue submitters. Does a list of
> Wow, see Crell's mail, why? I see the world "responsibility" and frown.

Same here, chx. While I agree with Angie that low barriers for new 
contributors are a huge part of what makes us great & who we are, I think 
Larry's email highlights how we've failed to focus on lowering the barriers 
for existing contributors, especially the dedicated ones. We tend to come at 
these problems from the perspective of "how do we make this work for new 
contributors?", come up with something, then (usually tacitly) ask 
existing/dedicated contributors to adapt to that solution. I think this is one 
of those once-in-a-while cases where we need to be ok with reversing that 
order - think about things from the existing contributors' standpoint, then fit 
new contributors into that solution.

MAINTAINERS.txt is the perfect example. As Larry points out, he's in there 
twice, but doesn't have a clear idea about what it _means_ to be in there, in 
practical terms for his day-to-day work as a drupal dev. I'd argue that's 
because it doesn't have a clear, formal meaning for existing contributors. The 
only clear meaning is for new folks: it's the list of people to talk to if 
they have questions/issues/ideas related to a particular subsystem.

But most of what we've been talking about for the past week re: subsystem 
maintenance, core patch workflow, etc., aren't problems that are gonna be 
solved simply by increasing the eyeballs:code ratio. It's about organizing 
those new eyeballs - a job that's inevitably done by existing, dedicated 
contributors. So let's focus on their/our needs first, _then_ figure out how to 
make those solutions work for new contributors.

It's worth noting that this falls into the category of "problems that only 
healthy communities have." Only communities that with a systemic commitment to 
open participation, inclusivity, and taking care of new members can have 
problems like this. But it's also pretty typical for such communities to prize 
new members at the expense of existing ones, and I think we need to be more 
cognizant of that. We need to remain open to the energy and excitement of new 
people, but we also REALLY need to not kneecap the energy and excitement of 
the contributors we already have.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.drupal.org/pipermail/development/attachments/20090428/abffed8b/attachment.pgp>

More information about the development mailing list