WG Supported Packages/Tools

[wesleytodd]

This has come up a few times, so I figured it is the right time to raise a separate issue (#192 & #236).

How do we want to maintain our own recommended solutions? Do we want "WG supported packages"? Do we just want them in the nodejs org on github? Are we alright just letting them live under the person who wrote the best (sadly often first mover biased) solution?

I setup a GH Org and registered the corresponding npm scope pkgjs because I wanted to start working on concrete implementations of the ideas we were discussing. I am happy to offer that up to the group as an option, but I recognize that there are also downsides to a "random" named GH org/scope.

The upsides I have so far is the ability to build things quickly and get them out there. Which we might not have as easily if it was all in the node org. I also personally like the idea of a scope dedicated to JS package maintainers and tools to make it all easier.

Anyone else have thoughts on this?

[Eomm]

How do we want to maintain our own recommended solutions? Do we want "WG supported packages"?

I think the easy way is to update the list of tools in onboarding-tools.md and add a disclaimer to contribute to the pkgjs org to grew up the tools faster.
But we should update also our CONTRIBUTING.md and find a balance because the issues here are the permissions to work on code (merge, publish and so on) that in node.js are more strict (for what I know). So, creating another org, we would need a bunch of rules like:

• to create a new repo open an issue in the package-maintenance ws as tool request
• to join you need to ..
• to cut new releases you need to ..
• etc...

These rules are difficult to define for me because they mean to create a new community.. that seems very tough.

So I would like to find a way to give the governance of the pkgjs org to this WG (and the nodejs foundation constitution) and define how to give code-right in the future.

[mhdawson]

The rules and process for repos under the node.js do vary. Making people collaborators in a repo within the org does potentially grant some access (for example to moderation repo). Just to say I think we could probably define the "governance" for the repo so that it allowed the same velocity.

For me the biggest thing to decide is on the value of being in the nodejs org in terms of discover-ability, ability to collaborate and overall support versus the potential to disadvantage other tools. Most important is to choose the option that will maximize forward progress. For example I'd prefer to have 1 widely used packages versus a larger number of hardly used packages. On the other side having 2-3 widely used packages competing with each other is better than have 1 dominant one.

I'm not sure there is one decision that will fit all cases. If it's unlikely that there will be competing vibrant modules then having one under the nodejs org is probably good. On the other hand if there is going to be a lot of people jumping into to develop a tool with different ideas and approaches having multiple viable options developed outside of the nodejs org will be better.

[mhdawson]

The other thing I'll add is that for people working at larger companies they often have to get approval to contribute to a given org or package. One extra benefit to being in the nodejs is that for anybody who has the ok to contribute to Node.js then they'll be able to contribute without having to get any additional approvals.

[wesleytodd]

the permissions to work on code (merge, publish and so on)

I am very much in support of having a place were a large group of people feel comfortable contributing. That said, at the small scale we are at it seems like just giving merge and publish rights on demand it fine IMO. For example, @Eomm I gave you merge rights on @pkgjs/support already, right when you mentioned it in one of the other issues. Leading to the next question:

So I would like to find a way to give the governance of the pkgjs org to this WG

In the long run I completely agree with this goal. In the interest of moving fast for the short term it seems more effective to grow it organically and not enforce governance or process too soon. Process this early would for sure block progress.

For me the biggest thing to decide is on the value of being in the nodejs org in terms of discover-ability, ability to collaborate and overall support versus the potential to disadvantage other tools.

I agree this is the most important issue IMO. The others we can figure out as we go, but this we need to decide on now. Personally I think that there is no clear answer on which is better, but if we go the nodejs org to start it will be much more difficult to change our mind later. Which is why I made the org in the first place :)

Most important is to choose the option that will maximize forward progress.

⚡️ 👍 ⚡️

The other thing I'll add is that for people working at larger companies they often have to get approval to contribute to a given org or package.

Do we have anyone we can get input on this from? This is similar to the "financial services company" issue brought up for the support spec, but without having experience there I am not able to understand the restrictions this type of company might impose. Input from someone who does would be great!

[mhdawson]

