Allow users to change visibility of projects (mozilla, mozilla-l10n)
Categories
(mozilla.org :: Github: Administration, task)
Tracking
(Not tracked)
People
(Reporter: flod, Assigned: cknowles)
Details
Currently, when creating a new project, is set by default as private, and the user cannot change its visibility (only Organization owners can do it).
GitHub has an option (I think it's called for that Allow members to change project visibilities for this organization). It would be nice to reconsider the default value for this option, if not as default for all orgs, at least for mozilla (which currently has 57 projects) and mozilla-l10n (that's where I would create projects normally).
For log purpose: in the meantime, I've asked gh-admins to switch the visibility of this project to public.
|
Assignee | |
Comment 1•2 years ago
|
||
Seeing as :flod is the admin of the Pontoon Pre-Translation project, I did set that to public.
I think the only question would be if the ability to set as public would be any sort of security concern - There are several private and public projects in the Mozilla org, so clearly at some point people would like to pivot.
The blurb for the setting to allow the pivot says "If enabled, members with admin permissions on a project can make the project public or private" - so this wouldn't be like some of the other settings where suddenly it's wild west. Only project admins can make the change. (And given that that's usually the bar we owners use, I think this is a fine change)
Setting an NI here for Hal to look/ponder, and will add to our tracking sheets so it doesn't get lost.
In the meantime, please reach out if there are other projects needing adjusting.
There's no security reason a project can not be public based on the judgement of the repository admin.
NI: Chris -- I don't know how you want to track changes to the "checklist" used for migration/new orgs. FWIW, there would be no harm in enabling public project on all existing orgs, as the control is in the hands of the repo admin.
|
|
Assignee | |
Comment 3•2 years ago
|
||
Perfect. Thank you. I've made that change on mozilla and mozilla-l10n, and with your statement above, I've added the field to the "Secops GHE new/migrated settings checklist" we use.
At some point, we'll be going over auditing/updating existing orgs around new/changed settings from GitHub, and this would probably go into that effort.
|
|
Assignee | |
Comment 4•2 years ago
|
||
Actually - Hal - Would this be a setting we would want to set at the enterprise level? All orgs in the enterprise would get a "enabled" from that. Only drawback is that there is no method for them to get an exception (that I can see), so it's all on for everyone.
(In reply to Chris Knowles [:cknowles] from comment #4)
Only drawback is that there is no method for them to get an exception (that I can see), so it's all on for everyone.
I'm assuming "them" refers to "orgs in the enterprise" and not "repos in an org in the enterprise". As long as repo admins can control the setting of projects for their repos, any config is fine.
Actually - Hal - Would this be a setting we would want to set at the enterprise level?
So "yes" -- as long as I assumed correctly above.
|
|
Assignee | |
Comment 6•2 years ago
|
||
sorry - pronouns are hard. "Them" here is the project visibility setting for the org. If that is setting at the enterprise level, there's no way for an org to be different.
And the projects discussed here are org level, not repo level, so that's not in play here.
|
|
Assignee | |
Comment 7•2 years ago
|
||
We're continuing this discussions in our GHE admin meetings, so as to reduce noise here.
|
|
Assignee | |
Comment 8•2 years ago
|
||
Per discussions in said meetings, decision was made to do the change at the enterprise level, so all orgs in GHE get the setting.
Description
•