Package-maintenance: Suggestion: Priority list of issues to be solved based on severity, popularity and reported need

[reinaldorauch]

It may be a specific case of #5 and #4 but here goes:

A common priority list that shows issues that need to be solved to keep the package updated with the lastest version of node, based on severity, popularity of the package, and reported need by the community.

Example: I identified a compatibility issue in nativescript-cli that crashed it when running in node 11.0.0 that was caused by a deep dependency that was stale and not receiving updates. It would be great if that compatibility break issue showed up in a centralized list in node.js ecosystem letting more people know that issue or package needs attention to not block the package from being used in next versions of node.

PS: this is a raw thought and by no means it is a finalized idea, so I wil appreciate any suggestions on this.

[mhdawson]

I agree it would be good have a place for a list of issues that are slowing adoption for the latest version of Node.js. We'll need to figure out what the best way to let people submit that information and then how to display it in a useful way.

[reinaldorauch]

We could use a new repo for this and digest metadata from issues from this repo to display in the page.

[balupton]

We could use a new repo for this and digest metadata from issues from this repo to display in the page.

From the example in your OP, seems that having something that scans npm for the most dependended upon packages, and then scan their github for bugs, and then when there is a +1 vote on the bug, use that multiplied by a weighting of the number of dependents, as the priority. Dependents may not be sufficient, install counts of the package, or install counts of the dependents may be better.

[Eomm]

Should also tests (or something like code coverage) a parameter of the function to define the priority?

[reinaldorauch]

@Eomm Could be, but I don't know how much of priority it has in sorting the packages.

[mcollina]

I think issues is too granular. IMHO we should focus on:

a) defining a set of criteria for modules we might want to help
b) creating and maintaining that list
c) define a process to work with the maintainer in keeping things up-to-date and stable

[aoberoi]

@mcollina that sounds like a pretty expensive approach, and one that needs to be balanced against some known capacity of this team. for example if the criteria yields 200 packages, will we have the capacity to work with 200 different maintainers? what if it yields 2,000?

i think any specific number will present a problem where this team doesn't have a constant capacity. members may come and go, along with any specific members attention. nobody would actually be accountable.

therefore i think it might be better for this group to design a process for surfacing known issues to a wider audience in the community. the process should be mostly automated so that it requires the least amount of capacity as possible. i do think having a blessed repo for "ecosystem impacting issues" is one possible solution.

[mcollina]

@aoberoi I think we are in total agreement, and we are actually saying the same thing.

[mhdawson]

therefore i think it might be better for this group to design a process for surfacing known issues to a wider audience in the community. the process should be mostly automated so that it requires the least amount of capacity as possible. i do think having a blessed repo for "ecosystem impacting issues" is one possible solution.

Is one of the approaches I had in mid for what this group might end up doing.

[reinaldorauch]

I will close this as I will not be able, unfortunately, to move forward with this