Fixed #36667 -- Added tips to help PRs get reviewed faster (FAQ). #20019
Conversation
Co-authored-by: Sarah Boyce <[email protected]>.
There was a problem hiding this comment.
Hello! Thank you for your contribution 💪
As it's your first contribution be sure to check out the patch review checklist.
If you're fixing a ticket from Trac make sure to set the "Has patch" 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.
Welcome aboard ⛵️!
| - Organize commits. Squash or group them logically (for example, separate | ||
| refactors from functional changes). | ||
| - Keep changes minimal. Avoid unrelated modifications. | ||
| - Ensure test coverage. Add or update tests where appropriate. | ||
| - Provide clear testing instructions. Include reproduction steps, profiling | ||
| scripts, or other details if automated tests can't cover the change. |
There was a problem hiding this comment.
This introduces a slight duplication with the patch review checklist. https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
I like the advice to do a self-review. What if that advice to self-review linked to the patch review checklist. We could spruce the other checklist up where needed. For instance, I like your advice here about "separate refactors from functional changes", which definitely matches our current practice. Shouldn't we update the patch review checklist, which currently says "Is the pull request a single squashed commit ...", with that nuance?
|
(very minor: unless Sarah directed you otherwise, I think we should stick to the email she normally signs commits with, see:) |
|
(also very minor: our current practice is when a docs change only affects one file to just name the file in the commit message, so something like:) We use "Fixed" rather than "Refs" when our intention is to close the ticket (we have automation that closes the ticket on Trac if so). Let's make sure that's discussed in the patch review checklist. |
| Tips to help your PR get reviewed faster | ||
| ======================================== |
There was a problem hiding this comment.
This is the FAQ and this heading is inconsistent with the others, which are (mostly) questions.
I think any new advice could be incorporated in the existing questions.
| 2. Find potential reviewers. | ||
|
|
||
| Look for contributors who are familiar with the component you're working on | ||
| and are still active. | ||
| You can do this by filtering *Ready for checkin* tickets by component and | ||
| grouping them by owner to see recent activity. | ||
| For example, for GIS-related changes, use the `GIS component filters`_ to | ||
| find active contributors. |
There was a problem hiding this comment.
I don't know about this suggestion. I personally wouldn't want to be pinged with review requests. I'd rather have some list of people who want to be pinged (if any exist) so that this isn't a research activity for each contributor.
| Make sure your pull request appears in the `review queue`_ so reviewers can | ||
| easily find it. |
There was a problem hiding this comment.
I would say the review queue is "Patches needing reviewing" at https://dashboard.djangoproject.com/ since this is easier to find without the obscure Trac URL.
Trac ticket number
ticket-36667
Co-authored-by: Sarah Boyce [email protected]
Branch description
This pull request updates the FAQ: Contributing Code section to provide contributors with clear and respectful guidelines on how to request reviews for their Django pull requests.
Checklist
mainbranch.