-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
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?). |
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:
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. |
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. |
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. 😄 |
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. |
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.
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. |
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 👀 Anyway, thanks everyone for helping in this conversation, let's see how these new permissions work :) |
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.
The text was updated successfully, but these errors were encountered: