Streamline developer project management for FS

[BigLep]

Background

The "FS" initiative involves multiple teams (e.g., FilOz, SpaceMeridian, FilB, Curio) working across multiple organizations (e.g., FilOzone, filecoin-project) working on multiple components (e.g., PDP, Pandora, payment contract, FilCDN). This is a tracking issue to take a few steps to streamline making this group effective managing their work across the various organization/repos.

Concrete items to help with streamlining

1. Make it self-sufficient for tpm @rjan90 to manage working group issues/PRs in filecoin-project/curio

A subset of filecoin-project/curio issues/PRs should be tracked in FOC so the working group is aware of all the work in progress and what is in the queue. I propose giving @rjan90 triage or write access to the repo so he can do things like close issues that are resolve/defferred, label issues/PRs, etc. I believe @rjan90 has a good track record in this role and highly cognizant of the impact of this actions that he can be trusted here.

2. Get all FS-related issues/PRs showing up on the FS Project Board automatically

It's useful to see in one place all the outstanding and upcoming work. While the FilOzone FS project board can pretty easily have issues/PRs added to it since it shows up as one of the projects within the organization, issues/PRs can't be automatically added due to limitation of only supporting auto-adding from one repo due to our current subscription level (docs). I want to set it up so that all issues/PRs from all the relevant repos in FilOzone automatically get added to the board.

GitHub Project Boards also make it possible to pull in issues/PRs from outside the organization, but there is no UI-provided workflow for this.

Proposal for FilOzone repos: setup a github action workflow using https://github.com/actions/add-to-project for each relevant repo. @FilOzzy's Personal Access Token can be used and stored as an organization secret. This common workflow could be stored in this repo or disseminated using FilOzone/github-mgmt "files capability" (docs).

[BigLep]

Work that has been done to be able to use @FilOzzy for add-to-project CI flow:

• Added @FilOzzy to FilOzone
• Made (and approved) @FilOzzy PAT in FilOzone org: https://github.com/settings/personal-access-tokens/7418963 . It is following the requirements of https://github.com/actions/add-to-project?tab=readme-ov-file#creating-a-pat-and-adding-it-to-your-repository
• I stored the @FilOzzy PAT in FilOz 1password
• I created a filecoin-project secret with this PAT: https://github.com/organizations/filecoin-project/settings/secrets/actions/FILOZZY_CI_ADD_TO_PROJECT . This can be used for curio and lotus.
• I create a FilOzne secret with this PAT: https://github.com/organizations/FilOzone/settings/secrets/actions/FILOZZY_CI_ADD_TO_PROJECT

[BigLep]

Next steps for moving 'Get all FS-related issues/PRs showing up on the FS Project Board automatically' forward...

1. Deploy an https://github.com/actions/add-to-project workflow to these repose:
   • https://github.com/FilOzone/synapse-sdk
   • https://github.com/FilOzone/pdp
   • https://github.com/FilOzone/filecoin-services
   • https://github.com/FilOzone/filecoin-services-payments
   • (@rjan90 may have more)

I assume we'll want content like:

name: Add issues and PRs to FS project board

on:
  issues:
    types:
      - opened
  pull_request:
    types:
      - opened

jobs:
  add-to-project:
    name: Add all issues and prs to project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@v1.0.2
        with:
          project-url: https://github.com/orgs/FilOzone/projects/14
          github-token: ${{ secrets.FILOZZY_CI_ADD_TO_PROJECT }}

I assume @galargh will have ideas for the best way to reduce duplication (e.g., use github-mgmt or some other mechanism in https://docs.github.com/en/actions/how-tos/sharing-automations/reusing-workflows ). I think it's fine to store these common workflows in this repo.

---

2. Deploy an https://github.com/actions/add-to-project workflow to these repose:
   • https://github.com/filcoin-project/curio
   • https://github.com/filcoin-project/lotus
   • (@rjan90 may have more)

I assume we'll want content like:

name: Add issues and PRs to FS project board

on:
  issues:
    types:
      - labeled
  pull_request:
    types:
      - labeled

jobs:
  add-to-project:
    name: Add all "fs-wg" issues and prs to project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@v1.0.2
        with:
          project-url: https://github.com/orgs/FilOzone/projects/14
          github-token: ${{ secrets.FILOZZY_CI_ADD_TO_PROJECT }}
          labeled: fs-wg

I assume @galargh will have ideas for the best way to reduce duplication. @rjan90 will need to create the label accordingly. (I didn't create it because wanted his confirmation on what label he'd want.)

[galargh]

I assume @galargh will have ideas for the best way to reduce duplication.

You're not wrong about this :P

Doing the distribution from github-mgmt is a valid option. We've done it in the past for all the Shipyard orgs with some workflows and we're doing it in filecoin-project with https://github.com/filecoin-project/github-mgmt/blob/master/files/.github/dependabot.yml config.

However, in practice, I found GitHub Actions workflow contents to be too much for github-mgmt. I mean, technically, it could handle them just fine, but the diffs that they would sometimes create in the PRs were just too long and made the github-mgmt config file just too bloated.

That's why I've been favouring distribution from the Unified GitHub Workflows repo lately. The same way we do distribute the Go verification workflows to some of the repositories in filecoin-project. In that repo, we have a centralised config of defaults per org/repo - https://github.com/ipdxco/unified-github-workflows/blob/main/defaults.yml - which allows us to control the default behaviour of web3-bot once it's added to a particular repository. I found this to be a more robust way to manage GitHub Actions workflows at scale.

We can chat more about this in our monthly sync!

[BigLep]

@galargh and I connected verbally 2025-07-08. For now, I'm going to take the approach of distributing the workflows via github-mgmt since they are small and aren't expected to change much. I'll also put a comment at the top making it clear the source of the file so someone doesn't accidentally edit the repository copy without realizing that it was copied there from github-mgmt.