James Walker wrote:
On 21-Feb-08, at 7:57 AM, Moshe Weitzman wrote:
FYI, what Karoly proposes is exactly how the Mozilla project works. Each patch needs a "super review" from a fixed (but large) list of reveiwers. See http://www.mozilla.org/hacking/
Those who have bothered to stick around and listen long enough while I ramble will know that I'm actually in favor of this kind of approach. I think it has several benefits :
* Clear responsibility - in case of questions, complications, etc - the "buck stops" at a defined point for resolution.
* Allows for "domain experts" - very frequently patches come in that can have tricky, subtle implications for some of the more complicated systems (menu, formapi, search etc etc etc) and it's *really* hard (frankly too much to ask) for the few core committers to have comprehensive understanding of all of Drupal at this level.
But we already have this, albeit more informally: - OpenID patches don't get committed until you've looked them over. - Actions patches don't get committed until John VanDyk has chimed in. - chx or pwolanin need to look at menu system patches. - Jeff Eaton or chx need to approve FAPI patches. - Barry or Frando need to thumbs-up Schema API changes. - merlinofchaos and dvessel are in charge of theming-related changes. - quicksketch is the Drupal JS master. And so on. MAINTAINERS.txt /already/ means something. The vast majority of patches, however, are not directly related to these types of low-level changes that require specific domain knowledge; they're string fixes, or usability improvements, or logic fixes, or simple new features, and so on. Being able to rely the "wisdom of crowds" in the larger community to handle tasks like reviewing patches and changing issue statuses is a /good/ thing. Further, I think Mozilla's model works because of the Mozilla Foundation, and the Mozilla Corporation. MoFo directly gets involved in setting directions and policies of development and MoCo has employees who are paid to oversee certain aspects of the code base. Drupal, by contrast, is a flat-hierarchy, bazaar-style project, with no one entity controlling the direction or governance of the project's development. The Drupal Association is removed from setting this type of direction, by design. It's the textbook case of herding cats. ;) Therefore, we need a completely different model: it's 100% in our best interest to *spread around* the domain knowledge and development process as much as possible, rather than entrusting it to a small handful of people. We have absolutely no guarantees that domain experts will remain as such. merlinofchaos might leave the Drupal community to become a world-renowned novelist, or quicksketch might take off and go backpacking around Europe for a year. When our menu system maintainer went AWOL, our only recourse was to start over completely over from scratch again. We should do everything we can to ensure that this does /not/ happen again. -Angie