Update docs - issues guide with new rules (labels, area labels, assignments, area owners).

4 files changed, 87 insertions, 30 deletions

diff --git a/Documentation/project-docs/api-review-process.md b/Documentation/project-docs/api-review-process.md
index d886912453..fae9d22bc6 100644
--- a/Documentation/project-docs/api-review-process.md
+++ b/Documentation/project-docs/api-review-process.md
@@ -4,7 +4,7 @@ The .NET Framework has a long standing history of taking API usability extremely
 
 ## Which APIs should be reviewed?
 
-The rule of thumb is that we (**corefx**) review every API that is being added to the `System.*` namespaces. In some cases, we also review APIs that are added to other namespaces, such as `Microsoft`. We mostly do this for high impact APIs, such as Roslyn, and when both the owner of the technology and we feel there is win-win for both sides if we review the APIs. However, we can't scale to review all APIs being added to .NET.
+The rule of thumb is that we (**corefx**) review every API that is being added to the `System.*` namespaces. In some cases, we also review APIs that are added to other namespaces, such as `Microsoft.*`. We mostly do this for high impact APIs, such as Roslyn, and when both the owner of the technology and we feel there is win-win for both sides if we review the APIs. However, we can't scale to review all APIs being added to .NET.
 
 ## Process
 
diff --git a/Documentation/project-docs/developer-guide.md b/Documentation/project-docs/developer-guide.md
index 38eebaaf1e..8743f7dc02 100644
--- a/Documentation/project-docs/developer-guide.md
+++ b/Documentation/project-docs/developer-guide.md
@@ -118,7 +118,7 @@ Under the src directory is a set of directories, each of which represents a part
   
 For example the src\System.Diagnostics.DiagnosticSource directory holds the source code for the System.Diagnostics.DiagnosticSource.dll assembly. Each of these directories includes two projects, one for the DLL being built and one for the tests, both specified by a .builds file.
 
-You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the src\System.Diagnostics.DiagnosticsSource\src directory and typing `msbuild System.Diagnostics.DiagnosticSource.builds`. The DLL ends up as  bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource\System.DiagnosticSource.dll.
+You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the src\System.Diagnostics.DiagnosticsSource\src directory and typing `msbuild System.Diagnostics.DiagnosticSource.builds`. The DLL ends up in bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource.
 
 You can build the tests for System.Diagnostics.DiagnosticSource.dll by going to 
 src\System.Diagnostics.DiagnosticSource\tests and typing `msbuild System.Diagnostics.DiagnosticSource.Tests.builds`.
diff --git a/Documentation/project-docs/issue-guide.md b/Documentation/project-docs/issue-guide.md
index 6a20c922dd..8c18a2436d 100644
--- a/Documentation/project-docs/issue-guide.md
+++ b/Documentation/project-docs/issue-guide.md
@@ -6,33 +6,90 @@ This page outlines how the CoreFx team thinks about and handles issues.  For us,
 ### When we close issues
 As noted above, we don't close issues just because we don't plan to address them in an upcoming release.  So why do we close issues?  There are few major reasons:
 
-1. Issues unrelated to CoreFx.  When possible, we'll try to find a better home for the issue and open it there on your behalf.
+1. Issues unrelated to CoreFx.  When possible, we'll try to find a better home for the issue and point you to it.
 2. Cross cutting work better suited for another team.  Sometimes the line between the framework, languages and runtime blurs.  For some issues, we may feel that the work is better suited for the runtime team, language team or other partner.  In these cases, we'll close the issue and open it with the partner team.  If they end up not deciding to take on the issue, we can reconsider it here.
-3. Nebulous and Large open issues.  Large open issues are sometimes better suited for [User Voice](http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481--net), especially when the work will cross the boundaries of the framework, language and runtime.  A good example of this is the SIMD support we recently added to CoreFx.  This started as a User Voice request, and eventually turned into work for both the core libraries and runtime.
+3. Nebulous and Large open issues.  Large open issues are sometimes better suited for [User Voice](http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481--net), especially when the work will cross the boundaries of the framework, language and runtime.  A good example of this is the SIMD support we recently added to CoreFx.  This started as a [User Voice request](https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2212443-c-and-simd), and eventually turned into work for both the core libraries and runtime.
 
