Additional org owned by Node.js project for package maintenance team

[mhdawson]

In the context of https://github.com/nodejs/package-maintenance/issues/271

The package maintenance team is exploring how to host tools being developed.

The team does not want to use a repo in the nodejs or due to concerns that might make them look officially supported by the Node.js project and put other tools at a disadvantage.

At the same time the team would like to leverage existing governance, moderation that comes with a repo that is part of the Node.js org.

The ask is whether the TSC/CommComm would consider:

Can the Node.js Project can 'own' and additional repo, with the TSC delegating management of it to the Package-maintenance team and ask that things like moderation be extended to this new org.

[mcollina]

Definitely +1.

We might want to change how the package-maintenance team is chartered (or actually not chartered right now).

My concerns are about moderation and governance. Would the new org still be moderated by our moderation team? What is the role of the Node.js TSC?

[cjihrig]

Sounds like a decent idea. +1 to trying it.

[mhdawson]

@mcollina right now the package-maintenance team is just a team (not chartered)

Would the new org still be moderated by our moderation team?

I think that is the ask, that the moderation team have responsibility for the second ord

What is the role of the Node.js TSC?

The TSC/CommComm would be responsible for the org, just like the nodejs org so that the same requirements for repos (licences etc.) would apply as if the repos were in the nodejs org. Some rights to manage the org would be delegated to the package-maintenance team members.

[bnb]

I am not entirely convinced that the structural, governance, and moderation overhead is going to be worth adding an additional organization. This definitely stems from my personal looseness with organizations - I don't really think it's problematic to put work being done by people associated with an org inside of an org. If folks think something is official when it's not despite being explicitly defined as such (i.e. in a readme), that's a them problem.

Note that I'm not -1, I'd just strongly recommend it be within our own org as I only see it adding additional complexity when we already have an overabundance of complexity.

[wesleytodd]

Would the new org still be moderated by our moderation team? I think that is the ask, that the moderation team have responsibility for the second org

Yes, that is the ask. I think that it is important that this kind of thing be explicit and supported, but also I don't believe that the few of us contributing so far have the additional bandwidth to support it ourselves.

We might want to change how the package-maintenance team is chartered

I am not sure what that would give us. I am fine with it, but since these packages are in fact outside the original scope of Node I am interested in how it would look.

I am not entirely convinced that the structural, governance, and moderation overhead is going to be worth adding an additional organization.

I understand this concern and share it. Is there something which would help this be less of a concern?

I don't really think it's problematic to put work being done by people associated with an org inside of an org. If folks think something is official when it's not despite being explicitly defined as such (i.e. in a readme), that's a them problem.

It sounds like this is an argument for working on them in the nodejs org.. I would like to lay out at least a few reasons I am not sure this belongs in the node org unrelated to "official-ness":

1. Watchers. Most folks are auto watching, which means we could create alot of unnecessary notification spam.
2. Scope. So far these are moderately broad in scope. It seems reasonable that the Package Maintenance team might build things which are pretty far removed from the normal scope of work in Node core.
3. Naming. In an effort to publish the first such package we created https://github.com/nodejs/package-compliant. This really isn't a good name, and it is confusing to see in the nodejs org. Having @pkgjs on GitHub and npm means we have a natural scope to publish under which allows more naming freedom.

Anyway, just wanted to make my case a little more clear than I had in the past. Hope that helps.

[codeekage]

Correct me if I’m wrong, but my understanding of this is - create a separate org completely independent from nodejs org (remove pkg-maintenance project from the node org).

Which brings up governance, moderation, and charter. And if the node project’s TSC still provides an overhead in the new org that makes the project the responsibility of node to ensure moderation in that new org.

From my time in node - moderation is extremely important.

I think it’ll make so much sense to have this figured out before giving a go-ahead on creating a new org.

Define its charter, define what governance is, define its moderation, and any other thing that we need to be clear on even legal, if necessary.

Another thought will be checking in with the CPC to ensure it’s ok for a project to have two GitHub orgs.

[ljharb]

Moderation is important, yes. I'm on the moderation team, and while I can't speak for the rest of the team, am happy to moderate the new repos we create - and the added complexity of it being in a separate org feels trivial to me (and also, automateable).

Why does the Github org name change anything? Does the project's governance not apply to whatever it both decides it applies to, and whatever it has the rights to apply it to? The arbitrary location of a repo is an administrative concern, not a TSC/governance/etc concern, no?

[MylesBorins]

Could the solution to this problem not be as simple as adding the new org / repo in the list in the readme.

Any repo / team will require their own governance... but it feels to me like just documenting it in the readme might be sufficient

[wesleytodd]

Correct me if I’m wrong, but my understanding of this is - create a separate org completely independent from nodejs org (remove pkg-maintenance project from the node org).

We do not intend to remove the team from the node org. We just have other projects we have started to help deliver on the work coming out of the team.

Another thought will be checking in with the CPC to ensure it’s ok for a project to have two GitHub orgs.

I missed the CPC meeting this morning, but I can ask in an issue. I am not sure why it would matter though.

Any repo / team will require their own governance... but it feels to me like just documenting it in the readme might be sufficient

That is what I was hoping. That if we agreed and documented it accordingly, that it would just be additions to the moderation team workflow and have the escalation policy go to the package maintenance team then TSC and not have to create a new group.

[MylesBorins]

Also worth mentioning I don't think there is any need to check with the cpc on this. Nodejs is chartered with governing it's project... The org / repo is an artifact of that. We have other orgs we already maintain

[WaleedAshraf]

We may need to extend the Applicability in moderation policy?

this policy applies to all repositories under the Node.js GitHub Organization and all Node.js Working Groups.

[mhdawson]

We've had few people chime in, but not enough to make sure we are moving towards a consensus. Going to add to the agenda for next week.

[bnb]

I understand this concern and share it. Is there something which would help this be less of a concern?

So far I’ve not seen a comprehensive list of what’s necessary. Before answering this, I think that would be needed to understand what the impact is.

Watchers.

We’ve got well over 100 repos in this org at present. If folks haven’t turned off auto-watch and aren’t okay with notification overflow, that seems like a them problem and IMO shouldn’t impact our decisions.

Scope.

The Node.js GitHub org has not been limited to the scope of Node.js core for some time, and I personally feel strongly that this should not be a blocker for us. Package Maintenance is a blessed team under the Node.js TSC and that equates the work we do as “official” regardless of whether or not it’s specifically about Node.js Core. If we are concerned about this, we should also consider spinning up a CommComm org, a nan org, a Docker org, and orgs for most WGs.

Naming.

I disagree that a mismatch in orgs is confusing. I completely understand the desire for purity here, but do not see it as a blocker in the given circumstances. If concerning, including a boilerplate section about “Why @pkgjs/” would definitely be sufficient, imo.

[mhdawson]

TSC has no objections/concerns over separate organization, removing tsc-agenda tag.

[bnb]

Pinging @nodejs/community-committee for objections/concerns. If there are none by Monday at 1pm ET, we can consider this CommComm approved.

On my personal comments: I am personally -0. I don't think it's ideal and I don't necessarily agree with the proposed reasons but I respect that others who are doing this work hold them.

[mhdawson]

No objections by Monday so considered approved.

[wesleytodd]

We are working out the details of this in the working group. Do we want to leave this open as a place to update and collect feedback on the plan, or are we good to close this now?

[mhdawson]

@wesleytodd I think leaving this open and using to document is a good idea.

[wesleytodd]

Awesome! Then here is the link to the WIP charter you started in case other folks want to give feedback: https://github.com/nodejs/package-maintenance/pull/338