Process to identify and engage with "Key Packages" about package-maintenance HOT 21 CLOSED

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.

from package-maintenance.

@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.

from package-maintenance.

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.

from package-maintenance.

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

from package-maintenance.

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.

from package-maintenance.

@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 .

from package-maintenance.

@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 :)

from package-maintenance.

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

from package-maintenance.

Packages with most depended-upon packages.

from package-maintenance.

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

from package-maintenance.

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'.

from package-maintenance.

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

from package-maintenance.

@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?

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

@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.

from package-maintenance.

@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.

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

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

from package-maintenance.