Process to identify and engage with "Key Packages"

[wesleytodd]

One of the primary goals of this working group is to identify and provide services to a group of npm packages we are calling "key packages". These packages will need to be defined in some way, and will hopefully receive the benefit of the WG's effort. Defining a small set of packages to "deem worthy" of our time is hard, and inevitably we will need to adapt it as we find success.

@mcollina recommended that we pilot our ideas with some "friendlies". This is a great idea for working out the kinks of the WG's role in third party package ecosystems, but it can limit the impact we can have on the community. To help both the short term and long term goals, I would like to propose a staged rollout approach.

Staged Rollout Proposal

1. "Pilot Packages": Establish a list of "pilot packages" we can use to start collaborating with the authors to learn and iterate with.
2. "High Impact Packages": Once we have established some of the group's initiatives and tried them out with the pilot packages we can choose a larger group of high impact packages to implement the same practices and standards with.
3. "Open Enrollment": Open adoption of the groups standards, best practices and any tooling support we provide. This would need a defined process, but would open the support to the greater community.

What to discuss here

To get things started I would like to discuss this approach to "defining key packages". If this approach suits the group, then I would like to open continuation issues for the three phases of the project where we can continue with those discussions. Once we have those smaller conversations defined, I will update this issue with links and decisions as the hub for the overall initiative.

What can wait for those other issues

I mentioned in the first meeting that I would like to offer up some of the Express ecosystem packages as good "pilot packages", which is why I was identified as a good person to push this forward. This kind of discussion I would like to push into those other issues if no one has strong opinions against the approach I propose here.

Also any information relating to how specifically we identify the packages at each phase can be left off for the other threads.

[chandanrjit]

@wesleytodd @mcollina What will be criteria for "defining key packages" . As pointed out by @jchip during the first meeting is "No of downloads".Do we have any other criteria options ? Can we go for a dashboard where we see list o the packages considered in phase one .

[wesleytodd]

@chandanrjit Thanks for posing some good questions, but these are questions I was hoping to move into the other issues I plan to make. It will be very helpful for us to keep these conversations on track. Once those issues are created I will be sure to address those questions!

If someone can mark my comment and the one above as off topic or give me the permissions on the repo to do so? Just want to keep the conversation moving forward and productive :)

[potham]

Do we have any metrics to 'define key pakages' other than downloads?

[ZiedCHOUK]

Packages with most depended-upon packages.

[mcollina]

I think a key measure would be to identify some frameworks/tools that are extremely commmon, as an example: express, webpack, react, etc. Then, we identify their full dependency tree (including their devDependencies) and rank by downloads. During this process, we should also check if one of those dependency is on an older major and why.

A criteria for ranking the modules in term of "do they need help", I propose

1. number of dependencies, the fewer the higher rank.
2. parse their CI file (.travis.yml for example) and verify that they test against all supported Node.js versions (or maybe just LTS). If they do not, seek and understand why.
3. number of "old" dependencies npm outdated

[esphas]

Apart from data like 'downloads' and 'dependents', I think community feedback of the package can also be considered, such as GitHub open issues, related Stack Overflow questions and so on. After all, these can somehow reflect the status of the package, and more problems tend to result in more feedback, although this kind of data may not be necessarily comparable among packages, and not as important as things like 'dependents'.

[Eomm]

I agree with the "staged rollout" proposed, maybe could be added also an "auto propose" form/issue because some maintainers could drop the maintenance and let us know before it happens.

And, shell we commit these kinds of utilities in a dedicated repo?
Because we could add a sort of pipeline to add multiple steps to define the priority, for example as said before:

+ num download
+ num dependencies inverted
+ look for CI test against LTS node.js
+ npm updated
+ opened issues on repo
+ stackoverflow sentiment
= priority

and will be easy to change based the on the experience we will acquire

[wesleytodd]

@Eomm thanks for the feedback, I think "auto propose" could be a part of step 3. The goal being to streamline bringing on new packages and contributors to the cause.

@esphas @mcollina @ZiedCHOUK @potham I hope we can narrow down these ideas once we decide if this overall approach is a good idea. Can we keep this issue on that focus until we hear some general thread of agreement?

[mhdawson]

I'm +1 for the approach outlined. One comment is that don't think it needs to be fully sequential in the sense that we can start discussing how we would identify key packages while we are working on stage 1. In that way we'd be ready to start engaging with those packages one we complete stage 1.

[wesleytodd]

don't think it needs to be fully sequential

