FED-BOM is using specific GitHub labels and project board columns to indicate where pull requests are in their lifecycle, to make it easier to determine at a glance what the status is of all the PRs in the FED-BOM project board. This workflow is listed below, documenting what changes to the labels and issue position should be made at each stage.

Typical Workflow

PR created, but not yet ready for review

If the author lacks write permission on the repository, they will need to first create a fork of it and submit a PR from that fork (and ask someone else, probably their manager, to set the assignee).

• The PR should be in Draft mode.

• The PR should be added to the “In Progress” column of the FED-BOM board.

• The assignee of the PR should be set to the author.

PR ready for owning team review

• The PR should no longer be in Draft mode.

• The PR should be moved to the “In Code Review” column of the FED-BOM board.

• The PR author should set the “Owner” field in the “Table” view of the FED-BOM board. The owning team can be identified either from other recent PRs in the same repo in that view or via the edX / OCM Tech Ownership Assignment spreadsheet.

• The PR author should request review from the owning team using the instructions from the “Squads” tab’s “PR Review Requests” section at the far right of the ownership spreadsheet.

• A comment should be added to the PR with a link to the review request (typically a Slack message or Jira ticket). For example, “Review Requested in https://2u.slack.com/archive/…”. This ensures that we don’t forget to explicitly ask for review, and makes it easier to find any related discussion that may have happened around the request.

• Once the review has been requested, the “engineering review” label should be added. See the notes at the end of this page if you don’t have permission to directly edit the issue’s labels.

• If the PR is needed for a security patch or to unblock other urgent work, a “priority” label is also added and it is moved at/near the top of the “In Code Review” column.

PR reviewed

Once the PR has been reviewed by a member of the owning team:

• The “waiting on author” label should be added.

• The reviewer is encouraged, but not required, to set themself as an additional assignee on the PR; this makes it easier to scan for the PRs they have been involved in.

• If no further review will be needed, the “engineering review” label should also be removed.

Review feedback addressed

If all feedback from the owning team has been addressed and the PR is ready for re-review:

• The author should remove the “waiting on author” label.

• The author should reach out to the reviewer in both a GitHub comment and Slack message to notify them. (The GitHub notifications alone are easily lost among other email, but it’s important to have the current status clear when looking at the PR.) If the author lacks write permission on the repository, this notification should include a request to merge the PR if the reviewer is satisfied with the changes.

PR closed/merged

Once the PR has been closed and/or merged:

• Any remaining “waiting on author” and “engineering review” labels should be removed.

• If the PR wasn’t automatically moved to the “Done” column of the FED-BOM board, do this manually.

Other Notes

• Any time feedback is wanted from the PR author, re-add the “waiting on author” label if not already present.

• If the “waiting on author” label is not present and the “engineering review” label is, the owning team should schedule time (again) to look at it.

• If the PR submitter lacks write permission on the repository, they should use comments to add or remove labels as described in .github/workflow-templates/add-remove-label-on-comment.yml at master · openedx/.github . If that workflow has not been enabled:

  • If the repo is in the openedx org, file an issue via https://github.com/openedx/tcril-engineering/issues/new/choose to request that the workflow be added

  • If the repo is in the edx org, ask the owning team to add the workflow