GitHub Owner permissions

[Trott]

Situation:

• Policy in the TSC repository indicates that only a small number of people should be owners. https://github.com/nodejs/TSC/blob/4d5e08146339c4553143721a2a70bd7e57ed8867/Github-Org-Management-Policy.md#owners
• In reality, Owners consist of TSC members (considerably more people than listed in the policy--additionally, not everyone who should be an Owner according to policy is)
• Moderation Team needs "Owner" privileges. There hasn't been any movement I'm aware of to get a bot to make the Moderation Team effective.

Issue:

• Arguments for expanding Owner role to Moderation Team:
  • Private security repos are moving to their own org.
  • If someone deletes a repo or something destructive like that, GitHub, Inc. can restore issue
    tracker, wiki, and everything else. (Probably want to get confirmation on this and also an idea of process and timeframe.)
  • We can always remove Moderation Team from Owners if we get a bot together at some point in the future.

Questions:

• Should we remove the policy text or replace it with a reflection of what is actually the case? Or should we start narrowing the Owners of the org?
• Should the Moderation Team be given Owner privileges? If not, how do we make it so the Moderation Team can be effective now on a practical level?

/cc @nodejs/moderation @nodejs/community-committee @nodejs/tsc

[addaleax]

I think it makes sense to change the policy text + make the moderation team owners.

[benjamingr]

So we discussed this in the moderation team meeting. Want to give my personal opinion:

I'm in favor of eventually using a bot but at the moment that's very far away. Given that, there has been several instances where I couldn't take actions due to permission limitations which was frustrating.

Org ownership does not give owners the power to do anything that's actually irreversible. The worst org owners can do is delete content that GitHub can restore for us.

I would object to the moderation team given access to security related repos - but from what I understand from TSC and CommComm members that attended the meeting that is not an issue since it belongs to a separate org.

I would also prefer it if non TSC/CommComm moderation team members were excluded from sensitive issues TSC/CommComm discuss but that's probably not in GitHub repos anyway (I don't know).

Given that - I'd love to be able to moderate more effectively :)

[MylesBorins]

As of right now we have still been primarily using nodejs/security for actively managing security issues. We have nodejs-private, but that is only the repos atm.

Until that repo moves over I object to modereation being added to owners

[ghost]

as far as i know, the current community committee co-chairs (@bnb and @rachelnicole) are also not given owner status?

[benjamingr]

@MylesBorins is there consensus on moving it?

[MylesBorins]

@benjamingr I've opened an issue to discuss

fwiw there is one other sensitive private repo that should be considered in all of this as well. I'll talk with folks to see if it needs to be moved.

[bnoordhuis]

Or should we start narrowing the Owners of the org?

From a security angle: fewer is better.

[mhdawson]

I'm in favor of moderation team members being added as owners if/when we move out the sensitive repos. At that point we should revisit the text.

[bnb]

I'd like to request that we actively track those discussions, even if it's just to have an open issue that those who are engaging in the discussions can report on while they're in progress/once they've completed.

Further, I'd like to push on enforcing the policy as defined in the Org Management file linked in the original post. Is there anything blocking this from happening now (Moderation is not a part of that policy)?

[Trott]

Is there anything blocking this from happening now (Moderation is not a part of that policy)?

Main thing blocking it is probably that there will be a lot of unforeseen friction. For example, I will no longer be able to manage a lot of group memberships and will not be able to audit two-factor authentication usage, which I've been doing as we inch closer to requiring it.

I'm not saying those concerns should stop it from happening, but I do think those are the reasons we haven't done it yet.

[rvagg]

The Node.js Foundation Executive Director, Node.js TSC Director, TSC Chair, Community Committee Chair, and Node.js Foundation Education Manager shall be the only individuals granted Owner permissions within the Node.js GitHub Organization. Should, at any point in the future, the Node.js Foundation Board establish a Community Committee Director position equivalent to the TSC Director, that individual would also be automatically granted Owner permissions within the organization.

Why was this passed if we're not able to enforce it? It's pretty clear that this doesn't work from a management perspective as @Trott noted but also due to some other factors such as infra administration (not impossible to work around but currently having build wg members who have owner perms makes it very easy to set up automation, special accounts with privileged access for bots and other tools, private/deployment keys, etc.).

I missed that clause when it was passed (I guess thanks to the downtime inflicted by the drama) but I'm really (really, really) not a fan of it because it further messes up technical team independence and its ownership of its technical space. Bringing in the ED puts the Executive and Linux Foundation into the mix, tying Director positions puts the Board into the mix, putting the CC into the mix confuses it further--the CC was supposed to be an outward-facing group, making it owner of the technical space makes no sense, perhaps it should just get a new org it can manage?

I propose that we wind back that clause, simply because it's currently not practical and doesn't match our reality at all, my personal preference would be to wind it back permanently too for the above reasons but I understand that it's a view that's not shared by all so we can have that discussion separately.

