Allow team leaders to approve changes to their `team.toml`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 363
- Forks
- 369
- Avg merge
- 1d 54m
- Merged PRs (30d)
- 59
Description
Should we do this?
@rust-lang/team-repo-admins and @rust-lang/leadership-council, do we want to give team leaders (proper team here) the ability to edit their team.toml files? E.g. Kobzol and apraino are leads for the community-survey team. Do we want them to be able to approve and merge changes to the community-survey file?
- Pro: teams are more autonomous and they don't need to wait for a member of @rust-lang/team-repo-admins or @rust-lang/mods to make changes.
- Con: security concern — if a team leader GitHub account is compromised, the attacker can change the team file however they want, including kicking everyone out of the team.
We discussed this topic in the latest infra team meeting and the general consensus is that it is fine to accept the security risk, especially because "cloud permissions" and GitHub teams are not synchronized. I.e. permissions are given to individuals. E.g. if someone is added to the bors team, they don't gain access to the AWS bors DB automatically.
If yes, how?
[!NOTE]
Leadership council members can skip this section if they are not interested.
If we want to allow team leaders to approve changes to their teams, we need to discuss how to do this.
I have a PR which implements the ownership mechanism with GitHub CODEOWNERS. Unfortunately the con of this approach is that everyone in the @rust-lang/team-repo-admins and @rust-lang/mods teams will be notified about all the PRs in the /people/, /repos/ and /teams/ directories.
I need to know from everyone in the @rust-lang/team-repo-admins and @rust-lang/mods teams whether they want to receive a notification or not on PRs touching the directories listed above. 🙏
I'll try to adjust your team's code review settings based on your preferences. See this screenshot for example (these settings are not saved):
There are many people complaining about CODEOWNERS notifications. Hopefully we'll find a way to configure these settings that makes everyone happy.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the proposed ownership mechanism in PR #1758 and the repository's /people/, /repos/ and /teams/ directories. Read the linked CODEOWNERS documentation and meeting discussion to understand the approval and notification constraints. Done requires an agreed approach for team-leader approvals and the corresponding repository configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github
- Domain
- authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100