On Monday 27 April 2009 22:18:05 Karoly Negyesi wrote:
draw a roadmap. Rather, that they would take responsibility for maintaining the issue queue--reviewing, improving, and refreshing patches and being available to help issue submitters. Does a list of
Wow, see Crell's mail, why? I see the world "responsibility" and frown.
Same here, chx. While I agree with Angie that low barriers for new contributors are a huge part of what makes us great & who we are, I think Larry's email highlights how we've failed to focus on lowering the barriers for existing contributors, especially the dedicated ones. We tend to come at these problems from the perspective of "how do we make this work for new contributors?", come up with something, then (usually tacitly) ask existing/dedicated contributors to adapt to that solution. I think this is one of those once-in-a-while cases where we need to be ok with reversing that order - think about things from the existing contributors' standpoint, then fit new contributors into that solution. MAINTAINERS.txt is the perfect example. As Larry points out, he's in there twice, but doesn't have a clear idea about what it _means_ to be in there, in practical terms for his day-to-day work as a drupal dev. I'd argue that's because it doesn't have a clear, formal meaning for existing contributors. The only clear meaning is for new folks: it's the list of people to talk to if they have questions/issues/ideas related to a particular subsystem. But most of what we've been talking about for the past week re: subsystem maintenance, core patch workflow, etc., aren't problems that are gonna be solved simply by increasing the eyeballs:code ratio. It's about organizing those new eyeballs - a job that's inevitably done by existing, dedicated contributors. So let's focus on their/our needs first, _then_ figure out how to make those solutions work for new contributors. It's worth noting that this falls into the category of "problems that only healthy communities have." Only communities that with a systemic commitment to open participation, inclusivity, and taking care of new members can have problems like this. But it's also pretty typical for such communities to prize new members at the expense of existing ones, and I think we need to be more cognizant of that. We need to remain open to the energy and excitement of new people, but we also REALLY need to not kneecap the energy and excitement of the contributors we already have. Sam