Merge branch 'main' of https://github.com/a-sully/webnn into fix-689

.github/workflows/auto-publish.yml

@@ -23,3 +23,21 @@ jobs:
           W3C_BUILD_OVERRIDE: |
             TR: https://www.w3.org/TR/webnn/
             status: CRD
+      - name: WebNN - Lint Bikeshed Source and Generated HTML
+        id: webnn-lint
+        shell: bash
+        env:
+          BIKESHED_SOURCE: "index.bs"
+          GENERATED_HTML: "index.bs.built.html"
+        run: |
+          echo "::group::Install Lint Tool Dependencies"
+          cd tools
+          npm install
+          cd ..
+          echo "::endgroup::"
+          echo "::group::Generate Static HTML"
+          bikeshed --die-on=warning spec $BIKESHED_SOURCE $GENERATED_HTML
+          echo "::endgroup::"
+          echo "::group::Run Lint Tool"
+          node tools/lint.mjs --verbose --bikeshed $BIKESHED_SOURCE --html $GENERATED_HTML
+          echo "::endgroup::"

CONTRIBUTING.md

@@ -30,6 +30,9 @@ Bug fixes and new content changes should proceed as follows:
 
 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.
 
+    - See [Bikeshed](https://speced.github.io/bikeshed/) for the tooling used for authoring and building the spec. Additionally, a ["lint tool"](tools/lint.mjs) is used to catch common errors and enforce style. GitHub Actions will run these automatically for any pull request that modifies the spec source, but it's helpful to run the tools locally to test and verify your changes.
+    - When updating your pull request in response to reviewer feedback, *do not squash the commits*. This allows reviewers to inspect only new commits to the pull request on GitHub.
+
 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.
 
 A pull request can be merged when it has received an adequate review from the Working Group. The editors and the chair are responsible for ensuring review is sought from appropriate people. For substantive changes, the adequate review is between two or more reviewers. The bi-weekly teleconference calls provide another venue for providing feedback and reviewing open pull requests.

docs/SpecCodingConventions.md

@@ -125,6 +125,8 @@ Example:
 * Do not include assertions about argument types. This is redundant with Web IDL declaration.
 * Do not include steps that test argument types if those types are guaranteed by WebIDL.
 * Do not refer to JavaScript or WebIDL types in method steps. Per the spec processing model, by the time a spec algorithm is invoked, JavaScript types (e.g. Numbers, Arrays) have been mapped to WebIDL types (e.g. unsigned longs, sequences) and those have been mapped to Infra types or general concepts (e.g. numbers, lists).
+    * In particular, avoid using "sequence" in prose, as recurrent operators deal with temporal sequences. Just use "list" in algorithms, or "array" in developer-facing examples.
+    * There is an exception to this rule: Referring to WebIDL types is necessary when dealing with unions. In this case, refer to the full WebIDL type, e.g. _If splits is an `unsigned long` ... Otherwise, if splits is a `sequence<unsigned long>` ..._
 * Do not repeat detaults provided by the WebIDL declaration.
 * For types like lists that can't be defaulted in WebIDL, define the default when missing as an explicit step. Example: _If options.padding does not exist, set options.padding to « 0, 0, 0, 0 »._