[development] Core module maintainers

[Boris Mann]

On 8/2/07, Jeff Eaton <jeff at viapositiva.net> wrote:
> On Aug 2, 2007, at 10:01 PM, Larry Garfield wrote:
>
> > On Thursday 02 August 2007, Karoly Negyesi wrote:
> >
> >> On the other hand, having two people around is a good idea but
> >> even better
> >> would be clearly outlining what does it entail to be a (co-)
> >> maintainer...
> >
> > I highly agree with that statement, before I volunteer myself for
> > anything. :-)  (I suspect I'll fit the bill for the database system
> > in Drupal
> > 7, but not sure if I want to submit myself now.)

* Bookmark the issue queue
* Be up to date on your particular queue, and keep it to a dull roar
* raise a cry for alarm / marshall the trips to implement changes
and/or look at important stuff that is being proposed
* do a first pass on patches / features / bugs etc. -- delegate, deal
with, or defer
* help push the battle plan for your portion of core and how it
interacts with major API changes and the current cycle of development

Basically, it's much like maintaining a contrib module, except more
coordination. And a higher bar for what gets in.

> walkah and I have chatted about this several times as well, and I
> think a strong case can be made that a core maintainer is *NOT*
> necessarily the person writing all the patches and code for a
> particular portion of Drupal.

Well. Actually, unless we get twice the number of people sign up...I
kind of expect the bulk of work to be done by ~2 people. Or at least,
massage the patches that do show up.

The best maintainers will delegate most of this to folks in the queue
that are interested.

> Rather, a core maintainer (and their buddy) should be primarily
> responsible for maintaining architectural knowledge and working with
> other developers to mentor and 'sanity check' patches and
> improvements. When we have portions of core that only one developer
> understands well, it's a bad thing.
>
> Steven, a few months ago, commented in IRC that he would not write a
> particular search-related patch, because no one else understood the
> mechanics of the requested improvement.

And some more discussions with Steven to truly grok the danger of this
is in part what made me speak up again.

> That was a wise move: It is
> *more important* for multiple people to grok a change and understand
> its architectural impact than for any specific change to make it into
> core, no matter how cool or needed that change is.
>
> That, in turn, helps relieve some of the pressure on the maintainers
> to 'keep the patches flowing' when the most valuable knowledge they
> bring to the table is architectural understanding.

Padawan learners: earn your stripes by wicked pissah feedback on the
code you're working on.

-- 
Boris Mann
Office 604-682-2889
Skype borismann
http://www.bryght.com