Changeset 1857

Timestamp:

01/08/06 00:24:17 (3 years ago)

Author:

adrian

Message:

Added 'Committing code' section to docs/contributing.txt and made a few cleanups

Files:

• django/trunk/docs/contributing.txt (modified) (9 diffs)

django/trunk/docs/contributing.txt

@@ -18 +18 @@
-      patches`_, below, for details on how to submit a patch.
-
-
-
-
+
+
+
+
-
-That's all you need to know if you'd like to join the Django development
@@ -51 +52 @@
-
-    * **Don't** use the ticket system to make large-scale feature requests.
-
+elopers
-      list before actually working on them.
-
-    * **Don't** reopen issues that have been marked "wontfix". This mark means
-      that the decision has been made that we can't or won't fix this particular
-
+elopers
-
-    * **Don't** use the ticket tracker for lengthy discussions, because they're
-      likely to get lost. If a particular ticket is controversial, please move
-
+elopers
-
-Reporting security issues
@@ -168 +169 @@
-          {{foo}}
-
+Committing code
+===============
+
+Please follow these guidelines when committing code to Django's Subversion
+repository:
+
+    * Write detailed commit messages in the past tense, not present tense.
+
+          * Good: "Fixed bug in RSS API."
+          * Bad: "Fixes bug in RSS API."
+          * Bad: "Fixing bug in RSS API."
+
+    * For commits to a branch, prefix the commit message with the branch name.
+      For example: "magic-removal: Added support for mind reading."
+
+    * Limit commits to the most granular change that makes sense. This means,
+      use frequent small commits rather than infrequent large commits. For
+      example, if implementing feature X requires a small change to library Y,
+      first commit the change to library Y, then commit feature X in a separate
+      commit. This goes a *long way* in helping all core Django developers
+      follow your changes.
+
+    * For any medium-to-big changes, where "medium-to-big" is according to your
+      judgment, please bring things up on the `django-developers`_ mailing list
+      before making the change.
+
-Requesting features
-===================
@@ -174 +201 @@
-part of that. Here are some tips on how to most effectively make a request:
-
-`_, not in the ticket tracker; it'll get
-
+elopers`_, not in the ticket tracker;
+it'll get 
-
-    * Describe clearly and concisely what the missing feature is and how you'd
@@ -202 +229 @@
-encapsulated in a single patch, or changes that need multiple eyes on them --
-will have dedicated branches. See, for example, the `i18n branch`_. If you
- `django-dev`_ for
-
-
+
+
+for pretty much any kind of 
-
-We will only branch entire copies of the Django tree, even if work is only
@@ -214 +241 @@
-
-Once the branch is stable and ready to be merged into the trunk, alert
-
+elopers
-
-After a branch has been merged, it should be considered "dead"; write access to
@@ -286 +313 @@
-
-Whenever possible, we strive for a rough consensus. To that end, we'll often
-django-dev about a feature. In these votes we follow th
-
-
+`django-developers`_ about a feature. In these votes w
+
+votes are given 
-
-    * +1: "I love the idea and I'm strongly committed to it."
@@ -299 +326 @@
-      into reality."
-
-
+elopers
-seriously. After a suitable voting period, if an obvious consensus arises
-we'll follow the votes.
@@ -338 +365 @@
-.. _community page: http://www.djangoproject.com/community/
-.. _ticket tracker: http://code.djangoproject.com/newticket
-
+elopers
-.. _FAQ: http://www.djangoproject.com/documentation/faq/
-.. _search the tracker: http://code.djangoproject.com/search