From d329668aabe5027ba671d4ec990b16e8fd6aa56f Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Tue, 18 Apr 2023 10:38:39 -0700 Subject: [PATCH] add github management policies dir Signed-off-by: Jordan Harband Signed-off-by: ctcpip Co-authored-by: Jordan Harband Co-authored-by: ctcpip --- README.md | 2 +- elections/tac-and-scir-election-process.md | 6 ++-- policies/access.md | 41 ++++++++++++++++++++++ 3 files changed, 45 insertions(+), 4 deletions(-) create mode 100644 policies/access.md diff --git a/README.md b/README.md index ce4f2926..a9c9412a 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ Official communications occur on the [TAC mailing list](https://lists.openssf.or Informal discussions occur in the TAC channel of the [OpenSSF Slack](https://slack.openssf.org/). To join, use the following [invite link](https://join.slack.com/t/openssf/shared_invite/zt-xoktwsef-VzM~b22G2gfT_~4woTTsQA). -Use [Github Issues](https://github.com/ossf/tac/issues) to request and discuss agenda items. +Use [GitHub Issues](https://github.com/ossf/tac/issues) to request and discuss agenda items. ## Meetings diff --git a/elections/tac-and-scir-election-process.md b/elections/tac-and-scir-election-process.md index 9ce0b43b..ca983fa2 100644 --- a/elections/tac-and-scir-election-process.md +++ b/elections/tac-and-scir-election-process.md @@ -6,14 +6,14 @@ This document outlines the election process for the OpenSSF Technical Advisory C ## Voter Eligibility (Electorate) Self-Nomination Process Any contributor to OpenSSF working groups, SIGs, or projects is eligible to participate in the election. -Valid contributions include: commits or submitted pull requests via Github; public edits or comments on Google docs or other work products associated with OpenSSF; consistent participation in working groups; posting messages to any mailing list or on Slack; and beyond that any other form of positive engagement with OpenSSF activities. +Valid contributions include: commits or submitted pull requests via GitHub; public edits or comments on Google docs or other work products associated with OpenSSF; consistent participation in working groups; posting messages to any mailing list or on Slack; and beyond that any other form of positive engagement with OpenSSF activities. The voter eligibility form asks you for an example of your contributions; this is merely to make it easier for the Election Officials and OpenSSF staff to validate eligibility. If you have in any way been involved in or care about OpenSSF, but are in doubt as to whether your contribution “counts”, please fill it out anyways, and we will follow up. -The Voter Eligibility Self-Nomination Form will be sent out via email along with the election announcement. +The Voter Eligibility Self-Nomination Form will be sent out via email along with the election announcement. (Note: The form is only open during the nomination period) - + ## TAC Self-Nomination Process The OpenSSF Technical Advisory Council (TAC) is composed of seven total individuals, four of whom are elected annually. diff --git a/policies/access.md b/policies/access.md new file mode 100644 index 00000000..792a6d10 --- /dev/null +++ b/policies/access.md @@ -0,0 +1,41 @@ +# GitHub Access Management Policy + +## Teams, not Individuals + +Access to repositories will be granted only to GitHub teams, not to individuals. A repo may have any number of teams added to it, with the appropriate access levels. + +## Team Structure + +Teams will be nested, using parent/child relationships, as needed. A child team will implicitly have any privileges its parent team does, so, the most deeply nested team should be the one with the most privileges. + +### Top-level teams + +Note: this list is intentionally not exhaustive. + +- [TAC](https://github.com/orgs/ossf/teams/tac) + This team is for current TAC members. Individuals should be added or removed from this team to reflect current membership. +- [Staff](https://github.com/orgs/ossf/teams/staff) + This team is for OpenSSF staff members. Individuals on the top-level team are there as a catch-all, but may be moved to subteams as the need arises. + - [PMs](https://github.com/orgs/ossf/teams/pms) + This teams is for PMs, who often need Maintain or Admin access on repos. + - [Marketing](https://github.com/orgs/ossf/teams/marketing) +- [Working Groups](https://github.com/orgs/ossf/teams/working-groups) + This is the parent team for Working Groups. Every WG should have a subteam contained within this one. All WG subteams must start with `wg-` for consistency. +- [SIGs](https://github.com/orgs/ossf/teams/sigs) + This is the parent team for SIGs. Every SIG should have a subteam contained within this one. All SIG subteams must start with `sig-` for consistency. +- [Projects](https://github.com/orgs/ossf/teams/projects) + This is the parent team for projects. Every project (eg scorecard, AO) should have a subteam contained within this one. + Teams for individual repositories go under here, which start with `repo-`, but team names may otherwise be unconstrained. + +## GitHub Org Membership + + Membership in the GitHub org should be freely given - it inherently confers no permissions or privileges, only a badge on the user's profile if they enable it - and it _does_ allow for easier team management. Someone should only be removed from the org in extreme circumstances where their association with OpenSSF would be problematic, and people should be encouraged to remain in the org in perpetuity. + + Individuals who choose not to be a member of the org will be unable to retain access to repositories due to being ineligible to being on GitHub teams. + +## Principle of Least Privilege + + Permission levels should be as high as they need to be, and no higher. + +- There's few settings that justify Admin access over Maintain, so prefer Maintain. +- Explicit Read access has an advantage: users with Read can be assigned to issues and requested as PR reviewers even if they're not the author