| 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. |
|---|
| | 154 | One way to help out is to *triage* bugs that have been reported by other |
|---|
| | 155 | users. A couple of dedicated volunteers work on this regularly, but more help |
|---|
| | 156 | is always appreciated. |
|---|
| | 157 | |
|---|
| | 158 | Most of the workflow is based around the concept of a ticket's "triage stage". |
|---|
| | 159 | This stage describes where in its lifetime a given ticket is at any time. |
|---|
| | 160 | Along with a handful of flags, this field easily tells us what and who each |
|---|
| | 161 | ticket is waiting on. |
|---|
| | 162 | |
|---|
| | 163 | Since 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 | |
|---|
| | 170 | We'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 | |
|---|
| | 178 | Second, 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 | |
|---|
| | 194 | The second part of this workflow involves a set of flags the describe what the |
|---|
| | 195 | ticket 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 | |
|---|
| | 215 | A 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 | |
|---|
| | 237 | If you believe that the ticket was closed in error -- because you're |
|---|
| | 238 | still 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 |
|---|
| | 240 | reopen tickets that have been marked as "wontfix" by core developers. |
|---|
| 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. |
|---|
| | 318 | Model 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 | ) |
|---|
| | 590 | A third option is to use a `path file`_ (``<something>.pth``) which should |
|---|
| | 591 | work on all systems (including Windows, which doesn't have symlinks |
|---|
| | 592 | available). 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 |
|---|
| | 595 | should contain a path to your copy of Django on a single line and optional |
|---|
| | 596 | comments. Here is an example that points to multiple branches. Just uncomment |
|---|
| | 597 | the line for the branch you want to use ('Trunk' in this example) and make |
|---|
| | 598 | sure 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 | |
|---|