Repository navigation
Conversation
|
|
||
| ## Open Questions | ||
|
|
||
| - Should we have an Emeritus label as an additional trust signal, given they are past trusted contributors? |
There was a problem hiding this comment.
There are a lot of emeriti, so I think this would work against the goal of the rfc.
There was a problem hiding this comment.
Yeah that makes sense. Thinking about it more, emeriti will no longer be members of the org and require two approvals, which might be confusing to label given the intended signals of the other labels.
| ## Open Questions | ||
|
|
||
| - Should we have an Emeritus label as an additional trust signal, given they are past trusted contributors? | ||
| - Should we avoid `read:org` scope in the workflow and instead refer to `data/contributors.yaml` from `flutter/contributors`? |
There was a problem hiding this comment.
The biggest difference is token security and secret management. The default GITHUB_TOKEN in GitHub Actions is scoped strictly to the repository where the workflow runs and cannot query organization team memberships. Checking teams via the GitHub API would require provisioning, rotating, and exposing a PAT or GitHub App token with read:org scope across every repository's Actions secrets, and would make up to 3–4 REST API calls per PR (/orgs/flutter/teams/{team}/memberships/{user}) against a single shared rate limit across all repositories.
By contrast, flutter/contributors is public, so labeler.yml can fetch data/contributors.yaml in a single lightweight request using the default repo-scoped GITHUB_TOKEN (or plain HTTPS) and check the author's role locally on the runner without any extra secrets or elevated org-level permissions. Roster drift also isn't really a concern since data/contributors.yaml is already our source of truth for quarterly audits and we have an out-of-band process in flutter/contributors for updating the roster when new teammates join.
Given our security postures, I figured reading data/contributors.yaml was much cleaner, but didn;t want to omit the alternative.
There was a problem hiding this comment.
Got it. Reading out of flutter/contributors definitely sounds simpler and safer.
Proposes adding labels to PRs to gain visibility on their ladder roles, making new code review process and requirements clearer for reviewers.
Tracking issue: flutter/flutter#186415
Related:
Pre-launch Checklist
design doc.dart run bin/assign_rfc_number.dartlocally when instructed).If you need help, consider asking for advice on the #hackers channel on Discord.