[key packages] Pilot Packages

[Eomm]

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.

[mhdawson]

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]

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]

I think https://github.com/mqttjs/MQTT.js and dependencies are another good place to start.

[mhdawson]

I agree we need to have several and MQTT sounds like a good one to add to the list.

[Eomm]

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]

I agree request seems 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 in request, 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]

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 request numbers (which is also a dependency for both)

[mcollina]

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

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]

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 request is (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]

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]

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]

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:

• The problems this program is designed to address.
• What is being asked for from “pilot” projects and what may be expected from projects in the future beyond the pilot.
• What is being offered by this group to these projects.