You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have two types of teams for giving Coding CCs write access to repos: ccp-$USERNAME teams and committers-$TOPIC teams. This wiki page explains the difference.
Why do we have both types in the first place?
Well, generally, we don't want to give CCs write access directly on any repos. It makes the program harder to audit, because we don't know what access is CC access on what access is special/legacy/accidental. So, we started with the ccp-$USERNAME teams because there was only a small number of CCs, and having a 1:1 user-team mapping was straightforward.
As the number of CCs grew, some of them gained write access to whole sets of repos (i.e., "all analytics" and "all MFEs"). It got harder to manage individual repos for individual users. It also got ambiguous whether, for instance, a CC with access to "all MFEs" should automatically gain access to new MFEs--to that question, we decided "yes", as long as their CC nomination thread made that clear.
So, we started grouping repos together with teams. The first teams like this were were frontend-all, frontend-mfes, and cc-analytics. Eventually, we decided to standardize on the committers-* name for all these sort of teams, so those teams are now committers-frontend, committers-frontend-apps, and committers-analytics, respectively. For CCs who have access to a single repo rather than a repo group, we figured that we could just have some one-off teams like committers-edx-platform.
We should finish switching from ccp-* teams to committers-* teams. The only reason we haven't is that it's one of those high-importance-but-low-urgency things.
Look for logical groupings of repos that appear multiple times on the wiki page. Create these groupings as new committers- teams if they don't already exist.
Then, for every CC:
Open up their ccp- team.
Does their GitHub access match the access described on the wiki? If not, write down the extra repos they can write to, flag for follow up in a new ticket. We'll need to dive into the forums to see what their appropriate access is.
Based on their current access described on the wiki, add them to existing committers- teams as appropriate.
For leftover repos that the wiki mentions but are not covered by any committers- teams, create new repo-specific committers- teams. For example, if some CC has one-off write access to edx-organizations, create a new committers-edx-organizations team with write access, and add them.
Back on the wiki page, update their "Project(s) And Access" to describe committers teams rather than repos.
Was the CC flagged for follow-up because their permissions didn't match the wiki page?
Yes -> Rename the team, which will have some extra write grants, to fixme-$username so we know to come back to it.
No -> Delete the team.
General notes:
At the end of this process, nobody's access should have changed.
Assign only write access. Not maintain or admin.
When you make a new team, GitHub puts you on it. Take yourself off.
Make sure the CCs are team members rather than team maintainers. This ensure that only Axim eng can change the teams.
The text was updated successfully, but these errors were encountered:
Agreed. I wonder if there's a way (label? new column on board?) that we could add these to that are like, "if you're on-call and it's a light week, please take one of these tasks"
Context
We have two types of teams for giving Coding CCs write access to repos:
ccp-$USERNAME
teams andcommitters-$TOPIC
teams. This wiki page explains the difference.Why do we have both types in the first place?
Well, generally, we don't want to give CCs write access directly on any repos. It makes the program harder to audit, because we don't know what access is CC access on what access is special/legacy/accidental. So, we started with the
ccp-$USERNAME
teams because there was only a small number of CCs, and having a 1:1 user-team mapping was straightforward.As the number of CCs grew, some of them gained write access to whole sets of repos (i.e., "all analytics" and "all MFEs"). It got harder to manage individual repos for individual users. It also got ambiguous whether, for instance, a CC with access to "all MFEs" should automatically gain access to new MFEs--to that question, we decided "yes", as long as their CC nomination thread made that clear.
So, we started grouping repos together with teams. The first teams like this were were
frontend-all
,frontend-mfes
, andcc-analytics
. Eventually, we decided to standardize on thecommitters-*
name for all these sort of teams, so those teams are nowcommitters-frontend
,committers-frontend-apps
, andcommitters-analytics
, respectively. For CCs who have access to a single repo rather than a repo group, we figured that we could just have some one-off teams likecommitters-edx-platform
.We should finish switching from
ccp-*
teams tocommitters-*
teams. The only reason we haven't is that it's one of those high-importance-but-low-urgency things.Tasks
Go to the CC access wiki page. Also open up the list of committers- teams.
Look for logical groupings of repos that appear multiple times on the wiki page. Create these groupings as new
committers-
teams if they don't already exist.Then, for every CC:
ccp-
team.committers-
teams as appropriate.committers-
teams, create new repo-specificcommitters-
teams. For example, if some CC has one-off write access toedx-organizations
, create a newcommitters-edx-organizations
team with write access, and add them.fixme-$username
so we know to come back to it.General notes:
The text was updated successfully, but these errors were encountered: