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