You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I often see PRs with misleading or vague titles. This is problematic, as the PR titles often end up being the commit titles, and commit titles are one of the most important tools we have when searching for historic changes. Bad titles impact maintainability.
Suggested edits:
Enforce a strict title format
Promote writing accurate and concise PR titles/descriptions
Perhaps the "Making Good PRs" section can be further promoted. Would it make sense to extract it and move it a level up in the doc hierarchy?
As a budding open-source contributor and extremely excited to start contributing to my favorite language, I agree with your suggestion, especially for new devs eager to contribute. For example, when creating my first PR, I had to go through the previous closed PRs to gauge the format and structure of the title, branch name, and commit message itself. A format for PRs won't hurt the dev workflow.
Related: add a note regarding how to write good commit message. For example, we try to avoid the overly verbose default squash merge message GitHub provides, especially for long-lived branches with lots of commits. See also python/cpython#120984 (comment)
Well, I need some help with resolving this issue. Based on what @erlend-aasland explained, I’d like to know specifically what I need to do, as this is my first time contributing to open source.
Well, I need some help with resolving this issue. Based on what @erlend-aasland explained, I’d like to know specifically what I need to do, as this is my first time contributing to open source.
I noticed that this issue hasn't been resolved yet, and I'd love to work on it. I'll start looking into it and provide updates as I make progress. Please let me know if there are any specific guidelines or things I should keep in mind.
There's an open PR (#1510), but there's been no feedback from the author for a while and the CLA is unsigned. You're welcome to open a new PR, but I would suggest starting with a smaller one as it is more likely to be approved/merged, you can then continue to make improvements in follow-ups.
Regarding the noted comment about the commit message details, it looks like there is already a blurb about creating a good commit message. Would you still like me to add anything to that?
Activity
abdnafees commentedon Nov 19, 2022
As a budding open-source contributor and extremely excited to start contributing to my favorite language, I agree with your suggestion, especially for new devs eager to contribute. For example, when creating my first PR, I had to go through the previous closed PRs to gauge the format and structure of the title, branch name, and commit message itself. A format for PRs won't hurt the dev workflow.
erlend-aasland commentedon Jul 1, 2024
Related: add a note regarding how to write good commit message. For example, we try to avoid the overly verbose default squash merge message GitHub provides, especially for long-lived branches with lots of commits. See also python/cpython#120984 (comment)
kasujjabash commentedon Oct 10, 2024
hey I would love to work on this issue if you don't mind, thanks
erlend-aasland commentedon Oct 11, 2024
Great; feel free to propose a PR updating the devguide :)
kasujjabash commentedon Oct 12, 2024
kasujjabash commentedon Oct 14, 2024
Well, I need some help with resolving this issue. Based on what @erlend-aasland explained, I’d like to know specifically what I need to do, as this is my first time contributing to open source.
Thank you
erlend-aasland commentedon Oct 14, 2024
See the OP for what needs to be done.
The Making good PRs section can be found starting around line 189 in the file
getting-started/pull-request-lifecycle.rstof the devguide repo.swastim01 commentedon Feb 9, 2025
Hi everyone,
I noticed that this issue hasn't been resolved yet, and I'd love to work on it. I'll start looking into it and provide updates as I make progress. Please let me know if there are any specific guidelines or things I should keep in mind.
Looking forward to contributing!
Thanks,
Swasti
swastim01 commentedon Feb 9, 2025
Hi all,
I created a pull request for this issue with relevant changes. Your feedback would be appreciated.
Thanks,
Swasti.
pythonGH-931: Improve 'Making Good PRs' section with title guidelines
gioviebell commentedon Aug 7, 2025
Hello! I noticed the previous claim, but it appears that this issue is still open. Am I able to claim this, or is it resolved? Thank you!
AA-Turner commentedon Aug 7, 2025
There's an open PR (#1510), but there's been no feedback from the author for a while and the CLA is unsigned. You're welcome to open a new PR, but I would suggest starting with a smaller one as it is more likely to be approved/merged, you can then continue to make improvements in follow-ups.
A
gioviebell commentedon Aug 8, 2025
I appreciate the feedback! I would like to claim it then please! I will submit a shorter PR first!
gioviebell commentedon Aug 9, 2025
Regarding the noted comment about the commit message details, it looks like there is already a blurb about creating a good commit message. Would you still like me to add anything to that?
Merge pull request #1 from gioviebell/gioviebell-patch-1
decoded15 commentedon Jan 3, 2026
Hi, I’m new to contributing to Python projects.
I’d like to work on this issue if it’s available.