[key packages] Pilot Packages #142
Comments
|
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. |
|
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? |
|
I think https://github.com/mqttjs/MQTT.js and dependencies are another good place to start. |
|
I agree we need to have several and MQTT sounds like a good one to add to the list. |
|
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 😁 |
|
I agree @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? |
|
Maybe some of the plumbing packages that are depended on for the native packages like node-pre-gyp |
|
@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. |
|
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. |
|
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 |
Eomm
added
the
package-maintenance-agenda
|
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. |
|
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:
|
|
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. |
|
@wesleytodd edited 👍 |
|
Hi, I would like to recap the topic to speed up the meeting tomorrow:
I hope I have correctly summarized 😁 |
Hi @mikeal, to reach the WG goals we need to start to help some pilot packages.
I hope to be exhaustive, let us know what do you think about it |
|
I would also be interested in being a maintainer of NeDB. I try to respond to most of the newly opened issues in the existing repository, and have also forked the project as NestDB to implement some requested new features, bug fixes, and performance improvements that its sole maintainer was not keen on merging or able to give time to (a problem with maintainership that so many of us know all too well). I've done my best to track the relationships of my changes to the original NeDB issues that most of them originated from in the hopes that, someday, they might make it back into the NeDB core codebase. There have also been other forks of NeDB, as |
|
@wesleytodd We touched on this briefly and we wondered if we are ready to take the next steps with either express or mqtt as we continue to build out the pilot list? |
mhdawson
removed
the
package-maintenance-agenda
|
Hey, yes any time. Do we have a concrete list of the first steps? I seem to remember an issue regarding this, but I have so many unread messages at the moment (👶 time). The start was a survey right? If so I can get that posted up in the express repo so we can fill it in. |
|
Ok, I posted this on the express discussion repo. I will hopefully get other contributor feedback and start working on those answers soon. |
@JamesMGreene could you ping the maintainer of NeDB to join the discussion? |
|
In last meeting we talked to find more packages We could start digging from this list: The top 20, to save you a click: |
|
https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509 contains a list of the top 1000 most downloaded modules. |
|
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? |
|
And here's some stats from versions extracted from node version count in travis.yml
|
|
Scavenging that data is very interesting. Another data that would be useful are the number of issues and prs open on those repo to gauge activity. |
|
tbh what I’d really like to see is top packages on npm with download counts of dependents and devDependents subtracted out |
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? |
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? |
I'll open a separate issue with the list shortly and we can take it from there. |
|
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? |
|
It is true, I thought the target for this issue was to find the pilot packages. |
|
+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. |
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:
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
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.
The text was updated successfully, but these errors were encountered: