Suggestion: Priority list of issues to be solved based on severity, popularity and reported need about package-maintenance HOT 10 CLOSED

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

from package-maintenance.

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.

from package-maintenance.

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

from package-maintenance.

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.

from package-maintenance.

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

from package-maintenance.

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

from package-maintenance.

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

from package-maintenance.

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

from package-maintenance.

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.

from package-maintenance.

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

from package-maintenance.