I&#39;m not going to pretend I read this whole thread, these are some general thoughts on this discussion. I don&#39;t have a lot of answers. We should understand why this situation exists before attempting to solve it.<div>
<br></div><div>I have not contributed a lot to Drupal 7. I didn&#39;t contribute a lot to Drupal 6, but that was because I was spending more time on Drupal 5. I can&#39;t blame this on the process, I&#39;ve worked with it and know how it works. The main factor is how I use my time, but the process does make a difference.</div>


<div><br></div><div>We should focus on removing barriers and pain points, not adding complexity. Many minor changes are better than major changes.</div><div><br></div><div>The current bottleneck does seem to be reviewing, not committing. Planning out big changes is hard, but that might be okay.</div>
<div><br></div><div>UI makes a big difference. Issue tags changed how people structure their attention. Flag integration will remove subscribe noise. We haven&#39;t tested testing in a code freeze situation. More problems should be found and improved.</div>


<div><br></div><div>I would like to see more quantitative data. Giant mailing list discussions have their place, but we need some way to test/prove/quantify/measure. Not everything can be quantified, but we should do something better than a big bag of opinions.</div>


<div><br></div><div>Structural changes are okay. We have gotten where we are with the same structure since 4.7, and that was simply adding another committer per-version. Something has been working, but the size and scope of the problem has changed. I don&#39;t know what/if structural changes would be ideal.</div>

<div><br></div><div>Adding more core committers without changing the structure would likely be good short-term, but we will run into the same situation later, that might be okay.</div><div><br></div><div>Adding subsystem maintainers might be helpful, as long as we remember that writing and committing are different processes.</div>
<div><br></div><div>Any additional committers need to be skilled willing volunteers with time. I am fine with the Dries chooses process. If you are seriously interested in filling a new position, you should already be doing what you want to do, then we remove a step from your process.</div>
<div><br></div><div>We should not make complex CVS branch/tag/repository systems. We should keep things simple and, if there are structural changes, consider moving to a distributed version control system.</div>
<div><br></div><div>API changes per year, reguardless of release cycle, should go down, which is a good thing. This is a more important measure than release cycle length.</div><div><br></div><div>More features and APIs, not necessarily modules, should go into core, we are too reliant on contrib.</div>
<div><br></div><div>Substantive things to do to help are:</div><div>- Review patches and look for annoyances in the process.</div><div>- Contribute to the Drupal.org redesign, <a href="http://groups.drupal.org/drupalorg-redesign-implementers">http://groups.drupal.org/drupalorg-redesign-implementers</a>.</div>
<div>- Contribute to project module, <a href="http://drupal.org/project/project">http://drupal.org/project/project</a>.</div><div>- If you are serious about changes, go ahead and do the work. If it works, we can codify it.</div>
<div><br></div><div>-Neil</div><div><br clear="all"><br>-- <br>Neil Drumm<br><a href="http://delocalizedham.com" target="_blank">http://delocalizedham.com</a><br>
</div>