[development] Very concerned over Drupal's core development

[Tomáš Fülöpp (vacilando.org)]

I am in Drupal up to my eyebrows every day but still I am not finding enough
time for my few contrib modules, the less for the core patches. I am not
giving up though - the opposite, understanding more and more every day,
gearing up.

Even without being a current core or active contributor I too clearly see a
problem with the differing speeds of development of core and contrib, and I
very much agree with most of the refreshing proposals of Nedjo Rogers and
Robert Douglass above.

In general, I think that so powerfully creative and committed (!) people
should be given more rights and space for driving development in their areas
of expertise. It is sad to hear people who have made major contributions to
Drupal feel shackled.


Let me give two comments to Angie's otherwise good and useful reasoning:

Worse, because all of these subsystems were rapidly evolving within their
> own sphere, 20, 30, perhaps 50 patches committed per day, it's become
> impossible for anyone to oversee all of them; at best you have people
> inspecting one-off patches here and there. That means things like coding
> standards compliance, performance benchmarking, algorithm optimization, and
> the collective DX (not to mention UX) experience of Drupal 7 plummets.
> Drupal 7 is usable by chx, pwolanin, DamZ, catch, and about 20 other people,
> and everyone else switches to Django. ;)


I could read what you say as: "no commit rights because the group might not
be able to oversee the changes", hence "better slow and frustrating
development than fast and exciting one". That might finally stifle Drupal.

I firmly believe more coders would be attracted to providing and testing
patches if development took up speed in this way. Far too often we see
modules sprouting with the apologetic explanation that 'it would take too
long in core, see the patch xy that's laying there for months'.
Probably in this way the teams of interested coders-turning-experts you talk
about would naturally emerge from the exciting development activity in such
areas! Further, if the maintainers of subsystems had commit rights they
would probably be more motivated to manage and work with such teams, etc. Or
turn it around - how can we expect the most able developers be motivated to
do fantastic things in their areas of experience if they cannot commit them?


"But webchick!" I hear you say. "Obviously, we wouldn't let these subsystem
> maintainers work /completely/ bereft of peer review. We'd surely have
> someone else check over their work." And I say, "Great! Then *why aren't
> these mythical someones doing this right now*?" and *then* you get at what I
> believe is the /actual/ root of the problem. ;)


I think the development would speed up, and so those who want to follow
would have to keep the pace. Its a tax you pay for the exciting new
functionality and stability. It works in major and vital contrib modules, so
why not in such specialized areas of core? Problem of overseeing fast
changes is there at any speed of development. That can be mitigated by
increasing pressure for providing documentation and decision paths along
with the code. (Perhaps a condition like: you can commit in your area but
only with full documentation of not only the code but also your clearly
stated and referenced reasoning and immediate roadmap.)


As I said, I am determined to contribute much more than I have ever done, to
contrib, and to core. But I believe adding more rights to the biggest Drupal
coders as proposed above would greatly help me and everybody, and Drupal as
a project.


Anyways; back to coding!

See you around --

Tomáš

--
Tomáš Fülöpp (vacilando)
http://vacilando.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090420/a0f5e841/attachment.htm>