github-community-projects / github-community-projects/safe-settings
Ability to set Teams and Team Members at the Org level, not only Rulesets
- Dominant language
- JavaScript
- Stars
- 921
- Forks
- 226
- Avg merge
- 18h 3m
- Merged PRs (30d)
- 14
Description
## Prerequisites:
* Is the functionality available in the GitHub UI? If so, please provide a link to information about the feature.
Currently this functionality is available to set at the org level here: `https://github.com/orgs//teams` where teams can be created and members added to them.
* Is the functionality available through the GitHub API? If the functionality is available, please provide links to the
API documentation (https://developer.github.com/v3/) as well as the Octokit documentation (https://octokit.github.io/).
Yes. API functionality is available for:
- Managing teams teams: https://docs.github.com/en/rest/teams/teams?apiVersion=2022-11-28
- Managing team members: https://docs.github.com/en/rest/teams/members?apiVersion=2022-11-28
## New Feature
Currently it is not possible to target any org settings except for `rulesets`. We would like to use the safe-settings app to also manage our teams at the org level, and manage members. These functionalities are fully available in the GitHub UI right now, and have full API support, as referenced above. If it is possible to manage teams and team members with the bot, we do not need to have org owners that can use the UI to manually manage these settings and we can use the PR approval flow to keep things consistent across our org.
Because Teams can have sub-teams, it might make sense to have the settings for teams to be its own file like `teams.yml` where Team name, details, members, sub-teams, etc... can be defined below nested as deeply as users might need to.
A note for project maintainers... my company needs this functionality, so I am willing to contribute these enhancements back to the safe-settings app. Ideally I would like to align with maintainers on a few implementation details (naming, should this be in the main org settings.yml or a separate teams.yml or both, etc) before moving too far forward, so that there are no annoying refactors afterwards.
Contributor guide
Assessment
This issue has not been assessed yet.