In GitHub, al contrario di Azure DevOps, i progetti non sono divisi per team e abbiamo direttamente visibili nella root tutti i repository. Questo, inizialmente, potrebbe essere traumatico per chi è abituato a gestire il backlog per pianificare le attività, perchè anzichè avere un backlog unico a livello di team, ci ritroviamo ad avere issues sparse per ciascun repository.

Proprio a questo scopo nasce il concetto di projects, una sorta di backlog che può fare da aggregato di tutte le issue che vengono aggiunte nei vari repository, per crearci questa visione d'insieme e ci permette di fare una pianificazione adeguata di tutte le attività. Purtroppo, almeno per il momento, non è possibile semplicemente selezionare i repository e vedere le issue automaticamente: questo passaggio, infatti, andrà automatizzato con un workflow dedicato.

name: Add issue to project board
on:
  issues:
    types:
      - opened
      - transferred

jobs:
  add-to-project:
    name: Add issue to project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@main
        with:
          project-url: https://github.com/orgs/{org}/projects/{id}
          github-token: ${{ secrets.GITHUB_TOKEN }}

Il workflow di esempio viene invocato ogni qualvolta che una issue viene aperta o spostata da un repository ad un altro e va solamente ad eseguire la action add-to-project che aggiunge la issue, quella che ha invocato il workflow, nel progetto di riferimento identificato dal suo {id}.

Eventualmente, è anche possibile copiare solo un subset delle issue, poichè queste siano identificate da una label specifica.

labeled: bug, needs-triage

In questo esempio vengono quindi aggiunte al project di riferimento solo le issue che sono marcate con la label bug o needs-triage.