From a99729ea817390150334ca76153322f04e42554c Mon Sep 17 00:00:00 2001 From: swastim01 Date: Sun, 9 Feb 2025 15:40:33 +0530 Subject: [PATCH 01/10] Moved 'Making Good PRs' section up in the hierarchy and clarified its content --- getting-started/pull-request-lifecycle.rst | 142 +++++++++++++-------- 1 file changed, 88 insertions(+), 54 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 59242f13f..b1951f771 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -16,6 +16,94 @@ that you create a branch in Git, make your changes, push those changes to your fork on GitHub (``origin``), and then create a pull request against the official CPython repository (``upstream``). +.. _good-prs: + +Making Good PRs +=============== + +When creating a pull request, following best practices ensures your contribution is **clear, maintainable, and easy to review**. A well-structured PR improves collaboration and speeds up the review process. + +1. **Use a Clear and Structured PR Title** + + PR titles often become commit messages, making them **critical for maintainability and searchability**. Follow these guidelines: + + **Do:** + + - Clearly summarize the change in a concise manner. + - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). + - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). + + **Avoid:** + + - "Bug fix" → Too vague. What bug was fixed? + - "Update README" → What was updated? Be precise. + - "Refactoring" → Explain what was refactored and why. + + **Example of a good PR title:** + + ``Improve error handling in JSON parser to prevent crashes`` + +2. **Write a Meaningful PR Description** + + Your PR description should provide **clear context** for reviewers. Answer the following questions: + + - **What does this PR do?** + - **Why is this change necessary?** + - **Are there any breaking changes?** + - **Does this PR fix any open issues?** (Reference issue numbers if applicable) + + Providing detailed descriptions makes the review process **faster and more efficient**. + +3. **Make Your Change Against the Right Branch** + + Ensure your PR is based on the correct branch: + + - **New changes should target the** ``main`` **branch unless they are specific to an older version.** + - If a change affects older versions, it will be **backported** after merging. + - Only use **maintenance branches** when the change does not apply to ``main`` or requires a different approach. + + Refer to :ref:`branch-merge` for more details on how backporting works. + +4. **Follow Python's Style Guidelines** + + - Python code should follow :PEP:`8`, and C code should follow :PEP:`7`. + - Maintainers may **fix minor style issues**, but major deviations can **delay or block merging**. + - PRs with **only style changes** are usually rejected unless they fix a formatting error. + + .. note:: + Fixes for typos and grammar errors in documentation and docstrings are always welcome. + +5. **Consider Backward Compatibility** + + - Changes should **not break existing code** unless absolutely necessary. + - When introducing **new arguments**, provide **default values** to maintain existing behavior. + - If unsure, refer to :PEP:`387` or discuss the issue with experienced maintainers in :ref:`communication`. + + Think about how your change affects existing users before submitting your PR. + +6. **Ensure Proper Testing** + + - Every PR should include **appropriate test cases** to validate the changes. + - PRs without tests **will not be accepted** unless they are purely documentation changes. + - Tests should **cover edge cases** and expected behaviors. + - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. + +7. **Make Sure All Tests Pass** + + - The entire test suite must **run without failures** before submission. + - Run ``make test`` or refer to :ref:`runtests` to check for test failures. + - Do not submit PRs with failing tests unless the failure is **directly related** to your change. + +8. **Keep Documentation Up to Date** + + - Any change affecting functionality should include relevant **documentation updates**. + - Follow :ref:`documenting` guidelines to ensure consistency in documentation. + + Keeping documentation updated ensures clarity for future contributors and users. + +By following these best practices, you increase the likelihood of your PR being **quickly reviewed and merged**! + + .. _pullrequest-quickguide: @@ -184,60 +272,6 @@ See `the merge command's documentation `_ for a detailed technical explanation. -.. _good-prs: - -Making good PRs -=============== - -When creating a pull request for submission, there are several things that you -should do to help ensure that your pull request is accepted. - -#. **Make your change against the right version of Python.** In general all - changes are made against the ``main`` branch first. This includes bug fixes. - After the change is merged there, it will be :ref:`ported back ` - to older :ref:`maintenance releases ` as well. That way we - ensure all affected versions are handled. Therefore, basing a new change - directly on a maintenance branch is only used in specific circumstances, - for instance when that change does not apply to ``main`` or the change - requires a different approach in an older Python version compared to - ``main``. - -#. **Make sure to follow Python's style guidelines.** For Python code you - should follow :PEP:`8`, and for C code you should follow :PEP:`7`. If you have - one or two discrepancies those can be fixed by the core developer who merges - your pull request. But if you have systematic deviations from the style guides - your pull request will be put on hold until you fix the formatting issues. - - .. note:: - Pull requests with only code formatting changes are usually rejected. On - the other hand, fixes for typos and grammar errors in documents and - docstrings are welcome. - -#. **Be aware of backwards-compatibility considerations.** While the core - developer who eventually handles your pull request will make the final call on - whether something is acceptable, thinking about backwards-compatibility early - will help prevent having your pull request rejected on these grounds. Put - yourself in the shoes of someone whose code will be broken by the change(s) - introduced by the pull request. It is quite likely that any change made will - break someone's code, so you need to have a good reason to make a change as - you will be forcing someone to update their code. (This obviously does not - apply to new classes or functions; new arguments should be optional and have - default values which maintain the existing behavior.) If in doubt, have a look - at :PEP:`387` or :ref:`discuss ` the issue with experienced - developers. - -#. **Make sure you have proper tests** to verify your pull request works as - expected. Pull requests will not be accepted without the proper tests! - -#. **Make sure all tests pass.** The entire test suite needs to - :ref:`run ` **without failure** because of your changes. - It is not sufficient to only run whichever test seems impacted by your - changes, because there might be interferences unknown to you between your - changes and some other part of the interpreter. - -#. Proper :ref:`documentation ` additions/changes should be included. - - Copyrights ========== From 38a16d643aee42a189657edd7a168506b01e2192 Mon Sep 17 00:00:00 2001 From: swastim01 Date: Sun, 9 Feb 2025 18:38:39 +0530 Subject: [PATCH 02/10] Reversed the doc hierarchy as it was before --- getting-started/pull-request-lifecycle.rst | 176 ++++++++++----------- 1 file changed, 88 insertions(+), 88 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index b1951f771..6c6a3c923 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -16,94 +16,6 @@ that you create a branch in Git, make your changes, push those changes to your fork on GitHub (``origin``), and then create a pull request against the official CPython repository (``upstream``). -.. _good-prs: - -Making Good PRs -=============== - -When creating a pull request, following best practices ensures your contribution is **clear, maintainable, and easy to review**. A well-structured PR improves collaboration and speeds up the review process. - -1. **Use a Clear and Structured PR Title** - - PR titles often become commit messages, making them **critical for maintainability and searchability**. Follow these guidelines: - - **Do:** - - - Clearly summarize the change in a concise manner. - - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). - - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). - - **Avoid:** - - - "Bug fix" → Too vague. What bug was fixed? - - "Update README" → What was updated? Be precise. - - "Refactoring" → Explain what was refactored and why. - - **Example of a good PR title:** - - ``Improve error handling in JSON parser to prevent crashes`` - -2. **Write a Meaningful PR Description** - - Your PR description should provide **clear context** for reviewers. Answer the following questions: - - - **What does this PR do?** - - **Why is this change necessary?** - - **Are there any breaking changes?** - - **Does this PR fix any open issues?** (Reference issue numbers if applicable) - - Providing detailed descriptions makes the review process **faster and more efficient**. - -3. **Make Your Change Against the Right Branch** - - Ensure your PR is based on the correct branch: - - - **New changes should target the** ``main`` **branch unless they are specific to an older version.** - - If a change affects older versions, it will be **backported** after merging. - - Only use **maintenance branches** when the change does not apply to ``main`` or requires a different approach. - - Refer to :ref:`branch-merge` for more details on how backporting works. - -4. **Follow Python's Style Guidelines** - - - Python code should follow :PEP:`8`, and C code should follow :PEP:`7`. - - Maintainers may **fix minor style issues**, but major deviations can **delay or block merging**. - - PRs with **only style changes** are usually rejected unless they fix a formatting error. - - .. note:: - Fixes for typos and grammar errors in documentation and docstrings are always welcome. - -5. **Consider Backward Compatibility** - - - Changes should **not break existing code** unless absolutely necessary. - - When introducing **new arguments**, provide **default values** to maintain existing behavior. - - If unsure, refer to :PEP:`387` or discuss the issue with experienced maintainers in :ref:`communication`. - - Think about how your change affects existing users before submitting your PR. - -6. **Ensure Proper Testing** - - - Every PR should include **appropriate test cases** to validate the changes. - - PRs without tests **will not be accepted** unless they are purely documentation changes. - - Tests should **cover edge cases** and expected behaviors. - - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. - -7. **Make Sure All Tests Pass** - - - The entire test suite must **run without failures** before submission. - - Run ``make test`` or refer to :ref:`runtests` to check for test failures. - - Do not submit PRs with failing tests unless the failure is **directly related** to your change. - -8. **Keep Documentation Up to Date** - - - Any change affecting functionality should include relevant **documentation updates**. - - Follow :ref:`documenting` guidelines to ensure consistency in documentation. - - Keeping documentation updated ensures clarity for future contributors and users. - -By following these best practices, you increase the likelihood of your PR being **quickly reviewed and merged**! - - .. _pullrequest-quickguide: @@ -271,6 +183,94 @@ message. It is usually okay to leave that as-is and close the editor. See `the merge command's documentation `_ for a detailed technical explanation. +.. _good-prs: + +Making Good PRs +=============== + +When creating a pull request, following best practices ensures your contribution is **clear, maintainable, and easy to review**. A well-structured PR improves collaboration and speeds up the review process. + +1. **Use a Clear and Structured PR Title** + + PR titles often become commit messages, making them **critical for maintainability and searchability**. Follow these guidelines: + + **Do:** + + - Clearly summarize the change in a concise manner. + - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). + - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). + + **Avoid:** + + - "Bug fix" → Too vague. What bug was fixed? + - "Update README" → What was updated? Be precise. + - "Refactoring" → Explain what was refactored and why. + + **Example of a good PR title:** + + ``Improve error handling in JSON parser to prevent crashes`` + +2. **Write a Meaningful PR Description** + + Your PR description should provide **clear context** for reviewers. Answer the following questions: + + - **What does this PR do?** + - **Why is this change necessary?** + - **Are there any breaking changes?** + - **Does this PR fix any open issues?** (Reference issue numbers if applicable) + + Providing detailed descriptions makes the review process **faster and more efficient**. + +3. **Make Your Change Against the Right Branch** + + Ensure your PR is based on the correct branch: + + - **New changes should target the** ``main`` **branch unless they are specific to an older version.** + - If a change affects older versions, it will be **backported** after merging. + - Only use **maintenance branches** when the change does not apply to ``main`` or requires a different approach. + + Refer to :ref:`branch-merge` for more details on how backporting works. + +4. **Follow Python's Style Guidelines** + + - Python code should follow :PEP:`8`, and C code should follow :PEP:`7`. + - Maintainers may **fix minor style issues**, but major deviations can **delay or block merging**. + - PRs with **only style changes** are usually rejected unless they fix a formatting error. + + .. note:: + Fixes for typos and grammar errors in documentation and docstrings are always welcome. + +5. **Consider Backward Compatibility** + + - Changes should **not break existing code** unless absolutely necessary. + - When introducing **new arguments**, provide **default values** to maintain existing behavior. + - If unsure, refer to :PEP:`387` or discuss the issue with experienced maintainers in :ref:`communication`. + + Think about how your change affects existing users before submitting your PR. + +6. **Ensure Proper Testing** + + - Every PR should include **appropriate test cases** to validate the changes. + - PRs without tests **will not be accepted** unless they are purely documentation changes. + - Tests should **cover edge cases** and expected behaviors. + - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. + +7. **Make Sure All Tests Pass** + + - The entire test suite must **run without failures** before submission. + - Run ``make test`` or refer to :ref:`runtests` to check for test failures. + - Do not submit PRs with failing tests unless the failure is **directly related** to your change. + +8. **Keep Documentation Up to Date** + + - Any change affecting functionality should include relevant **documentation updates**. + - Follow :ref:`documenting` guidelines to ensure consistency in documentation. + + Keeping documentation updated ensures clarity for future contributors and users. + +By following these best practices, you increase the likelihood of your PR being **quickly reviewed and merged**! + + Copyrights ========== From 0cdb96aa2c831957b0d1f61b649ac0b13ad6b112 Mon Sep 17 00:00:00 2001 From: swastim01 Date: Sun, 9 Feb 2025 19:41:51 +0530 Subject: [PATCH 03/10] Improved capitalization, added #. instead of hardcoding, trimmed trailing spaces using pre-commit, removed blockquotes --- getting-started/pull-request-lifecycle.rst | 88 +++++++++++----------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 6c6a3c923..5e61a0d6d 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -190,81 +190,81 @@ Making Good PRs When creating a pull request, following best practices ensures your contribution is **clear, maintainable, and easy to review**. A well-structured PR improves collaboration and speeds up the review process. -1. **Use a Clear and Structured PR Title** +1. **Use a Clear and Structured PR Title** PR titles often become commit messages, making them **critical for maintainability and searchability**. Follow these guidelines: - **Do:** - - - Clearly summarize the change in a concise manner. - - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). - - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). + **Do:** - **Avoid:** + - Clearly summarize the change in a concise manner. + - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). + - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). - - "Bug fix" → Too vague. What bug was fixed? - - "Update README" → What was updated? Be precise. - - "Refactoring" → Explain what was refactored and why. + **Avoid:** - **Example of a good PR title:** + - "Bug fix" → Too vague. What bug was fixed? + - "Update README" → What was updated? Be precise. + - "Refactoring" → Explain what was refactored and why. + + **Example of a good PR title:** ``Improve error handling in JSON parser to prevent crashes`` -2. **Write a Meaningful PR Description** +2. **Write a Meaningful PR Description** - Your PR description should provide **clear context** for reviewers. Answer the following questions: + Your PR description should provide **clear context** for reviewers. Answer the following questions: - - **What does this PR do?** - - **Why is this change necessary?** - - **Are there any breaking changes?** - - **Does this PR fix any open issues?** (Reference issue numbers if applicable) + - **What does this PR do?** + - **Why is this change necessary?** + - **Are there any breaking changes?** + - **Does this PR fix any open issues?** (Reference issue numbers if applicable) Providing detailed descriptions makes the review process **faster and more efficient**. -3. **Make Your Change Against the Right Branch** +3. **Make Your Change Against the Right Branch** - Ensure your PR is based on the correct branch: + Ensure your PR is based on the correct branch: - - **New changes should target the** ``main`` **branch unless they are specific to an older version.** - - If a change affects older versions, it will be **backported** after merging. - - Only use **maintenance branches** when the change does not apply to ``main`` or requires a different approach. + - **New changes should target the** ``main`` **branch unless they are specific to an older version.** + - If a change affects older versions, it will be **backported** after merging. + - Only use **maintenance branches** when the change does not apply to ``main`` or requires a different approach. Refer to :ref:`branch-merge` for more details on how backporting works. -4. **Follow Python's Style Guidelines** +4. **Follow Python's Style Guidelines** - - Python code should follow :PEP:`8`, and C code should follow :PEP:`7`. - - Maintainers may **fix minor style issues**, but major deviations can **delay or block merging**. - - PRs with **only style changes** are usually rejected unless they fix a formatting error. + - Python code should follow :PEP:`8`, and C code should follow :PEP:`7`. + - Maintainers may **fix minor style issues**, but major deviations can **delay or block merging**. + - PRs with **only style changes** are usually rejected unless they fix a formatting error. - .. note:: - Fixes for typos and grammar errors in documentation and docstrings are always welcome. + .. note:: + Fixes for typos and grammar errors in documentation and docstrings are always welcome. -5. **Consider Backward Compatibility** +5. **Consider Backward Compatibility** - - Changes should **not break existing code** unless absolutely necessary. - - When introducing **new arguments**, provide **default values** to maintain existing behavior. - - If unsure, refer to :PEP:`387` or discuss the issue with experienced maintainers in :ref:`communication`. + - Changes should **not break existing code** unless absolutely necessary. + - When introducing **new arguments**, provide **default values** to maintain existing behavior. + - If unsure, refer to :PEP:`387` or discuss the issue with experienced maintainers in :ref:`communication`. Think about how your change affects existing users before submitting your PR. -6. **Ensure Proper Testing** +6. **Ensure Proper Testing** - - Every PR should include **appropriate test cases** to validate the changes. - - PRs without tests **will not be accepted** unless they are purely documentation changes. - - Tests should **cover edge cases** and expected behaviors. - - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. + - Every PR should include **appropriate test cases** to validate the changes. + - PRs without tests **will not be accepted** unless they are purely documentation changes. + - Tests should **cover edge cases** and expected behaviors. + - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. -7. **Make Sure All Tests Pass** +7. **Make Sure All Tests Pass** - - The entire test suite must **run without failures** before submission. - - Run ``make test`` or refer to :ref:`runtests` to check for test failures. - - Do not submit PRs with failing tests unless the failure is **directly related** to your change. + - The entire test suite must **run without failures** before submission. + - Run ``make test`` or refer to :ref:`runtests` to check for test failures. + - Do not submit PRs with failing tests unless the failure is **directly related** to your change. -8. **Keep Documentation Up to Date** +8. **Keep Documentation Up to Date** - - Any change affecting functionality should include relevant **documentation updates**. - - Follow :ref:`documenting` guidelines to ensure consistency in documentation. + - Any change affecting functionality should include relevant **documentation updates**. + - Follow :ref:`documenting` guidelines to ensure consistency in documentation. Keeping documentation updated ensures clarity for future contributors and users. From 5932e90513684cb34c010dd76693733fde864eca Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:41:53 +0530 Subject: [PATCH 04/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 5e61a0d6d..1e10caa28 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -255,7 +255,7 @@ When creating a pull request, following best practices ensures your contribution - Tests should **cover edge cases** and expected behaviors. - For bug fixes, add a test that **fails without the fix** and **passes after applying it**. -7. **Make Sure All Tests Pass** +#. **Ensure all tests pass** - The entire test suite must **run without failures** before submission. - Run ``make test`` or refer to :ref:`runtests` to check for test failures. From 1c12ebdc237a92f19033881feb24b767af1839f0 Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:42:42 +0530 Subject: [PATCH 05/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 1e10caa28..ea40b05ac 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -271,7 +271,6 @@ When creating a pull request, following best practices ensures your contribution By following these best practices, you increase the likelihood of your PR being **quickly reviewed and merged**! - Copyrights ========== From 980bac071a89ce23c46bb931dfb8b0670ac53c57 Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:43:24 +0530 Subject: [PATCH 06/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index ea40b05ac..047b26bdd 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -208,7 +208,7 @@ When creating a pull request, following best practices ensures your contribution **Example of a good PR title:** - ``Improve error handling in JSON parser to prevent crashes`` + ``gh-128002: Simplify all_tasks to use PyList_Extend instead of manual iteration`` 2. **Write a Meaningful PR Description** From bd58b77340acd84803b0697309dcac33d55f88af Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:43:40 +0530 Subject: [PATCH 07/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 047b26bdd..e54724090 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -214,7 +214,7 @@ When creating a pull request, following best practices ensures your contribution Your PR description should provide **clear context** for reviewers. Answer the following questions: - - **What does this PR do?** + - What does this PR do? - **Why is this change necessary?** - **Are there any breaking changes?** - **Does this PR fix any open issues?** (Reference issue numbers if applicable) From e43ccdfe38fbca140bbd9cb8b91d0b89900f3efb Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:44:07 +0530 Subject: [PATCH 08/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index e54724090..a20c89c2f 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -268,7 +268,7 @@ When creating a pull request, following best practices ensures your contribution Keeping documentation updated ensures clarity for future contributors and users. -By following these best practices, you increase the likelihood of your PR being **quickly reviewed and merged**! +By following these best practices, you increase the likelihood of your PR being **reviewed and merged**! Copyrights From d36d02ec2b3c1561e3a475742228e0a3a62b98ba Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:44:49 +0530 Subject: [PATCH 09/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index a20c89c2f..79f00667f 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -210,7 +210,7 @@ When creating a pull request, following best practices ensures your contribution ``gh-128002: Simplify all_tasks to use PyList_Extend instead of manual iteration`` -2. **Write a Meaningful PR Description** +#. **Write a detailed description** Your PR description should provide **clear context** for reviewers. Answer the following questions: From 057d5b4e9e5216c8860a55c34de7e97751d0ee76 Mon Sep 17 00:00:00 2001 From: Swasti Mishra <140950062+swastim01@users.noreply.github.com> Date: Wed, 12 Feb 2025 13:47:06 +0530 Subject: [PATCH 10/10] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 79f00667f..90b2138b1 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -200,12 +200,6 @@ When creating a pull request, following best practices ensures your contribution - Use the **imperative mood** (e.g., "Fix crash in parser" instead of "Fixed a crash in parser"). - Be specific about what is being changed (avoid vague words like "Update" or "Fix"). - **Avoid:** - - - "Bug fix" → Too vague. What bug was fixed? - - "Update README" → What was updated? Be precise. - - "Refactoring" → Explain what was refactored and why. - **Example of a good PR title:** ``gh-128002: Simplify all_tasks to use PyList_Extend instead of manual iteration`` pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy