Add docs/ directory

CONTRIBUTING.md

@@ -23,10 +23,10 @@ Wording change does not require opening a GitHub Issue, as the change in the pul
 
 Similarly, a stylistic change does not necessarily require opening a GitHub Issue. It does, however, require buy-ins from the Working Group to proceed. The best way to propose this type of change is to attend one of the bi-weekly Web Machine Learning Working Group teleconference calls. A practical way to reach out to the Working Group to get invited to the teleconference call is to post a GitHub Issue giving a rough explanation of the proposed change and ask to be invited.
 
-Follow the guidance in [SpecCodingConventions.md](SpecCodingConventions.md) for your change to ensure it aligns with best practices and existing conventions.
+Follow the guidance in [SpecCodingConventions.md](docs/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 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.
+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](docs/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.