Which Problems Node.js OSS maintainers/authors face today? about package-maintenance HOT 31 OPEN

We should include in our best practices that Node.js as shipped by Debian and Electron need to be tested as well

It's difficult to draw a line there. E.g. if we recommend to test native modules against Debian's distribution, then what about Alpine (for which prebuilt binaries must be built with musl), ARM, Android and so forth.

I think rather than saying "you need to test on X" as a best practice, we should say "if you want to target X, here's what you can do" as a guide.

from package-maintenance.

For what it's worth, I strongly disagree with only supporting LTS versions and think that trend is hugely harmful to the ecosystem (I'd be delighted to debate/discuss that somewhere else, but let's please not get into it on this thread :-D ).

In other words, even that recommendation wouldn't be uncontroversial.

from package-maintenance.

We usually direct them to stackoverflow and our gitter channel, but that kind of help still takes time reading and assessing. What I was proposing is people who were around and wanted to be helpful could triage and direct people like we do. And if it was something more complicated, could be tagged for the primary maintainers to look at.

from package-maintenance.

Can we find a way to make people who do tech support in their day jobs spend their evenings to do OSS support for free? (Sorry, dark humour)

I think doing support is one of the most draining tasks that maintainers face. It's personal, it brings little value to the remaining community, it brings little value to the maintainer (unless a recurring request identifies a broader usability problem, which is rather rare, I suppose) and it is hard and quite often even when support is provided or a request for more information is made, the person who asked for support never responds again.

I don't have an answer, but I have observed and thought (more like sighed...) several times about it. I think that package-help deserves a separate issue to discuss options and ideas.

My current thinking is that OSS maintainers should not do unpaid support and that's probably a best practice. Support is expensive (there's a reason that businesses have separate departments doing that, rather than send their devs to do T1 responses) and brings value only to the supported, so maybe some default template responses with some links to where paid/free support can be acquired is a good thing to prep.

Yes, there's people who are willing to do that, but I'm not sure that relying on that is sustainable. Yes, people supporting each other is what communities are made of, but more often than not an issue for support is the single contribution a given Github account has ever made.

from package-maintenance.

Indeed @dominykas this is the dichotomy we face, we on one hand depend on these packages for our daily work and spend all day long solving business problems that make money. This leaves little time for us to show our appreciation by way of offering support for the tools we have been essentially gifted to make that money. I think we are searching for sustainability. Currently this entire endeavor is asking how we can sustain without paying for it, at least in cash. We will have to find a middle ground.

from package-maintenance.

A practical approach is to only support the LTS version. But we actually need to be really clear about what are our aims and what consequences those aims will have.

If the aim is to make sure that the enterprise can adopt and choose to subsequently support node then the LTS path makes the most sense. Enterprise upgrade less often and stick to the LTS versions.

We have to also be practical in that the weight of maintenance would eventually not be sustainable for anything other than the current LTS.

from package-maintenance.

as suggested I opened a new issue. I agree that what I said may be cause discussion.

from package-maintenance.

I don’t agree; i find tons of bugs by supporting the community. I think supporting the community is a best practice - if someone will pay, great, but regardless.

from package-maintenance.

Should we recommend that these utility be moved into a bigger organization

This is what express has done, but it still has not developed a "community" around them. We have jshttp and pillarjs as a way to organize different types of modules used or maintained by the express team. It turns out that it is basically just the same group who worked on express.

There are two main trends in supporting different Node.js versions in the ecosystem

I fully agree with @ljharb's comment above. That being said, Express does not support "all" versions. We support the core versions at the time of the major release and above. So the wide range of support right now is just because we have not cut 5.0, but when we do it will drop support below the current versions. This is keeping with semver, and IMO would be what we should recommend if we recommend anything in this area.

Framework authors have often the challenge of testing the ecosystem for breakage of their dependents.

This is where a CITGM engine would be great! #84

Providing support for the user is a tough job

This is a problem we can help with IMO. This is one of the largest time investments the express team does, and it often has nothing to do with express directly. Many times it is "new to node" type issues, others it is node core http, and some are just asking for advice.

