On 8/2/07, Jeff Eaton <jeff@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