Add pre-merge checklist in core developer guide
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 62/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Stale
- Domain
- documentation
Research direction
Edit the reviewing section in docs/developers/coredev/core_dev_guide.md, linked in the issue. Start by reading that section and align the proposed pre-merge checklist with its existing guidance; decide whether to describe the final checks step and its automation role. Done means the guide covers the listed checks and the distinction between final checks and a merge wait period.
Written by the indexing model from the issue text.
Description
Our core developer guide has a section on reviewing, but it is missing essential information about merge-time conventions/etiquette. Especially now that @willingc is advocating for getting rid of the "ready to merge" wait period, I think it's important to add to the guide everything that needs to happen before a PR is merged:
- check the type label type (feature, label, performance, etc)
- check the milestone
- check discussion comments are addressed or an issue is made to keep track of remaining to-dos
- make sure the title still reflects the state/purpose of the PR
- make sure the description reflects the current state/purpose of the PR (it's encouraged to leave the original description underneath under the heading "original description", since it provides the context for the subsequent discussion on the PR itself. However, the description becomes the commit message, so it should reflect the status of the PR at the time of merging.)
Some of those checks should ideally be automated, so we could perhaps rename "ready to merge" to "final checks" and keep it only for the automations, not for the wait period.
- Dominant language
- Makefile
- Stars
- 13
- Forks
- 71
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 30
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from napari/docs
-
Link Checker ReportOpenmaintenance task
Difficulty 1/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
task
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
napari/docs#1152 · 3 comments ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 57/100
napari/docs#1186 · 1 reaction ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
napari/docs#1179 · 8 comments ·
Maintainers usually reply within 2 days
Similar issues
-
documentation enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
good first issue priority:low type:docs
Difficulty 1/5 1-3 hours Newbie friendliness 95/100
crazy-goat/rabbit-stream#969 ·
Maintainers usually reply within 1 day
-
question
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
backend docs
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Open-Locker/Open-Locker#368 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
fsprojects/FSharp.Formatting#1370 ·
Maintainers usually reply within 1 day