Django

Code

Show
Ignore:
Timestamp:
06/17/07 17:18:54 (2 years ago)
Author:
clong
Message:

per-object-permissions: Merged to trunk [5486] NOTE: Not fully tested, will be working on this over the next few weeks.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • django/branches/per-object-permissions/docs/contributing.txt

    r4242 r5488  
    123123      tracker apply correct syntax highlighting, which is quite helpful. 
    124124 
    125     * Put the prefix "[patch] " before the title of your ticket. This will make 
    126       it obvious that the ticket includes a patch, and it will add the ticket 
    127       to the `list of tickets with patches`_. 
     125    * Check the "Has patch" box on the ticket details. This will make it 
     126      obvious that the ticket includes a patch, and it will add the ticket to 
     127      the `list of tickets with patches`_. 
    128128 
    129129    * The code required to fix a problem or add a feature is an essential part 
     
    152152don't meet all the requirements of a `good patch`_. 
    153153 
    154 One way to help out is to *triage* bugs that have been reported by other users. 
    155 Pick an open ticket that is missing some details, and try to replicate the 
    156 problem. Fill in the missing pieces of the report. If the ticket doesn't have 
    157 a patch, create one. 
    158  
    159 Once you've completed all the missing details on the ticket and you have a 
    160 patch with all the required features, e-mail `django-developers`_. Indicate 
    161 that you have triaged a ticket, and recommend a course of action for dealing 
    162 with that ticket. 
    163  
    164 At first, this may require you to be persistent. If you find that your triaged 
    165 ticket still isn't getting attention, occasional polite requests for eyeballs 
    166 to look at your ticket may be necessary. However, as you earn a reputation for 
    167 quality triage work, you should find that it is easier to get the developers' 
    168 attention. 
     154One way to help out is to *triage* bugs that have been reported by other 
     155users. A couple of dedicated volunteers work on this regularly, but more help 
     156is always appreciated. 
     157 
     158Most of the workflow is based around the concept of a ticket's "triage stage". 
     159This stage describes where in its lifetime a given ticket is at any time. 
     160Along with a handful of flags, this field easily tells us what and who each 
     161ticket is waiting on. 
     162 
     163Since a picture is worth a thousand words, let's start there: 
     164 
     165.. image:: http://media.djangoproject.com/img/doc/djangotickets.png 
     166   :height: 451 
     167   :width: 590 
     168   :alt: Django's ticket workflow 
     169 
     170We've got two roles here: 
     171 
     172    * Core developers: people with commit access who make the decisions and 
     173      write the bulk of the code. 
     174 
     175    * Ticket triagers: community members who keep track of tickets, making 
     176      sure the tickets are always categorized correctly. 
     177 
     178Second, note the four triage stages: 
     179 
     180    1. A ticket starts as "Unreviewed", meaning that a triager has yet to 
     181       examine the ticket and move it along. 
     182 
     183    2. "Design decision needed" means "this concept requires a design 
     184       decision," which should be discussed either in the ticket comments or on 
     185       django-developers. 
     186 
     187    3. Once a ticket is ruled to be approved for fixing, it's moved into the 
     188       "Accepted" stage. This stage is where all the real work gets done. 
     189 
     190    4. If a ticket has an associated patch (see below), a triager will review the 
     191       patch. If the patch is complete, it'll be marked as "ready for checkin" so 
     192       that a core developer knows to review and check in the patches. 
     193 
     194The second part of this workflow involves a set of flags the describe what the 
     195ticket has or needs in order to be "ready for checkin": 
     196 
     197    "Has patch" 
     198        This means the ticket has an associated patch_. These will be 
     199        reviewed to see if the patch is "good". 
     200 
     201    "Needs documentation" 
     202        This flag is used for tickets with patches that need associated 
     203        documentation. Complete documentation of features is a prerequisite 
     204        before we can check a fix into the codebase. 
     205 
     206    "Needs tests" 
     207        This flags the patch as needing associated unit tests. Again, this is a 
     208        required part of a valid patch. 
     209 
     210    "Patch needs improvement" 
     211        This flag means that although the ticket *has* a patch, it's not quite 
     212        ready for checkin. This could mean the patch no longer applies 
     213        cleanly, or that the code doesn't live up to our standards. 
     214 
     215A ticket can be resolved in a number of ways: 
     216 
     217    "fixed" 
     218        Used by one of the core developers once a patch has been rolled into 
     219        Django and the issue is fixed. 
     220 
     221    "invalid" 
     222        Used if the ticket is found to be incorrect or a user error. 
     223 
     224    "wontfix" 
     225        Used when a core developer decides that this request is not 
     226        appropriate for consideration in Django. This is usually chosen after 
     227        discussion in the ``django-developers`` mailing list, and you should 
     228        feel free to join in when it's something you care about. 
     229 
     230    "duplicate" 
     231        Used when another ticket covers the same issue. By closing duplicate 
     232        tickets, we keep all the discussion in one place, which helps everyone. 
     233 
     234    "worksforme" 
     235        Used when the triage team is unable to replicate the original bug. 
     236 
     237If you believe that the ticket was closed in error -- because you're 
     238still having the issue, or it's popped up somewhere else, or the triagers have 
     239-- made a mistake, please reopen the ticket and tell us why. Please do not 
     240reopen tickets that have been marked as "wontfix" by core developers. 
    169241 
    170242.. _required details: `Reporting bugs`_ 
    171243.. _good patch: `Patch style`_ 
     244.. _patch: `Submitting patches`_ 
    172245 
    173246Submitting and maintaining translations 
     
    187260 
    188261.. _Django i18n mailing list: http://groups.google.com/group/django-i18n/ 
    189 .. _i18n documentation: http://www.djangoproject.com/documentation/i18n/ 
     262.. _i18n documentation: ../i18n/ 
    190263 
    191264Coding style 
     
    207280      for details. 
    208281 
     282    * Please don't put your name in the code you contribute. Our policy is to 
     283      keep contributors' names in the ``AUTHORS`` file distributed with Django 
     284      -- not scattered throughout the codebase itself. Feel free to include a 
     285      change to the ``AUTHORS`` file in your patch if you make more than a 
     286      single trivial change. 
     287 
     288Template style 
     289-------------- 
     290 
    209291    * In Django template code, put one (and only one) space between the curly 
    210292      brackets and the tag contents. 
     
    218300          {{foo}} 
    219301 
     302View style 
     303---------- 
     304 
    220305    * In Django views, the first parameter in a view function should be called 
    221306      ``request``. 
     
    231316              # ... 
    232317 
    233     * Please don't put your name in the code. While we appreciate all 
    234       contributions to Django, our policy is not to publish individual 
    235       developer names in code -- for instance, at the top of Python modules. 
     318Model style 
     319----------- 
     320 
     321    * Field names should be all lowercase, using underscores instead of 
     322      camelCase. 
     323 
     324      Do this:: 
     325 
     326          class Person(models.Model): 
     327              first_name = models.CharField(maxlength=20) 
     328              last_name = models.CharField(maxlength=40) 
     329 
     330      Don't do this:: 
     331 
     332          class Person(models.Model): 
     333              FirstName = models.CharField(maxlength=20) 
     334              Last_Name = models.CharField(maxlength=40) 
     335 
     336    * The ``class Meta`` should appear *after* the fields are defined, with 
     337      a single blank line separating the fields and the class definition. 
     338 
     339      Do this:: 
     340 
     341          class Person(models.Model): 
     342              first_name = models.CharField(maxlength=20) 
     343              last_name = models.CharField(maxlength=40) 
     344 
     345              class Meta: 
     346                  verbose_name_plural = 'people' 
     347 
     348      Don't do this:: 
     349 
     350          class Person(models.Model): 
     351              first_name = models.CharField(maxlength=20) 
     352              last_name = models.CharField(maxlength=40) 
     353              class Meta: 
     354                  verbose_name_plural = 'people' 
     355 
     356      Don't do this, either:: 
     357 
     358          class Person(models.Model): 
     359              class Meta: 
     360                  verbose_name_plural = 'people' 
     361 
     362              first_name = models.CharField(maxlength=20) 
     363              last_name = models.CharField(maxlength=40) 
     364 
     365    * The order of model inner classes and standard methods should be as 
     366      follows (noting that these are not all required): 
     367 
     368        * All database fields 
     369        * ``class Meta`` 
     370        * ``class Admin`` 
     371        * ``def __str__()`` 
     372        * ``def save()`` 
     373        * ``def get_absolute_url()`` 
     374        * Any custom methods 
     375 
     376    * If ``choices`` is defined for a given model field, define the choices as 
     377      a tuple of tuples, with an all-uppercase name, either near the top of the 
     378      model module or just above the model class. Example:: 
     379 
     380          GENDER_CHOICES = ( 
     381              ('M', 'Male'), 
     382              ('F', 'Female'), 
     383          ) 
    236384 
    237385Committing code 
     
    312460how to write new tests. 
    313461 
    314 .. _Testing Django applications: http://www.djangoproject.com/documentation/testing/ 
     462.. _Testing Django applications: ../testing/ 
    315463 
    316464Running the unit tests 
     
    322470 
    323471Yes, the unit tests need a settings module, but only for database connection 
    324 info -- the ``DATABASE_ENGINE``, ``DATABASE_USER`` and ``DATABASE_PASSWORD``. 
    325 You will also need a ``ROOT_URLCONF`` setting (its value is ignored; it just 
    326 needs to be present) and a ``SITE_ID`` setting (any integer value will do) in 
    327 order for all the tests to pass. 
     472info -- the ``DATABASE_NAME`` (required, but will be ignored), 
     473``DATABASE_ENGINE``, ``DATABASE_USER`` and ``DATABASE_PASSWORD`` settings. You 
     474will also need a ``ROOT_URLCONF`` setting (its value is ignored; it just needs 
     475to be present) and a ``SITE_ID`` setting (any integer value will do) in order 
     476for all the tests to pass. 
    328477 
    329478The unit tests will not touch your existing databases; they create a new 
     
    439588change the symlink to point to the old code. 
    440589 
     590A third option is to use a `path file`_ (``<something>.pth``) which should 
     591work on all systems (including Windows, which doesn't have symlinks 
     592available). First, make sure there are no files, directories or symlinks named 
     593``django`` in your ``site-packages`` directory. Then create a text file named 
     594``django.pth`` and save it to your ``site-packages`` directory. That file 
     595should contain a path to your copy of Django on a single line and optional 
     596comments. Here is an example that points to multiple branches. Just uncomment 
     597the line for the branch you want to use ('Trunk' in this example) and make 
     598sure all other lines are commented:: 
     599 
     600    # Trunk is a svn checkout of: 
     601    #   http://code.djangoproject.com/svn/django/trunk/ 
     602    # 
     603    /path/to/trunk 
     604 
     605    # <branch> is a svn checkout of: 
     606    #   http://code.djangoproject.com/svn/django/branches/<branch>/ 
     607    # 
     608    #/path/to/<branch> 
     609 
     610    # On windows a path may look like this: 
     611    # C:/path/to/<branch> 
     612 
    441613If you're using Django 0.95 or earlier and installed it using 
    442614``python setup.py install``, you'll have a directory called something like 
     
    445617file. Then copy the branch's version of the ``django`` directory into 
    446618``site-packages``. 
     619 
     620.. _path file: http://docs.python.org/lib/module-site.html 
    447621 
    448622Official releases 
     
    549723.. _django-users: http://groups.google.com/group/django-users 
    550724.. _`#django`: irc://irc.freenode.net/django 
    551 .. _list of tickets with patches: http://code.djangoproject.com/report/12 
     725.. _list of tickets with patches: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=1&order=priority 
    552726.. _PEP 8: http://www.python.org/peps/pep-0008.html 
    553 .. _i18n documentation: http://www.djangoproject.com/documentation/i18n/ 
    554727.. _i18n branch: http://code.djangoproject.com/browser/django/branches/i18n 
    555728.. _`tags/releases`: http://code.djangoproject.com/browser/django/tags/releases