Do we have anyone we can get input on this from? This is similar to the "financial services company" issue brought up for the support spec, but without having experience there I am not able to understand the restrictions this type of company might impose. Input from someone who does would be great!

Me for one. I have approval to contribute to the Node.js project but will have to request access/get IBM review to contribute to a new org

[wesleytodd]

Me for one. I have approval to contribute to the Node.js project but will have to request access/get IBM review to contribute to a new org

OH! Well that is a big issue then. I had assumed this would be an edge case, but sounds like it will be more common.

With that in mind, if I had embarked on creating @pkgjs/support in this org, what are the answers to these questions:

1. Could I have just created the repo without raising flags or getting too much attention too soon? If not, what is the process for creating new repos in the node org?
2. What happens if we decide to abandon an idea? Does the repo still exist in the Node org forever? Do we retire it somewhere else? Delete it?
3. Scopes. With the GH package registry, my goal was to ensure I could get the same name in both ecosystems (to avoid package shadowing and confusion), do we need to publish under @nodejs the scope on npm?
4. Naming in general. As @Eomm pointed out, it was hard to pick a good name which was available in the global scope. Would we want this difficulty for each tool?

I am sure I have more questions, but those are the ones I thought I off hand.

[ljharb]

Why does the specific org make it a node, or a non-node, project? I’d think permission to contribute to any node project applies to any node repo, in any org.

[dougwilson]

Right, at my company there is no generic approval for any org, it is specific to each repo. This is because the approval is not arbitrary; they are looking for certain things, like is there a CLA and what does it say, what is the license of the project and what does the license say about patents, etc. A GitHub org does not force every repo within it to abide by the same rules, so my company doesn't care about the organization under GitHub :) Of course that's not to say company don't just give blanket allows, but if the idea is to cater to these types of organizations, I just wanted to provide another data point.

[wesleytodd]

@dougwilson This is also great input. I think this would be a great thing to expand on and make recommendations based on what makes the most people able to contribute. If a CLA is required, we should have a guide and default setup's for a CLA. Licenses are a different topic, and I would hesitate to make recommendations there, but maybe resources for maintainers about what companies look for would be helpful.

[mhdawson]

What @dougwilson mentions is true, although there are some high level requirements/consistency across the Node.js org in terms of licences, whether as CLA is used or not, etc. which are in place That makes it easier and can make a broader ok possible.

I can make it work either way. Just wanted to comment that it is potentially a bit more work people will need to do.

[mhdawson]

I'll also add that I think what I outlined in #263 (comment) is the primary concern, with whether its a bit harder/easier for people to contribute being secondary.

[dominykas]

I personally don't mind much either way, but just wondering if we need to formalize this yet? Can we treat @pkgjs as an incubator, and then depending on contributor needs and/or traction graduate to nodejs org?

Alternatively, can we somehow designate "pkgjs" to be the same as "nodejs"?

I find it useful to have that namespace - the nodejs org has 160+ repos and 160+ teams - it can be a bit overwhelming and that's aside the discoverability issues?

On the other hand - both GH and npm have teams, so maybe there is a case for being a part of larger org and doogfooding organizational issues and tooling. Not sure how much of that other maintainers/orgs face - but possibly they do have some of these problems, even if that might be smaller scale?

[ljharb]

Personally i find little to no value of this being in the node org, and a bunch of valuable things by being in a separate org. These packages aren’t node and don’t belong with node - this working group is to manage parts of the node ecosystem, but this deserve its own space imo.

[wesleytodd]

Can we treat @pkgjs as an incubator, and then depending on contributor needs and/or traction graduate to nodejs org?

I think this is reasonable, but then are we going to ask users to migrate from the incubator version to the "node core" version? That seems unlikely to happen smoothly. If we can make a good plan for this I am fine, but it seems easier to point people from node to the separate place, than try to move the whole repo.

These packages aren’t node

I tend to agree on this, and it was a good decision when Express broke out into pillarjs and jshttp. That said, there has been a discoverability problem. With things like the StatusBoard I am hoping to improve things, but it for sure has been a hurdle to contributions to the other orgs. I think it was worth it, but it is a downside for sure.