[development] Subsystem maintainers or targeted committers?

[Jose A. Reyero]

I agree that Gabor has done a great job for these latest months and also
with the need of some kind of 'subsystem maintainers/targetted committers'.

But the thing is to have 'targetted committers' we firs need to have
something: goals and targets. And not individual ones, like it seems to
be now for each developer, but team goals/targets, so we can work as a
-big- team towards some common goals, and better focus time and energy.

So how about moving from this current time-based release cycles to
something at least a bit more 'feature driven'. How about having a
roadmap? And by 'a bit more' I mean we don't need to go with the same
'hardcoded' roadmap from beginning to end, but we could go through some
development/review cycles, addapting the roadmap as time passes and
having a time frame to fit the roadmap in.

For what we've seen these latest months, and for each previous release
too, but the issue gets bigger as Drupal grows, most of us have been
fighting some patches/features till the last minute before the code
freeze with better luck for some and worse for others.

Wouldn't have been much better if we had known before which ones were
getting in and which ones not so we could have better focused the huge
amount of time and energy?

So it could go like this:

0. We start with the big list of what everyone plans to do
1. Some time to get started with new patches/features and maybe for some
new ideas
2. Sometime towards the middle of the realease cycle we stop for a
minute and see which of the initial ideas are really in progress, what
we've got and what would be possible and also on which ones everybody
has more interest.

3. Then we put together a reduced list based on:
  - Progress
  - Interest
  - Time left

4. More development and discussion on the issue queue, but just around
the features left in the previous step

5. Time? Progress? (Back to 3, new 'reduced list'.)

We can go through one or more of this coding/review/restating targets
cycles till the end of the process (Drupal 7?). But the main idea is
that we won't be fighting our patches till the last minute, but we are
periodically re-aligning our attention and effort around just a few
issues left.

I don't know exactly which kind of tools we'd need to support such a
process, maybe a rating system for patches or features or how it will
work for many small -maybe depending on each other patches-. But I
really think we can better focus our efforts and try to avoid so much
time and work spent on things that finally didn't get in.

There are really some more things I wanted in Drupal 6, but had I known
in advance they weren't finally getting in maybe I could have worked on
someone else's patchs which I liked too....

Jose


Robert Douglass wrote:
> The link[1] Thomas Barregren posted was quite interesting. Indeed,
> Drupal seems to be experiencing some of the issues the Linux kernel
> faced some years ago, albeit not nearly as drastically. Reading
> through that post and the rest of the comments on the mailing list
> here bring me to some observations.
>
> 1. Gabor has done a great job. In particular, he has led the drive for
> i18n features in core. That's awesome.
> 2. Gabor came in almost as if he had a mandate to focus on #1, and
> indeed, he has focused nearly exclusively on #1.
> 3. Whether this was by accident or design, it worked well and would
> seem to be scalable and repeatable.
> 4. Dries could "scale" his vision of Drupal architecture by assigning
> more such targeted committers. He could say "Jeff Eaton... for D7,
> your job is to make sure the Data API gets in, and that it rocks." Or
> "KarenS, for D7, your job is to make sure CCK hits core, and that it
> rocks." Or "Earl Miles, get your query builder into core and
> integrated at a deep level, and make sure it rocks."
> 5. Whether or not the people in #4 get core commit privileges is
> nearly irrelevant (though I'd opt for them having commit privs, with
> the understanding that they were to be exercised on a limited domain
> of applicability only.) The important part would be that one person
> was understood to be "in charge" of the features. Any other developers
> wishing to see those features into core would have to work with the
> target committer, and the target committer would be responsible for
> tracking and coordinating the effort.
>
> We do this in a way now, so codifying it would only be a reinforcement
> of current patterns. Yet by making it formal we'd be enhancing the
> efficiency and scale of the operation. Such an approach may be the way
> in which we get high quality features into core while Dries maintains
> the overview and flexibility to do what he's been doing so well.
>
> -Robert
>
>
> [1] http://lkml.org/lkml/2002/1/28/83
>