add github management policies dir

Signed-off-by: Jordan Harband <[email protected]> Signed-off-by: ctcpip <[email protected]> Co-authored-by: Jordan Harband <[email protected]> Co-authored-by: ctcpip <[email protected]>
ossf · Apr 18, 2023 · d329668 · d329668
1 parent 35e9dc9
commit d329668
Show file tree

Hide file tree

Showing 3 changed files with 45 additions and 4 deletions.
diff --git 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
@@ -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
@@ -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