[development] Drupal development maintenance teams

larry at garfieldtech.com larry at garfieldtech.com
Tue Apr 28 18:55:53 UTC 2009

Angela Byron wrote:
> On 28-Apr-09, at 1:54 PM, Derek Wright wrote:
>> On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote:
>>> 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.
>> Your whole message is right-on, but this is the "money quote".
> Sure, I don't think anyone would disagree with that.
> But can you help me understand how the community initiatives pages are 
> "kneecapping" existing contributors? As far as I'm concerned, they're 
> simply a public place to document all of the regular 
> brainstorming/organization that naturally happens over IRC, e-mail, and 
> g.d.o anyway among people who already make up the 'teams' that Nedjo is 
> proposing that we formalize in some way. If we add names to the pages, 
> then we get the added benefit of said people being publicly identified, 
> which helps them recruit others who share the same itch are looking for 
> someone to collaborate with.
> Seems win-win to me? Can you please enlighten me with a clue bat?
> -Angie

Sure, there's nothing wrong with clarifying who the "point people" are 
for a given initiative.  But that's not quite the point being raised.

chx's original email raised the issue that for any given subsystem in 
Drupal, there's only a handful of people who REALLY know it well enough 
to support it long term and we've done a rather poor job of adding 
people to that list overall.  How many people besides chx and eaton 
*really* grok FAPI?  There's what, 2-3 people who have any idea how 
Field API works?  DB API is up to *gasp* 5 people who should know it 
well, if we assume that those in MAINTAINERS.txt know a system well, 
which is quite high.

That means a very low "bus number", which is bad.

I countered with "what incentive is there for someone to grok a core 
system to that level of detail unless they've written it themselves?" 
(which is how all of the current domain experts, myself included, ended 
up with that level of knowledge).  Aside from the ego trip of saying 
"*I* have my name in MAINTAINERS.txt", there's little incentive for 
anyone else to become, say, a total theme system innards ninja.  OK if 
they need it specifically for their job they'll learn just enough for 
what they need by running through it in a debugger, but then they are 
unlikely to become a leader in that realm unless there's something in it 
for them.

To Sam's point, we focus on getting developers past the "I suck" 
threshold, but there's really not much encouragement to get people past 
the "I kick ass" threshold.  (See the chart below for what that means.) 
  And it's the people above that threshold who can act as leaders and 
teachers to increase our bus number.


Your earlier email about the "bat phone to the branch maintainer" was 
actually the first semi-official statement of what being a submaintainer 
actually means that I've heard since I became one.  OK, cool, so part of 
the incentive to become a domain expert is a quasi-veto on major changes 
to that area, and the ability to cut in line when vying for webchick's 
time.  How many people not reading this thread know that?

Are there other things we can do to encourage people to become domain 
experts besides give them a bat phone?  I'm not sure off hand, but 
that's the root of the problem that chx raised that has still not been 
addressed.  (Forks in the thread about moving things out of core to 
contrib are well and good but don't really address that problem.)

--Larry Garfield

More information about the development mailing list