[development] Drupal development maintenance teams
drupal-devel at webchick.net
Tue Apr 28 21:07:27 UTC 2009
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
* 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
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.
More information about the development