[development] Time to take away RTBC from every Joe

[Michael F]

Angie, excellent post.
I reviewed a patch earlier today, http://drupal.org/node/223549. It's a
no-duh usability patch that I highly approve of, but I hadn't yet looked at
the code, and even if I had, I'm not a coder by any means. So I said, yep, I
wish I could mark this RTBC but I can't.

But I looked at the code for the heck of it, and I saw that it was a one
word change- After to Before. If that's all it takes, it's an RTBC by my
standards, so I marked it RTBC.

I may be wrong on that, but if I don't have the ability to mark that RTBC,
then that's irrational. It's a simple change that was not getting a lot of
attention, and Usability is a high priority in D7. What's the point of
contributing if you can't make that simple change?

Sorry for the rant.

On Thu, Feb 21, 2008 at 1:37 PM, Angela Byron <drupal-devel at webchick.net>
wrote:

> 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
>
>


-- 
Sincerely,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080221/c3944b71/attachment.htm