I'm also -1 to making the Moderation team owners, the org should be the technical team's space to own, the TSC is the peak body of the technical team. Moderation is a delegated responsibility, any execution of those responsibilities that requires org ownership should either be pass through an available TSC member or tooling should be set up for it. There's some very solid programming skills on the Moderation team, if they need tooling then perhaps that should be a task for them? The bot is already in place and only needs extension.

[mcollina]

I think we should revisit that policy, as it is not working as it is currently written.

@rvagg the nodejs github org is not just a technical space, but also an external-facing community space for obvious visibility reasons. As an example, nodejs/help is here, nodejs/summit, and a lot of other repos. Also, a group of hundreds of individuals is also a community in itself.
In other term, I do not consider the nodejs github org the technical team space.

[benjamingr]

I agree with almost everything you say @rvagg but I'm having issues with:

I'm also -1 to making the Moderation team owners, the org should be the technical team's space to own, the TSC is the peak body of the technical team.

Ownership of the technical side and ownership of the github org are very different things. (Although I'd argue that the collaborators own the technical side and the TSC governs it - but that's offtopic here).

The interesting thing to note here is that outside of a few repos (that I hope would be passed to the private org - which is a good idea regardless) - org owners can't actually do anything irreversible.

It's not like it's super strict either - I was an org owner by mistake for a week before (even before I was a collaborator) a while back before realizing it and removing myself. Even if I wanted to do something fishy - we have our release team who act as the actual barrier of what can impact people using Node.js in their actual projects.

