Switch to YAML and GitHub data

.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 git@github.com:${{ 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).