Open erlend-aasland opened 2 years ago
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 https://github.com/python/cpython/pull/120984#issuecomment-2201360258
hey I would love to work on this issue if you don't mind, thanks
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 :)
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 https://github.com/python/devguide/issues/931#issuecomment-2407930564, 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.rst
of the devguide repo.
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?