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