[development] taking a break

[Chad Phillips -- Apartment Lines]

On Jul 1, 2007, at 4:20 PM, walkah wrote:

> IMNSHO, the issue we're facing right now is not that Dries is  
> failing or
>  we need to add more Dries - but rather we need some stronger support
> around him.

...snip...

>> more time can be created by having more responsible parties.
>
> Now, here I agree with you... but 'responsible' != 'final say'.

...snip...

> So we need a
> way where we can distribute the load a bit - so that Dries has a  
> sort of
> 'executive overview' - and can help guide in the early stages of  
> patches

what you're outlining would be a good step, _if_ there are clear  
protocols for this setup, and those protocols are well-known to the  
community.  we as developers should know what to expect from the  
process of trying to get something committed to core, otherwise  
things can get very discouraging.

to take the deletion api as a case study, although i had not received  
direct input from dries, i was still getting input from steven and  
chx on my work -- two well-respected members of the community, one of  
whom is a core committer and 'right hand man' (not to mention quite a  
few usability reviews from other respected coders).  i thought this  
was enough guidance, but i was mistaken.  when steven committed the  
patch, again i assumed that the change was 'official', and put in  
another 30 hours of work on documentation, bugfixes, and conversion  
patches.  but again i was mistaken.

i may be wrong -- but i don't think my assumptions were way off-base,  
and yet the whole thing became a big ol' mess.  i'm not saying that  
we need to have some highly restrictive structure in place -- but at  
least enough of one that a developer has confidence that they're  
taking the right steps to move in the right direction as they  
continue to work on their code.  i don't think that's too much to  
ask.  :)

> Dries has expressed to me more than once a frustration that not enough
> people are focused on core. I've heard from some of the people that I
> suspect Dries would like to focus on core that there are issues that
> make it hard, difficult or unpleasant for them to do so.

and this is a very clear sign that we need to make adjustments --  
people on both sides are frustrated!

one more point about having 'final say', which is mostly  
theoretical.  final say on commits is certainly another level of  
responsibility than just being able to commit.  that level of  
responsibility has it's own challenges and lessons that are not  
available at lower levels.  while it might introduce other issues,  
more people having final say would result in more experience for more  
top-level people.  i won't argue if the benefits outweigh the costs  
-- just seems like something worth considering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070701/e7adac1d/attachment-0001.htm