One board, many uses

GitHub’s Security team spans engineers, analysts, researchers, and leadership across departments like product security engineering, security lab, and security operations. Coordinating quarterly, cross-functional initiatives across those groups needs to be transparent and low-friction. The team’s answer is what members call their “organizational operating system”: the new projects experience for structure, paired with GitHub Actions for the administrative burden.

Each objective, key result, and initiative becomes a tracking issue in the github/security repository. Issues cross-reference one another, carry details and links, and assign a directly responsible individual (DRI) through the assignee field. That lets anyone start from a high-level goal and drill down into team-level tasks, or connect an individual piece of work to the objective it supports.

The new projects experience gives the team flexible views over those issues. Metadata lets items be filtered and sorted so anyone at GitHub can categorize them usefully. Everything gets a URL, making sharing and revisiting straightforward. The same content serves different audiences: a viewer who wants only an executive summary gets it from the issue, while someone needing full context can click through to deeper detail.

One concrete example is a single project board the team maintains to track security reports for two separate incident response teams. The board has a summary view for executive briefings and a specialized view that surfaces high-impact cases or reports needing extra attention, so understanding the board takes little effort.

Screenshot of Security Team quarterly planning in projects How the security team’s planning and tracking project looked last quarter

Automation where it counts

All that tracking adds overhead, so the team relies on the most natural automation tool available to it: GitHub Actions. Actions handle bulk issue creation, add issues to project boards, and enforce accountability for regular status updates throughout the quarter. DRIs post brief comments on tracking issues at a set cadence; GitHub Actions then updates the project board automatically from those comments, giving the team a unified view of each key result’s progress.

To update a board, the team uses an open source composite GitHub Action. The command can modify project board fields no matter where the triggering update happened on GitHub. Adding it means inserting a step in a YAML file inside the repository’s .github/workflows/ directory:

name: Update status on project board
on:
  repository_dispatch:
    types: [status_update]
jobs:
  update_project:
    runs-on: ubuntu-latest
    steps:
      - name: Update status
        uses: github/update-project-action
        with:
          github_token: ${{ secrets.STATUS_UPDATE_TOKEN }}
          organization: github
          project_number: 1234
          content_id: ${{ github.event.client_payload.command.resource.id }}
          field: Status
          value: ${{ github.event.client_payload.data.status }}

Note: The same step can be repeated in a job to update multiple fields on the same project or different projects.

The point, the team stresses, is avoiding process for its own sake. Projects plus light automation removes the time cost of weekly status reports and manual board upkeep while meeting team members where they already work. The same setup is available to others through the projects quickstart in GitHub Docs and the latest feature updates in the Changelog.