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``