New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy on github roles #16
Comments
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. |
Yes it would be very useful to hear how other groups have handled this. |
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 |
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:
|
@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. |
Thanks Thibaut and Josh. |
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). |
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:
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. |
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. |
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.
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. |
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 #16 (comment). 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. |
This is solved by epiverse-trace/.github#30. |
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:
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:
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!
The text was updated successfully, but these errors were encountered: