Review and clean up access across all 5 MathCAT repositories (follow-up to #851, #848)

Abierto
#856 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
10/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github

Línea de trabajo

This is a governance task, not a code change. Start by reading the CODEOWNERS file referenced in #848 and #851, then check each of the five repos' collaborator and team settings in the daisy organization to compare access. Done means the team-access decisions are agreed, the matching changes are made by an admin, and the protection-rule scope for each repo is recorded in the thread.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

devops discussion

While working on #848 (adding more detail to CODEOWNERS), I checked who has access to each of the 5 MathCAT code repositories on GitHub, and found some things that don't match what we'd expect. I'm opening this as its own issue because it has its own action items: some decisions to make and some changes that need an organization owner or repo admin to actually carry out.

Background:

As part of DAISY's current pilot year exploring sustainable governance and maintenance, several MathCAT repos have been moved from @NSoiffer's personal account into the shared daisy organization. Organizing access and team structure supports the goal of sharing maintenance load rather than depending on one person.

A few GitHub terms used below:
  • Organization (org): a shared GitHub account for a group, rather than one person — in our case, daisy. MathCAT's repositories and teams exist inside this one organization.
  • Organization owner: someone with full control over the whole daisy organization — not just one repo. Owners can invite new people into the organization, create or delete teams, and change access to any repo inside it. This is a small, separate group from repo-level admins (below).
  • Repository (repo): one codebase inside the organization. MathCAT has 5 of them.
  • Organization member: someone who's been invited into the daisy organization. Being a member doesn't automatically give access to any specific repo — that's granted separately, either to the person directly or through a team.
  • Team: a named group of organization members (for example, "MathCAT-Maintainers"). Teams exist at the organization level, and can be given access to one or more repos at once, instead of adding each person to each repo one by one.
  • Collaborator: a specific person given access to one repo, either directly or through a team they belong to.
  • Access levels, from least to most: read (can view and download, cannot change anything), write (can push code changes and merge approved changes), admin (can additionally change settings, rules, and who else has access to that repo).
  • Ruleset: a set of rules GitHub can enforce on a repo, like "every change must go through review before merging."
  • CODEOWNERS: a file that says which people or teams should review changes to specific folders.
What I found:
  1. Access is granted separately for each repo, not as one shared setting. Most of us have similar access on 4 of the repos: MathCAT, MathCATDemo, MathCATForPython, and MathCATForC. The 5th, MathCATForJS, looks different — several of us only have read access there, even though we have write or higher on the others. If that's intentional, MathCATForJS should probably be left out of any change that sets the same team-wide permissions across all 5 repos.
  2. The MathCAT-Translators team has no access to any repo yet. This is an organization-level team, and the CODEOWNERS file already lists it as the expected reviewer for language-related files. But GitHub can only auto-request a team as a reviewer if that team already has at least read access to the repo. Right now it doesn't, so those review requests are probably not happening.
  3. The MathCAT-Maintainers team only has read access, even though its name suggests members should be able to review and merge changes day-to-day. Right now, the people who actually can merge have that ability because they were added individually as repo collaborators, not because of this organization-level team.
  4. Only the main MathCAT repo has any protection rules turned on, and even those are limited. As #851 already notes, they only stop people from deleting the branch or force-pushing over it — they don't require review before merging yet. The other 4 repos have no protection rules at all. #851's proposal would fix this for MathCAT, but doesn't say whether the same rules should apply to the other 4 repos too.
What each team is for, and what access would let them do
Team name Who it's for Access level What that lets them do
MathCAT-Repo-Admins People who manage the repos themselves Admin, on all 5 repos Turn protection rules on/off, change who has access, delete or rename a repo
MathCAT-Maintainers Regular contributors who review and merge changes Write, on all 5 repos Push code and merge approved changes, manage issues. Once branch protection rules are turned on (per #851), this access will still be limited by those rules. For example, maintainers will still not be able to merge unreviewed PRs.
MathCAT-Translators People translating/localizing MathCAT Read, on the main MathCAT repo Gets notified as a team when something affects their work and can be asked to review language-related files.
Who can make these changes today:
To do this... ...this needs to be done by
Invite someone new into the daisy organization An organization owner can always do this. Team maintainers may also be able to, indirectly, by adding someone to their team who isn't yet an org member. We should check this, as it would mean routine MathCAT access changes don't need to go through DAISY admins.
Add or remove someone from the MathCAT-Maintainers team NSoiffer, avneeshsingh, or MartheGjelstad (they manage that team), or any organization owner
Add or remove someone from the MathCAT-Translators team avneeshsingh or MartheGjelstad (they manage that team), or any organization owner
Change how much access a team has on a repo Someone with admin access on that specific repo. Right now, that's the 7 organization owners plus @NSoiffer.
Add, remove, or change one person's individual access to a repo Same as above — admin access on that repo
Suggested next steps:
  • Decide if MathCATForJS access should match the other 4 repos, or if there's a reason it's different.

  • Once we agree on the team access levels above, have one of the people listed in the table actually turn them on, and decide what to do with people's individual access once the teams cover the same ground.

  • Confirm whether team maintainers can bring new people into the organization via team invites, without needing an org owner.

  • Decide whether the proposed protection rules in #851 should extend to MathCATDemo, MathCATForPython, MathCATForC, and MathCATForJS, or stay limited to MathCAT for now.

  • cc @NSoiffer @SarahMorleyWilkins @MartheGjelstad @aimalz

Lenguaje dominante
Rust
Estrellas
130
Forks
96
Merge medio
1 d 1 h
PR fusionados (30 d)
84

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de daisy/MathCAT

Todos los issues de daisy/MathCAT

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.