GitHub orgs in scope ipfs<

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Immediate next steps: (Expected date for PRs to be created: 20

(Expected date for PRs to be created: 2024-02-09): <a class="user-mention

Documenting some thoughts that occurred while <a href="https://github.com/ipfs/github-

Comments (15)

dhuseby commented on June 11, 2024 1

This set of ["org owners"] people should be:
...
3. representative of multiple independent companies/teams

I like this a lot but for libp2p right now, there is no formal structure for "org owners". Other open source projects I've worked with have had standing "technical steering committees" for this purpose. I'm just pointing out that the roles with responsibility should probably map to real-world groups with official standing.

from ipfs.

BigLep commented on June 11, 2024 1

FYI that I I'm not including ipfs-inactive since it currently doesn't have github-mgmt. Here is the current membership per https://github.com/orgs/ipfs-inactive/people:

@lidel : not required, but I leave it up to you as one of the current org owners whether you want want to prune some of the folks who aren't as active anymore.

from ipfs.

BigLep commented on June 11, 2024 1

@dhuseby:

This set of ["org owners"] people should be:
...
3. representative of multiple independent companies/teams

I like this a lot but for libp2p right now, there is no formal structure for "org owners". Other open source projects I've worked with have had standing "technical steering committees" for this purpose. I'm just pointing out that the roles with responsibility should probably map to real-world groups with official standing.

Ack, makes sense. As part of the "2024 libp2p growing up" work, there is a steering committee that is intended to be set up. It seems like it would be good to map to the groups involved with that.

In the meantime, I am making a best effort of using tribal knowledge that we have to make this better than it was (e.g., too many org owners/admins, many of which are not actively involved in the project anymore.)

from ipfs.

lidel commented on June 11, 2024 1

(As someone who had owner status for years) I think limiting surface for security problems is a net positive.

In theory, the set of things that can only be done by owners will be limited, and they won't be needed often. I do a repo transfer once or twice a quarter. For needs like that we can go with LO-FI solution and have issue templates in github-mgmt for owner-only operations like "transferring repository" with assignees pre-filled up.

In practice there will be unexpected disruptions, but the need does not occur often, we would discover gaps and create additional templates/playbooks as the needs arise.

from ipfs.

BigLep commented on June 11, 2024 1

2024-02-16 update concerning phase 2: "Archive" inactive teams and users

This should be ready to start week of 2024-02-19. @galargh demoed to me the work in ipdxco/github-as-code#113 and ipdxco/github-as-code#115 . These will clean up the diffs substantially when inactive users get "archived" and make them easier to reason about. I personally won't be driving this next phase. @galargh and @lidel will be at the helm.

Below is some starter messaging to help with this phase:

PRs for "archiving" inactive teams and users

PR title: "Archiving" inactive teams and users 2024Q1

PR Description

Summary

This pertains to the "'archive' inactive users and teams" in #511.

Who is this targeting?

The current PR is what results from a script to identify inactive teams users in an org. Some additional manual cleanup changes may have been done as well when looking at the repos. For example, the "w3dt-stewards" team is removed as it doesn't make sense in light of having github-mgmt now for that wide of a group of people to have admin permissions across so many repos.

Why is this being done?

See "Why do we care about periodically cleaning up permissions across the orgs?" in #511

Is this set in stone?

No. This PR was created and being left open for some days to give awareness and incorporate feedback. We're not taking a "ask for permission" approach as that would require way too much wrangling. Instead, we're giving visibility to what's proposed and invite folks to comment and influence. A saving grace here is that none of this is a "one-way door". If something got messed up or missed, a followup PR can be done to correct it.

Is anyone being removed from the organization?

No. All existing members of the org are staying members. In the most reduced/scoped-down case, someone will still be part of of an "Alumni" team in the org to signal their past involvement. Thank you for your past contributions, and we certainly welcome you to play a more active role in the future.

Timeline

2024-02-XX: public PR
2024-02-XX: notify affected parties with @mention: LINK_TO_COMMENT_IN_THIS_PR
2024-02-XX: merge this change after incorporating feedback

Reviewer's Checklist

It is clear where the request is coming from (if unsure, ask)
All the automated checks passed
The YAML changes reflect the summary of the request
The Terraform plan posted as a comment reflects the summary of the request

PR comment @mentioning affected parties

Comment message

$LIST_OF_PEOPLE_TO_@MENTION

We're @mentioning you to inform you that your $ORG_NAME github "org ownership" permissions will be adjusted as part of a #511 unless you respond back with your use-case for having these permissions by 2024-02-XX. You can read more about the purpose and motivation for the changes in the PR description.

To see how this proposed change is affecting you see $LINK_TO_DIFF_OF_USER_FOCUSED_VIEW_OF_PERMISSION_CHANGES.

You can also see the access you have currently (and via what means) at $LINK_TO_DUMP_OF_USER_FOCUSED_VIEW_OF_PERMISSIONS_CURRENTLY_IN_MAIN

This isn't a one-way door. If we got this wrong or you don't see the notification after the merge date above, a new PR can be created to fix permissions at $ORG_NAME/github-mgmt.

Thanks and let us know if you have any questions or concerns.

from ipfs.

BigLep commented on June 11, 2024

Immediate next steps:

(Expected date for PRs to be created: 2024-02-09): @BigLep to get the "Reduce org owners" PRs created (and added to the summary table)
(Expected date for PRs to be created: 2024-02-14): @galargh to address ipdxco/github-as-code#113

from ipfs.

BigLep commented on June 11, 2024

(Expected date for PRs to be created: 2024-02-09): @BigLep to get the "Reduce org owners" PRs created (and added to the summary table)

I didn't get to this on Friday, 2024-02-09. I'll be doing on 2024-02-12.

from ipfs.

BigLep commented on June 11, 2024

"Reduce Org Owners" PRs have been created and are tracked in the issue description.

The plan is to get those merged 2024-02-14.

from ipfs.

BigLep commented on June 11, 2024

Doh - I'm realizing I didn't have multiformats on the list of in-scope orgs. Doh! My bad! That wasn't intentional. I'm adding it now and getting started on the org owner/admin cleanup.

from ipfs.

BigLep commented on June 11, 2024

Documenting some thoughts that occurred while responding on what to do concerning some foundational-but-not-currently-active-in-github team members:

I was wondering about going to a larger extreme of effectively removing all org owners and then just relying on github-mgmt stewards to self-promote themselves to "org owner" when they need this (leaving a comment for why they need this and what conditions need to be met to be removed from the owner role). This seems like the safest thing to reduce the chance that org owners accidentally use their permissions in unintended ways (and reduces some of the potential blas radius if their account gets hacked - there would at least be a PR to github-mgmt that would show the escalation of permissions which may give someone the chance to react/response.)

I sided against advocating for this because:

Likely too extreme of an operational posture given there are no paying customers here. (I'm assuming amongst PL Inc nucleations that org owner permissions are getting flexed quite a bit right now in moving things around, cleaning up, etc.)
There are likely notifications that come through to owners that it would be risky to not have any human receiving.

Feedback welcome though if anyone thinks we should tighten further.

from ipfs.

olizilla commented on June 11, 2024

The current "almost secure but not quite" position is humane but logically untenable. Tighten it up as you suggest so everyone has to apply for the perms they need, or leave them as they are.

If the proposal here is to remain as is then please can it be explicitly documented why those who have been granted this power have it. What orgs are they representing? Which orgs are sufficiently ipfs/ipld/etc enough to count?

from ipfs.

BigLep commented on June 11, 2024

I should have updated earlier on where things are at.
I'm investigating how to tighten up the org owner role further. I'll report back more today.
@galargh and I are meeting on 2024-02-16 so we can review his work in ipdxco/github-as-code#115 and ipdxco/github-as-code#113 which should unblock phase 2: "'Archive' inactive users and teams"
More to come.

from ipfs.

BigLep commented on June 11, 2024

The current "almost secure but not quite" position is humane but logically untenable. Tighten it up as you suggest so everyone has to apply for the perms they need, or leave them as they are.

Good comment. Generally, I don't think we should let best be the enemy of better (e.g., getting down to 6 individuals who are active in an org is better than 20 people many of which haven't been active in years even if it's not the ideal solution).

That said, I looked harder at what it would be like to really reduce the org owner permissions. I went through all permissions listed in github org role docs and then listed how I think they could/should be handled (see the collapsed table at the bottom).

Going through this exercise is leading me to propose:

Reduce org owners to:
- @galargh: co-founder of IPDX, and IPDX is contracted to look after github for this organization.
- @andyschwab-admin: leader of Sodal, has close access to sead which is charged with sysadmin around these organizations, and general long-standing sysadmin for these organizations with his past roles at PL Inc
Remove all existing org owners and just have the reduced set from the recent PRs in the "github-mgmt Stewards" teams.
Give the "github-mgmt Stewards" team "moderator" and "security manager" roles.
- I don't think this is something that can be done through github-mgmt. For example, I don't see any useful docs when searching Terraform's docs. It would need to be a one-time action through the GitHub UI.

can it be explicitly documented why those who have been granted this power have it

Yeah, I can start the precedent of documenting everyone in the "github-mgmt Stewards" role.

I'm going to update/create PRs for ipfs/libp2p/IPLD incorporating this proposal above and will report back when they're done.

github org role permissions and suggestion on how to handle in light of github-mgmt

collapsed table

The data below started from https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles . The Owners, Members, Moderators, Billing managers, and Security managers columns are directly from Github docs. It was augmented and sorted in this public spreadsheet.

The copy/paste below causes the hyperlinks to be lost. If you want those, go to the spreadsheet.

GitHub Docs Website Order (2024-02-15)	Organization permission	Way To Handle	Way To Handle Comment	Owners	Members	Moderators	Billing managers	Security managers
24	Block and unblock non-member contributors (see " Blocking a user from your organization ")	handled by moderator role		✔️	❌	✔️	❌	❌
25	Limit interactions for certain users in public repositories (see " Limiting interactions in your organization ")	handled by moderator role		✔️	❌	✔️	❌	❌
39	Limit activity in public repositories in an organization	handled by moderator role	can also be handled by repo moderators	✔️	❌	❌	❌	❌
31	Manage security and analysis settings (see " Managing security and analysis settings for your organization ")	handled by security moderator role		✔️	❌	❌	❌	✔️
36	Receive Dependabot alerts about insecure dependencies for all of an organization's repositories	handled by security moderator role		✔️	❌	❌	❌	✔️
37	Manage Dependabot security updates (see " About Dependabot security updates ")	handled by security moderator role		✔️	❌	❌	❌	✔️
40	Pull (read) all repositories in the organization	handled by security moderator role		✔️	❌	❌	❌	✔️
14	Delete all teams	‼️ should require explicit escalation of permissions	don't ever want to do	✔️	❌	❌	❌	❌
15	Delete the organization account, including all repositories	‼️ should require explicit escalation of permissions	don't ever want to do	✔️	❌	❌	❌	❌
41	Push (write) and clone (copy) all repositories in the organization	‼️ should require explicit escalation of permissions	this is rare or never need	✔️	❌	❌	❌	❌
33	Transfer repositories	escalate when needed	this will provide some friction as it's needed from time-to-time, especially during reorg and cleanup seasons.	✔️	❌	❌	❌	❌
12	Access the organization audit log	escalate in lower freqency cases	This is something we'd be fine to be more public. Maybe IPDX can expose or snapshot this more publicly.	✔️	❌	❌	❌	❌
13	Edit the organization's profile page (see " About your organization's profile ")	escalate in lower freqency cases		✔️	❌	❌	❌	❌
34	Purchase, install, manage billing for, and cancel GitHub Marketplace apps	escalate in lower freqency cases	this isn't common	✔️	❌	❌	❌	❌
45	Manage default labels (see " Managing default labels for repositories in your organization ")	escalate in lower freqency cases	this isn't common	✔️	❌	❌	❌	❌
4	Edit and cancel invitations to join the organization	escalate if ever needed	this isn't common since github-mgmt will trigger the invites	✔️	❌	❌	❌	❌
30	Manage the publication of GitHub Pages sites from repositories in the organization (see " Managing the publication of GitHub Pages sites for your organization ")	escalate if ever needed	already enabled; doesn't need to be toggled	✔️	❌	❌	❌	❌
35	List apps in GitHub Marketplace	escalate if ever needed	this isn't common	✔️	❌	❌	❌	❌
38	Manage the forking policy	escalate if ever needed	already disabled and likely doesn't need to be toggled again	✔️	❌	❌	❌	❌
44	Manage the default branch name (see " Managing the default branch name for repositories in your organization ")	escalate if ever needed	already set and likely doesn't need to be adjusted	✔️	❌	❌	❌	❌
22	Hide comments on writable commits, pull requests, and issues (see " Managing disruptive comments ")	handled at the repo level	anyone with write access to a repository can handle	✔️	✔️	✔️	❌	✔️
23	Hide comments on all commits, pull requests, and issues (see " Managing disruptive comments ")	handled at the repo level	anyone with write access to a repository can handle	✔️	❌	✔️	❌	✔️
46	Manage pull request reviews in the organization (see " Managing pull request reviews in your organization ")	handled at the repo level		✔️	❌	❌	❌	❌
9	Configure code review assignments (see " Managing code review settings for your team ")	team maintainer can handle		✔️	❌	❌	❌	❌
10	Set scheduled reminders (see " Managing scheduled reminders for your team ")	team maintainer can handle		✔️	❌	❌	❌	❌
26	Set a team profile picture in all teams (see " Setting your team's profile picture ")	team maintainer can handle		✔️	❌	❌	❌	❌
1	Create repositories (see " Restricting repository creation in your organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
16	Create teams (see " Setting team creation permissions in your organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
18	Create projects (see " Project (classic) permissions for an organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
19	See all organization members and teams	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
20	@mention any visible team	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
21	Can be made a team maintainer	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
2	View and edit billing information	n/a	Organization is on free plan. Billing managers can be added separately (e.g., IPFS Foundation)	✔️	❌	❌	✔️	❌
32	View security overview for the organization (see " About security overview ")	n/a	not relevant since don't use GitHub Enterprise	✔️	❌	❌	❌	✔️
43	View people with access to an organization repository	n/a	already self-service for world by viewing github-mgmt publicly. No permisisons needed.	✔️	❌	❌	❌	❌
3	Invite people to join the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
5	Remove members from the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
6	Reinstate former members to the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
7	Add and remove people from all teams	normal github-mgmt PR case		✔️	❌	❌	❌	❌
8	Promote organization members to team maintainer	normal github-mgmt PR case		✔️	❌	❌	❌	❌
11	Add collaborators to all repositories	normal github-mgmt PR case		✔️	❌	❌	❌	❌
17	Move teams in an organization's hierarchy	normal github-mgmt PR case		✔️	❌	❌	❌	❌
42	Convert organization members to outside collaborators	normal github-mgmt PR case		✔️	❌	❌	❌	❌
27	Sponsor accounts and manage the organization's sponsorships (see " Sponsoring open source contributors ")	defer	not critical to account for currently	✔️	❌	❌	✔️	✔️
28	Manage email updates from sponsored accounts (see " Managing updates from accounts your organization sponsors ")	defer	not critical to account for currently	✔️	❌	❌	❌	❌
29	Attribute your sponsorships to another organization (see " Attributing sponsorships to your organization " for details )	defer	not critical to account for currently	✔️	❌	❌	❌	❌

from ipfs.

BigLep commented on June 11, 2024

Phase 1 to reduce org owners is complete.

Thanks to all for the feedback here. We ended up reducing org ownership to just a couple of individuals, giving additional permissions to the "github-mgmt stewards" teams (moderator and security manager org roles), and documenting why all the github-mgmt stewards members are on the respective team.

from ipfs.

Stebalien commented on June 11, 2024

With respect to PRs like ipfs/github-mgmt#193...

I think we should merge this, but I'd go even further and remove repo and user specific permissions entirely in most cases, replacing them with teams.

from ipfs.

[Tracking Issue] "Interplanetary Stack" Github permissions cleanup 2024Q1 about ipfs HOT 15 OPEN

Comments (15)

2024-02-16 update concerning phase 2: "Archive" inactive teams and users

PRs for "archiving" inactive teams and users

Summary

Who is this targeting?

Why is this being done?

Is this set in stone?

Is anyone being removed from the organization?

Timeline

Reviewer's Checklist

PR comment @mentioning affected parties

github org role permissions and suggestion on how to handle in light of github-mgmt

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent