Hi folks -- Starting today, we're going to be making some minor but significant changes to the way the Django core committer team "does business."
Put simply, we're changing the way we make decisions so that we can make important policy and design calls more quickly and easily. In a nutshell: * We're substantially reducing the number of decisions that Adrian and I need to make as BDFLs, thus removing us as a decision-making bottleneck. * We're cutting back on our reliance on consensus for decision making, thus ensuring that decisions can be made in a timely manner. * Finally -- and I think most importantly -- we're relaxing our policy on adding new core committers. I've just made a couple of changes [1] to our "Contributing to Django" guide [2] which explain these changes; read them if you want the short explanation of the new rules. [1] http://code.djangoproject.com/changeset/13962 [2] http://docs.djangoproject.com/en/dev/internals/contributing/ For those who've been following our development process closely -- and calling for these kind of changes for quite some time -- I'll explain some of the background and ramification in more detail below. Some background --------------- The discussion leading to these changes began with conversations Russ had at DjangoCon. I wasn't there, but he reported that there was a repeated and general dissatisfaction with the activity and responsiveness of the core team. I don't think this came as a surprise to any of us. I, at least, have felt like we've been lax in our responsibilities lately. Now, I don't really care to examine the merits of individual complaints or make excuses/explanations for the lack of time and attention the core team's been paying. Any way you cut it, it's clear that the core team -- and Adrian and I in particular -- have some work to do to regain the confidence and trust of the community. It's clear this won't happen overnight, and I don't expect the changes we're making today to magically grant us that confidence back. Instead, I see these changes as the first step in a general process towards more openness and inclusiveness in Django's development process. Making decisions ---------------- One of the main reasons we've ended up in this situation is our decision making process. When we first came up with Django's development process, Django was a tiny project with a handful of developers and a not-much-larger group of users. In that context, decision by consensus made some sense, but it simply doesn't scale as the number of participants increases. In particular, our reliance on consensus means that any developer can accidentally execute a veto simply by not having time to participate in discussions! We've always had the "out" of appealing to Adrian or I for a BDFL decision. However, that, too, did't scale as the number of decisions-to-be-made increased (and our own spare time decreased). So we've adopted a new, simple, streamlined voting process. This deals with situations where we can't reach a quick consensus, and it cuts out the requirement that Adrian and/or I rule on each and every decision. This new process allows a proposal to be carried if: * There are at least 3 "+1" votes from core committers. * There are no "-1" votes from core committers. * A BDFL hasn't issued a ruling on the issue. Since this process allows any core committer to veto a proposal, any "-1" votes (or BDFL vetos) should be accompanied by an explanation that explains what it would take to convert that "-1" into at least a "+0". More details are in the contributor doc, but in essence this means that we can move forward without needing to wait for the entire core team to weigh in. It does maintain our fairly skeptical attitude towards feature-creep by allowing any one contributor to object if something rubs him/her the wrong way, but it also forces that contributor to explain how she/he may be overruled. With luck, we'll see the pace of development speed up a bit as a result. I should stress that this voting procedure DOES NOT replace community discussion, nor does it remove entirely the desire for consensus. In other words, this new process is a new way to "break ties" without having to ask for a BDFL ruling. Whenever possible, we should continue to strive to reach consensus on issues, and use the voting process only as a fallback where consensus can't be reached for whatever reason. I, at least, plan to vote "-1" if I see community discussion being skipped, or if I see no attempt at consensus before a vote. Committers ---------- It's been clear for quite some time that there's a really right bottleneck at the top of the project: we simply don't have enough committers. The issue of adding new ones comes up fairly regularly, but has never come to any conclusion. We've deliberately set the bar for new contributors quite high: new committers required unanimous approval of all existing committers. We've resisted lowering that bar out of a fear that the quality of Django would degrade; we're quite proud that many users of Django run the latest trunk revision in production. However, like other decisions, requiring consensus simply stops scaling. Over the last year we've discussed a number of candidates for commit access, but many times failed to reach consensus often simply because not every committer was familiar with the candidate's work. Looking back, we all agree that we've failed to give the commit bit to some very deserving people. It's not that these folks failed to clear the bar; it's that we set the bar at an unobtainable height. So we're lowering the bar a bit: from now on, we'll decide on new committers using the same voting procedure described above. In essence, instead of unanimity we'll now simply require 3 champions and no strong votes against. This doesn't represent a huge change from our existing approach. No core committer will be committing big features without some sign-off and review from at least one other committer. No bug fixes will go in if we're not sure we've gotten it right. We'll continue to encourage new committers to "start small" and work up towards larger commits as the rest of the team gets to know their work. All that we're doing is making a change in our "default" opinion about proposed committers: instead of assuming that un-received votes are "no" votes, we're assuming that most committers will be happy to see new blood, forcing ourselves to articulate objections if they're serious. We've already started discussing a group of new committers under this policy, and the new process seems to be working out well. I expect we'll see some new names on the core committer list shortly. Actually, they won't be new names at all: anyone who's been around for a while will recognize these names. [If, when we add these new members, you don't see *your* name and think you should have, please let one of us know so we can discuss it with you and probably nominate you. Please do ask: we won't be able to intuit who's interested.] What's next ----------- Again, this is just the start of an ongoing process. For example, one of the things we haven't done well is to articulate exactly what our criteria for the commit bit ought to be. Our "we know it when we see it" policy doesn't set clear goals for community members who'd like to work towards commit, and we need to do a better job mentoring potential and new committers. We're going to continue to work on these areas, and on improving our process in general. If you have other suggestions please feel free to make 'em here -- we're listening. Thank you! Jacob PS: And if anyone feels uncomfortable raising process issues -- related or unrelated to the above -- please always feel free to contact me privately. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