If we could channel all of this helpful energy into helping triage and debug with users it would go a long way to helping reduce burden for maintainers. I think the "good first issue" tag model might be something we could piggy back off and make a "needs triage" tag. Just pulling a list of these issues and presenting them to people who want to help might be a good start.

from package-maintenance.

Many times it is "new to node" type issues, others it is node core http, and some are just asking for advice.

Variety of places, stackoverflow: there are a lot of answers with no real understanding.
Is it still "help" or not, if they look like answer but impact as a problem for thouse, who asking?

And if some package mainteiners answers directly, it always seems like a best solution. Therefore I think it might be more helpfull for users to make some solution of QA for packages, and additionally some sort of answers rate for managing "helpfull energy", if package is moved to bigger organization.

Or, though it might be hard, there is a way to link package with stackoverflow directly.

from package-maintenance.

And if it was something more complicated, could be tagged for the primary maintainers to look at.

Oh, I see, thank you. Looks like 1st tier of support. So there can be common solutions, kind of enterprise ITSM software, but 4 everywone. Still wonder how person from this 1st tier will separate "something more complicated". Though, users are always turning back to the ticket, if answer was not helpfull. I think that is why users more often prefer systems with tracking ID to general chats with no linking.

Then the second point is to seek a solution for this. For example, this can be real help from "bigger organization" to unfold that solution if package is moved in. It might be real preference for package maintainers if there will be sort of guarantie of help to users. Google Groups are good as Help Desk, might be if the will be a way to auto-create pre-set of a group with all that necessary stuff, it will be the answer. Though it is very complicated topic. And also it can help with releases\changes notification channels as well: some bots stuff able to notify via twitter\slack\telegramm\whatever.

from package-maintenance.

In MQTT.js, we have 113 open issues, most of those from people that are new to Node.js. There has been a huge amount of questions of how EventEmitter works for example.

We usually direct them to stackoverflow and our gitter channel, but that kind of help still takes time reading and assessing. What I was proposing is people who were around and wanted to be helpful could triage and direct people like we do. And if it was something more complicated, could be tagged for the primary maintainers to look at.

As you said, this requires time as well, and it's the lack of time that we are talking about here. Should we perhaps recommend to go to https://github.com/nodejs/help?

from package-maintenance.

I don't think using https://github.com/nodejs/help would be the right answer but we might create something like https://github.com/nodejs/package-help.

That would let existing contributors to ../help continue to focus on Node.js if that is there interest and provide a more centralized place for people who want to contribute to helping people with more general issues.

from package-maintenance.

I don't think using https://github.com/nodejs/help would be the right answer but we might create something like https://github.com/nodejs/package-help.

I am not sure either of these would be the right solution. This would just be another place to check, because most of these users would not go there in the first place. I think stack overflow and some real time chat community (slack or gitter or whatever new chat app the kids use these days) is fine.

My current thinking is that OSS maintainers should not do unpaid support

While I agree in principal, this is one of the reasons the node community has been so great for new developers. That there are a lot of people out there willing to help. I think saying "we dont do unpaid support" is too hard of a line.

I'm not sure that relying on that is sustainable

I think we are searching for sustainability

Currently this entire endeavor is asking how we can sustain without paying for it, at least in cash. We will have to find a middle ground.

I think these are the right questions to be asking. Sustainability is the goal, and I think a mix of paid and unpaid work is the goal.

from package-maintenance.

I might step in .. I have the habit of publishing to npm quite often (sorry for that) and doing so over a long time, I guess shipping something that is available for a big number of node versions has become harder (i guess) and here we could look at some new good practices.

from package-maintenance.

I think it would be useful to identify a few key package maintainers and then have somebody reach out to them to either discuss/capture their major pain points or ask them to get involved in this thread. I'm not sure how to generate that list but finding maintainers with larger number of packages or those that are heavily depending on might be a good start.

from package-maintenance.

In respect to

