Skip to content

testing-checklist.md

Latest commit

 

History

History
51 lines (35 loc) · 4.19 KB

testing-checklist.md

File metadata and controls

51 lines (35 loc) · 4.19 KB
Raw

Testing Checklist — Devices GitHub Automation

A running list of things to test with the working group. Check items off as they're verified; add new ones as we build more. Each item notes who should do it, since some tests require a non-owner or a brand-new user to be meaningful.

Legend: ⬜ not tested · ✅ verified working · ❌ found a problem (note it)

1. Repository creation automation

  • ⬜ Co-chair can create a repo. A dev-co-chairs member opens New Repository Request → repo is created from the template. (who: a co-chair, not you)
  • ⬜ Non-co-chair is blocked. Someone NOT in dev-co-chairs opens the same request → it's declined with a comment and the issue is closed, no repo created. (who: a regular member)
  • ⬜ Per-repo teams are created. After creation, {name} writer and {name} maintainer teams exist as child teams of devices-domain. (who: anyone)
  • ⬜ Team roles are correct. The new repo shows dev-co-chairs = Admin, {name} maintainer = Maintain, {name} writer = Write. (who: anyone with repo access)
  • ⬜ Result comment is accurate. The issue's closing comment lists the repo and all three teams with the right roles. (who: anyone)

2. Adding people to teams automation

  • ⬜ Co-chair can add an existing org member. Open Add People to a Team, list a username already in the IHE org → they're added immediately. (who: a co-chair)
  • ⬜ ★ Brand-new person gets an org invite. List someone who is NOT yet in the IHE org → they receive an email invitation, and once they accept they land on the team. This is the key assumption — confirm it actually works. (who: a co-chair + a volunteer who isn't in the org yet)
  • ⬜ Email address works. List an email address (not a username) → an org invitation is sent. (who: a co-chair)
  • ⬜ Team maintainer (non-co-chair) can add to their own team. A maintainer of WIA writer adds someone to WIA writer → succeeds. (who: a team maintainer who is not a co-chair)
  • ⬜ Unauthorized person is blocked. Someone who is neither a co-chair nor a maintainer of the target team → request declined. (who: a regular member)
  • ⬜ Wrong team name is rejected helpfully. Type a team that doesn't exist → declined with a comment listing the valid teams. (who: a co-chair)
  • ⬜ Bad username is reported. Include a misspelled/nonexistent username among good ones → the good ones still succeed and the bad one is flagged in the result table. (who: a co-chair)
  • ⬜ Capitalization / spacing is forgiving. Type wia writer or WIA Writer for a team named WIA writer → still resolves. (who: a co-chair)

3. Change Proposal (CP) workflow

  • ⬜ CP folders exist in a new repo. A repo made from the template has CP/ and CP/Approved/. (who: anyone)
  • ⬜ Create-a-CP flow is clear. Walk a lead author through: branch → add CP file → merge to main → work on CP branch → PR to ballot. Does the documented flow make sense to them? (who: a lead author)
  • ⬜ Approved CP move works. Move a test CP file from CP/ to CP/Approved/ via PR. (who: a lead author)

4. Build / CI (already validated, re-confirm on a real repo)

  • ⬜ Build runs on push. Pushing to main of a new supplement repo produces HTML + PDF artifacts. (who: a contributor)
  • ⬜ Shared theme is applied. The built output picks up the shared IHE theme from DEV.tooling. (who: anyone reviewing output)

5. Documentation review

  • ⬜ Playbooks match reality. Have each role (org admin, domain lead, contributor, reviewer) read their playbook and confirm the steps match what they actually see in GitHub. (who: one person per role)
  • ⬜ Team reference is clear. The Teams reference correctly explains parent/child teams, making managers, and the org-invite catch. (who: a co-chair)

Open questions to raise in the meeting

  • Public vs. private repos — still undecided.
  • License for document content — still deferred.
  • Should approved CPs ever be archived, and how? (We dropped the Archive/ folders for now.)
  • The existing teams have mixed display-name styles (e.g. SDPi writer vs dev-co-chairs) — do we want to standardize?