Switch to YAML and GitHub data

This changes the data format for activities from JSON to YAML, and uses information from the GitHub issues (the OP and labels). The data is presented on a new dashboard website. There's a workflow to push the `merged-data.json` file to `gh-pages` to publish.

.github/workflows/build-and-deploy.yml

@@ -0,0 +1,54 @@
+name: Build and Deploy
+
+on:
+  schedule:
+    - cron: '0 */6 * * *' # Runs every 6 hours
+  push:
+    branches:
+      - main
+  workflow_dispatch: # Allows manual trigger
+
+jobs:
+  build_and_deploy:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4
+
+      - name: Set up SSH for Git (deploy key)
+        run: |
+          mkdir -p ~/.ssh
+          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
+          chmod 600 ~/.ssh/id_ed25519
+          ssh-keyscan github.com >> ~/.ssh/known_hosts
+
+      - name: Set up Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.x'
+
+      - name: Install Dependencies
+        run: |
+          python3 -m pip install --upgrade pip
+          pip install -r requirements.txt
+
+      - name: Fetch GitHub data
+        run: |
+          python3 gh-data.py
+
+      - name: Merge data sources
+        run: |
+          python3 merge-data.py
+
+      - name: Commit and Push Changes to `gh-pages`
+        run: |
+          git config --global user.name "github-actions[bot]"
+          git config --global user.email "github-actions[bot]@users.noreply.github.com"
+          git checkout -b gh-pages
+          git add -f merged-data.json
+          git add .
+          # If there are no changes, no commit gets created, and nothing is pushed
+          git commit -m "Update GitHub Pages with latest data"
+          git remote set-url origin [email protected]:${{ github.repository }}.git
+          git push origin gh-pages

.gitignore

@@ -2,3 +2,7 @@
 *.swp
 *~
 /venv/
+.DS_Store
+/gh-data-summary.json
+/gh-data.json
+/merged-data.json

CONTRIBUTING.md

@@ -46,37 +46,7 @@ resources to it.
 
 ### Making a Position Request
 
-New specifications can be added by opening a new issue, or by making a pull request with the
-appropriate details in the `activities.json` file.
-
-If you decide to make a pull request, the `activities.py` script can help to fill in some of the
-relevant details:
-
-```
-    > ./activities.py add https://example.com/url_to_the_spec
-```
-
-If successful, it will modify `activities.json` with the new specification. Check the json file to make sure that the appropriate details are present:
-
-```
-{
-  "ciuName": "The short tagname from caniuse.com for the feature, if available",
-  "description": "A textual description; often, the spec's abstract",
-  "id": "A fragment identifier for the positions table",
-  "mdnUrl": "The URL of the MDN page documenting this specification or feature, if available",
-  "mozBugUrl": "The URL of the Mozilla bug tracking this specification, if available",
-  "mozPosition": "under consideration",
-  "mozPositionIssue": the number of the issue in this repo, if available,
-  "mozPositionDetail": "more information about Mozilla's position",
-  "org": one of ['IETF', 'W3C', 'WHATWG', 'Ecma', 'Unicode', 'Proposal', 'Other'],
-  "title": "The spec's title",
-  "url": "The canonical URL for the most recent version of the spec"
-}
-```
-`activities.json` is sorted by the title field. Once again, the `activities.py` script can help:
-```
-    > ./activities.py sort
-```
+New specifications can be added by opening a new issue.
 
 ### Asking Mozilla to Update a Position
 
@@ -118,7 +88,7 @@ reactions](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-an
 issue or a specific comment.
 
 If you want to ask about (or contribute to) Firefox support for a specification, please use
-the respective Bugzilla bug, linked with a wrench 🔧 icon in the standards-position dashboard entry.
+the respective Bugzilla bug, linked in the standards-position dashboard entry / the GitHub issue.
 
 If an issue becomes overwhelmed by excessive advocacy or other off-topic comments,
 comments might be hidden, edited, or deleted, and the issue might be locked.
@@ -157,20 +127,41 @@ by giving appropriate context when filing issues, such as:
 to help evaluate what Mozilla thinks of it,
 and while doing that I noticed ..."
 
-Members of the Mozilla community are
-welcome to judge that we've come to sufficient consensus in the issue,
-and make a pull request to document that consensus by changing `activities.json`.
-When this happens, we'd like to try to keep the technical discussion
+#### Propose a position
+
+Add a comment in the issue with a summary of any concerns, a proposed position, and rationale (as appropriate).
+
+If you have [permission to add labels](https://github.com/orgs/mozilla/teams/standards-contributor), you can add "topic:", "concerns:", "venue:" labels. These will show up in the dashboard.
+
+The maintainers of this repo will add the appropriate "position:" label to the issue after 7 days if there's no disagreement, and then either close the issue or ask for a PR to add detailed rationale to the dashboard (see below).
+
+#### Add a rationale to the dashboard
+
+Some standards positions should have a recorded rationale in the dashboard. This is recorded in the `activities.yml` file.
+
+To add an item to `activities.yml` or to update the rationale of an existing item, run:
+
+```
+python3 activities.py add 1234 --rationale "..."
+```
+
+...where 1234 is the GitHub issue number. Optionally also add `--description "..."` to add a description of the feature or specification.
+
+Alternatively, edit `activities.yml` directly.
+
+Then submit a pull request with the changes.
+
+We'd like to try to keep the technical discussion
 about the position
 in the issue itself
 (so that it stays in one place),
 and limit the discussion in the pull request
-to the details of making the change to `activities.json`,
+to the details of making the change to `activities.yml`,
 and accurately communicating the consensus in the issue.
 
-Similarly, when changes to a proposal warrant an updated position and 
-there is sufficient consensus in subsequent comments on the issue, 
-make a pull request to document that updated consensus by changing `activities.json`.
+Similarly, when changes to a proposal warrant an updated position and
+there is sufficient consensus in subsequent comments on the issue,
+make a pull request to document that updated consensus by changing `activities.yml`.
 
 Tips:
 * Specification URLs should link to a living standard or editor’s draft if available.

DEVELOP.md

@@ -0,0 +1,40 @@
+# Develop
+
+## Building locally
+
+The data for the dashboard website is sourced from:
+
+- The `activities.yml` file
+- The GitHub issues in mozilla/standards-positions (text in OP, labels)
+
+To fetch the GitHub information:
+
+```
+python3 gh-data.py
+```
+
+This will create or overwrite `gh-data.json` and `gh-data-summary.json`.
+
+Then, to combine that data with the information in `activities.yml`:
+
+```
+python3 merge-data.py
+```
+
+This will create `merged-data.json` which is used by `index.html`.
+
+To view the dashboard page locally, you need to start a local web server:
+
+```
+python3 -m http.server 8000
+```
+
+Then load http://localhost:8000/ in a web browser.
+
+## GitHub Actions / Publishing
+
+Publishing happens automatically when pushing to `main` as well as every 6 hours (to reflect any
+changes to labels in GitHub) with the `build-and-deploy.yml` workflow. It can also be triggered
+manually from the Actions page. This workflow needs a deploy key (Settings, Deploy keys), and the
+private key stored as an environment secret named SSH_PRIVATE_KEY (Settings, Secrets and variables,
+Actions).

README.md

@@ -42,3 +42,7 @@ specification in Firefox.
 ## Requesting a Position
 
 *See our [contribution guidelines](CONTRIBUTING.md) for information about how you can participate.*
+
+## Building locally
+
+See [DEVELOP.md](DEVELOP.md).