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:
parent
92dd2fb677
commit
24a7c39076
2
.github/pull_request_template.md
vendored
2
.github/pull_request_template.md
vendored
@ -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.
|
||||
|
2
.github/workflows/new_contributor_pr.yml
vendored
2
.github/workflows/new_contributor_pr.yml
vendored
@ -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).
|
||||
|
||||
|
@ -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/
|
||||
|
@ -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
|
||||
|
@ -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::
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user