[development] Drupal development maintenance teams

[Angela Byron]

On 28-Apr-09, at 2:55 PM, larry at garfieldtech.com wrote:

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

I'm happy to add it to the handbook, if you want. Though I'm not sure  
I can speak for all core maintainers.

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

Well now we're really into a big philosophical discussion around why  
people contribute to open source projects. And there are a variety of  
reasons, each unique to each individual. Here are mine:

* I get a thrill out of collaborating together with other people  
smarter than me, and constantly learning new things as a result.  
Nothing else quite scratches that itch quite like Drupal core  
development.

* I have made lots of friends in the Drupal community, and want to  
continue to foster those relationships and build new ones.

* Drupal is the basis of my livelihood so I want to do whatever I can  
to make sure it continues to kick ass so I can stay fed. :)

As such, you'll find that almost everything I do outside of reviewing  
and committing patches is centered around leading initiatives to help  
grow the base of new contributors, raise visibility around the work  
going on in core, and provide better tools to help existing  
contributors to keep kicking ass.

Community initiative pages are part of those tools. Blogging around  
core development best practices is part of those tools. Keeping myself  
accessible 16-18 hours a day in IRC is part of those tools. All are  
focused on helping new contributors who are "core-curious" to get  
started, combined with increased visibility of various efforts so  
fewer things fall through the cracks, both of which lead to existing  
contributors getting a constant infusion of "new" blood and interest  
in their areas, which helps keep their morale/motivation/interest in  
the project high. Or, that's the theory, anyway.

By far, the most effective tool I've found so far is the patch review  
sprint. A funny thing happened over the weekend. With basically zero  
planning (a Drupal Planet post on Thursday night that said, "Hey,  
everyone. Show up in IRC this weekend!"), about 50 of us, including  
both core committers, knocked through 100+ patches that needed review.  
But the numbers, while impressive, are far less significant to me than  
what happened "on the ground" during the sprint.

What I noticed over and over again were those existing genius-level  
contributors hanging out, asking each other for the detailed technical  
reviews their patches were solely missing, and getting them. When new  
people would join and say, "Hey! I'm new! I'd like a patch to review,  
please!" the existing contributors would go get one of their long- 
lingering patches and say, "Great! Check this one out. Let me know if  
you have questions." All of a sudden, you saw these patches that had  
been stagnating have new life breathed into them by virtue of someone  
else paying attention. You also saw lots of mentorship taking place:  
"I don't really get how DBTNG works here. Can you explain it to me?"  
"Sure, how that works is..." You saw rapid turnaround from needs  
review -> needs work -> needs review -> RTBC -> commit.

It was, in short, Drupal core development at its very best.

So given the choice between:

a) completely uprooting our community's current way of doing things,  
spending lots of time/resources/energy on additional infrastructure to  
support this, and then debating ad infinitum what guidelines we need  
to put in place around these changes, all in the hopes that at the end  
we *might* provide some additional incentive for existing contributors

-or-

b) simply doing some basic community-building things that help  
facilitate getting good reviewers to look at good patches, which has  
the *demonstrated* effect of motivating existing contributors

...I prefer to do the latter.

-Angie