[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?
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
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.)
More information about the development