Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove references to milestone & remove it from project management docs #2537

Merged
merged 2 commits into from
Apr 29, 2024
Merged

Remove references to milestone & remove it from project management docs #2537

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
94197c8
Remove references to milestone & remove it from project management docs
kaixin-hc Apr 28, 2024
72098c9
Update docs/devGuide/projectManagement.md
kaixin-hc Apr 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 10 additions & 20 deletions docs/devGuide/projectManagement.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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).

<box type="info" seamless>

**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.
</box>

* **Once the second approval is given** from a ==senior developer== (or there are >= 3 approvals given from anyone), the PR can be merged immediately.<br>
If there is no second approval yet, wait for a day before merging the PR without the second approval.

Expand Down Expand Up @@ -67,7 +60,7 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http

<box type="info" seamless>

**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.
</box>

1. **Draft the release note for breaking changes**.
Expand All @@ -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.
</box>

1. **Set a milestone** to the PR.

<box type="info" seamless>

**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.
</box>

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:
Expand Down Expand Up @@ -120,7 +106,7 @@ For general best practices, refer to the guide [_Working with PRs_ @SE-EDU](http

<box type="info" seamless>

* 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.
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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

<box type="info" icon=":fas-question:" icon-color="info" seamless header='About Milestones'>

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.
kaixin-hc marked this conversation as resolved.
Show resolved Hide resolved
</box>

{% from "njk/common.njk" import previous_next %}
{{ previous_next('githubActions/workflowSecurity', 'styleGuides') }}
Loading