On Mon, Apr 27, 2009 at 2:03 AM, Greg Knaddison wrote:
FWIW, I really like the current (somewhat chaotic) system without maintainers and teams. Teams in other projects strike me as something that creates a barrier to entry rather than increasing involvement. I like how anyone can show up and, with a few days of commenting/patching intelligently join a "team."
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. However, MAINTAINERS.txt is about the only place you can go to find out who's responsible for what. In reality you'd generally have to ask on irc or spend several hours trawling through the issue queue to see who's active in the different components - since according to our documentation most of them don't have a specific maintainer at all. That's also a big hurdle. Here's how I see the main issues at the moment: # It's hard or impossible to know who to speak to or where to start if you want to work on core - unless you come onto irc and ask at the right time. # Trying to document what's happening (patch spotlight, Drupal core initiatives) takes work to maintain, and presumably still requires a lot of research for someone new (compared to logging onto #drupal). # Even people who are listed as responsible already don't really know what it means. What I'd like to see, and this is somewhat repeating my comments on the reviews discussion is more stats. At the moment, Greg can scrape the commit logs and see who had the most patches committed - that's pretty much the only core stats we have. What'd be ideal is being able to see: Who's submitting patches. Who's patches are getting committed. Who's reviewing patches. All of these for across core and by component. Once we have that in a database somewhere, then we could also do things like compare within and across releases etc. That'd then give as an idea of who the 'contact module team' is and generally where people's efforts are focused. Most of the people listed in MAINTAINERS.txt are spread out between a lot of different places - this is a result both of core being very interdependent and the way core development works overall. While it's good that the database system has a few specific maintainers, it's also one of our most low-level and self-contained systems (partly a result of it being one of the newest), and it having be rewritten by one or two people from scratch. If you want to work on the areas which are neglected - say forum module, then you're immediately going to get into a tangle of dependent issues with comment, taxonomy, node, tracker, views in core. We list people multiple times in MAINTAINERS.txt - but I don't think this scales well, whether trying to add individual maintainers for those modules or build teams around them. The first step would be a more accurate picture of who's actually doing what where - if that ends up getting codified in MAINTAINERS.txt then fine. Nat