Conversely - not being org owners has severely restricted our ability to be effective in our role. Creating a bot is great and dandy but it hasn't happened for a while and it's unreasonable to expect it to happen any time soon (and when it does, I'm +1 on removing as many people as possible from org ownerships without affecting effectiveness)

[rvagg]

OK, thanks for the nuance @benjamingr @mcollina I appreciate it and see your POV here.

My focus is on preserving the independence of the technical team (which you're right is not just the TSC) and a lot of recent governance moves have been both intentionally and unintentionally undermining that. The Foundation was set up with this independence for very good reason and we're eroding it to the peril of the project. If we accept that github.com/nodejs isn't the technical team's space, what is? Is it just specific repositories? Perhaps we need to go back to the "scope" discussions because it seems that we're either narrowing it or removing the clear boundaries all together.

[jasnell]

At the time this policy was proposed (and I should note, the PR was open for review for quite some time and it's discouraging to find out that it seems folks are only now actually reading it) ... there was an intent around evolving the processes further. Absent those other changes, the restrictions in ownership no longer make sense and I'm +1 on reverting that portion. Let's keep it such that all TSC members have ownership rights in the org, make it such that the chairs of the CommComm have ownership rights, and make it such that the Moderation Team can nominate individuals to have ownership rights subject to approval from both the TSC and CommComm.

[bnoordhuis]

I have to admit I don't understand why CommComm members need to be owners. TSC¹ and Moderation Team² I can see, but why CommComm?

¹ Although a handful of designated owners for day-to-day operations is probably sufficient and (value judgment) better.

² Making them admins on all teams and repos may work too but would be very tedious to maintain.

[jasnell]

but why CommComm

Because CommComm create and manage their own repositories and need the agency to manage those (including actions on those repos that require ownership permissions). Note that what I'm suggesting is that only the CommComm chairs would have those permissions.

[Trott]

Because CommComm create and manage their own repositories and need the agency to manage those (including actions on those repos that require ownership permissions). Note that what I'm suggesting is that only the CommComm chairs would have those permissions.

Can someone provide more specific information on this? It's not clear to me why CommComm needs it when (just to pick one example) Build (who also need to create and manage their own repositories) does fine without it.

I'm cool with CommComm chairs having Owner permissions. It would be good to document the justification/reasoning with specificity.

[Trott]

nodejs/TSC#456

[mhdawson]

@Trott to answer the question why build does ok, my guess it is because it has a big enough overlap with TSC members that getting repos created/modified is not a big deal.

[mhdawson]

From my perspective, we are working towards 2 peer groups, the TSC and the Community committee. Those two share the repo so the question is why individual TSC members are granted ownership while community committee members are not. Limiting it to the chair/director representation of the two groups was intended to provide equal access.

I know there were concerns with the security repo (which are being addressed) but once that is resolved I think we'd need to grant equivalent access or make it based on 'need'.

[ghost]

i think it would be easier to make everyone have equal access once the concerns are resolved, but this brings up membership process issues in the commcomm, as right now, participating in meetings/etc for 3 months more or less puts you in the commcomm, therefore technically giving you github org ownership. i think that if we go down this route we'd have to revise our membership rules and processes

[hackygolucky]

I'm still confused as to how moderation team members can do their job of moderation without Owner level permissions in the short term. Maybe I missed someone providing a solution to this somewhere in this thread?(please point me to it) 😕 Longer term, I very much +1 the idea of not having org owner for Moderation members.

Currently, the bot is not in existence. Members don't have access to be able to fulfill moderation roles because of the permission levels in various repos(I get why that level of agency is important to each repo/group), so things like editing or temp-banning require pinging people who are not on the team to assist in repos without permissions, when we're trying to work on things within the Moderation team already such as availability and coverage to continue to build up trust amongst everyone trying to communicate on this platform. Can we set a timeline for the bot solution and allow org ownership short-term for the moderation team? I'm just trying to find some middle ground here where we can do our jobs as moderators, while being very sensitive to who needs access.

[othiym23]

For an example of how this affects the members of the moderation team, see nodejs/moderation#169, where the distribution of responsibility is such that only a few (one?) members of the moderation team could enact a temp ban, were it merited.

[bnb]

Yes, in working on the issue @othiym23 linked I realized just how limited the resources currently available to the Moderation team are.

Addressing this proactively—enabling the Moderation Team before something like the incident we had in the Inclusivity WG ~two years ago happens again and the Moderation team isn't able to act effectively—is going to be better for the project than acting reactively after an incident where the Moderation Team isn't able to respond effectively.

[ryanmurakami]

This issue has been open for nearly a month and there doesn't seem to be progress. The only issue keeping the Moderation Team from becoming Owner privileges seems to be moving two sensitive repos to a different org. @MylesBorins, do you have an update on those discussions?

At this point we're going on over three months since the Moderation Team's kickoff meeting and members are still not able to effectively moderate. The Moderation Policy clearly defines that the Moderation Team is tasked with enforcing the policy. The venue for moderation is "all repositories under the Node.js GitHub Organization and all Node.js Working Groups", which means that the Moderation Team does need Owner permissions.

I'm sorry if this sounds a little urgent, but the world isn't going to wait while we figure this stuff out. We need to enable the Moderation Team to do their job ASAP or we need to decide that this isn't a priority and change our documents accordingly.

[mhdawson]

@targos has been working to figure out if we can remove some of the remaining repos. @targos can you provide an update here ?

[MylesBorins]

I've posted intent to transfer the security repo to nodejs-private on wednesday the 10th, prior to the TSC meeting. This issue is on the agenda and I hope that we will be able to reach consensus on Wednesday as to how we can move this forward.

Are there any other repos we need to move?

[rvagg]

we have build-private and secrets repos that are sensitive, I suggest we defer to @nodejs/build about their status though

[rvagg]

only a few (one?) members of the moderation team could enact a temp ban, were it merited.

&

At this point we're going on over three months since the Moderation Team's kickoff meeting and members are still not able to effectively moderate. The Moderation Policy clearly defines that the Moderation Team is tasked with enforcing the policy. The venue for moderation is "all repositories under the Node.js GitHub Organization and all Node.js Working Groups", which means that the Moderation Team does need Owner permissions.

Or the moderation could be developing tooling to enable access to its limited set of needs, in the same way that the nodejs-github-bot project does for so many other needs. Again, if this is so urgent, you should be applying developer time to extend the bot functionality we already have to enable privileged access to just the pieces of functionality you need.

[MylesBorins]

build-private should likely be moved to nodejs-private, we can make granular teams to avoid leaking other repos

secrets is not particularly valuable if your gpg key was not used to encrypt stuff.

Or the moderation could be developing tooling to enable access to its limited set of needs

TBQH I don't think this is fair. We've tasked a group of volunteers with doing specific work which is not engineering. I think that if we don't want to extend access to the group it should fall on the TSC to do the engineering effort if we want it done. Overall moving sensitive data to nodejs-private seems like a really good idea... which could allow us to use more generic tooling without requiring custom engineering

[gibfahn]

Again, if this is so urgent, you should be applying developer time to extend the bot functionality we already have to enable privileged access to just the pieces of functionality you need.

The bot already exists, it needs people to push it forward. That would need to be people in the TSC, as they are the owners. I don't think we'd want the org management bot and the github bot to be the same bot, as they'd need different permissions.

See nodejs/community-committee#22 and nodejs/TSC#51, not sure how a moderation team member could push this forward.

As a moderation team member and possible future TSC person, I'd be interested in championing us using the bot, however experience tells me that that is going to take months at least, which is why I'm in favour of us moving private repos to nodejs-private, and giving the moderation team owner permissions.

In fact giving mod team owner permissions is the perfect way to stimulate people to get the bot operational, as then the mod team don't have to be owners.

we have build-private and secrets repos that are sensitive

+1 to moving them to nodejs-private, who has owner access on that repo btw?

[mhdawson]

@gibfahn looks like the current owners are the TSC members.

I also agree we should not block on automation being put in place that can take a while.

[mhdawson]

I'd proposed we move the discussion on org ownership for the moderation team to nodejs/TSC#469

[MylesBorins]

build-private has now been moved