github-community-projects / github-community-projects/safe-settings

Ability to set Teams and Team Members at the Org level, not only Rulesets

Open
#690 4 comments 4 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.