-Sometimes after debate, we'll decide an issue isn't a good fit for CoreFx.  In that case, we'll also close it.  Because of this, we ask that you don't start working on an issue until it's tagged with "up for grabs" or "feature approved".  Both you and the team will be unhappy if you spend time and effort working on a change we'll ultimately be unable to take. We try to avoid that.
+Sometimes after debate, we'll decide an issue isn't a good fit for CoreFx.  In that case, we'll also close it.  Because of this, we ask that you don't start working on an issue until it's tagged with [up for grabs](https://github.com/dotnet/corefx/labels/up%20for%20grabs) or [api-approved](https://github.com/dotnet/corefx/labels/api-approved).  Both you and the team will be unhappy if you spend time and effort working on a change we'll ultimately be unable to take. We try to avoid that.
 
 ### Labels
-We use GitHub labels on our issues in order to classify them.  We have the following categories per issue:
-* **Area**: These labels call out the assembly or assemblies the issue applies to. In addition to tags per assembly, we have a few other tags: Infrastructure, for issues that relate to our build or test infrastructure, and Meta for issues that deal with the repository itself, the direction of the .NET Core Platform, our processes, etc.
-* **Type**: These labels classify the type of issue.  We use the following types:
- * [api addition](https://github.com/dotnet/corefx/labels/api%20addition): Issues which would add APIs to an assembly.
- * [bug](https://github.com/dotnet/corefx/labels/bug): Issues for bugs in an assembly.
- * [documentation](https://github.com/dotnet/corefx/labels/documentation): Issues relating to documentation (e.g. incorrect documentation, enhancement requests)
- * [enhancement](https://github.com/dotnet/corefx/labels/enhancement): Issues related to an assembly that improve it, but do not add new APIs (e.g performance improvements, code cleanup)
- * [test bug](https://github.com/dotnet/corefx/labels/test%20bug): Issues for bugs in the tests for a specific assembly.
-* **Ownership**: These labels are used to specify who owns specific issue. Issues without an ownership tag are still considered "up for discussion" and haven't been approved yet. We have the following different types of ownership:
- * [up for grabs](https://github.com/dotnet/corefx/labels/up%20for%20grabs): Small sections of work which we believe are well scoped. These sorts of issues are a good place to start if you are new.  Anyone is free to work on these issues.
- * [feature approved](https://github.com/dotnet/corefx/labels/feature%20approved): Larger scale issues.  Like up for grabs, anyone is free to work on these issues, but they may be trickier or require more work.
- * [grabbed by community](https://github.com/dotnet/corefx/labels/grabbed%20by%20community): Someone outside the CoreFx team has assumed responsibility for addressing this issue and is working on a fix.  The comments for the issue will call out who is working on it.  You shouldn't try to address the issue without coordinating with the owner.
- * [grabbed by assignee](https://github.com/dotnet/corefx/labels/grabbed%20by%20assignee): Like grabbed by community, except the person the issue is assigned to is making a fix.  This will be someone on the CoreFx team.
-* **Project Management**: CoreFX uses [milestones](https://github.com/dotnet/corefx/milestones) to prioritize work for each upcoming release to NuGet.org.  In addition to milestones, these labels are also used to indicate the current status of an issue.
- * [0 - Backlog](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3A%220+-+Backlog%22): Tasks that are not yet ready for development or are not yet prioritized for the current development cycle.
- * [1 - Up Next](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3A%221+-+Up+Next%22): Tasks that are ready for development and prioritized above the rest of the backlog.
- * [2 - In Progress](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3A%222+-+In+Progress%22): Tasks that are under active development.
- * [3 - Done](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3A%223+-+Done%22): Tasks that are finished.  There should be no open issues in the Done stage.
-
-In addition to the above, we have a handful of other labels we use to help classify our issues.  Some of these tag cross cutting concerns (e.g. cross platform, performance, serialization impact) where as others are used to help us track additional work needed before closing an issue (e.g. needs API review). Finally, we have the "needs more info" label.  We use this label to mark issues where we need more information in order to proceed.  Usually this will be because we can't reproduce a reported bug.  We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue.
+We use GitHub [labels](https://github.com/dotnet/corefx/labels) on our issues in order to classify them.  We have the following categories per issue:
+* **Area**: These area-* labels (e.g. [area-System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections)) call out the assembly or assemblies the issue applies to. In addition to labels per assembly, we have a few other area labels: [Infrastructure](https://github.com/dotnet/corefx/labels/Infrastructure), for issues that relate to our build or test infrastructure, and [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta) for issues that deal with the repository itself, the direction of the .NET Core Platform, our processes, etc. See [full list of areas](#areas).
+* **Issue Type**: These labels classify the type of issue.  We use the following types:
+ * [bug](https://github.com/dotnet/corefx/labels/bug): Bugs in an assembly.
+ * api-* ([api-approved](https://github.com/dotnet/corefx/labels/api-approved), [api-needs-work](https://github.com/dotnet/corefx/labels/api-needs-work)): Issues which would add APIs to an assembly (see [API Review process](api-review-process.md) for details).
+ * [enhancement](https://github.com/dotnet/corefx/labels/enhancement): Improvements to an assembly which do not add new APIs (e.g. performance improvements, code cleanup).
+ * [test bug](https://github.com/dotnet/corefx/labels/test%20bug): Bugs in the tests for a specific assembly.
+ * [test enhancement](https://github.com/dotnet/corefx/labels/test%20enhancement): Improvements in the tests for a specific assembly (e.g. improving test coverage).
+ * [documentation](https://github.com/dotnet/corefx/labels/documentation): Issues related to documentation (e.g. incorrect documentation, enhancement requests).
+ * [question](https://github.com/dotnet/corefx/labels/question): Questions about the product, source code, etc.
+* **Other**:
+ * [up for grabs](https://github.com/dotnet/corefx/labels/up%20for%20grabs): Small sections of work which we believe are well scoped.  These sorts of issues are a good place to start if you are new.  Anyone is free to work on these issues.
+ * [needs more info](https://github.com/dotnet/corefx/labels/needs%20more%20info): Issues which need more information to be actionable.  Usually this will be because we can't reproduce a reported bug.  We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue.
+
+In addition to the above, we have a handful of other labels we use to help classify our issues.  Some of these tag cross cutting concerns (e.g. [cross platform](https://github.com/dotnet/corefx/labels/X-Plat), [tenet-performance](https://github.com/dotnet/corefx/labels/tenet-performance)), whereas others are used to help us track additional work needed before closing an issue (e.g. [api-needs-exposed](https://github.com/dotnet/corefx/labels/api-needs-exposed)).
+
+### Milestones
+We use [milestones](https://github.com/dotnet/corefx/milestones) to prioritize work for each upcoming release to NuGet.org.
 
 ### Assignee
-We assign each issue to a CoreFx team member.  In most cases, the assignee will not be the one who ultimately fixes the issue (that only happens in the case where the issue is tagged "grabbed by assignee"). The purpose of the assignee is to act as a point of contact between the CoreFx team and the community for the issue and make sure it's driven to resolution.  If you're working on an issue and get stuck, please reach out to the assignee (just at mention them)  and they will work to help you out.
+We assign each issue to assignee, when the assignee is ready to pick up the work and start working on it.  If the issue is not assigned to anyone and you want to pick it up, please say so - we will assign the issue to you.  If the issue is already assigned to someone, please coordinate with the assignee before you start working on it.
+
+Note: This is a new scheme introduced in 2016/9.  The old scheme used assignees as area owners.  We will migrate issues to the new scheme throughout 2016.
+
+### Areas
+Areas are tracked by labels area-* (e.g. area-System.Collections), or Infrastructure. Each area typically corresponds to one or more contract assemblies.
+
+| Area                                                                                          | Owners / experts | Description | Triage Status |
+|-----------------------------------------------------------------------------------------------|------------------|-------------|--------------------|
+| [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta)                                |  | Issues without clear association to any specific API/contract (e.g. packaging, project-wide docs) |  |
+| [Infrastructure](https://github.com/dotnet/corefx/labels/Infrastructure)                      |  |  |  |
+| [area-Serialization](https://github.com/dotnet/corefx/labels/area-Serialization)                   |  |  |  |
+| **System contract assemblies** | | | |
+| [System.AppContext](https://github.com/dotnet/corefx/labels/area-System.AppContext)           |  |  |  |
+| [System.Buffers](https://github.com/dotnet/corefx/labels/area-System.Buffers)                 |  |  |  |
+| [System.CodeDom](https://github.com/dotnet/corefx/labels/area-System.CodeDom)                 |  |  |  |
+| [System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections)         | @priya91, @ianhays |  | Triaged |
+| [System.ComponentModel](https://github.com/dotnet/corefx/labels/area-System.ComponentModel)   |  |  |  |
+| [System.ComponentModel.DataAnnotations](https://github.com/dotnet/corefx/labels/area-System.ComponentModel.DataAnnotations) |  |  |  |
+| [System.Composition](https://github.com/dotnet/corefx/labels/area-System.Composition)         |  |  |  |
+| [System.Console](https://github.com/dotnet/corefx/labels/area-System.Console)                 |  |  |  |
+| [System.Data](https://github.com/dotnet/corefx/labels/area-System.Data)                       |  |  |  |
+| [System.Data.SqlClient](https://github.com/dotnet/corefx/labels/area-System.Data.SqlClient)   |  |  |  |
+| [System.Diagnostics](https://github.com/dotnet/corefx/labels/area-System.Diagnostics)         |  |  |  |
+| [System.Diagnostics.Process](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Process) |  |  |  |
+| [System.Diagnostics.Tracing](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Tracing) |  |  |  |
+| [System.DirectoryServices](https://github.com/dotnet/corefx/labels/area-System.DirectoryServices) |  |  |  |
+| [System.Drawing](https://github.com/dotnet/corefx/labels/area-System.Drawing)                 |  |  |  |
+| [System.Dynamic.Runtime](https://github.com/dotnet/corefx/labels/area-System.Dynamic.Runtime) |  |  |  |
+| [System.Globalization](https://github.com/dotnet/corefx/labels/area-System.Globalization)     |  |  |  |
+| [System.IO](https://github.com/dotnet/corefx/labels/area-System.IO)                           | @JeremyKhune, @ianhays |  | Triaged |
+| [System.IO.Compression](https://github.com/dotnet/corefx/labels/area-System.IO.Compression)   | @ianhays |  | Triaged |
+| [System.Linq](https://github.com/dotnet/corefx/labels/area-System.Linq)                       |  |  |  |
+| [System.Linq.Expressions](https://github.com/dotnet/corefx/labels/area-System.Linq.Expressions)   |  |  |  |
+| [System.Linq.Parallel](https://github.com/dotnet/corefx/labels/area-System.Linq.Parallel)     |  |  |  |
+| [System.Net](https://github.com/dotnet/corefx/labels/area-System.Net)                         |  |  |  |
+| [System.Numerics](https://github.com/dotnet/corefx/labels/area-System.Numerics)               | @mellinoe |  | Triaged |
+| [System.Reflection](https://github.com/dotnet/corefx/labels/area-System.Reflection)           |  |  |  |
+| [System.Reflection.Emit](https://github.com/dotnet/corefx/labels/area-System.Reflection.Emit) |  |  |  |
+| [System.Reflection.Metadata](https://github.com/dotnet/corefx/labels/area-System.Reflection.Metadata) |  |  |  |
+| [System.Resources](https://github.com/dotnet/corefx/labels/area-System.Resources)             |  |  |  |
+| [System.Runtime](https://github.com/dotnet/corefx/labels/area-System.Runtime)                 |  |  |  |
+| [System.Runtime.CompilerServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.CompilerServices)   |  |  |  |
+| [System.Runtime.Extensions](https://github.com/dotnet/corefx/labels/area-System.Runtime.Extensions)   |  |  |  |
+| [System.Runtime.InteropServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.InteropServices) |  |  |  |
+| [System.Security](https://github.com/dotnet/corefx/labels/area-System.Security)               |  |  |  |
+| [System.ServiceModel](https://github.com/dotnet/corefx/labels/area-System.ServiceModel)       |  |  |  |
+| [System.ServiceProcess](https://github.com/dotnet/corefx/labels/area-System.ServiceProcess)   |  |  |  |
+| [System.Text.Encoding](https://github.com/dotnet/corefx/labels/area-System.Text.Encoding)     |  |  |  |
+| [System.Text.RegularExpressions](https://github.com/dotnet/corefx/labels/area-System.Text.RegularExpressions) | @priya91 |  |  |
+| [System.Threading](https://github.com/dotnet/corefx/labels/area-System.Threading)             | @kouvel, @alexperovich |  | Triaged |
+| [System.Transactions](https://github.com/dotnet/corefx/labels/area-System.Transactions)       |  |  |  |
+| [System.Xml](https://github.com/dotnet/corefx/labels/area-System.Xml)                         | @sepidehMS, @krwq  | | Triaged |
+| [System](https://github.com/dotnet/corefx/labels/area-System)                                 |  | Issues without clear contract association (corss-contract, or potentially new contracts) |  |
+| **Microsoft contract assemblies** | | |  |
+| [Microsoft.CSharp](https://github.com/dotnet/corefx/labels/area-Microsoft.CSharp)             |  |  |  |
+| [Microsoft.VisualBasic](https://github.com/dotnet/corefx/labels/area-Microsoft.VisualBasic)   |  |  |  |
+| [Microsoft.Win32](https://github.com/dotnet/corefx/labels/area-Microsoft.Win32)               |  |  |  |
+
+Note: Area triage will apply the new scheme (issue types and assignee) throughout 2016.
diff --git a/Documentation/project-docs/triage.md b/Documentation/project-docs/triage.md
index d7dc430d21..edc8f48b89 100644
--- a/Documentation/project-docs/triage.md
+++ b/Documentation/project-docs/triage.md
@@ -24,7 +24,7 @@ Of course, teams aren't hostage to the set of themes and scenarios. But they pro
 
 ## What this means for CoreFx
 
-Our goal is to become a bit more trigger happy when it comes to closing issues. We've currently over 700 open issues on the corefx repo alone. We've noticed that our design review process is a major bottleneck for adding new features, in particular when we're adding APIs to types that are shared with the .NET Framework: we need to think about how we can reconcile that difference in the future so that you can still author libraries that can run on both platforms.
+Our goal is to become a bit more trigger happy when it comes to closing issues. We've currently over 1,400 open issues on the corefx repo alone. We've noticed that our design review process is a major bottleneck for adding new features, in particular when we're adding APIs to types that are shared with the .NET Framework: we need to think about how we can reconcile that difference in the future so that you can still author libraries that can run on both platforms.
 
 We owe our customers -- and this includes our open source community -- that we don't lose track of what's important. We do, however, want to make sure we can continuously improve small things as well. We strongly believe that one of the key reasons open source is so successful is because it encourages a mindset of small changes over time.
 
@@ -66,6 +66,6 @@ Here are some of the factors that are considered:
  
 Generally, all changes are expected to be tracked as GitHub issues. We are going to introduce the following three labels on GitHub to track and report progress around porting:
 
-* **netfx-port-consider**: A given issue should be considered for inclusion in the .NET Framework. Once an issue has this label, the team will consider it for inclusion in the .NET Framework.
-* **netfx-port-approve**: If the proposed change is shown to add value and not introduce unmitigated risk then the issue will be checked in and ship in a future release of the .NET Framework. Marking an issue with this label does not imply that it will ship in the next release or any specific release of the .NET Framework.
-* **netfx-port-decline**: If the proposed change does not align with our business goals or introduces unmitigated risk, the issue will not be included in the .NET Framework. In the event of this scenario, we will add a comment on the issue.
\ No newline at end of file
+* [**netfx-port-consider**](https://github.com/dotnet/corefx/labels/netfx-port-consider): A given issue should be considered for inclusion in the .NET Framework. Once an issue has this label, the team will consider it for inclusion in the .NET Framework.
+* [**netfx-port-approved**](https://github.com/dotnet/corefx/labels/netfx-port-approved): If the proposed change is shown to add value and not introduce unmitigated risk then the issue will be checked in and ship in a future release of the .NET Framework. Marking an issue with this label does not imply that it will ship in the next release or any specific release of the .NET Framework.
+* [**netfx-port-declined**](https://github.com/dotnet/corefx/labels/netfx-port-declined): If the proposed change does not align with our business goals or introduces unmitigated risk, the issue will not be included in the .NET Framework. In the event of this scenario, we will add a comment on the issue.