Skip to content

Create a project board for tracking community PR review progress #155

Closed
@GuySartorelli

Description

@GuySartorelli

As part of adding the new peer reviewer and refiner roles, we should provide a project board that these community roles can use to organise and track their work.

Epic

Acceptance Criteria

  • A new GitHub project board is created for tracking community pull request review progress
  • All teams have access to the board
    • Probably the refiners should have view-only access, if that's possible
  • The project board is documented on either the maintainer guidelines page, triage and peer review page, or both
  • The "Backlog with PRs" column in zenhub is removed, in favour of using the new project board for tracking community PRs
  • If possible, all issues with a pull request are displayed in the project board
    • Otherwise, all issues are displayed on the project board
    • NOTE: Opted to list PRs in the end because that's ultimately what people need to review, and that's much easier than finding the 5 different ways PRs can be "related" to an issue in order to know when an issue should be added

TO DECIDE (or explicitly leave it up to whoever implements it)

  • What columns do we want? Examples below
    • New issues
    • Needs review (has a PR but isn't being reviewed yet)
    • In review (must be assigned to the person reviewing)
    • Awaiting contributor feedback (must be assigned to the person who requested feedback)
    • Needs escalation (core committers or CMS squad need to take a look)
    • Needs second approval
    • Done/Merged (HIDDEN)

We'll aim to review these column early once we start having some contributors on-boarded. So we'll go with the initial suggested column.

NOTE about using secrets in GitHub Actions

https://docs.github.com/en/actions/learn-github-actions/contexts#secrets-context

If a secret was used in the job, GitHub automatically redacts secrets printed to the log. You should avoid printing secrets to the log intentionally.

In other words, so long as we're not echoing it out ourselves, there should be no risk of our secret being exposed via logs.

Project board

PRs

Module Standardiser PRs

Running against default-branch

Running against the CMS 5 next-patch branch

I've limited this to only run the new script (with exception of the new repo which had all scripts run). This is because the last few times standardiser was run it was against the next-minor branch, and running all those scripts here would result in redundant changes to check - some of which when I tried it did result in failures.

After merging

Reassign to Guy to

  1. Make a docs PR for this whole thing
  2. run standardiser against the next-patch branch again
  3. Add all pre-existing community PRs to the board

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions