From 94197c871c73ec93d32243a6d3b68d648e9b10b5 Mon Sep 17 00:00:00 2001 From: Hannah Date: Sun, 28 Apr 2024 21:47:29 +0700 Subject: [PATCH 1/2] Remove references to milestone & remove it from project management docs --- docs/devGuide/projectManagement.md | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/docs/devGuide/projectManagement.md b/docs/devGuide/projectManagement.md index 570de0fee..a05ab0e7d 100644 --- a/docs/devGuide/projectManagement.md +++ b/docs/devGuide/projectManagement.md @@ -22,13 +22,6 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http * **If the PR is very simple** (e.g. correcting a simple typo), one approval is sufficient for merging. Other PRs need two approvals. -* **Once the first approval is given** from a developer, assign a version milestone to the PR (this is usually the next version, unless there is a justification for delaying the merging to future versions). - - - - **Note:** Should there be a subsequent rejection by other reviewers (or an error is spotted), the version milestone is removed immediately. The version milestone should only be restored once the new approvals come in. - - * **Once the second approval is given** from a ==senior developer== (or there are >= 3 approvals given from anyone), the PR can be merged immediately.
If there is no second approval yet, wait for a day before merging the PR without the second approval. @@ -67,7 +60,7 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http - **Reason:** The release manager may not review all PRs, so please add the label to highlight the version impact of the PR. This helps to clarify which milestone the PR should be assigned to. + **Reason:** The release manager may not review all PRs, so please add the label to highlight the version impact of the PR. 1. **Draft the release note for breaking changes**. @@ -77,13 +70,6 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http **Reason:** The release manager may not have the full details of the PR, so please work with the PR author to prepare a release note (if applicable) in the PR description. -1. **Set a milestone** to the PR. - - - - **Reason:** We may have missed it during the "Approval" stage, so please add the version milestone if it is missing, so that the drafting of the release notes during the release process will be easier. - - 1. Tip: how to **undo an accidental merge commit.** * In the event of a wrong commit strategy chosen, you can undo the merge to master by: @@ -120,7 +106,7 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http - * Double check that the PRs are correctly set to the milestone for the new version. Review the definition of [SEMVER](https://semver.org/) and the impact of the PRs. + * Double check that the PRs are appropriate for the new version. Review the definition of [SEMVER](https://semver.org/) and the impact of the PRs. * We will specify updated version numbers exactly to ensure that each version will consistently fetch the same versioned internal packages. * The end result of this command is version commit with an appropriate tag. We will make use of the generated tag and commit message later. * Do not push this commit to the remote repository yet. @@ -206,10 +192,6 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http $ npm run deploy:ug ``` -1. **Update milestones**. Close the [milestone on GitHub](https://github.com/MarkBind/markbind/milestones) and all issues in that milestone. - - Also create a new milestone for the next iterations. Recommended to have at least two upcoming milestones opened. Use the format `vA.B.C` for the milestone title. - 1. **Release on GitHub**. a. Go to the MarkBind release page at https://github.com/MarkBind/markbind/releases. @@ -380,5 +362,13 @@ Note that: * Some time later: "@all-contributors please add tlylt for doc" * Result: 'tlylt' will be updated to have both icons(code and doc) + +## Other Notes + + + + Previously, we used milestones to help manage versions, adding a milestone to an issue once related PRs had been merged. However, there was confusion over the use of milestones and labels, adding a milestone was often forgotten, and ultimately it was not sufficiently useful to the team. + + {% from "njk/common.njk" import previous_next %} {{ previous_next('githubActions/workflowSecurity', 'styleGuides') }} From 72098c9035676f7ef1ea804087a1df253b78124f Mon Sep 17 00:00:00 2001 From: Hannah <59471320+kaixin-hc@users.noreply.github.com> Date: Sun, 28 Apr 2024 22:03:20 +0700 Subject: [PATCH 2/2] Update docs/devGuide/projectManagement.md Co-authored-by: Chan Yu Cheng <77204346+yucheng11122017@users.noreply.github.com> --- docs/devGuide/projectManagement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/devGuide/projectManagement.md b/docs/devGuide/projectManagement.md index a05ab0e7d..02034a51d 100644 --- a/docs/devGuide/projectManagement.md +++ b/docs/devGuide/projectManagement.md @@ -367,7 +367,7 @@ Note that: - Previously, we used milestones to help manage versions, adding a milestone to an issue once related PRs had been merged. However, there was confusion over the use of milestones and labels, adding a milestone was often forgotten, and ultimately it was not sufficiently useful to the team. + Previously, we used milestones to help manage versions, adding a milestone to an issue once related PRs had been merged. However, there was confusion over the use of milestones and labels and adding a milestone was often forgotten. Hence, ultimately it was not sufficiently useful to the team. {% from "njk/common.njk" import previous_next %}