[development] Very concerned over Drupal's core development

[Neil Drumm]

I'm not going to pretend I read this whole thread, these are some general
thoughts on this discussion. I don't have a lot of answers. We should
understand why this situation exists before attempting to solve it.
I have not contributed a lot to Drupal 7. I didn't contribute a lot to
Drupal 6, but that was because I was spending more time on Drupal 5. I can't
blame this on the process, I'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.

We should focus on removing barriers and pain points, not adding complexity.
Many minor changes are better than major changes.

The current bottleneck does seem to be reviewing, not committing. Planning
out big changes is hard, but that might be okay.

UI makes a big difference. Issue tags changed how people structure their
attention. Flag integration will remove subscribe noise. We haven't tested
testing in a code freeze situation. More problems should be found and
improved.

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.

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't know what/if structural changes would be ideal.

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.

Adding subsystem maintainers might be helpful, as long as we remember that
writing and committing are different processes.

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.

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.

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.

More features and APIs, not necessarily modules, should go into core, we are
too reliant on contrib.

Substantive things to do to help are:
- Review patches and look for annoyances in the process.
- Contribute to the Drupal.org redesign,
http://groups.drupal.org/drupalorg-redesign-implementers.
- Contribute to project module, http://drupal.org/project/project.
- If you are serious about changes, go ahead and do the work. If it works,
we can codify it.

-Neil


-- 
Neil Drumm
http://delocalizedham.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090420/91579bf0/attachment-0001.htm>