Repository navigation
Improve the "Making Good PRs" section #931
Description
Activity
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.
Reacted by Erlend E. AaslandRelated: 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)
hey I would love to work on this issue if you don't mind, thanks
Reacted by Erlend E. Aaslandhey I would love to work on this issue if you don't mind, thanks
Great; feel free to propose a PR updating the devguide :)
- Thank you…On Fri, 11 Oct 2024 at 21:29, Erlend E. Aasland ***@***.***> wrote: hey I would love to work on this issue if you don't mind, thanks Great; feel free to propose a PR updating the devguide :) — Reply to this email directly, view it on GitHub <#931 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZVBS7YM57W3OHNQGDPERGTZ3AKHPAVCNFSM6AAAAABKGNTR66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBXHEZTANJWGQ> . You are receiving this because you commented.Message ID: ***@***.***>
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
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.
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.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,
SwastiHi all,
I created a pull request for this issue with relevant changes. Your feedback would be appreciated.Thanks,
Swasti.- added a commit that references this issue
on Feb 24, 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!
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
I appreciate the feedback! I would like to claim it then please! I will submit a shorter PR first!
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?
- added a commit that references this issue
on Aug 10, 2025 Hi, I’m new to contributing to Python projects.
I’d like to work on this issue if it’s available.
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:
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?