Drupal development maintenance teams
Karoly's recent post to this list about stagnation in the core issue queue sparked a lot of good ideas and some great short term action, including this weekend's patch review sprint (yeah participants!). I want to follow up on one of the ideas--that we should consider new structures in our patch management and in particular look at building teams responsible for different areas of development. Of all the great ideas that came up, this is the one that I find the most exciting. In lots of ways it builds on what we're already doing elsewhere. Take code sprints--these are short term development teams, working together on a particular area of development. Or else consider the security team. Formal membership, clear mandate and responsibilities, and a great track record of members stepping up and capably doing the work. What would the equivalent be for core development? Here's the idea in a nutshell. Instead of the current situation, where it's pretty much every patch for itself, we have instead a team of maintainers for each area of core (mapped to the core "component" identified in project issues). For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list. Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help. A key advantage is that this approach wouldn't rely on big process or infrastructural changes. In many ways it's just a small step in the same direction we've been going. But, by enabling developers and contributors to take on formal responsibilities in patch management, it could have the potential to harness and coordinate our currently disparate efforts. Drupal development maintenance teams--an idea whose time has come? If so, what are our first steps to make it happen? Nedjo
On Sunday 26 April 2009 2:56:56 pm Nedjo Rogers wrote:
Karoly's recent post to this list about stagnation in the core issue queue sparked a lot of good ideas and some great short term action, including this weekend's patch review sprint (yeah participants!).
I want to follow up on one of the ideas--that we should consider new structures in our patch management and in particular look at building teams responsible for different areas of development. Of all the great ideas that came up, this is the one that I find the most exciting.
In lots of ways it builds on what we're already doing elsewhere. Take code sprints--these are short term development teams, working together on a particular area of development. Or else consider the security team. Formal membership, clear mandate and responsibilities, and a great track record of members stepping up and capably doing the work.
What would the equivalent be for core development?
Here's the idea in a nutshell. Instead of the current situation, where it's pretty much every patch for itself, we have instead a team of maintainers for each area of core (mapped to the core "component" identified in project issues).
For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list.
Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help.
A key advantage is that this approach wouldn't rely on big process or infrastructural changes. In many ways it's just a small step in the same direction we've been going. But, by enabling developers and contributors to take on formal responsibilities in patch management, it could have the potential to harness and coordinate our currently disparate efforts.
Drupal development maintenance teams--an idea whose time has come? If so, what are our first steps to make it happen?
Nedjo
Nedjo, that's very closely related to my earlier comments. The database subsystem already has this sort of setup, in practice. (The team consists of myself, chx, DamZ, David Strauss, and Josh.) However, it still doesn't address the point I raised before: Aside from bragging rights, what incentive is there for someone to want such a job? Let me give a concrete example: http://drupal.org/node/432440 In that issue, we are discussing possible ways to improve schema API, specifically with regards to table modification statements. There are two perfectly viable options available, each with pros and cons (listed). It is a waste of my time or anyone else's to try to write code for it until we know which one we want to do, so "talk is silver code is gold" does not apply. How do we decide which approach to take? 1) I, as DB maintainer, make an executive decision on which one to do and we do that (presumably based on what feedback we've gotten so far, which is not much). 2) The DB team (listed above) pow-wows somewhere and comes to a, executive decision, and we do that. 3) We sit and twiddle our thumbs and hope that people notice the issue enough to discuss it for 200 comments so that we have enough data points to be able to determine a majority consensus and then implement that, and pray that when Dries or webchick get to the issue they agree with whatever that decision was rather than kill the issue with the fatal "let's discuss this more" comment. 4) I kidnap webchick in IRC and talk for 2 hours, and explain every possible detail to her 3 times so that she groks it, then she makes a recommendation and I go code it and we hope that Dries agrees when he gets there. Right now most issues follow #3. For most of the DB layer I've tried to follow #4 in order to avoid the death by a thousand comments that is #3, but that can be quite time consuming and only works when both the branch maintainer (webchick) and I have 2 hours to spare in IRC. (That's been less and less frequent of late.) I really don't think #3 is going to continue to scale, in fact I think it has already ceased to scale. However, I do not feel comfortable with #1 or #2 because I have no reason to believe that I have any actual authority, either individually or as part of the DB team, to make such decisions and not have to just redo everything later. If that's not the case then I wish someone would tell me. So before we talk about adding more people to MAINTAINERS.txt, we need to have a very clear, explicit understanding of what it means to be in MAINTAINERS.txt. I am listed in there twice, and I have no clear idea what it actually means. This is a problem. :-) -- Larry Garfield larry@garfieldtech.com
3) We sit and twiddle our thumbs and hope that people notice the issue enough to discuss it for 200 comments so that we have enough data points to be able to determine a majority consensus and then implement that, and pray that when Dries or webchick get to the issue they agree with whatever that decision was rather than kill the issue with the fatal "let's discuss this more" comment.
... Could this problem be solved by some sort of semi regular developer companion/list/news/other subscribable thing/section on the website? A place that lists any issues, big developments related to core developments? This should be able to be done by people who are not coders too, so there may be a pool of followers out there who can help? It could help focus attention on issues that are not code related (or maybe even code related issues).
On Sun, Apr 26, 2009 at 1:56 PM, Nedjo Rogers <nedjo@islandnet.com> wrote:
For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list.
Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help.
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." The docs team is morphing and has moved to a more distributed model that allows anyone to maintain most of the pages in the handbook. I've heard several people say "well, I'm not on Drupal's core team so I can't be involved in developing patches." Of course I correct them that we have no such team and they are empowered to contribute just like everyone, but the "team/outsider" feeling persists based on false perceptions of the project. I wonder if there's something that can be done to provide greater recognition/control for individuals in certain areas without erecting this kind of false barrier. Another alternative would be to try out the team idea in one area - like i18n - and then re-evaluate for core in general based on the success of that pilot. Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
Greg, I totally understand your sentiment about "teams". However, if there are "leaders" in these areas, and the teams can be ad-hoc, how does that feel? The important thing, to me, is empowering more of the exceptional people in the community become stronger leaders (by vesting power and responsibility in them). Robert Douglass The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter Follow me on Twitter: http://twitter.com/robertDouglass On Apr 27, 2009, at 3:03 AM, Greg Knaddison wrote:
On Sun, Apr 26, 2009 at 1:56 PM, Nedjo Rogers <nedjo@islandnet.com> wrote:
For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list.
Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help.
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."
The docs team is morphing and has moved to a more distributed model that allows anyone to maintain most of the pages in the handbook.
I've heard several people say "well, I'm not on Drupal's core team so I can't be involved in developing patches." Of course I correct them that we have no such team and they are empowered to contribute just like everyone, but the "team/outsider" feeling persists based on false perceptions of the project.
I wonder if there's something that can be done to provide greater recognition/control for individuals in certain areas without erecting this kind of false barrier. Another alternative would be to try out the team idea in one area - like i18n - and then re-evaluate for core in general based on the success of that pilot.
Greg
-- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass <rob@robshouse.net> wrote:
Greg, I totally understand your sentiment about "teams". However, if there are "leaders" in these areas, and the teams can be ad-hoc, how does that feel? The important thing, to me, is empowering more of the exceptional people in the community become stronger leaders (by vesting power and responsibility in them).
That feels great. (But how is that different from the MAINTAINERS.txt we currently have?) Thanks, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
On Sunday 26 April 2009 8:27:36 pm Greg Knaddison wrote:
On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass <rob@robshouse.net> wrote:
Greg, I totally understand your sentiment about "teams". However, if there are "leaders" in these areas, and the teams can be ad-hoc, how does that feel? The important thing, to me, is empowering more of the exceptional people in the community become stronger leaders (by vesting power and responsibility in them).
That feels great. (But how is that different from the MAINTAINERS.txt we currently have?)
Thanks, Greg
See my replies in this thread and the previous one. Explain to me what MAINTAINERS.txt actually *means* in practice and then we can say how some other proposal would be different. -- Larry Garfield larry@garfieldtech.com
Quoting Larry Garfield <larry@garfieldtech.com>:
On Sunday 26 April 2009 8:27:36 pm Greg Knaddison wrote:
On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass <rob@robshouse.net> wrote:
Greg, I totally understand your sentiment about "teams". However, if there are "leaders" in these areas, and the teams can be ad-hoc, how does that feel? The important thing, to me, is empowering more of the exceptional people in the community become stronger leaders (by vesting power and responsibility in them).
That feels great. (But how is that different from the MAINTAINERS.txt we currently have?)
Thanks, Greg
See my replies in this thread and the previous one. Explain to me what MAINTAINERS.txt actually *means* in practice and then we can say how some other proposal would be different.
Is it a GNU requirement? Or perhaps it is an autoconf one. Or perhaps became popular because of Linux distributions have one. I find no requirement in the GNU standard. So as I see it MAINTAINERS.txt could be instructions for future maintainers of the project. Something that gives direction to future contributors. Or it could be a list of assigned people who have responsibilities in some area of Drupal project management. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
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
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
On 27-Apr-09, at 9:11 AM, Nathaniel Catchpole wrote:
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.
200% agreed with this. The fact that it is effectively the community of active participants who draws the roadmap for each release of core by their actions (and that anyone at all can pick up a crayon and start drawing their own little part as well) is key to Drupal's strength as a community, which ties directly to its strength as a platform, imo. We need to keep that barrier to contributing as low as possible, and eliminate it entirely where we can.
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.
Here's a thought. (Note: I snipped the part about better statistics in catch's reply because although I would *love* to have those, that's an implementation project that's going to take awhile and I'm always more interested in things we can do *right now*.) After about 50 iterations trying to figure out a way to have some sort of a bottom-up "Patch Spotlight"-esque thingy that allowed the community of participants to escalate what they think is important in each of their respective areas of interest, we came up with the Drupal core community initiatives section of the handbook at http://drupal.org/community-initiatives/drupal-core . It's awesome, because it allows me as a core committer to a) see what is on the minds of the people who tend to usability, i18n, JS, etc. so I can prioritize my time accordingly, and b) help guide new contributors who ask "I want to help out with X. Where do I start?" to issues that people in that "space" have identified as those that will have the largest impact. (Of course, the section has its drawbacks as well. I's not promoted nearly enough, maintainers of these pages don't always keep them up to date, there's not a lot of structure (sort of by design, since I want each page to work best for the group of people managing it), and there are no subscription tools to get e-mail notifications and such. But it does have the advantage of actually *existing*! ;)) So what if we simply added a "This initiative is being led by X, Y, Z" line at the top of each page? Then we identify who to go to if you want to start working on i18n stuff, we do not have the concept of formal "teams" to join, anyone could at any time add their own name to the list f people managing X initiative, and we retain the ability for anyone to start their own campaign around improving Blog API module, for example. And FWIW, what being in MAINTAINERS.txt means to me as a committer is that I don't commit patches that impact your area of expertise without talking to you first. If you ping me wanting to bounce around ideas for an hour about your area, barring some sort of client/family emergency, I make the time to talk with you. If someone comes to me and wants to get involved in your area, you're the person I direct them to. If you ping me and say "X has to go in," I move it to the top of my review list (as long as I have mental energy remaining, which has been painfully short as of late.. sorry yched/Barry :\). And so on. I'm definitely NOT perfect, and sometimes I get distracted by other things or for am traveling which means I am not being as conscientious about keeping on top of core as I would normally be, but in general that's how I try and treat it: as giving those in MAINTAINERS.txt a "bat phone" to a core committer (and vice-versa) so that those important areas don't get stalled. -Angie
Angela Byron wrote:
200% agreed with this. The fact that it is effectively the community of active participants who draws the roadmap for each release of core by their actions (and that anyone at all can pick up a crayon and start drawing their own little part as well) is key to Drupal's strength as a community, which ties directly to its strength as a platform, imo. We need to keep that barrier to contributing as low as possible, and eliminate it entirely where we can.
Thanks for your comments Angie. I agree that we don't want formal teams tasked with making roadmaps for given areas of core. So let me rephrase the idea. It's *not* that a maintenance team for e.g. Javascript would 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 people taking responsibility for working on an area of the core issue queue still seem like something that could be a barrier?
So what if we simply added a "This initiative is being led by X, Y, Z" line at the top of each page? Great idea, and basically an initial step towards Drupal development maintenance teams.
Nedjo
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.
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
On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote:
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.
Your whole message is right-on, but this is the "money quote". Thanks, -Derek (dww)
On 28-Apr-09, at 1:54 PM, Derek Wright wrote:
On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote:
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.
Your whole message is right-on, but this is the "money quote".
Sure, I don't think anyone would disagree with that. But can you help me understand how the community initiatives pages are "kneecapping" existing contributors? As far as I'm concerned, they're simply a public place to document all of the regular brainstorming/ organization that naturally happens over IRC, e-mail, and g.d.o anyway among people who already make up the 'teams' that Nedjo is proposing that we formalize in some way. If we add names to the pages, then we get the added benefit of said people being publicly identified, which helps them recruit others who share the same itch are looking for someone to collaborate with. Seems win-win to me? Can you please enlighten me with a clue bat? -Angie
Angela Byron wrote:
On 28-Apr-09, at 1:54 PM, Derek Wright wrote:
On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote:
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.
Your whole message is right-on, but this is the "money quote".
Sure, I don't think anyone would disagree with that.
But can you help me understand how the community initiatives pages are "kneecapping" existing contributors? As far as I'm concerned, they're simply a public place to document all of the regular brainstorming/organization that naturally happens over IRC, e-mail, and g.d.o anyway among people who already make up the 'teams' that Nedjo is proposing that we formalize in some way. If we add names to the pages, then we get the added benefit of said people being publicly identified, which helps them recruit others who share the same itch are looking for someone to collaborate with.
Seems win-win to me? Can you please enlighten me with a clue bat?
-Angie
Sure, there's nothing wrong with clarifying who the "point people" are for a given initiative. But that's not quite the point being raised. chx's original email raised the issue that for any given subsystem in Drupal, there's only a handful of people who REALLY know it well enough to support it long term and we've done a rather poor job of adding people to that list overall. How many people besides chx and eaton *really* grok FAPI? There's what, 2-3 people who have any idea how Field API works? DB API is up to *gasp* 5 people who should know it well, if we assume that those in MAINTAINERS.txt know a system well, which is quite high. That means a very low "bus number", which is bad. I countered with "what incentive is there for someone to grok a core system to that level of detail unless they've written it themselves?" (which is how all of the current domain experts, myself included, ended up with that level of knowledge). Aside from the ego trip of saying "*I* have my name in MAINTAINERS.txt", there's little incentive for anyone else to become, say, a total theme system innards ninja. OK if they need it specifically for their job they'll learn just enough for what they need by running through it in a debugger, but then they are unlikely to become a leader in that realm unless there's something in it for them. To Sam's point, we focus on getting developers past the "I suck" threshold, but there's really not much encouragement to get people past the "I kick ass" threshold. (See the chart below for what that means.) And it's the people above that threshold who can act as leaders and teachers to increase our bus number. http://buytaert.net/drupal-learning-curve Your earlier email about the "bat phone to the branch maintainer" was actually the first semi-official statement of what being a submaintainer actually means that I've heard since I became one. OK, cool, so part of the incentive to become a domain expert is a quasi-veto on major changes to that area, and the ability to cut in line when vying for webchick's time. How many people not reading this thread know that? Are there other things we can do to encourage people to become domain experts besides give them a bat phone? I'm not sure off hand, but that's the root of the problem that chx raised that has still not been addressed. (Forks in the thread about moving things out of core to contrib are well and good but don't really address that problem.) --Larry Garfield
On 28-Apr-09, at 2:55 PM, larry@garfieldtech.com wrote:
Your earlier email about the "bat phone to the branch maintainer" was actually the first semi-official statement of what being a submaintainer actually means that I've heard since I became one. OK, cool, so part of the incentive to become a domain expert is a quasi-veto on major changes to that area, and the ability to cut in line when vying for webchick's time. How many people not reading this thread know that?
I'm happy to add it to the handbook, if you want. Though I'm not sure I can speak for all core maintainers.
Are there other things we can do to encourage people to become domain experts besides give them a bat phone? I'm not sure off hand, but that's the root of the problem that chx raised that has still not been addressed. (Forks in the thread about moving things out of core to contrib are well and good but don't really address that problem.)
Well now we're really into a big philosophical discussion around why people contribute to open source projects. And there are a variety of reasons, each unique to each individual. Here are mine: * I get a thrill out of collaborating together with other people smarter than me, and constantly learning new things as a result. Nothing else quite scratches that itch quite like Drupal core development. * I have made lots of friends in the Drupal community, and want to continue to foster those relationships and build new ones. * Drupal is the basis of my livelihood so I want to do whatever I can to make sure it continues to kick ass so I can stay fed. :) As such, you'll find that almost everything I do outside of reviewing and committing patches is centered around leading initiatives to help grow the base of new contributors, raise visibility around the work going on in core, and provide better tools to help existing contributors to keep kicking ass. Community initiative pages are part of those tools. Blogging around core development best practices is part of those tools. Keeping myself accessible 16-18 hours a day in IRC is part of those tools. All are focused on helping new contributors who are "core-curious" to get started, combined with increased visibility of various efforts so fewer things fall through the cracks, both of which lead to existing contributors getting a constant infusion of "new" blood and interest in their areas, which helps keep their morale/motivation/interest in the project high. Or, that's the theory, anyway. By far, the most effective tool I've found so far is the patch review sprint. A funny thing happened over the weekend. With basically zero planning (a Drupal Planet post on Thursday night that said, "Hey, everyone. Show up in IRC this weekend!"), about 50 of us, including both core committers, knocked through 100+ patches that needed review. But the numbers, while impressive, are far less significant to me than what happened "on the ground" during the sprint. What I noticed over and over again were those existing genius-level contributors hanging out, asking each other for the detailed technical reviews their patches were solely missing, and getting them. When new people would join and say, "Hey! I'm new! I'd like a patch to review, please!" the existing contributors would go get one of their long- lingering patches and say, "Great! Check this one out. Let me know if you have questions." All of a sudden, you saw these patches that had been stagnating have new life breathed into them by virtue of someone else paying attention. You also saw lots of mentorship taking place: "I don't really get how DBTNG works here. Can you explain it to me?" "Sure, how that works is..." You saw rapid turnaround from needs review -> needs work -> needs review -> RTBC -> commit. It was, in short, Drupal core development at its very best. So given the choice between: a) completely uprooting our community's current way of doing things, spending lots of time/resources/energy on additional infrastructure to support this, and then debating ad infinitum what guidelines we need to put in place around these changes, all in the hopes that at the end we *might* provide some additional incentive for existing contributors -or- b) simply doing some basic community-building things that help facilitate getting good reviewers to look at good patches, which has the *demonstrated* effect of motivating existing contributors ...I prefer to do the latter. -Angie
There is actually a written statement that is quite old about what the MAINTAINERS.txt file is for. It has not been changed other then minor edits for years Created 2005, but existed before then). This page in it's original form was part of a longer page that Puregin created when we were breaking up the larger single pages that had existed previous to 2005. http://drupal.org/node/21778 Maintainer. Though not directly making decisions, maintainers have informal responsibility for a designated portion of the core (for example, a particular core module). Individual areas of responsibility are listed in the file MAINTAINERS.txt. Maintainers are appointed by Dries. Core contributors who have made substantive contributions (particularly to a core component not individually maintained) may apply for Maintainer status by writing to Dries. Dries may also individually invite them. So, Larry, now you know what historically had been expected from those listed in the Maintainers.txt. If this changes of course it will need to be updated to reflect those changes. I just noticed that someone changed the title recently. The title doesn't accurately reflect the contents and there is an issue regarding some other information on the page I am looking at. Steven On Tue, Apr 28, 2009 at 11:55 AM, larry@garfieldtech.com <larry@garfieldtech.com> wrote:
Angela Byron wrote:
On 28-Apr-09, at 1:54 PM, Derek Wright wrote:
On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote:
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.
Your whole message is right-on, but this is the "money quote".
Sure, I don't think anyone would disagree with that.
But can you help me understand how the community initiatives pages are "kneecapping" existing contributors? As far as I'm concerned, they're simply a public place to document all of the regular brainstorming/organization that naturally happens over IRC, e-mail, and g.d.o anyway among people who already make up the 'teams' that Nedjo is proposing that we formalize in some way. If we add names to the pages, then we get the added benefit of said people being publicly identified, which helps them recruit others who share the same itch are looking for someone to collaborate with.
Seems win-win to me? Can you please enlighten me with a clue bat?
-Angie
Sure, there's nothing wrong with clarifying who the "point people" are for a given initiative. But that's not quite the point being raised.
chx's original email raised the issue that for any given subsystem in Drupal, there's only a handful of people who REALLY know it well enough to support it long term and we've done a rather poor job of adding people to that list overall. How many people besides chx and eaton *really* grok FAPI? There's what, 2-3 people who have any idea how Field API works? DB API is up to *gasp* 5 people who should know it well, if we assume that those in MAINTAINERS.txt know a system well, which is quite high.
That means a very low "bus number", which is bad.
I countered with "what incentive is there for someone to grok a core system to that level of detail unless they've written it themselves?" (which is how all of the current domain experts, myself included, ended up with that level of knowledge). Aside from the ego trip of saying "*I* have my name in MAINTAINERS.txt", there's little incentive for anyone else to become, say, a total theme system innards ninja. OK if they need it specifically for their job they'll learn just enough for what they need by running through it in a debugger, but then they are unlikely to become a leader in that realm unless there's something in it for them.
To Sam's point, we focus on getting developers past the "I suck" threshold, but there's really not much encouragement to get people past the "I kick ass" threshold. (See the chart below for what that means.) And it's the people above that threshold who can act as leaders and teachers to increase our bus number.
http://buytaert.net/drupal-learning-curve
Your earlier email about the "bat phone to the branch maintainer" was actually the first semi-official statement of what being a submaintainer actually means that I've heard since I became one. OK, cool, so part of the incentive to become a domain expert is a quasi-veto on major changes to that area, and the ability to cut in line when vying for webchick's time. How many people not reading this thread know that?
Are there other things we can do to encourage people to become domain experts besides give them a bat phone? I'm not sure off hand, but that's the root of the problem that chx raised that has still not been addressed. (Forks in the thread about moving things out of core to contrib are well and good but don't really address that problem.)
--Larry Garfield
On Apr 28, 2009, at 11:35 AM, Angela Byron wrote:
can you help me understand how the community initiatives pages are "kneecapping" existing contributors?
For starters, because they're impossible to find. Maybe it's because it's after 4am and I've been rolling update.module patches[1] for the last few hours, but I just spent literally 10 minutes clicking around the handbooks, and I can't find these pages anywhere. That "Current Drupal core initiatives" link in the Contributor links block? Useless. No where under "Contribute", nor "Documentation", etc, etc. I only spent that long clicking around because not even googling for "site:drupal.org core initiatives" turns up anything (at least not in the first few pages). How is this helping anyone if I can't even find the pages to add one for update module? Much less how is anyone else going to help me with update module if they can't find the pages, either? -Derek (dww) p.s. Oh, google finally wins on "community initiatives" and I found it: http://drupal.org/community-initiatives *sigh* ;) Oh well, my energy to start an initiative page is totally spent for the night, hopefully in the near future... [1] for the interested reader: http://drupal.org/node/220592#comment-1532940 http://drupal.org/node/448268
This has been sitting in the queue to add a proper link in the sidebar for quite a long while: http://drupal.org/node/341070 - Addi On Apr 29, 2009, at 7:20 AM, Derek Wright wrote:
On Apr 28, 2009, at 11:35 AM, Angela Byron wrote:
can you help me understand how the community initiatives pages are "kneecapping" existing contributors?
For starters, because they're impossible to find. Maybe it's because it's after 4am and I've been rolling update.module patches[1] for the last few hours, but I just spent literally 10 minutes clicking around the handbooks, and I can't find these pages anywhere. That "Current Drupal core initiatives" link in the Contributor links block? Useless. No where under "Contribute", nor "Documentation", etc, etc. I only spent that long clicking around because not even googling for "site:drupal.org core initiatives" turns up anything (at least not in the first few pages).
How is this helping anyone if I can't even find the pages to add one for update module? Much less how is anyone else going to help me with update module if they can't find the pages, either?
-Derek (dww)
p.s. Oh, google finally wins on "community initiatives" and I found it:
http://drupal.org/community-initiatives
*sigh* ;) Oh well, my energy to start an initiative page is totally spent for the night, hopefully in the near future...
[1] for the interested reader: http://drupal.org/node/220592#comment-1532940 http://drupal.org/node/448268
On Wed, Apr 29, 2009 at 1:20 PM, Derek Wright <drupal@dwwright.net> wrote:
On Apr 28, 2009, at 11:35 AM, Angela Byron wrote:
can you help me understand how the community initiatives pages are "kneecapping" existing contributors?
For starters, because they're impossible to find. Maybe it's because it's after 4am and I've been rolling update.module patches[1] for the last few hours, but I just spent literally 10 minutes clicking around the handbooks, and I can't find these pages anywhere. That "Current Drupal core initiatives" link in the Contributor links block? Useless. No where under "Contribute", nor "Documentation", etc, etc. I only spent that long clicking around because not even googling for "site:drupal.org core initiatives" turns up anything (at least not in the first few pages).
How is this helping anyone if I can't even find the pages to add one for update module? Much less how is anyone else going to help me with update module if they can't find the pages, either?
I think the reason it is not properly linked in is that it does not have a huge history. It gained popularity when we introduced status level coloring and reporting in issue links as well as assignee info. Which makes assembling and maintaining such initiative pages much easier. They are after all organized and documented flows of issue links. Gábor
participants (15)
-
Addison Berry -
Angela Byron -
Derek Wright -
Earnie Boyd -
Greg Knaddison -
Gábor Hojtsy -
Karoly Negyesi -
Larry Garfield -
larry＠garfieldtech.com
-
Naheem Zaffar -
Nathaniel Catchpole -
Nedjo Rogers -
Robert Douglass -
Sam Boyer -
Steven Peck