[development] taking a break
Chad Phillips -- Apartment Lines
chad at apartmentlines.com
Sun Jul 1 23:26:39 UTC 2007
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.
>> more time can be created by having more responsible parties.
> Now, here I agree with you... but 'responsible' != 'final say'.
> 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
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
> 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...
More information about the development