From 6d664ccd95eeb3bd65a4d5c0cb01aafd3f7ab5a5 Mon Sep 17 00:00:00 2001 From: Tomoko Uchida Date: Sat, 27 Aug 2022 13:02:48 +0900 Subject: [PATCH] adjast wording --- dev-docs/github-issues-howto.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/dev-docs/github-issues-howto.md b/dev-docs/github-issues-howto.md index 1b56255bb4c8..a9a3a61fe71f 100644 --- a/dev-docs/github-issues-howto.md +++ b/dev-docs/github-issues-howto.md @@ -23,12 +23,10 @@ under the License. We use Milestones for release planning. -A milestone represents a release. All issues/PRs associated with a milestone must be resolved before the release, which means unresolved issues/PRs in a milestone are blockers for the release. +A milestone represents a release. All issues/PRs associated with a milestone must be resolved before the release, which means unresolved issues/PRs in a milestone are blockers for the release. Release managers should consider how to address blockers. Some may be resolved by developers, and others may be postponed to future releases. The Milestone associated with an Issue/PR should be the same version in CHANGES. For instance, if an Issue/PR appears in the CHANGES section 10.0.0, it should be marked as Milestone 10.0.0. -Release managers should consider how to address blockers. Some may be resolved by developers, and others may be postponed to future releases. - Once the release is done, the Milestone should be closed then a new Milestone for the next release should be created. See [GitHub documentation](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones) for more details.