From 478f51c4bb516538da6825e9fe13677e1482b9ca Mon Sep 17 00:00:00 2001 From: Karel Zikmund Date: Sat, 3 Aug 2019 22:08:08 +0200 Subject: [PATCH] Update PR milestone motivation Commit migrated from https://github.com/dotnet/corefx/commit/2f9cb4b9caf33a2a6c69d8229c23ed4550079a14 --- docs/libraries/project-docs/issue-guide.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/libraries/project-docs/issue-guide.md b/docs/libraries/project-docs/issue-guide.md index 63eb7eb..2bbc430 100644 --- a/docs/libraries/project-docs/issue-guide.md +++ b/docs/libraries/project-docs/issue-guide.md @@ -140,6 +140,7 @@ Feel free to use other labels if it helps your triage efforts (e.g. **needs more * Motivation: Helps communicate desire/timeline to community. Can spark further priority/impact discussion. 1. Each issue has exactly one "*issue type*" label (**bug**, **enhancement**, **api-needs-work**, **test bug**, **test enhancement**, **question**, **documentation**, etc.) * Don't be afraid to be wrong when deciding 'bug' vs. 'test bug' (flip a coin if you must). The most useful values for tracking are 'api-*' vs. 'enhancement', 'question', and 'documentation'. + * Note: The **api-\*** labels are important for tracking API approvals, the other *issue type* labels are in practice optional. 1. Don't be afraid to say no, or close issues - just explain why and be polite 1. Don't be afraid to be wrong - just be flexible when new information appears @@ -150,8 +151,8 @@ Feel free to use other labels if it helps your triage efforts (e.g. **needs more 1. PR has **Assignee** set to author of the PR, if it is non-CoreFX engineer, then area owners are co-assignees * Motivation #1: Area owners are responsible to do code reviews for PRs from external contributors. CoreFX engineers know how to get code reviews from others. * Motivation #2: Assignees will get notifications for anything happening on the PR. -1. [Optional] Set milestone according to the branch (master = 2.1, release/2.0.0 = 2.0, release/1.0.0 = 1.0.x, release/1.1.0 = 1.1.x) - * Motivation: Easier to track where which fix ended and if it needs to be ported into another branch +1. [Optional] Set milestone according to the branch the PR is against (master = 5.0, release/3.0 = 3.0, release/2.1 = 2.1.x, etc.) + * Motivation: Easier to track and audit where which fix ended up and if it needs to be ported into another branch (hence reflecting branch the specific PR ended up and not the abstract issue). * Note: This is easily done after merge via simple queries & bulk-edits, you don't have to do this one. 1. Any other labels on PRs are superfluous and not needed (exceptions: **blocked**, **NO MERGE**) * Motivation: All the important info (*issue type* label, api approval label, OS label, etc.) is already captured on the associated issue. -- 2.7.4