Process: Add documentation for labels, current and proposed

Author: inexorabletash

CONTRIBUTING.md

@@ -26,7 +26,8 @@ Similarly, a stylistic change does not necessarily require opening a GitHub Issu
 Follow the guidance in [SpecCodingConventions.md](SpecCodingConventions.md) for your change to ensure it aligns with best practices and existing conventions.
 
 Bug fixes and new content changes should proceed as follows:
-1. **Open an issue in GitHub Issues** with a brief description of the problem and a potential solution if it's not already obvious. A proposal or suggestion for improvement may need a bit more explanation with possible references to related information. An active issue is the best way to get attention. Members of the Working Group scan active issues constantly.
+1. **Open an issue in GitHub Issues** with a brief description of the problem and a potential solution if it's not already obvious. A proposal or suggestion for improvement may need a bit more explanation with possible references to related information. An active issue is the best way to get attention. Members of the Working Group scan active issues constantly and should apply labels to help categorize them, following the guidance in [IssueTriage.md](IssueTriage.md). If you're a member of the Working Group, please apply appropriate labels to the new issue.
+
 2. **Prepare the change in a pull request** and put a reference to the active issue(s) the change is addressing in the description. We prefer that a pull request is represented by a single type of change as outlined in the previous section for a speedy review and approval. Conversely, a specific change should also be captured by a single and not multiple pull requests. This helps to reduce the dependency between pull requests and the chance for the specification to be left in a transient state between multiple pull requests. Exceptions to this should be discussed and approved by the Working Group in one of our bi-weekly calls.
 
 3. **Close the issue** once the pull request is reviewed and merged. Make sure to resolve any error that arises during the merge and check the post-merged published result. The Bikeshed document format isn't very good for an automatic merge, you may need to intervene and manually correct the merge's mistakes if any. You also want to make sure all the GitHub Actions that are put in place to catch document issues are all clean before merging the change into the main branch.

IssueTriage.md

@@ -40,13 +40,15 @@ These broad categories describe the projected impact on the specification and im
 
 TODO: I'm not convinced of the utility of these; maybe drop them?
 
+
 ## Issue Scope
 
 Every issue should have at least one of these issue types, but occasionally multiple.
 
 - **operation set** - discussions about the overall operator coverage of WebNN; examples include alignment with other published operator sets, use cases that require multiple new operators, compatibility with implementations, etc.
 - **operator specific** - _PROPOSED_ - issues regarding the specification of a single operator or small number of operators
 
+
 ## Next Steps
 
 - **question** - there is outstanding discussion needed on the issue before progress can be made
@@ -59,6 +61,7 @@ Every issue should have at least one of these issue types, but occasionally mult
 - **needs WPT** - _PROPOSED_ - a corresponding Web Platform Test should be filed, either to capture new behavior or cover a gap
 - **has WPT** - _PROPOSED_ - test coverage exists (either merged or in review)
 
+
 ## Resolved Issues
 
 These labels can be applied to issues when the issue is closed. This is helpful to capture why the issue was closed if it isn't clear from context.