[development] taking a break

[Chad Phillips -- Apartment Lines]

i'd like to start by saying i appreciate that you're willing to  
discuss this and listen to feedback.

On Jul 1, 2007, at 6:00 AM, Dries Buytaert wrote:

> Furthermore, it is impossible for me to review every single patch  
> every time it was updated.  This means I'm forced to prioritize my  
> own code reviews, just like you or anyone else prioritizes yours.   
> I focus my time on patches (i) that people tell me are important or  
> (ii) that align well with my vision for Drupal.

do you think it's possible that it's better for the project if there  
were more than one person who had 'final say' on matters?  i  
understand that might occasionally mean that something important  
might not go the way you think it should.  i see myself as a bit of a  
control freak, so i understand why that might cause some  
discomfort  ;)  but beyond that discomfort and possibly some  
temporary misdirection, would that change be better for the project  
_overall_?

from your own blog entry on being a responsible maintainer:

"Well, we have to accept and acknowledge the fact that a project the  
size of Drupal is always going to be a bit broken, and that command  
and control won't cultivate the Drupal wilderness."

> Granted, sometimes important patches are neglected because they  
> have a high barrier to entry.  This is highly unfortunate and I try  
> to deal with those as time permits.

more time can be created by having more responsible parties.

> I try to review a lot of these patches.  Anyway, we're currently  
> nearing the code freeze, and people tend to forget about all other  
> patches except their own.

this may be an aside to the present discussion, but i've been quite  
pleased and surprised by the mutual co-operation that surrounded the  
deletion API patch.  by offering to review other's patches in  
exchange for their review of my work, progress was made in both  
directions.

futhermore, it generated legitimate personal interest from both  
parties in another's code that they may have otherwise never bothered  
to look at. i would highly encourage the patch review trade approach  
-- everybody wins.  :)

> These are inherently crazy times.  I don't know why, but sometimes  
> people think of the code freeze as the end of the world, and their  
> patch being the magic hero that comes in to save the world just in  
> time.  Of course, it is nothing like that, and there is nothing  
> wrong with patches being postponed.

i would agree that there is nothing wrong with a patch being  
postponed.  but the question is: what is a valid reason for  
postponing a patch?

i wouldn't say that a bottleneck in manpower is an invalid reason,  
but at the same time that should be a problem we can remedy. i've  
heard other devs comment, and i've seen it as well: there are an  
ungodly amount of patches in the queue that are RTBC, and are just  
sitting there, waiting for command control to take the next step.

> I agree with parts of the book patch, and I disagree with other  
> parts of the book patch.  Regardless my disagreements, I don't  
> think the book patch is super-high priority.  Frankly, there is no  
> harm done when the book improvements don't make it into Drupal 6.

i thought i heard it mentioned that these book improvements would  
help the drupal.org documentation effort a lot. if that's the case,  
then it does sound like there would be harm done.

> I care a lot about what the delete API tries to accomplish, and  
> that's why I think it is so important to do it right, and why I'm  
> not happy with a half-baked solution.

while i may sometimes disagree with the reasoning, i do appreciate  
the quality control.  but let's look a step deeper at what's happened  
here with this patch.

above you seem to indicate that the area i was working in was  
important for drupal, and yet the work received no attention from you  
during the development cycle. my repeated requests for your attention  
to it were met with "it's not high on my priority list".

this seems to be a fundamental contradiction.  above and beyond my  
personal frustration, it seems to indicate that you alone do not  
possess enough time to look at everything that's important, and yet  
you still maintain the only position of "final decision".  that  
sounds bad for the project to me.  i don't mean bad as in fatal, but  
more bad as in "we can do better".

so i'm just suggesting that you take a look at why you're still the  
only person with final say, and determine if that's the best policy  
going forward.  from my perspective, opening things up a bit more  
would result in less developer frustration, more quality code being  
produced, and more leaders being born. i think that's worth an  
occasional bump in the road that might get past you.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070701/3659cf58/attachment-0001.htm