Repository navigation
[key packages] Pilot Packages #142
Description
Split 1/3 of #105
We can use to start collaborating with the authors to learn and iterate with.
Edit more info:
to reach the WG goals we need to start to help some pilot packages.
These modules will be helped by this WG adding support tools, documentation, fixes and all things to archive our goals and carry benefit to the package itself.
This WG will improve his guidelines, will learn different requirements and will be able to find patterns and solutions, test all the process and tools that are gonna to be built in order to evangelize the community and let the maintenance of an OSS package will be easier for maintainers.
What this WG ask to the pilot packages is:
- explain the biggest problems and their priorities (as talk about Which Problems Node.js OSS maintainers/authors face today? #113 )
- give feedback to our improvements/suggestion/PR
Express and all its direct and transient dependencies like pillarjs and jshttp are the most mentioned package to start with.
@wesleytodd has discussed a bit of this possibility on the last Express TC meeting so I think the Express team would be on board to participating.
What to discuss here
- We need to agree or not to start with Express as a pilot package. If "no" what else?
- To define if we can and should add more "friendly" pilot packages
After that we could start to get "Directions of Help": the way package maintainers wish to receive help and define the first tasks.
Ex:
Express needs help with repo cleanup, automation, documentation and, user support.
Activity
mhdawson commentedon Jan 31, 2019
Starting with Express sounds good to me, given that they are a key part of the ecosystem and it sounds like they are open to working with us.
wesleytodd commentedon Jan 31, 2019
While clearly I am a fan of working with Express, I think we need at least a few others to make sure we have a variety of input. Anyone have other suggestions?
mcollina commentedon Feb 1, 2019
I think https://github.com/mqttjs/MQTT.js and dependencies are another good place to start.
mhdawson commentedon Feb 1, 2019
I agree we need to have several and MQTT sounds like a good one to add to the list.
Eomm commentedon Feb 1, 2019
I don't know other friendly packages that could collaborate with us in this pilot phase.
Appling manually the basic criteria we talk about, I think that request could be a candidate: it is widely used and have a lot of issue and PR: it seems they need help to break all that work!
I looked here, there is a nice bubble schema that show the libs per usage, I took the first one with many issue&PR opened. Nothing personal 😁
wesleytodd commentedon Feb 1, 2019
I agree
requestseems like a good target. @reconbot & @mikeal Does this program seem like something you would be willing to participate in? I know you two are involved inrequest, but if there is anyone else we should ping please feel free!@mcollina Are you the primary maintainer for MQTT? If not, are there others we should reach out to to see if they are willing to participate?
nschonni commentedon Feb 1, 2019
Maybe some of the plumbing packages that are depended on for the native packages like node-pre-gyp
I'm hoping to move node-sass to that in the next major version, which would bump it up close to
requestnumbers (which is also a dependency for both)mcollina commentedon Feb 1, 2019
@wesleytodd I'm the only active one with publish access. I can add more if it is needed, but I'm probably the only one that knows how all the pieces fits together.
reconbot commentedon Feb 2, 2019
I've been doing some bug triage for request, and have landed some patches but haven't yet done a release. The future of that package is a discussion. There is a desire to leave it as is and encourage the use of more modern packages even, however keeping it supported is obviously desirable. I've read the linked issue and the blog post, but I'm not sure what the work would be to be part of this project.
wesleytodd commentedon Feb 2, 2019
I think that is a great stage for this WG to look at. I think we should be taking into consideration the entire life cycle of maintenance, including EOL like you say
requestis (although I feel like this might come as a shock so some users). That is to say, I don't believe this should disqualify it from consideration here.wesleytodd commentedon Feb 2, 2019
Also, @reconbot, maybe you will have some input on #139. Does that proposal seem like something which would help signal to users the state the maintainers think the project is in?
chrkaatz commentedon Feb 3, 2019
One other candidate might be nedb as the creator of it asked for help himself but I know that the package is not used very much anymore these days.
mikeal commentedon Feb 4, 2019
It’s not clear to me from the thread here and the links exactly what this pilot program means and what the goals are.
When engaging projects it would be great to have a concise write up of:
wesleytodd commentedon Feb 4, 2019
Great points. @Eomm maybe we could edit the OP and add some of this?
The goals of this WG can be found here.
A pilot project would be the first group we try to help. The requirement would be a willingness to try some ideas and provide feedback on how they work.
This is in the process of being defined. And the hope is that the pilot projects help us refine and decide on what specific things would be best for us to provide.
8 remaining items
Eomm commentedon Mar 4, 2019
@JamesMGreene could you ping the maintainer of NeDB to join the discussion?
Because I think we can't help that package if the maintainer can't collaborate for whatever reason.
Eomm commentedon Apr 10, 2019
In last meeting we talked to find more packages
We could start digging from this list:
The top 20, to save you a click:
debug
kind-of
supports-color
readable-stream
source-map
yargs
camelcase
minimist
strip-ansi
chalk
commander
@types/node
punycode
ansi-regex
ms
glob
define-property
semver
async
string_decoder
https://twitter.com/seldo/status/1115725616433602560?s=19
mcollina commentedon Apr 12, 2019
https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509 contains a list of the top 1000 most downloaded modules.
It would be good to do some sort of data analysis of the dependants and dependencies of these, as I guess there are a lot of overlaps and macro-trends.
dominykas commentedon Apr 13, 2019
Here's some percentiles on last update age of top 1000 packages:
This means that roughly half of them have not been published since last node LTS... Now, that in itself does not mean they weren't tested in that LTS (even it travis.yml wasn't update, although that's a good indicator), but it gives perspective on how much of just the top 1000 is either "abandoned" or "done".
What kind of dependents / dependencies data did you want to see @mcollina?
dominykas commentedon Apr 13, 2019
And here's some stats from versions extracted from
.travis.yml(didn't bother cleaning those up, just yet):node version count in travis.yml
mcollina commentedon Apr 14, 2019
Scavenging that data is very interesting.
I’d like to see if there are some dependency relationship. For example, we know that express uses debug. This info is helpful because we can take some macro-family.
Another data that would be useful are the number of issues and prs open on those repo to gauge activity.
ljharb commentedon Apr 14, 2019
tbh what I’d really like to see is top packages on npm with download counts of dependents and devDependents subtracted out
dominykas commentedon Apr 20, 2019
Sorry, not sure I'm following. You'd like to have the top1k somehow clustered into a group of deps that belong to a single dependent or smth? Or to put it differently - try to find a group that would likely get downloaded together? I can try to look into the dependency links in the top1k, but we don't have an easy, publically available method to go beyond that...
So getting these numbers is easy, but gaining insight is hard... Do you have any specific ideas or questions in mind?
A number of open issues on its own does not say anything (some maintainers close everything, others let issues linger, esp. support ones), the issue/pr rate over time is also meaningless - low activity could just be an indicator of done-ness and stability and I'm not sure how that is helpful?
What problems are we looking to solve with this? What problems can be discovered? I'm usually a fan of looking for data that can help make decisions, e.g. the numbers I posted can be used to determine which packages need some touching up to at least have CI run with newer node versions. Are there any other specific things we could be looking for?
Eomm commentedon Apr 23, 2019
I think that this question is more related to this issue #143 (comment) and here (pilot packages) I think we are looking for collaboration mainly from the maintainers of the modules and download numbers.
Adding issues/PR numbers will be useful for sure, but we could proceed step by step building the tool that we will use to list the modules to find them out so.. who are those packages in the >=50% from last travis update?
dominykas commentedon Apr 24, 2019
I'll open a separate issue with the list shortly and we can take it from there.
Eomm commentedon Aug 31, 2019
I would close the issue since the pilot packages have been selected
I don't know if we could ask to join in the #221 #239
wesleytodd commentedon Sep 1, 2019
Do we feel that the pilot packages issues have been addressed? I know we have a lot of things in the works, but it seems to me that unless we think we are ready to move onto the next phase we should keep this open.
IMO, the goal of the pilots are to get some actual working tests for the ideas we have. From express, we are only just now starting to implement the stuff we have talked about, and have not really even gotten to give feedback on their success/failure. I dont know how the MQTT progress is on this, but I haven't seen anything concrete here yet.
Thoughts?
Eomm commentedon Sep 2, 2019
It is true, I thought the target for this issue was to find the pilot packages.
We can keep it open to collect the results also for sure 👍
mhdawson commentedon Sep 5, 2019
+1 to keeping it open. We are starting to make some progress but I'd agree there is more work before we can consider this part complete.