[development] Drupal development maintenance teams

[Nedjo Rogers]

Nathaniel Catchpole wrote:
> I agree with this - when I see other projects which seem to have
> defined teams for different areas, it puts me off them. If I'm
> interested in a couple of different areas do I have to join two teams,
> and possibly issue queues, mailing lists, groups?. That's how Joomla
> looks to me from the outside from what little I've seen. As soon as
> you have a team, you have something which requires hurdles in order to
> join - whether real or psychological.
>   
I agree that there are potential problems with formalized teams. I also
agree that improved infrastructure for seeing who's most active where
would be great.

Here's the specific issue as I see it. Currently, we have over 1,700
patches in the D7 queue . For most, the "patch bingo" system is probably
a good metaphor for their life cycle--it's largely a question of chance
whether their number will come up. If most patches sit there
indefinitely, nothing's gone wrong--it's just the way the system works.
A few contributions "float to the top", most are never resolved.

What I think we need is roles that contributors can grow into that take
responsibility for areas of the issue queue.

As I'm seeing it, the focus of teams would be managing the issue
queue--not guiding development. It would basically be people taking
responsibility to review, update, and refine patches in a given area. It
would be a role somewhat analogous to documentation admins on
drupal.org. Every community member can contribute documentation (can
submit patches and participate in the issue queue). A few have taken on
the added responsibility of editing and administering.

To contribute to development in an area, you'd in no way need to join a
team. The relatively small group of contributors who have no problem
finding their place and have a handle on most of core dev could continue
to do the amazing work they currently do. But the rest of us, who don't
spend most of our waking lives in #drupal (or if we do are in observer
mode), who don't know everyone and don't have our finger on the pulse of
core development, who would like to contribute but find the endless
issue queue daunting, who review issues here and there but never feel
much of a sense of progress, this rest of us, I believe, could use some
limited, simple, welcoming way to plug in.

I can't hope to keep up with all of core. But if I and six others took
responsibility for managing the core Javascript component issue queue, I
could indeed have a good hope of seeing that area's issues well managed.
I'd also be willing to be on call for contributors wanting help or
reviews of their patches in that area.

This approach wouldn't fix all of our challenges. Probably it wouldn't
help much in resolving large, complex patches that involve many parts of
core.

But would this - or some improved proposal - help bring the issue queue
into some reasonable shape? Would it reduce the life cycle of the
typical patch from "anyone's guess, come back in six months or a year"
to "usually dealt with within six weeks"? Would it encourage more
community members to step forward and take on specific responsibility
for manageable tasks in facilitating core development?

I don't know. But I'd like to find out.

Nedjo