Ensure that all references to creating and reviewing PRs mention blurb and NEWS entries
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation
Research direction
Read the Git Bootcamp and Cheat Sheet, the Accepting Pull Requests section, and the Lifecycle of a Pull Request section in the devguide. Consolidate the existing blurb and MiscNEWS.d guidance into the Git Bootcamp section, add guidance on good NEWS entries, and link to it wherever PR creation, review, or committing is discussed.
Written by the indexing model from the issue text.
Description
Other than for the most trivial sorts of changes (e.g. obvious spelling errors), nearly all changes to the cpython repo should include a NEWS entry; that's our primary mechanism to communicate changes with downstream users. We should be encouraging everyone, including non core-developers to submit PRs with NEWS entries. Among other benefits, having a NEWS entry makes reviews of the PR easier and helps to focus everyone include the submitter on what problem the PR is trying to address. And the tool we have to create NEWS entry is blurb; we want to encourage everyone creating or modifying a PR to use it. It's easier to delete the occasional unnecessary NEWS item than it is to create one when committing. To that end, suggest:
-
Create a section in the Git Bootcamp and Cheat Sheet
Accepting and Mergingsection to describe the details of using blurb with a fallback to how to manually create aMiscNEWS.dentry: basically, adapt and move the detailed info from the Accepting Pull Requests section. We want to be careful to encourageblurbusage and not encourage manually creation as the details could change in the future. -
This section should also include some guidelines on what a good NEWS entry looks like, or, if not here, one place in the devguide with references to it.
-
Review the whole document and add mentions of NEWS entries and the
blurbcommand everywhere creating or reviewing or committing a PR is discussed and include a link to the detailed section created above. In particular, the Lifecycle of a Pull Request section needs to be edited to include blurb.
- Dominant language
- Python
- Stars
- 2.1k
- Forks
- 1k
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 12
Contributor 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 python/devguide
-
type-feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
type-feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
topic-building python type-feature
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
needs: decision topic-test type-bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
topic-dev process type-feature
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·