Update "Labels, milestones, and projects" section

- Document new milestone workflow
- Add section on "affected release" label
- Miscellaneous updates, cleanup, and clarification

introduction/issue-tracking.md

@@ -82,8 +82,11 @@ that we use to keep
 
 ### Labels
 
-Only Qubes team members have permission to modify
+When an issue is first created, certain labels may automatically be applied to
-[labels](https://github.com/QubesOS/qubes-issues/labels) and
+it based on the type of issue the reporter selected. For example, if someone
+selects the "Bug report" template, then the `T: bug` label will automatically
+be applied to that issue. After that, only Qubes team members have permission
+to modify [labels](https://github.com/QubesOS/qubes-issues/labels) and
 [milestones](https://github.com/QubesOS/qubes-issues/milestones). Many labels
 and milestones have descriptions on them that can be viewed either in their
 respective lists or by hovering over them. Let's go over some of the most
@@ -91,7 +94,7 @@ important ones.
 
 #### Type
 
-There are three **types**: `T: bug`, `T: enhancement`, and `T: task`.
+There are three issue **types**: `T: bug`, `T: enhancement`, and `T: task`.
 
 - `T: bug` --- Type: bug report. A problem or defect resulting in unintended
   behavior in something that exists.
@@ -102,17 +105,18 @@ There are three **types**: `T: bug`, `T: enhancement`, and `T: task`.
 
 Every open issue should have **exactly one** type. An open issue should not
 have more than one type, and it should not lack a type entirely. Bug reports
-are for things that already exist. If something doesn't exist yet, but you
+are for problems in things that already exist. If something doesn't exist yet,
-think it should exist, then `T: enhancement`. If something already exists and
+but you think it ought to exist, then use `T: enhancement` instead. If
-could be improved in some way, `T: enhancement` is appropriate. `T: task` is
+something already exists, but you think it could be improved in some way, you
-for issues that fall under under neither `T: bug` nor `T: enhancement`.
+should again use `T: enhancement`. `T: task` is for issues that fall under
+under neither `T: bug` nor `T: enhancement`.
 
 #### Priority
 
-There are several **priority** levels ranging from `P: minor` to `P: blocker`
+There are several issue **priority** levels ranging from `P: minor` to `P:
-(see [here](https://github.com/QubesOS/qubes-issues/labels?q=P%3A) for the full
+blocker` (see [here](https://github.com/QubesOS/qubes-issues/labels?q=P%3A) for
-list). Every open issue should have **exactly one** priority. An open issue
+the full list). Every open issue should have **exactly one** priority. An open
-should not have more than one priority, and it should not lack a priority
+issue should not have more than one priority, and it should not lack a priority
 entirely. See [here](/doc/version-scheme/#bug-priorities) for details about how
 the developers use these priorities.
 
@@ -124,29 +128,35 @@ full list). Every open issue should have **at least one** component. An open
 issue may have more than one component, but it should not lack a component
 entirely. When no other component applies, use `C: other`.
 
+#### Affected release
+
+A label of the form `affects-<RELEASE_NUMBER>` indicates that an issue affects
+the corresponding Qubes OS release. An issue can have more than one of these
+labels if it affects multiple releases.
+
 ### Milestones
 
 The issue tracker has several
-[milestones](https://github.com/QubesOS/qubes-issues/milestones). Every issue
+[milestones](https://github.com/QubesOS/qubes-issues/milestones). Individual
-should be assigned to **exactly one** milestone. The issue tracker does not
+issues can be assigned to milestones. The issue tracker does not allow an issue
-allow assigning an issue to more than one milestone. If an issue is already
+to be assigned to more than one milestone. If an issue is already assigned to a
-assigned to a milestone, assigning it to a different one will *replace* the
+milestone, assigning it to a different one will *replace* the existing
-existing milestone assignment.
+milestone assignment. Each milestone has a progress indicator showing how close
+that milestone is to completion.
 
-Most milestones correspond to specific Qubes OS releases. For **bug reports**,
+Most milestones correspond to specific Qubes OS releases. The Qubes developers
-the milestone designates the *earliest supported release* in which that bug is
+decide which issues will be assigned to specific milestones. The general idea
-believed to exist. For **enhancements** and **tasks**,  the milestone indicates
+is that each milestone's progress indicator should provide a rough idea of how
-that the goal is to implement or do that thing *in* or *for* that release.
+much progress has been made on that milestone and how much work remains until
-
+the milestone is complete. Most issues will not be assigned to any milestone at
-The `Release TBD` (To Be Determined) milestone is for **enhancements** or
+all until a Qubes developer manually assigns it to one. While anyone is free to
-**tasks** that will be specific to a Qubes OS release but have yet to be
+open an issue, this does not create an obligation on the Qubes developers to
-assigned to a specific release milestone. **Bug reports** should never be
+act on that issue. Every open issue should be understood to be merely "under
-assigned to the `Release TBD` milestone, because every bug is a problem or
+consideration" unless or until a Qubes developer decides to assign it to a
-defect in something that already exists.
+milestone. Issues that are assigned to a milestone are issues that either the
-
+Qubes developers or another contributor plans to complete *for* that milestone.
-The `Non-release` milestone is for issues that are independent of the Qubes OS
+The Qubes developers reserve the right to modify or remove milestones at any
-release cycle, including (but not limited to) most website, documentation, and
+time at their discretion.
-project management issues.
 
 ### Projects