Policy on github roles

[thibautjombart]

Our github organization is growing and it will be useful to firm up policies on roles we each endorse. Options are listed in this article.

Current state

As of now, the de-facto policy has been to make every PI who has joined the organization an owner, and every RSE a member. We end up with:

• 17 people
• 9 owners
• 8 members
• 1 outside collaborator

While I understand this may make sense at first glance, current roles reflect overall leadership and seniority in the project, rather than the actual roles used in the github organization.

Thoughts on our policy

Members vs owners

From the description of permissions for the different roles, it seems we should have a majority of members, as they can create repositories, and perform most of the tasks needed (push code, handle PR, etc.). Owners should be restricted to administrative roles, mostly for organization-wide infrastructure, billing, and handling membership (which should stabilize in the weeks to come). Owners each have the ability to delete the entire organization, which is one of the reasons why we want to reduce the number of owners. We are working on a solution for making regular, automated backups of the whole organization, but this does not entirely remove the issue of having too many owners.

Teams

Are there any views on whether we should or should not use teams? As ideally people may contribute to a variety of projects, I am not sure if we need this, but curious to hear thoughts on the topic.

Other roles

I would think we may not need to set up these roles, at least initially:

• moderators: may only become needed if there is a large volume of issues raised by end-users to sort through?
• billing managers: so far all our projects are public, so we are not charged for github actions, and it does not look like we need to pay for any services on github
• security managers: seems like this could be handled by owners without having to appoint a dedicated role
• app manager: if we use github apps across the board, then this role could be useful, as project members should have autonomy on this

Way forward

Given the above, I would suggest reducing the roles of owners to a small number of people handling administrative, security, and potentially billing tasks for the github organization. Default for contributors should be 'members', with the caveat that we need to set up workflows so that RSEs have all the autonomy they need for their work.

I appreciate this may be a sensitive topic so very keen to hear the thoughts of everyone. Please share!

[rozeggo]

This is fine by me. As long as owners can add people and do as much as possible it seems fine. If you want me to contact my colleague at OpenSafely who has dealt with a lot of these things then I can do that.

[thibautjombart]

Yes it would be very useful to hear how other groups have handled this.

[rozeggo]

Ive sent a message to Seb https://github.com/sebbacon and will let you know if someone in the team has capacity to share experience

[thibautjombart]

Posting this link as I find it to be a good summary of roles for repositories (see detailed table). We are currently defaulting to write for all members, but can shift it to admin if needed. The outline of roles is:

• Read: Recommended for non-code contributors who want to view or discuss your project
• Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
• Write: Recommended for contributors who actively push to your project
• Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
• Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository

[joshwlambert]

@thibautjombart thanks for opening the issue and for taking the time to discuss the matter in person earlier. I do not feel strongly on the category of access for any member of the team. The access that is granted to RSE’s as members is reasonable, but with the acknowledgement that as blockages arise in the development process they can be raised with project lead(s) in order to provide access for that specific task. If this system works efficiently then after some time the access should be optimised for each person to allow them to carry out their role without impediment. This assumes that senior people in the team do not mind being messaged with requests and immediately updating the access settings.

I do not mind if different access roles are given to different people within the same job title. For example, a new RSE without experience in the role prior to now (for example myself) starting off as a member of the organisation, whereas a senior RSE either through experience at LSHTM or elsewhere could come in as owner.

I am happy to also note inconvenient restrictions on a GitHub issue so that changes can be made across the organisation to prevent each member having to repeat the process of reporting the same issues to an owner.

Lastly, I have not previously used teams within an organisation, however I'd be happy to give it a go to see.

[rozeggo]

Thanks Thibaut and Josh. I was just looking at permissions (as Thibaut quoted above) and I think that for RSEs, the default of admin may be better, since that might end up with the lowest amount of requests for actions. Happy with what Josh said about different access levels at different times if needed.

[thibautjombart]

Thanks @joshwlambert for sharing thoughts. I agree it makes sense for things to evolve organically, and adjust roles and permissions as needed. There is a balance to strike between flexibility and security, and I'm happy to err on the side of flexibility. Setting everyone to admin by default may be the way to go. As far as I can tell it grants all rights on a given repository. The main difference seems to be it does not grant organization-wide destructive permissions (though individual repos can still be deleted permanently).

[pratikunterwegs]

Thanks all, I'll keep this brief and functional. RSEs will need to perform a certain set of technical actions on repos. These currently include:

1. Main branch protections on new or newly active repos,
2. Changing PR merge settings to allow only squash merges on main branches,
3. Changing code review settings on repos (e.g. repos with more active users may need more approvals) More actions may become necessary in future.

The current 'members with write permissions' doesn't meet these requirements. Some role X - current consensus seems to be around 'members as admins' - must exist that does. RSEs holding at least this role is a non-negotiable. Other roles can be assigned as the PIs prefer - I have no firm opinions.

[annacarnegie]

Agree with the (what seems to be) emerging consensus of admin > member for RSEs - with this to be reviewed periodically to ensure that this level of permission is practicable for all.

[Bisaloo]

Thanks for starting this discussion! I had indeed noticed a lack of homogeneity in how the roles had been distributed until now and I believe it's important to have a clear policy.

For context, this topic is quickly touched in a post on rOpenSci's blog: Safeguards and Backups for GitHub Organizations. I just asked them explicitly and they put package maintainers as admin of their individual repo. They are much more stringent with organization ownership, with only 4 people from the core team being owners.

Although I'm not certain it's strictly necessary (details in the next comment), I agree with the comments saying it's probably better to err on the side of flexibility for now. Just note that this makes sense for now because we still are a relatively small organization, but it is likely to change towards increased security as the organization grows. As mentioned by @thibautjombart, I think the security risks associated with admin access to individual repos can be mitigated:

• it is possible to remove to disallow repository deletion, even from repo admins, at the organisation level
• we will hopefully soon have a weekly backup of our entire organisation, including issues, PRs, etc.

Now remains the issue that we are a multi-teams organization, with, at the moment, little cross-team collaboration. In the current state of things, if I was a PI in one of the partner institutions, I would find it odd to have someone who is basically a complete stranger with admin access to the repos of my team. With that in mind, I believe a slightly better model would be to make one LSHTM/MRC/UKHSA team and one LAC team and give admin access to the relevant team each time. However, I cannot think of an easy way to automate that just now.

[Bisaloo]

Tangentially related because as mentioned in the previous comment, I'm okay with erring on the side of flexibility but I wanted to react to some points in https://github.com/epiverse-trace/blueprints/issues/16#issuecomment-1259708867.

I believe most of the repo settings should be adjusted automatically. Since we have shared policies, it seems much more scalable to do this with a script or even at the org level, if GitHub ever adds this option. Requiring RSEs to do this on individual repos seems like increasing unnecessarily their workload, and running the risk that some repos fall through the cracks.

[Bisaloo]

This is solved by https://github.com/epiverse-trace/.github/pull/30.