Skip to content
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

Permissions #5

Closed
grabbou opened this issue Mar 22, 2019 · 7 comments
Closed

Permissions #5

grabbou opened this issue Mar 22, 2019 · 7 comments
Labels
discussion Let's talk about stuff

Comments

@grabbou
Copy link
Collaborator

grabbou commented Mar 22, 2019

Not sure if this is the format of issues that works for you (feel free to close it), but we should also talk about permissions, on npm and Github, for projects and whole organisation.

@kelset
Copy link
Contributor

kelset commented Mar 22, 2019

yeah that's actually a good point! It should be a separate Guideline maybe? 🤔

But feel free to start throwing ideas here - thanks for opening!

Btw is there like a GitHub doc with how the various level of auth work (org level auth VS single repo auth?).

@kelset kelset added the discussion Let's talk about stuff label Mar 25, 2019
@kelset
Copy link
Contributor

kelset commented May 29, 2019

Hey everyone - I'm back on this subject after some tinkering & experience sharing with some other maintainers for different big open source orgs.

One of the most interesting approaches to this I've heard is to, basically, give every member of the organisation admin level auth: in the experience of one of his maintainers, this has basically led to the members feeling more empowered and responsible towards the org.

Also, surprisingly, this didn't lead to anything backfiring nor people starting feeling pressured to help every repo in said org. But over time, it allowed the org to be less "tied" to a dedicated subset of people with full powers, and to sporadic "cross-repo" help between maintainers.

I really think there is value in what approach, and I'd like to propose to actually do something similar - to a certain extent:

  1. give as default permissions to every member of the RNCommunity org "write" level of permissions
  2. ensure that all maintainers are also members of the org (which is not something that is currently happening, and we should fix this anyway)
  3. create org teams (I've already started creating one for the maintainers) because this will allow to, as example, request a certain PR to be reviewed by that team instead of having to "pick" the precise person

All of these steps would move us as a community towards a more trustful and empowering environment where each person can decide to focus on whatever aspect they want (ex. maybe they are super into documentation, or styling the READMEs) - and also more "indipendence" from admins when it comes to do a precise set of tasks.

I feel that we should start experimenting with the "write" level auth first, and eventually if we feel confident and this works, we can consider upping it to the "admin" level.

I would like to start tackling this over the next few weeks (in combo with the conversation of #1) to get us to a better space as an org.

About the npm permissions: atm I feel that we should still make sure that only one or more codeowners for each repo has publishing auth for the pack they are maintaining, and that no one person can publish everything.

@matt-oakes
Copy link
Collaborator

I wholeheartedly agree with this approach! I agree that NPM permissions should be more tightly controlled, and it doesn't matter so much for the projects which have "semantic-release" setup.

I did kind of the same thing with a small PHP project that I was no longer maintaining. Whenever I got a PR from someone, I would give them "write" access to the repo and let them know they could help to maintain it. There are now a couple of people who actively use that to keep the library going.

@MateusAndrade
Copy link
Contributor

I agree with the write level for the maintainers and the restrict npm permission.

Having more people with maintainer access becomes easier to check issues, prs, etc. 😄

@grabbou
Copy link
Collaborator Author

grabbou commented Jun 2, 2019

Thank you @kelset for working on it! The proposal sounds really interesting. I agree with your reasoning and like the fact you have also focused on the maintainers motivation - this is one of the reasons this organisation has been created in the first place.

As a developer, I am always in favour of embracing people and limiting the amount of management. My only concern is security here, mainly because we need better Github permissions system itself. I am pretty sure they are already working on that, so it's probably just a matter of time.

Is there any mechanism from Github to revert transfer of the repository or deleting it? For example, I wouldn't like the CLI repository to be removed by accident or as a result of a security issue. At the same time, I wouldn't like someone transferring it to a private namespace and making private.

Another thing is various tools that can get integrated within the organisation. Some of them request really bizarre permissions, such as full admin access, which can also be a weak point. We should probably keep an eye on that list. Again, having more granular system that allows to uncheck "adding apps" on per role basis would be amazing.

@kelset
Copy link
Contributor

kelset commented Jun 3, 2019

Is there any mechanism from Github to revert transfer of the repository or deleting it?

Yes, only admins will have that power - and I share your concerns, hence why I want to move everyone ""only"" to the write level of permission.

Another thing is various tools that can get integrated within the organisation.

yeah we need to come up with a better flow for this, but I'm quite sure only an admin can approve a new tool.

@kelset
Copy link
Contributor

kelset commented Jun 12, 2019

Allright, I've changed the default permissions for members to "write".

This will mean that you'll more easily be able to help each other in the different repos hosted in the org.

Next step would be to enforce the 2FA for everyone but it seems that a lot of people don't have it enabled and GitHub will kick you from the org if you don't have it 👀
So that's for another day.

Anyway, thanks everyone for helping in this conversation, let's see how these new permissions work :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Let's talk about stuff
Projects
None yet
Development

No branches or pull requests

4 participants