Update PR milestone motivation

Commit migrated from https://github.com/dotnet/corefx/commit/2f9cb4b9caf33a2a6c69d8229c23ed4550079a14

diff --git a/docs/libraries/project-docs/issue-guide.md b/docs/libraries/project-docs/issue-guide.md
index 63eb7eb..2bbc430 100644 (file)
--- 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.