I am not sure either of these would be the right solution. This would just be another place to check, because most of these users would not go there in the first place. I think stack overflow and some real time chat community (slack or gitter or whatever new chat app the kids use these days) is fine.

On the flip side, if there are people who want to help out with having issues go into one place versus all of the different packages would be easier for them. The module owner would have to document that the first place to open an issue is package-help as opposed to opening an issue in the repo for the module (you could even require an issue be opened there for a week before you can open an issue in the repo for the module). The big assumption is that there are people who will be willing to provide general help for multiple different modules and I think a common package-help would have to auto close issues that are opened if nobody jumps in to help after 1 or 2 weeks.

The question in my mind is does this over value over people just using stack overflow instead. Maybe just documenting how module owners and refer people to stack overflow for initial help?

For example in @mcollina's case, would requiring people open an issue in stack overflow first and have it be active for a week before you can open an issue in the MQTT repo help. If so them maybe working through and documenting the mechanics for that might help. If it does help then would having something like package-help improve the situation by making it easier for people willing to help find the issues? If so then it might make sense, otherwise not.

from package-maintenance.

Interesting subjects being discussed here.

I've been thinking about supporting all versions vs just LTS and I think I'm in the camp where just supporting LTS seems like the more practical approach longer term. Supporting everything is quite a challenge in that package maintainers would need some kind of way to reliably test breakage across all the versions and then figure out how to provide the same functionality regardless of whatever JS language features are available or not. Imagine writing a brand new and clean npm utility package that uses async/await and then having to port that code to versions of node before 8... It could potentially introduce quite a lot of complexity to manage.

https://github.com/nodejs/citgm is amazing for at least digging into compatibility! Maybe there's a way to leverage CITGM for testing before publishing to npm? Seems like some minor tweaks could add a lot of value if it were suggested as a baseline check for documenting compatibility with authority.

2¢

from package-maintenance.

@bluesockets you can already test breakage across all versions going back to 0.6 using travis-ci and nvm, see here for an example; you can use babel to transpile prepublish with the env preset so you never have to think about syntax support. These are all solved problems that end up requiring minimal complexity to set up and virtually zero to maintain.

from package-maintenance.

@ljharb That's gold right there! I sure as heck didn't know about these tools until this conversation. I'm completely for surfacing this info somehow as a best practice for maintainers. If it's low effort/complexity to do then should we recommend it as a best practice so modules can maximize compatibility?

from package-maintenance.

I certainly do already :-) it’d be great to come up with a best practices guide for things like this.

from package-maintenance.

We should include in our best practices that Node.js as shipped by Debian and Electron need to be tested as well, because they may be ABI-incompatible with the official distribution of Node.js as provided by nvm even though the NODE_MODULE_VERSION happens to line up.

nodejs/TSC#651

from package-maintenance.

Personally i only support (and recommend supporting) node as installled from the only official distribution mechanism, nodejs.org, but i also don’t write native modules :-)

from package-maintenance.

On a related note, users also have trouble with native modules on platforms like AWS Lambda, which a maintainer cannot solve (other than graciously providing support). So perhaps we need both a guide for maintainers (how to support as many platforms as possible) and a guide for users (what to do when your platform isn't officially supported).

from package-maintenance.

Maybe the next step is to talk to the maintainers of the pilot packages we have identified and try and get their topic issues?

@mcollina is that something you can setup.

from package-maintenance.

I won't have time to do this for the next two weeks.

from package-maintenance.

Nobody in today's meeting to discuss this specific issue/tool. Will hold off on discussion next meeting that someone is present to discuss.

from package-maintenance.

Maybe the next step is to talk to the maintainers of the pilot packages we have identified and try and get their topic issues?

I would add to this issue how the MQTT.js reply to questions #175
We are also waiting for the express.js reply.

from package-maintenance.

@mcollina have you had any time to make progress on this?

from package-maintenance.

Not at all. I would not have time anytime soon unfortunately :/. Sorry.

from package-maintenance.

Is there anything npm can provide in the context of anonymized data, patterns & behaviours that would help further surface information and insights here?

from package-maintenance.