From 136bf00615c3dadd697e746185f5c35258aa418a Mon Sep 17 00:00:00 2001 From: Jacob Kaplan-Moss Date: Wed, 29 Sep 2010 17:56:27 +0000 Subject: [PATCH] Additions to the contributing document explaining our new decision-making process. git-svn-id: http://code.djangoproject.com/svn/django/trunk@13962 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/contributing.txt | 96 ++++++++++++++++++++++++++------- 1 file changed, 76 insertions(+), 20 deletions(-) diff --git a/docs/internals/contributing.txt b/docs/internals/contributing.txt index 399e458c2a..6bf8aa1951 100644 --- a/docs/internals/contributing.txt +++ b/docs/internals/contributing.txt @@ -812,6 +812,42 @@ repository: Subversion and Trac so that any commit message in that format will automatically post a comment to the appropriate ticket. +Reverting commits +----------------- + +Nobody's perfect; mistakes will be committed. When a mistaken commit is +discovered, please follow these guidelines: + + * Try very hard to ensure that mistakes don't happen. Just because we + have a reversion policy doesn't relax your responsibility to aim for + the highest quality possible. Really: double-check your work before + you commit it in the first place! + + * If possible, have the original author revert his/her own commit. + + * Don't revert another author's changes without permission from the + original author. + + * If the original author can't be reached (within a reasonable amount + of time -- a day or so) and the problem is severe -- crashing bug, + major test failures, etc -- then ask for objections on django-dev + then revert if there are none. + + * If the problem is small (a feature commit after feature freeze, + say), wait it out. + + * If there's a disagreement between the committer and the + reverter-to-be then try to work it out on the `django-developers`_ + mailing list. If an agreement can't be reached then it should + be put to a vote. + + * If the commit introduced a confirmed, disclosed security + vulnerability then the commit may be reverted immediately without + permission from anyone. + + * The release branch maintainer may back out commits to the release + branch without permission if the commit breaks the release branch. + Unit tests ========== @@ -1159,11 +1195,8 @@ file. Then copy the branch's version of the ``django`` directory into .. _path file: http://docs.python.org/library/site.html -Deciding on features -==================== - -Once a feature's been requested and discussed, eventually we'll have a decision -about whether to include the feature or drop it. +How we make decisions +===================== Whenever possible, we strive for a rough consensus. To that end, we'll often have informal votes on `django-developers`_ about a feature. In these votes we @@ -1183,24 +1216,45 @@ Although these votes on django-developers are informal, they'll be taken very seriously. After a suitable voting period, if an obvious consensus arises we'll follow the votes. -However, consensus is not always possible. Tough decisions will be discussed by -all full committers and finally decided by the Benevolent Dictators for Life, -Adrian and Jacob. +However, consensus is not always possible. If consensus cannot be reached, or +if the discussion towards a consensus fizzles out without a concrete decision, +we use a more formal process. + +Any core committer (see below) may call for a formal vote using the same +voting mechanism above. A proposition will be considered carried by the core team +if: + + * There are three "+1" votes from members of the core team. + + * There is no "-1" vote from any member of the core team. + + * The BDFLs haven't stepped in and executed their positive or negative + veto. + +When calling for a vote, the caller should specify a deadline by which +votes must be received. One week is generally suggested as the minimum +amount of time. + +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". + +Whenever possible, these formal votes should be announced and held in +public on the `django-developers`_ mailing list. However, overly sensitive +or contentious issues -- including, most notably, votes on new core +committers -- may be held in private. Commit access ============= Django has two types of committers: -Full committers +Core committers These are people who have a long history of contributions to Django's - codebase, a solid track record of being polite and helpful on the mailing - lists, and a proven desire to dedicate serious time to Django's development. - - The bar is very high for full commit access. It will only be granted by - unanimous approval of all existing full committers, and the decision will err - on the side of rejection. - + codebase, a solid track record of being polite and helpful on the + mailing lists, and a proven desire to dedicate serious time to Django's + development. The bar is high for full commit access. + Partial committers These are people who are "domain experts." They have direct check-in access to the subsystems that fall under their jurisdiction, and they're given a @@ -1208,10 +1262,12 @@ Partial committers is likely to be given to someone who contributes a large subframework to Django and wants to continue to maintain it. - Like full committers, partial commit access is by unanimous approval of all - full committers (and any other partial committers in the same area). - However, the bar is set lower; proven expertise in the area in question is - likely to be sufficient. + Partial commit access is granted by the same process as full + committers. However, the bar is set lower; proven expertise in the area + in question is likely to be sufficient. + +Decisions on new committers will follow the process explained above in `how +we make decisions`_. To request commit access, please contact an existing committer privately. Public requests for commit access are potential flame-war starters, and will be ignored.