mirror of
https://github.com/django/django.git
synced 2025-04-15 04:44:37 +00:00
Removed references to the DDN triage state.
Rephrased "How can I help with triaging?" a bit to reflect the current practice.
This commit is contained in:
parent
ed576b69f9
commit
4a7292df3b
docs/internals
File diff suppressed because it is too large
Load Diff
Binary file not shown.
File diff suppressed because one or more lines are too long
Before (image error) Size: 23 KiB After (image error) Size: 18 KiB |
@ -140,12 +140,3 @@ FAQ
|
||||
Short answer: No. It's always better to get another set of eyes on a
|
||||
ticket. If you're having trouble getting that second set of eyes, see
|
||||
question 1, above.
|
||||
|
||||
3. **My ticket has been in DDN forever! What should I do?**
|
||||
|
||||
Design Decision Needed requires consensus about the right solution. At the
|
||||
very least it needs consensus among the core developers, and ideally it has
|
||||
consensus from the community as well. The best way to accomplish this is to
|
||||
start a thread on the django-developers mailing list, and for very complex
|
||||
issues to start a wiki page summarizing the problem and the possible
|
||||
solutions.
|
||||
|
@ -51,8 +51,8 @@ attribute easily tells us what and who each ticket is waiting on.
|
||||
Since a picture is worth a thousand words, let's start there:
|
||||
|
||||
.. image:: /internals/_images/triage_process.*
|
||||
:height: 564
|
||||
:width: 580
|
||||
:height: 501
|
||||
:width: 400
|
||||
:alt: Django's ticket triage workflow
|
||||
|
||||
We've got two roles in this diagram:
|
||||
@ -128,30 +128,13 @@ Beyond that there are several considerations:
|
||||
and docs, running the test suite with the included patch, and leaving
|
||||
feedback on the ticket.
|
||||
|
||||
* **Accepted + Has Patch + (any other flag)**
|
||||
* **Accepted + Has Patch + Needs ...**
|
||||
|
||||
This means the ticket has been reviewed, and has been found to need further
|
||||
work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch
|
||||
needs improvement" will generally be accompanied by a comment on the ticket
|
||||
explaining what is needed to improve the code.
|
||||
|
||||
Design Decision Needed
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This stage is for issues which may be contentious, may be backwards
|
||||
incompatible, or otherwise involve high-level design decisions. These issues
|
||||
should be discussed either in the ticket comments or on `django-developers`_.
|
||||
|
||||
If a ticket has been marked as "DDN", decisions are generally eventually
|
||||
made by the core committers, however that is not a requirement. See the
|
||||
:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
|
||||
DDN forever! What should I do?"
|
||||
|
||||
This stage will often be used for feature requests. It can also be used for
|
||||
issues that *might* be bugs, depending on opinion or interpretation. Obvious
|
||||
bugs (such as crashes, incorrect query results, or non-compliance with a
|
||||
standard) skip this stage and move straight to "Accepted".
|
||||
|
||||
Ready For Checkin
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -165,11 +148,13 @@ RFC forever! What should I do?"
|
||||
Someday/Maybe
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Generally only used for vague/high-level features or design ideas. These
|
||||
tickets are uncommon and overall less useful since they don't describe
|
||||
This stage isn't shown on the diagram. It's only used by core developers to
|
||||
keep track of high-level ideas or long term feature requests.
|
||||
|
||||
These tickets are uncommon and overall less useful since they don't describe
|
||||
concrete actionable issues. They are enhancement requests that we might
|
||||
consider adding someday to the framework if an excellent patch is submitted.
|
||||
These tickets are not a high priority.
|
||||
They are not a high priority.
|
||||
|
||||
Other triage attributes
|
||||
-----------------------
|
||||
@ -301,20 +286,23 @@ developers and bring the issue to django-developers_ instead.
|
||||
How can I help with triaging?
|
||||
-----------------------------
|
||||
|
||||
Although the core developers make the big decisions in the ticket triage
|
||||
process, there's a lot that general community members can do to help the
|
||||
triage process. Really, **ANYONE** can help.
|
||||
The triage process is primarily driven by community members. Really,
|
||||
**ANYONE** can help.
|
||||
|
||||
Start by `creating an account on Trac`_. If you have an account but have
|
||||
forgotten your password, you can reset it using the `password reset page`_.
|
||||
Core developers may provide feedback on issues they're familiar with, or make
|
||||
decisions on controversial ones, but they aren't responsible for triaging
|
||||
tickets in general.
|
||||
|
||||
To get involved, start by `creating an account on Trac`_. If you have an
|
||||
account but have forgotten your password, you can reset it using the `password
|
||||
reset page`_.
|
||||
|
||||
Then, you can help out by:
|
||||
|
||||
* Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
|
||||
|
||||
* Promoting "Unreviewed" tickets to "Design decision needed" if a design
|
||||
decision needs to be made, or "Accepted" in case of obvious bugs or
|
||||
sensible, clearly defined, feature requests.
|
||||
* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests
|
||||
requiring a discussion on `django-developers`_.
|
||||
|
||||
* Correcting the "Needs tests", "Needs documentation", or "Has patch"
|
||||
flags for tickets where they are incorrectly set.
|
||||
@ -322,22 +310,18 @@ Then, you can help out by:
|
||||
* Setting the "`Easy pickings`_" flag for tickets that are small and
|
||||
relatively straightforward.
|
||||
|
||||
* Set the *type* of tickets that are still uncategorized.
|
||||
|
||||
* Checking that old tickets are still valid. If a ticket hasn't seen
|
||||
any activity in a long time, it's possible that the problem has been
|
||||
fixed but the ticket hasn't yet been closed.
|
||||
|
||||
* Contacting the owners of tickets that have been claimed but have not
|
||||
seen any recent activity. If the owner doesn't respond after a week
|
||||
or so, remove the owner's claim on the ticket.
|
||||
|
||||
* Identifying trends and themes in the tickets. If there a lot of bug
|
||||
reports about a particular part of Django, it may indicate we should
|
||||
consider refactoring that part of the code. If a trend is emerging,
|
||||
you should raise it for discussion (referencing the relevant tickets)
|
||||
on `django-developers`_.
|
||||
|
||||
* Set the *type* of tickets that are still uncategorized.
|
||||
|
||||
* Verify if patches submitted by other users are correct. If they do and
|
||||
also contain appropriate documentation and tests then move them to the
|
||||
"Ready for Checkin" stage. If they don't then leave a comment to explain
|
||||
|
Loading…
x
Reference in New Issue
Block a user