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.
I wonder if the concerns about bottlenecks and decentralization could be addressed if Dries habitually marked some patches as "non-strategic" and left them to others. Perhaps then the "strategic" patches could get earlier feedback and guidance. Correcting bugs or code style could be considered "non-strategic", but of course the line can depend on a few things, not the least of which is the available time to spend.
Summary: This sounds like a bad idea. 1. Dries doesn't need a special status to prioritize the attention he gives to issues - he knows his priorities without changing a form element. 2. Dries' priorities aren't kept secret from the rest of us - he communicates them through drupal-dev emails, blog posts, issue queue updates, DrupalCon talks, etc. Pay particular attention to emails with subject lines like "code freeze - I think these issues are important". 3. Issue queue management will never be improved by adding more work to the core committers, of which there are only three on the development branch. It is a failing strategy. 4. Discussing issue queue strategy is rarely productive - like most Drupal issues imo, we don't need more talk, just more effort from the community. Non-committers need to step up to submit better patches and give better reviews, myself included. Case closed. Cog Rusty wrote:
I wonder if the concerns about bottlenecks and decentralization could be addressed if Dries habitually marked some patches as "non-strategic" and left them to others. Perhaps then the "strategic" patches could get earlier feedback and guidance.
Correcting bugs or code style could be considered "non-strategic", but of course the line can depend on a few things, not the least of which is the available time to spend.
On 7/1/07, Chris Kennedy <chrisken@mail.utexas.edu> wrote:
4. Discussing issue queue strategy is rarely productive - like most Drupal issues imo, we don't need more talk, just more effort from the community. Non-committers need to step up to submit better patches and give better reviews, myself included. Case closed.
I don't think this is going to be an easy discussion to end by simply declaring case closed. If the number of people contributing to Drupal stayed constant there's be something to this. We could all just focus in a do a better job. The problem is that we keep growing and successful past practices don't always scale well. There will need to be changes, I don't think anyone knows exactly what they are which is why we need to have this conversation rather than trying to stifle it. andrew
On Sunday 01 July 2007, andrew morton wrote:
On 7/1/07, Chris Kennedy <chrisken@mail.utexas.edu> wrote:
4. Discussing issue queue strategy is rarely productive - like most Drupal issues imo, we don't need more talk, just more effort from the community. Non-committers need to step up to submit better patches and give better reviews, myself included. Case closed.
I don't think this is going to be an easy discussion to end by simply declaring case closed. If the number of people contributing to Drupal stayed constant there's be something to this. We could all just focus in a do a better job. The problem is that we keep growing and successful past practices don't always scale well. There will need to be changes, I don't think anyone knows exactly what they are which is why we need to have this conversation rather than trying to stifle it.
andrew
Note that while there are 3 committers now, there are only 2 for most of the dev cycle. Gabor was appointed D6 maintainer late in the cycle. Perhaps naming a 3rd committer for D7 earlier would help, as there'd be another gate keeper earlier to keep the RTBC pile from getting too big? (Thus not scaring people into thinking that they have to RTBC quickly in order to even get looked at, which makes the committer job even harder, which... you get the idea.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
participants (5)
-
andrew morton -
Chad Phillips -- Apartment Lines -
Chris Kennedy -
Cog Rusty -
Larry Garfield