I agree. I think we should have all three parts being discussed in parallel. I mainly didn't want us to bite off more than we can chew right away. For example if we find that one approach is much too hard in the pilot, then we could avoid having too many packages depend on it.

[wentout]

Hi, just wish to suggest some discussions of packages known by everywone.
For example utilising the MEAN stack it will be:

• express already nominated through some issues here
• mongoose as an obvious dependency

Also this might be widely used: moment.js

Sorry, though: not so deliberate and very opinionated addition...

And seems, cost of popularity can differ also. For example, Mongoose.js is not so popular package, if make mesurements only by installations/downloads. From the other side, it usually runs server with a lot of users of that server. Therefore one Mongoose Installation/Download might impact more than one React or Angular installation. Accordingly issue in Moment.js might inflict a lot of chained errors, and all we know that cost of errors with Dates.

[nairihar]

@wentout seems mongoose has lots of issues but only one of them is confirmed the bug.
Mongoose Open Bug Issues

Same with express: Express Open Bug Issues

But its not same with moment.js package, there is lots of comfirmed bugs.
Moment Open Bug Issues

Seems it's one other good way to find some packages which need help, we can search Open issues which labelled as confirmed bug of the package.

[ghinks]

@nairihar indeed express is many folks bread and butter. From my interactions with vkarpov15 who is the mongoose maintainer I do not believe that there would be many open bugs. But it is an important module. I think, just my 2 cents worth, we should start with express and friends just as you have suggested.

[wentout]

@nairihar @ghinks

Yes, about Mongoose and Express it seems: number of issues doesn't mean a lot of bugs. Just this software is widely used and for solving really huge bunch of tasks. Mongoose it not only about DB, and Express is not only about HTTP and servers, and therefore there might be a lot of just questions of some tough tasks. And I wish to say the way of helping there is about helping users and cleaning up that pale if Issue, to make it easier to maintain really important things.

And about moment, sure, it is very needed module, though it has competitors, but it used widely. And number lf bugs there really matters.

So, I'd wish to suggest "Directions of Help" and construct measurements calculations based on the way package maintainers wish to receive help.

[mcollina]

I don't think either Mongoose or Express fit in this description. Mongoose has a maintainer that has put in 80-something commits in the last month (Dec 2018), so development is very active there. Moreover it's maintained by a company (Automattic) which I think it should be outside of the scope of our activity. Express is a Node.js Foundation project, and as such it should be treated somehow differently. if we think Express needs some help, then it's worth a discussion on its own to boost the number of active collaborators, if this is something the project would think it's needed (Node.js has a good track record of attracting new collaborators, and there is a lot that could be borrowed from it).

I would consider most modules under https://github.com/pillarjs good candidates, these are part of express but also used in other frameworks and indepedently.

[mhdawson]

I don't think we should rule out Express just because it is part of the Node.js Foundation. As a "friendly" project it might fit with finding "Friendlies" for the Pilot phase along with the supporting modules.

[wesleytodd]

I would consider most modules under https://github.com/pillarjs good candidates, these are part of express but also used in other frameworks and indepedently.

When I mentioned "express" I was implicitly including all of its direct and transient dependencies. Most of which live in either https://github.com/pillarjs or https://github.com/jshttp.

Also, what we need help with is mostly not feature work, but repo cleanup, automation, documentation and, user support. If we had good first line triage (including issue template, response bots, etc) it would free up the primary contributors for some of the other stuff, but anything in the other areas would be great help!

And status as a node foundation project has really been zero value add other than a place to "own" the assets like the website and such. So I agree that that should not be a reason to exclude it, in fact it might be a reason to focus on it (but I am clearly biased 🤣).

I have been busy with stuff, but hopefully this weekend I will have time to start a clean thread for discussions of the three phases proposed above. At that time I will close this one, as it was just to start the conversation with a clear plan. I will make a synopses of this conversation there to kick things off.

[mhdawson]

I have been busy with stuff, but hopefully this weekend I will have time to start a clean thread for discussions of the three phases proposed above. At that time I will close this one, as it was just to start the conversation with a clear plan. I will make a synopses of this conversation there to kick things off.

+1 was thinking this discussion was at the stage where it needed that.

[mhdawson]

Tagged with package-maintenance-agenda so that it's on the agenda for an update.

[Eomm]

make a synopsis of this conversation there to kick things off.

Done in #142 #143 and #144
I hope I don't have miss nothing, in case I ask you to write it in the right issue ✌

Closing

[wesleytodd]

Thanks @Eomm for taking this for me, great job on breaking them down! And it looks very complete to me. I think having three targeted conversation will be much more productive.