Opening PRs by Community

[AryanAhadinia]

Right now, due to the security concerns we have about secrets exposure, only approved contributors are allowed to open a PR. As @Anunay-Yadav suggested, it would be nice to only restrict running the CI to authorized contributors rather than opening PR.

As of the current stage of the project, as the implementation is tied to Alps infrastructure, we rarely have external collaborators. But, as a part of the effort for generalizing SML, we want to also enable community to contribute to the project.

[andreolf]

+1 to @Anunay-Yadav's approach — you can open PRs to everyone without ever exposing secrets by splitting the pipeline by trust level:

1. Unprivileged CI on pull_request (lint, build, unit tests): GitHub already withholds repository secrets from workflows triggered by fork PRs, so this is safe to run for anyone. Adding permissions: read-all at the workflow level makes the token read-only too.
2. First-run gate: in Settings → Actions → Fork pull request workflows, "Require approval for first-time contributors" (or "for all outside collaborators") keeps a human in the loop before any fork's CI runs at all.
3. Privileged jobs (anything touching Alps infrastructure or deploy credentials): keep them on push to protected branches, or behind a GitHub environment with required reviewers, so they only run post-merge or with explicit maintainer approval. Avoid pull_request_target + checkout of the PR head — that's the pattern that actually leaks secrets.

With that split, branch protection stays intact and untrusted code never runs in a secrets-bearing context. Happy to open a PR restructuring the workflows this way if it helps — I'd also be glad to be an early guinea pig for the community-contribution path.