1
0
mirror of https://github.com/django/django.git synced 2024-12-23 01:25:58 +00:00

Refs #35894 -- Renamed trac flags from patch to pull request.

This commit is contained in:
Baptiste Mispelon 2024-11-13 10:16:13 +01:00 committed by Sarah Boyce
parent 92dd2fb677
commit 24a7c39076
7 changed files with 33 additions and 33 deletions

View File

@ -9,7 +9,7 @@ Provide a concise overview of the issue or rationale behind the proposed changes
#### Checklist
- [ ] This PR targets the `main` branch. <!-- Backports will be evaluated and done by mergers, when necessary. -->
- [ ] The commit message is written in past tense, mentions the ticket number, and ends with a period.
- [ ] I have checked the "Has patch" ticket flag in the Trac system.
- [ ] I have checked the "Has pull request" ticket flag in the Trac system.
- [ ] I have added or updated relevant tests.
- [ ] I have added or updated relevant docs, including release notes if applicable.
- [ ] I have attached screenshots in both light and dark modes for any UI changes.

View File

@ -20,7 +20,7 @@ jobs:
As it's your first contribution be sure to check out the [contribution checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist).
If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has patch"_ flag and include a link to this PR in the ticket!
If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has pull request"_ flag and include a link to this PR in the ticket!
If you have any design or process questions then you can ask in the [Django forum](https://forum.djangoproject.com/c/internals/5).

View File

@ -65,8 +65,8 @@ must:
Django Git ``main`` branch, as for any code change.
* Open a ticket in Django's ticket system, set its ``Component`` field to
``Translations``, set the "has patch" flag, and include the link to the pull
request.
``Translations``, set the "has pull request" flag, and include the link to
the pull request.
.. _Transifex: https://www.transifex.com/
.. _Django project page: https://app.transifex.com/django/django/

View File

@ -156,7 +156,7 @@ This isn't personal. There are a lot of tickets and pull requests to get
through.
Keeping your pull request up to date is important. Review the ticket on Trac to
ensure that the *Needs tests*, *Needs documentation*, and *Patch needs
ensure that the *Needs tests*, *Needs documentation*, and *Pull request needs
improvement* flags are unchecked once you've addressed all review comments.
Remember that Django has an eight-month release cycle, so there's plenty of

View File

@ -70,17 +70,17 @@ By way of example, here we see the lifecycle of an average ticket:
incorrect implementation).
* Bob reviews the pull request, marks the ticket as "Accepted", "needs tests",
and "patch needs improvement", and leaves a comment telling Alice how the
pull request could be improved.
and "pull request needs improvement", and leaves a comment telling Alice how
the pull request could be improved.
* Alice updates the pull request, adding tests (but not changing the
implementation). She removes the two flags.
* Charlie reviews the pull request and resets the "patch needs improvement"
flag with another comment about improving the implementation.
* Charlie reviews the pull request and resets the "pull request needs
improvement" flag with another comment about improving the implementation.
* Alice updates the pull request, fixing the implementation. She removes the
"patch needs improvement" flag.
"pull request needs improvement" flag.
* Daisy reviews the pull request and marks the ticket as "Ready for checkin".
@ -125,19 +125,19 @@ Beyond that there are several considerations:
accepted for that feature. Seek more feedback before writing an extensive
contribution if you are in doubt.
* **Accepted + Has Patch**
* **Accepted + Has Pull Request**
The ticket is waiting for people to review the supplied solution. This means
checking out the pull request and trying it out, verifying that it contains
tests and docs, checking that all the automated tests on the pull request are
passing, and leaving feedback.
* **Accepted + Has Patch + Needs ...**
* **Accepted + Has Pull Request + 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.
work. "Needs tests" and "Needs documentation" are self-explanatory. "Pull
request needs improvement" will generally be accompanied by a comment on the
ticket explaining what is needed to improve the code.
Ready For Checkin
-----------------
@ -167,15 +167,15 @@ Other triage attributes
A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
Has patch
---------
Has pull request
----------------
This means the ticket has an associated solution. These will be reviewed to
ensure they adhere to the :doc:`documented guidelines
<writing-code/submitting-patches>`.
The following three fields (Needs documentation, Needs tests,
Patch needs improvement) apply only if a pull request has been supplied.
Pull request needs improvement) apply only if a pull request has been supplied.
Needs documentation
-------------------
@ -190,8 +190,8 @@ Needs tests
This flags the pull request as needing associated unit tests. Again, this is a
required part of a valid contribution.
Patch needs improvement
-----------------------
Pull request needs improvement
------------------------------
This flag means that although the ticket *has* a solution, it's not quite
ready for checkin. This could mean the pull request has merge conflicts, there
@ -356,7 +356,7 @@ Then, you can help out by:
sparse to be actionable, or when they're feature requests requiring a
discussion on the `Django Forum`_ or |django-developers|.
* Correcting the "Needs tests", "Needs documentation", or "Has patch"
* Correcting the "Needs tests", "Needs documentation", or "Has pull request"
flags for tickets where they are incorrectly set.
* Setting the "`Easy pickings`_" flag for tickets that are small and
@ -377,7 +377,7 @@ Then, you can help out by:
* Verify if solutions submitted by others are correct. If they are correct
and also contain appropriate documentation and tests then move them to the
"Ready for Checkin" stage. If they are not correct then leave a comment to
explain why and set the corresponding flags ("Patch needs improvement",
explain why and set the corresponding flags ("Pull request needs improvement",
"Needs tests" etc.).
.. note::

View File

@ -136,10 +136,10 @@ Regardless of the way you submit your work, follow these steps.
* Make sure your code fulfills the requirements in our :ref:`contribution
checklist <patch-review-checklist>`.
* Check the "Has patch" box on the ticket and make sure the "Needs
documentation", "Needs tests", and "Patch needs improvement" boxes aren't
checked. This makes the ticket appear in the "Patches needing review" queue
on the `Development dashboard`_.
* Check the "Has pull request" box on the ticket and make sure the "Needs
documentation", "Needs tests", and "Pull request needs improvement" boxes
aren't checked. This makes the ticket appear in the "Patches needing review"
queue on the `Development dashboard`_.
.. _ticket tracker: https://code.djangoproject.com/
.. _Development dashboard: https://dashboard.djangoproject.com/
@ -340,10 +340,10 @@ If the pull request passes all the criteria below and is not your own, please
set the "Triage Stage" on the corresponding Trac ticket to "Ready for checkin".
If you've left comments for improvement on the pull request, please tick the
appropriate flags on the Trac ticket based on the results of your review:
"Patch needs improvement", "Needs documentation", and/or "Needs tests". As time
and interest permits, mergers do final reviews of "Ready for checkin" tickets
and will either commit the changes or bump it back to "Accepted" if further
work needs to be done.
"Pull request needs improvement", "Needs documentation", and/or "Needs tests".
As time and interest permits, mergers do final reviews of "Ready for checkin"
tickets and will either commit the changes or bump it back to "Accepted" if
further work needs to be done.
If you're looking to become a member of the `triage & review team
<https://www.djangoproject.com/foundation/teams/#triage-review-team>`_, doing

View File

@ -622,7 +622,7 @@ What's next after creating a pull request?
After a ticket has a branch, it needs to be reviewed by a second set of eyes.
After submitting a pull request, update the ticket metadata by setting the
flags on the ticket to say "has patch", "doesn't need tests", etc, so others
can find it for review. Contributing doesn't necessarily always mean writing
code from scratch. Reviewing open pull requests is also a very helpful
flags on the ticket to say "has pull request", "doesn't need tests", etc, so
others can find it for review. Contributing doesn't necessarily always mean
writing code from scratch. Reviewing open pull requests is also a very helpful
contribution. See :doc:`/internals/contributing/triaging-tickets` for details.