nodejs / package-maintenance

Repository for work for discussion of helping with maintenance of key packages in the ecosystem.

package-maintenance team

Repository for discussion on how to help ensure baseline maintenance and ability to safely use key packages in the ecosystem with current Node.js versions. You can find more about this initiative in the article: Call to Action: Accelerating Node.js Growth

Goals

• Define and document how to prioritize which packages are key to the Node.js ecosystem, and how/what assistance can/should be provided. One key aspect is understanding what communication channels are needed in order to identify when specific issues are slowing migration from one Node.js version to another, or causing friction in the ecosystem.
• Building and documenting guidance, tools and processes so businesses can identify the packages they depend on. Businesses can use the information to build a business case which supports both the organization and developers helping to maintain those packages.
• Documenting a backlog and providing resources to help businesses identify how their developers can contribute, and get engaged. Developers can test and validate a workflow to help with issues slowing migration to Node.js 10.x.
• Building, documenting and evangelizing guidance, tools and processes (for example LTS for modules) can make it easier for maintainers to manage multiple streams, and accept help from those who depend on their module.

For Maintainers

Are you a maintainer of an open source project looking for help and resources maintaining your package and community? To get you started,

• Review our growing set of documentation around topics like CI / CD, testing, and governance

Feedback

Want to provide feedback on your experiences as a maintainer? Want to let us know what topic and tools you think would be helpful to pursue within this group? Open a PR to fill out this survey and the team will be sure to review and get in touch with you.

Joining

We encourage participation from members across the Node.js and JavaScript ecosystem. Feel free to join schedule meetings and participate in the issues within the repository.

How to Join

The package-maintenance team has two levels of membership. Administrative members and regular members.

If you'd like to be listed as regular team member, open a PR adding yourself to this MEMBERS.md along with a few words on how you are planning to contribute to the team's efforts.

Administrative members take on additional levels of responsibility with respect to managing the pkgjs organization and the other repositories managed by the working group. Administrative members should have a long standing involvement in the working group.

Individuals who have made significant contributions and who wish to be considered as an Administrative member may create an issue or contact an Administrative WG member directly. It is not necessary to wait for an Administrative WG member to nominate the individual.

For more details refer to the WG Governance document.

Logistics

Meetings

Meetings of the working group typically occur bi-weekly as shown on the the node.js project calendar. A few days before each meeting, an issue will be created with the date and time of the meeting. The issue will provide schedule logistics as well as an agenda, links to meeting minutes, and information about how to join as a participant or a viewer.

Communications

The working group can chat on the Node.js slack in the channel #package-maintenance in order to continue conversations beyond the meetings. All the contributors are expected to follow the Code of Conduct of the Node.js project.

To join on slack you have to send a request and wait to be accepted: it is a manual workflow, so it could take some days (we are working to help improve this).

Pull Request Merging Policy

The package maintenance team policy on landing a PR in the nodejs/package-maintenance repository is for there to be:

• At least 4 approvals from regular members
• No blocking reviews
• 7 day period from the 4th approval to merging

All PRs shall follow the contributions policy

Current Project Team Members

• See the list of Administrative Members
• See the list of Members

Emeritus Project Team Members

See the list of Emeritus

package-maintenance's Issues

Suggestion: Broaden to cover security patching any abandoned package

I've had a situation arise a few times where abandoned packages have pinned dependencies, and one of these dependencies contains a vulnerability that could be removed simply by loosening the semver range in package.json. But pull requests to fix the problem are ignored, These packages probably don't meet the "key to the Node.js ecosystem" criteria, but nevertheless are something that the npm community does not deal with adequately.

The official way for a user to deal with these problem packages is to write to the author, and if they consent/don't respond, ask npm to transfer ownership to their account. But this is rarely done, as few individuals want to volunteer to maintain a package that they are only connected to via a long dependency chain. It feels like there is a need for some way for users to take collective action.

Could it be in scope for this group to enforce dependency patching for abandoned packages?

Chose Second Timeslot for meetings

In the first meeting we agreed to continue to use 3 EST on Monday as one of the times for the meeting.

I've added the next meeting as 14 Jan at 3 EST. Issue will be auto-generated later this week.

We also agreed we should alternate with another timeslot that works better for members who are in Europe and other regions versus N/A.

This is the doodle link to select that alternate time: https://doodle.com/poll/5thet26ff7uybinv

Inner vs. Open Source

I see all the guides here being a great resource for both open source and inner source packagae maintainance, how can we ensure we cover both use-cases in the language / advise offered?

e.g. in the comments of #160 a suggestion was made to infer that maintainers should not mark projects "unlicensed", but that is unapplicable for inner source projects.

Definition Reminder:
Inner source is the use of open source software development best practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software, but internally opens up its development. The term was coined by Tim O'Reilly in 2000. source - wikipedia

can we add Inner Source as part of the objectives / target coverage for topics produced and discussed in this project?

I only see it as a partial incerement in effort to ensure the language / examples / etc... are inclusive of that context.

Discussion: Baseline practices - brainstorm initial list

This issue is to discuss/brainstorm an initial set of best practices that the team would focus on.

To start the discussion there are some possibilities:

• Maintaining Modules:

  • Generally, effective access control / publishing rights on npm

    • for example use of 2 factor auth

  • How to transfer sole ownership of a module

    • how to establish trust of potential new owner
    • how to inform module users/ node community

  • How to request help, but not relinquish ownership

    • how to facilitate easy contribution from 'trusted' parties

  • Adherence to SemVer, adopting (some form of) module LTS, keeping dependencies minimal and up-to-date

  • What to do when it all goes wrong

    • Malicious takeover
    • Backing out malicious code contribution
    • Known severe vulnerabilities clearly being exploited, no time/ability to fix

• Consuming Modules:

  • Help assessing and including a module -- Content from this talk might be a good starting point https://www.youtube.com/watch?list=PL0CdgOSSGlBY7DBgOp1xsRvV31AAUZrX2&v=6pHuj6Hs9Gwfor distilling best practices

[baseline practices] Choosing a License and Choosing Dependencies

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Choosing a License

• important to the end user of which license the package uses

Choosing Dependencies

• has there been a change of ownership ? re-review dep : nothing

If I am missing anything please add a comment and tag me so I can update

Suggestion: CITGM for a module dependants

Developing a library at scale is hard, and as a maintainer the goal is to avoid unwanted breakage and regression. Especially when doing breaking changes, it's of critical importance to validate the impact of those changes, more or less how we do it in core.

In pino, we have done https://github.com/pinojs/pino-integration. In Fastify, we have done https://github.com/fastify/fastify-citgm. I think there is a space to build a generic and supported tool for testing dependant projects, so that we avoid breakages when doing releases.

[baseline practices] Testing

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Testing

• Jest, Mocha
• coverage should match most use cases for the module

If I am missing anything please add a comment and tag me so I can update

Suggestion: Job Board for common maintenance tasks

As an alternative to wikis and tooling to solve maintenance issues, for things that require manual efforts, such as:

• converting a project to typescript
• writing typescript declaration files
• upgrading dependency that has breaking changes across all dependents of it

It would be nice to have a job board, so that say someone in a specialist of upgrading X dependency can do it at $50 a pop for all dependents. Or someone who is an expert in typescript can convert the most used projects to typescripts or do up their declaration files for $50 a pop.

I'd certainly be a employer and employee of this service. It will also help provide jobs for the maintainers by trade, as well as help them work on the most scarce work of their talent while delegating common lesser gruels to others.

---

For instance, I've spent 3 weeks trying to learn typescript and convert all of @bevry's utility libraries to typescript, or at least provide declaration files for them. This is large waste of time for me, for the benefits of others, as it detracts from the product work I should be doing to earn an income. I'd much rather get a job for 3 weeks as an expert consultant, and pay a TypeScript expert $500 to convert everything (a few days work of consultancy for me), than for me spending 3+ weeks unpaid wrestling with learning and implementing typescript. However now that I am somewhat familiar with typescript, perhaps I can convert other libraries for a fee, as a way to recoup my efforts.

_{Sent with GitHawk}

Node.js Foundation Package Maintenance Team Meeting 2019-01-28

Time

UTC Mon 28-Jan-2019 14:00 (02:00 PM):

Timezone	Date/Time
US / Pacific	Mon 28-Jan-2019 06:00 (06:00 AM)
US / Mountain	Mon 28-Jan-2019 07:00 (07:00 AM)
US / Central	Mon 28-Jan-2019 08:00 (08:00 AM)
US / Eastern	Mon 28-Jan-2019 09:00 (09:00 AM)
London	Mon 28-Jan-2019 14:00 (02:00 PM)
Amsterdam	Mon 28-Jan-2019 15:00 (03:00 PM)
Moscow	Mon 28-Jan-2019 17:00 (05:00 PM)
Chennai	Mon 28-Jan-2019 19:30 (07:30 PM)
Hangzhou	Mon 28-Jan-2019 22:00 (10:00 PM)
Tokyo	Mon 28-Jan-2019 23:00 (11:00 PM)
Sydney	Tue 29-Jan-2019 01:00 (01:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-01-28&iso=20190128T14
• or http://www.wolframalpha.com/input/?i=02PM+UTC%2C+Jan+28%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1S_SrODJwz011yR_EeDGVx9og81TtVw8yMaauunv1e3k/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• Engaging Enterprise teams to better understand challenges at scale #138
• Discussion: Baseline practices - brainstorm initial list #119
• Which Problems Node.js OSS maintainers/authors face today? #113
• Process to identify and engage with "Key Packages" #105
• discourage use of unmaintained packages #93
• Suggestion: Provide template/guides/automation for common maintainer needs #17

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Schedule First Meeting

Planning for scheduling the first meeting.

Would like to plan for the week of Nov 26 which I know is a bit last minute, but it would let us kickoff some of the discussions and then hopefully have a second meeting ~ the week of Dec 17.

[key packages] Pilot Packages

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

Suggestion: Promote use of N-API for native addons

In light of nodejs/node#22754 (comment) we may want to reach out to native addon maintainers to remind them of the benefits of porting their addon to N-API. We at @nodejs/n-api can support their efforts.

Which Problems Node.js OSS maintainers/authors face today?

In the early days, the Node.js community was composed by a small set of individual that learned to trust each other. Those individuals now maintains a high number of packages that are part of everyone dependency tree. Now, more complex software is being built and released on NPM on top of those tiny utilities, and the authors struggle to keep up with updates on their dependencies. Which challenges are the maintainers on both set face?

1. Building a community around an Open Source is a different job compared to writing a tiny module. Moreover, creating a community around a single utility is extremely hard. What strategies can we recommend to grow this community? Should we recommend that these utility be moved into a bigger organization (all streams module should move to github.com/node-streams for example) to simplify maintenance?
2. Managing changes in Node.js and dependencies is hard. Whenever there is a breakage that is fixed in a semver-major release, it’s highly possible that a stream of semver-major updates on all the dependency on a given tree. In some cases, CITGM is not broad enough to catch those breakages when a new version of Node.js happens.
3. There are two main trends in supporting different Node.js versions in the ecosystem: support ALL of them (express) or support only the LTS version. Is there a common strategy that we could recommend? The LTS cadence is dictated by Node.js.
4. Framework authors have often the challenge of testing the ecosystem for breakage of their dependents. Currently there is no such tool that helps in that regard.
5. Providing support for the user is a tough job and some project have an unchecked issue tracker because of this. How it is possible to migate this problem? What strategy should we recommend?

[best practices] managing LTS & release lines for userland modules

I'm starting a discussion in Mocha around how we can best support multiple "LTS" release lines.

I'm familiar with what Node.js itself does (though I haven't ever cut a Node.js release myself; it seems essentially like trunk-based development). But I don't have an understanding of all the gotchas around something like this.

It does seem that, without proper tooling, maintainers will be in for a lot of pain in addition to the extra overhead that the strategy initially incurs.

I also don't know how other teams/projects that want to do long-lived release lines do it, and would love to hear from them!

How can we, as the package maintenance team, help projects that want to take this on? What works and what doesn't?

[baseline practices] Versioning

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Versioning (semver)

• how to enforce?
• possibly through CICD processes
• example tooling package https://www.npmjs.com/package/semantic-release
• look to add node preset to commit-analyzer
• following npm's advice to start at v1

If I am missing anything please add a comment and tag me so I can update

[baseline practices] Support levels

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Support Levels

• Support statements?
• LTS strategy?
• Refer to #5 for discussion around tooling and #139 for initial draft around support

If I am missing anything please add a comment and tag me so I can update

Node.js Foundation Package Maintenance Team Meeting 2018-12-17

Time

UTC Mon 17-Dec-2018 20:00 (08:00 PM):

Timezone	Date/Time
US / Pacific	Mon 17-Dec-2018 12:00 (12:00 PM)
US / Mountain	Mon 17-Dec-2018 13:00 (01:00 PM)
US / Central	Mon 17-Dec-2018 14:00 (02:00 PM)
US / Eastern	Mon 17-Dec-2018 15:00 (03:00 PM)
London	Mon 17-Dec-2018 20:00 (08:00 PM)
Amsterdam	Mon 17-Dec-2018 21:00 (09:00 PM)
Moscow	Mon 17-Dec-2018 23:00 (11:00 PM)
Chennai	Tue 18-Dec-2018 01:30 (01:30 AM)
Hangzhou	Tue 18-Dec-2018 04:00 (04:00 AM)
Tokyo	Tue 18-Dec-2018 05:00 (05:00 AM)
Sydney	Tue 18-Dec-2018 07:00 (07:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2018-12-17&iso=20181217T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Dec+17%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/12eZnzQK4fmUo3zoF7_EAh-DoWAemmkqP7UWfyEac4Cw/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

• Agree on standard meeting process
• Discuss recurring meeting times
• Review initial goals and identify first steps
  • Define and document how to prioritize which packages are key to the
    Node.js ecosystem and how/what assistance can/should be provided.
    One of the key aspects of this is understanding what communication
    channels we need in order to be able to identify when specific
    issues are slowing migration from one Node.js version to another
    or causing friction in the ecosystem in some other way.
  • Building and documenting guidance, tools and processes that
    businesses can use to identify packages on which they depend,
    and then to use this information to be able to build a business
    case that supports their organization and developers helping to
    maintain those packages.
  • Documenting a backlog and providing resources that help
    businesses identify how their developers can ramp up and
    get engaged to help. Test and validate a workflow by helping
    with some issues that are slowing migration to Node.js 10.x.
  • Building, documenting and evangelizing guidance, tools and
    processes (for example LTS for modules)
    that make it easier for maintainers to manage multiple
    streams and accept help from those who depend on their module.
• Process to get sub-teams working

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Engaging Enterprise teams to better understand challenges at scale

Background

As part of the @nodejs/user-feedback Initiative, we've kicked off a work stream to better engage with large Enterprise teams, with the goal to enable a two-way channel of value-sharing and feedback between large corporations and the node community.

The value of engaging is to capture the context of large teams in large organizations (200+ devs, 1000+ applications) around slower operations, compliance demands, training and knowledge sharing, as well as varying levels of maturity of their technology practices.

A great recent examples such context: Security and Compliance needs in Enterprise as told by @isaacs OSS Risk & Compliance

The ask

Discuss how to best assist in bringing useful / actionable insights to the @nodejs/package-maintenance team.

Suggestion: Short Q&A section ?

I'd wish to ask if we can make short Q & A section in the repo?

For newcomers: maintainers and who wish to help.

Something answering questions:

How can I get help if I'm package maintainer?

How can I give help, if I wish?

Something with keys to easy understanding of what happens or milestones.

Gantt Chart is quite nice, but hard to generate.
Changelog format is also nice, in relation to summ of meetings discussions.

Sum of what is the current moment, or how to start investigation what happens here. For me it is clear how to learn from group issues, and I know it is hard for some of my acquitances.

And also, from the other side, seems that, for example I need guidance to make helpfull effort. It is another point, but it tightly related to that Q & A for me.

Suggestion: Provide template/guides/automation for common maintainer needs

There are many great tools and features we can take advantage of to help reduce day-to-day support workload. All of which take time and resources to research, setup, and maintain. That time takes away from actual support and maintenance of the modules themselves.

As an example, on Express we have talked about setting up GH issue templates, helpful bots and other things like this. But because the main contributors prioritize the immediate need of doing security patches, responding to user support requests, reviewing PRs, and discussion of new features those things don't get done. In a large community like Express, there are tons of repo's we would need to set this up for, making a small job for each into a big one for the whole group.

If there was a great template, guide, or even a team which could go around and do this for us, it would be super helpful. Is there is an automated way to add this? What about keeping them all updated as the standard changes? I think it would be great to hear from people who have set these up and decide on the best and most impactful things we can do.

These kind of resources would save each individual maintainer group from having to go through the whole process themselves. It would also mean that consumers and new contributors would be more likely to be familiar with the tools in use, so it might make it easier to get someone to take things over if you move on.

Node.js Foundation Package Maintenance Team Meeting 2019-03-11

Time

UTC Mon 11-Mar-2019 19:00 (07:00 PM):

Timezone	Date/Time
US / Pacific	Mon 11-Mar-2019 12:00 (12:00 PM)
US / Mountain	Mon 11-Mar-2019 13:00 (01:00 PM)
US / Central	Mon 11-Mar-2019 14:00 (02:00 PM)
US / Eastern	Mon 11-Mar-2019 15:00 (03:00 PM)
London	Mon 11-Mar-2019 19:00 (07:00 PM)
Amsterdam	Mon 11-Mar-2019 20:00 (08:00 PM)
Moscow	Mon 11-Mar-2019 22:00 (10:00 PM)
Chennai	Tue 12-Mar-2019 00:30 (12:30 AM)
Hangzhou	Tue 12-Mar-2019 03:00 (03:00 AM)
Tokyo	Tue 12-Mar-2019 04:00 (04:00 AM)
Sydney	Tue 12-Mar-2019 06:00 (06:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-03-11&iso=20190311T19
• or http://www.wolframalpha.com/input/?i=07PM+UTC%2C+Mar+11%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/11vy7j72aObqKpKMNq-bCyP9Uzum56YMTUc43AklOhXo/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• A first draft of testing guidelines #169
• [baseline practices] .npmignore or package.json files #164
• add deprecate guidelines doc [draft] #150
• Which Problems Node.js OSS maintainers/authors face today? #113

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Upgrading Problems - Can we help?

This is a copy of the text posted in: nodejs/user-feedback#116 which was posted Oct 26 2018:

As Node.js 10.x becomes LTS next week,now is a good time to consider upgrading.

We understand that there are stometimes issues when migrating to a newer Node.js major version.
One of the things we have heard is that this can be due to a module in the dependency chain that is not being updated.

We would like to gather some feedback and better understand how we can improve the migration experience.

Sme questions we would like to float to the community:

What challenges do you have when you upgrade to a newer Node.js major release?
Have all modules you depend on been updated?
Which specific modules do you have problems with when upgrading. And more specifically are there any modules preventing you from migrating to 10.x?
Are you a maintainer that is overwhelmed and you are not able to update your modules anymore?

A practical approach is to only support the LTS version

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.

Originally posted by @ghinks in https://github.com/_render_node/MDU6SXNzdWUzOTIyNzk4MTA=/issues/unread_timeline#issuecomment-448401317

Question: How to disincentivise selling packages to the highest bidder?

Unlike traditional labor, where being a good actor is financially rewarding, with open-source labor, there is more monetary incentive in selling packages… and with the current state of open-source remuneration, there seems more incentive by bad actors than good actors to express monetary value for packages

How should this be addressed? Shall npm just disable access and ban any user who sells a package (regardless of good or bad actor)? Will there be a defensive fund by the foundation to outbid bad actors in auctions?

[key packages] Open Enrollment

Split 3/3 of #105

For all those maintainers that are searching for help, we need to define groups standards,
best practices and any tooling support we provide to other packages.
This would need a defined process, but would open the support to the greater community.

What to discuss here

• Define a process to share all the tooling and know-how that will be build helping the Pilot and High Impact packages
• How a maintainer can ask for help to this group?

[key packages] High Impact Packages

Split 2/3 of #105

We have to to choose a larger group of high impact packages to implement the same practices and standards developed in conjunction with the Pilot Packages.

To choose this group of packages, we need to define the right formula to find who need help first.

The starting list of criteria for ranking is:
➕ = higher value increment the priority assigned
➖ = lower value increment the priority assigned

Criteria	Evaluation for priority
Number of downloads	➕
Number of downloads of their full dependency tree✨	➕
Most depended-upon packages	➕
Number of dependencies	➖
Test against Node.js versions	➕, less is to seek and understand why
Old dependencies	Less are to seek and understand why. "old" is managable or do we have many false positive?
Deprecated dependencies	➖
Open issues	➕ - only if labelled as confirmed bug or bug
Is it maintained by a company?	They want help?
Last activities	More recent: ➕

✨ During this process, we should also check if one of those dependency is on an older major and why.

What to discuss here

• We need to complete the criteria list and define the evaluation of the criteria itself

Discussion: Node.JS Slack channel

I would like to raise a discussion around continued conversations beyond the meetings. As well all know with meetings it is definitely a time crunch around topics on the agenda and trying to get everyones opinion/idea. Sometimes those topics need additional time to talk through and sort out. With this in mind I would like to propose creating a channel in the official Node.JS slack room. This will allow us to continue discussions effectively and with those we are working with on particular topics that we've taken up. The one thing I would appreciate is that if we do create the channel that we be mindful of the use of @here and @channel unless absolutely necessary and that if you are responding to a user to keep it threaded. This will allow conversations to stay on point and not get lost in translation.

Suggestion: Provide standards around integrity between source code and published package

Right now, it seems that most maintainers may publish their packages from their local environment. There should be a way to verify what is published against the public source code or specific git sha to maintain transparency of what is being published. Not only will this mitigate out of sync issues or accidents, but will provide greater confidence that additions aren't added as they are published (potentially malicious).

Not sure if this is the best place for this, but after reading through other issues and recent resources I thought I better put this down somewhere. And it brings up the discussion of maintainers permissions to not only package registry, but SCM as well.

Suggestion: definition of "at risk" packages using heuristics

A recurring topic I'm seeing in the open issues right now is how we want to make an impact across the ecosystem by identifying packages who are themselves in bad shape or depend (transitively) on packages that are in bad shape.

I believe there is an opportunity for this group to work on a set of heuristics to (either manually or programmatically) identify what it means for a project to be "at risk".

Here's a rather simplistic example of what such a set of heuristics might look like:

A package is classified to be at-risk when one of the following is true:

• The package has open GitHub issues or PRs that are more than X months old and have no interaction from an owner/collaborator.
  • The threshold is X/2 when the package has more than Y number of downloads per week - to correct for the much larger impact extremely popular packages might have.
• The package generates npm deprecate warnings from one of its dependencies
• The package uses some other explicit signal that the owner is no longer interested in maintaining the project moving forward.

Once it can be "tuned" and we feel confident in it, we can begin surfacing the results - projects which are classified as at-risk - in many places. We may be able to work with npm, Inc. to utilize this in the CLI or on the website. We might publish our own website. We might publish guidelines or a tool that application and/or package authors can use to analyze their own dependency tree. We could supply a README badge service. The possibilities are endless, but I think it starts with creating a common definition of what we think at-risk looks like.

Refs:

• This would be a prerequisite for #93.
• I personally think #78 should be reconsidered, but this would be required to make progress on that. I personally think of email as one way to surface the results of this set of heuristics applied to the npm ecosystem, but maybe not the best way.
• The anecdote in #73 is a good example of a case our heuristics should classify as at risk, and collecting more of these anecdotes should help us "tune" our algorithm.
• My comment from earlier is mostly about asking why npm deprecate as an opt-in way to signal this sort of information isn't working.
• I think #6 is related insofar as one "business model" might be "completely unfunded and unresourced". This could serve as an explicit signal from the owner that the project is at-risk.
• We could build the list in #14 fairly easily if we had this definition.=

[baseline practices] Maintainers

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Maintainers

• proper use of maintainers in package.json
• How to detemine/select maintainers?
• potentially a github md template that requires a PR for code reivew
  • If looking for maintainers possibly adding maintainers wanted badge https://github.com/pickhardt/maintainers-wanted
• Background check (possibly)
• Open source Github app to assist https://probot.github.io/apps/background-check/

If I am missing anything please add a comment and tag me so I can update

Suggestion: Broaden scope to all packages

The scope of this initiative thus far is "key packages" in the ecosystem.

I would argue that the huge diversity of packages available for node is in itself key to the ecosystem. Therefore, I feel it'd be ideal if this initiative could widen its scope to trying to put in place systems/assistance which could be applicable to all packages.

Obviously, it'd be an impossible task to make active interventions on thousands of packages, but what I'm trying to suggest is that it'd be useful to bear in mind a wider scope when discussing how to tackle this problem.

An example:

react-loadable is a module which gets 250k weekly downloads, and has been unmaintained for some time including unfixed bugs. 250k evidences a large user base, and judging by the number of open PRs, many motivated would-be contributors - enough I expect to keep the package maintained if they were able to.

But I don't imagine that it's big enough to be considered "key" in the way an express or mocha would.

Only a fraction of node's user-base will use react-loadable. But I would hazard a guess that pretty much every node user depends on some other mid-level package like it. So the experience of using node overall depends not just "key" packages, but a large range of packages.

Perhaps this is already obvious, but I thought I'd make it explicit.

I have a couple of specific suggestions which I'll raise as separate issues as soon as I get a chance, but just wanted to drop this in now in case it's a useful perspective.

Also, just to say, I think this is a great initiative. The burden of maintenance, and the mess of duplicated, abandoned, and half-done packages littering npm that it causes, is the biggest pain point with node. I really hope the community can find some solutions.

discourage use of unmaintained packages

This would be more of an "advocacy" or "lobbying" initiative.

Tools like npm and GitHub should perhaps actively discourage users from adopting unmaintained packages.

How such packages would be flagged is another problem, but a combination of crowdsourcing and analysis might work.

That said, I do want to limit the scope of the nodejs/package-maintenance initiative, and unless this is something others feel strongly about, I'd say our time is probably better spent on helping projects that want our help.

Node.js Foundation Package Maintenance Team Meeting 2019-02-11

Time

UTC Mon 11-Feb-2019 20:00 (08:00 PM):

Timezone	Date/Time
US / Pacific	Mon 11-Feb-2019 12:00 (12:00 PM)
US / Mountain	Mon 11-Feb-2019 13:00 (01:00 PM)
US / Central	Mon 11-Feb-2019 14:00 (02:00 PM)
US / Eastern	Mon 11-Feb-2019 15:00 (03:00 PM)
London	Mon 11-Feb-2019 20:00 (08:00 PM)
Amsterdam	Mon 11-Feb-2019 21:00 (09:00 PM)
Moscow	Mon 11-Feb-2019 23:00 (11:00 PM)
Chennai	Tue 12-Feb-2019 01:30 (01:30 AM)
Hangzhou	Tue 12-Feb-2019 04:00 (04:00 AM)
Tokyo	Tue 12-Feb-2019 05:00 (05:00 AM)
Sydney	Tue 12-Feb-2019 07:00 (07:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-02-11&iso=20190211T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Feb+11%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/10Iz95p0y6b8bbd3GiN9dcYUNLNfV69yxZs082dT7VMI/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• [key packages] Pilot Packages #142
• Discussion: Baseline practices - brainstorm initial list #119
• Which Problems Node.js OSS maintainers/authors face today? #113
• discourage use of unmaintained packages #93
• Suggestion: Provide template/guides/automation for common maintainer needs #17

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Demo of CITGM work/Module Insights

IBM, as part of CloudNativeJS, has created some automation around Module testing across different LTS Node.js versions - https://modules.cloudnativejs.io. This work included extending and building a wrapper around CITGM, which I believe relates to #84 and #114.

I'd like to demo what we have and how it works as a proof of concept, as it may help to determine some use cases/features of any future tools formed to solve pacakage maintenance problems.

/cc @mhdawson

Suggestion: email maintainers of packages not updated for a long time with a lot of issues

I suggest automatically emailing maintainers of packages that have multiple issues (to avoid emailing packages that do not need updating such as left-pad), but the last release happened months ago.

The email should suggest them that they should either deprecate the package, or find another maintainer (suggesting organizations willing to take care of packages with many downloads per day such as Code Shelter, or suggest them using the method described in #4 ).

This email should only be sent once.

Suggestion: maintainers guidance and platform/forum for finding new maintainers

In the light of recent problems with malicious changes introduced into a popular npm package. I'd like to suggest addressing the hand-over problems that most of maintainers face. Namely, it is hard to:

• find a new maintainer for a project
• communicate ownership change to package users
• check trustworthiness of the new owner

Suggestion: add standard methods to limit APIs dependencies can use

I believe it might help to allow packages to set limits on which APIs can be accessed by the dependencies. This way, packages that do not need access to abusable resources such as FS access, networking and native bindings (those can access everything else) can be restricted from using them, reducing the impact in the event of packages whose job is mostly data processing (most body processors, utilities such as lodash) being compromised.

I believe the implementation does not need to be granular, and that with simply restricting access of a dependency (and all its childs).

While this is probably not the ideal way to implement sandboxing, I believe that some sandboxing method would be helpful.

Suggestion: Tooling to assist maintenance errands

Travis CI recently informed me that I have over 800 packages using it.

I've done up the following tooling to assist in automating the maintenance of my packages as much as possible, they have been used for years, and probably others will find them useful:

• https://github.com/bevry/badges - generate readme badges
• https://github.com/bevry/projectz - automate readmes
• https://github.com/bevry/awesome-travis - travisci scripts for testing, publishing, deployment, etc
• https://github.com/bevry/boundation - scaffold projects with the above

If you have your own, post them too.

Proposal: automated PRs for code mods

Back in 2012 there was an effort to update path.{exists,existsSync} to fs.{exists,existsSync}. One of the folks at Nodejitsu wrote up a bot to automate this PR process.

Here is an example of one of those PRs. It looks like the bot made over 700 PRs.

Would there be interest from package maintainers for a more generic code mod bot for Node-specific API changes (e.g. new Buffer vs. Buffer.from);

Create a "support section" validator

Create a simple NPM module that will confirm that the value of the support property in the package.json file matches one of the established values from the "support level" documentation created in this PR -> #139

[baseline practices] .npmignore or package.json files

Do we have something for specifying the included files for publishing yet?

I just happen to look through some of the files in node_modules for one of my apps and this is what I found:

• coverage, .nyc_output
• .idea
• .eslintrc, .travis.yml, etc
• quite a few packages include their full test files.
• also for packages written in ts, some are including the TS source, is that needed?

Kind of related to #77

We should have some thing that suggest ensuring files exist in package.json and include essential files for publishing.

Node.js Foundation Package Maintenance Team Meeting 2019-02-25

Time

UTC Mon 25-Feb-2019 14:00 (02:00 PM):

Timezone	Date/Time
US / Pacific	Mon 25-Feb-2019 06:00 (06:00 AM)
US / Mountain	Mon 25-Feb-2019 07:00 (07:00 AM)
US / Central	Mon 25-Feb-2019 08:00 (08:00 AM)
US / Eastern	Mon 25-Feb-2019 09:00 (09:00 AM)
London	Mon 25-Feb-2019 14:00 (02:00 PM)
Amsterdam	Mon 25-Feb-2019 15:00 (03:00 PM)
Moscow	Mon 25-Feb-2019 17:00 (05:00 PM)
Chennai	Mon 25-Feb-2019 19:30 (07:30 PM)
Hangzhou	Mon 25-Feb-2019 22:00 (10:00 PM)
Tokyo	Mon 25-Feb-2019 23:00 (11:00 PM)
Sydney	Tue 26-Feb-2019 01:00 (01:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-02-25&iso=20190225T14
• or http://www.wolframalpha.com/input/?i=02PM+UTC%2C+Feb+25%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1smP5WBBNEUqvS4FXfYWtOFZCgS9MfOehBkctSJpIMp0/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• [baseline practices] Choosing a License and Choosing Dependencies #160
• [baseline practices] Versioning #158
• [baseline practices] Testing #157
• [baseline practices] Maintainers #155
• add deprecate guidelines doc [draft] #150
• [key packages] Pilot Packages #142
• Which Problems Node.js OSS maintainers/authors face today? #113
• discourage use of unmaintained packages #93
• Suggestion: Provide template/guides/automation for common maintainer needs #17

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Process to identify and engage with "Key Packages"

One of the primary goals of this working group is to identify and provide services to a group of npm packages we are calling "key packages". These packages will need to be defined in some way, and will hopefully receive the benefit of the WG's effort. Defining a small set of packages to "deem worthy" of our time is hard, and inevitably we will need to adapt it as we find success.

@mcollina recommended that we pilot our ideas with some "friendlies". This is a great idea for working out the kinks of the WG's role in third party package ecosystems, but it can limit the impact we can have on the community. To help both the short term and long term goals, I would like to propose a staged rollout approach.

Staged Rollout Proposal

1. "Pilot Packages": Establish a list of "pilot packages" we can use to start collaborating with the authors to learn and iterate with.
2. "High Impact Packages": Once we have established some of the group's initiatives and tried them out with the pilot packages we can choose a larger group of high impact packages to implement the same practices and standards with.
3. "Open Enrollment": Open adoption of the groups standards, best practices and any tooling support we provide. This would need a defined process, but would open the support to the greater community.

What to discuss here

To get things started I would like to discuss this approach to "defining key packages". If this approach suits the group, then I would like to open continuation issues for the three phases of the project where we can continue with those discussions. Once we have those smaller conversations defined, I will update this issue with links and decisions as the hub for the overall initiative.

What can wait for those other issues

I mentioned in the first meeting that I would like to offer up some of the Express ecosystem packages as good "pilot packages", which is why I was identified as a good person to push this forward. This kind of discussion I would like to push into those other issues if no one has strong opinions against the approach I propose here.

Also any information relating to how specifically we identify the packages at each phase can be left off for the other threads.

Node.js Foundation Package Maintenance Team Meeting 2019-03-25

Time

UTC Mon 25-Mar-2019 13:00 (01:00 PM):

Timezone	Date/Time
US / Pacific	Mon 25-Mar-2019 06:00 (06:00 AM)
US / Mountain	Mon 25-Mar-2019 07:00 (07:00 AM)
US / Central	Mon 25-Mar-2019 08:00 (08:00 AM)
US / Eastern	Mon 25-Mar-2019 09:00 (09:00 AM)
London	Mon 25-Mar-2019 13:00 (01:00 PM)
Amsterdam	Mon 25-Mar-2019 14:00 (02:00 PM)
Moscow	Mon 25-Mar-2019 16:00 (04:00 PM)
Chennai	Mon 25-Mar-2019 18:30 (06:30 PM)
Hangzhou	Mon 25-Mar-2019 21:00 (09:00 PM)
Tokyo	Mon 25-Mar-2019 22:00 (10:00 PM)
Sydney	Tue 26-Mar-2019 00:00 (12:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-03-25&iso=20190325T13
• or http://www.wolframalpha.com/input/?i=01PM+UTC%2C+Mar+25%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/146yfcuqtP9oiLq7ltgUqNLVFSYIbmhYVvCopOjEhJto/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• A first draft of testing guidelines #169
• [baseline practices] .npmignore or package.json files #164
• Create a "support section" validator #161
• add deprecate guidelines doc [draft] #150
• Which Problems Node.js OSS maintainers/authors face today? #113
• Demo of CITGM work/Module Insights 179

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Node.js Foundation Package Maintenance Team Meeting 2019-01-14

Time

UTC Mon 14-Jan-2019 20:00 (08:00 PM):

Timezone	Date/Time
US / Pacific	Mon 14-Jan-2019 12:00 (12:00 PM)
US / Mountain	Mon 14-Jan-2019 13:00 (01:00 PM)
US / Central	Mon 14-Jan-2019 14:00 (02:00 PM)
US / Eastern	Mon 14-Jan-2019 15:00 (03:00 PM)
London	Mon 14-Jan-2019 20:00 (08:00 PM)
Amsterdam	Mon 14-Jan-2019 21:00 (09:00 PM)
Moscow	Mon 14-Jan-2019 23:00 (11:00 PM)
Chennai	Tue 15-Jan-2019 01:30 (01:30 AM)
Hangzhou	Tue 15-Jan-2019 04:00 (04:00 AM)
Tokyo	Tue 15-Jan-2019 05:00 (05:00 AM)
Sydney	Tue 15-Jan-2019 07:00 (07:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-01-14&iso=20190114T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Jan+14%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1bhq7kpBkZUFpECM01kZTPhjPkVflaULkz5SwTiugY0E/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• Discussion: Baseline practices - brainstorm initial list #119
• Discussion: Node.JS Slack channel #118
• Which Problems Node.js OSS maintainers/authors face today? #113
• Process to identify and engage with "Key Packages" #105
• discourage use of unmaintained packages #93
• Suggestion: Provide template/guides/automation for common maintainer needs #17
• Suggestion: Display a projects business model #6

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

[baseline practices] Security Reporting

This is in continuation of #119 to keep the discussion focused on one part as we can further flesh out each piece to create a draft proposal around baseline practices.

Security Reporting

• utilizing npm audit through cicd process
• Working in conjunction with registries and WG's

If I am missing anything please add a comment and tag me so I can update

Suggestion: Display a projects business model

I think having a badge in a project's readme with their business model is a good idea.

For instance:

• for something like react can get maintenance: enterprise supported with a link to the enterprise backing
• for something like keystonejs maintenance: company supported with a link to the company backing statement
• for an individual project actively maintained maintenance: individual supported with a link to their patreon page or whatever
• for an project no longer maintained maintenance: free time supported with no link
• for a project maintained through bounties: maintenance: bounty supported with a link to their used bounty services
• for projects with absolutely no support: maintenance: abandoned

Or something like this. If this becomes popular, then the different tiers will get more wider understanding, and help in people making their decisions.

https://github.com/bevry/projectz and https://github.com/bevry/badges could automate this so that in an entry in the package.json file is all that is needed to generate this meta information, which could even be scanned by tooling to look for free time supported packages as warnings. Projectz would also be able to automate the insertion of say a npm keyword or a github topic.

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

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.

Node.js Foundation Package Maintenance Team Meeting 2019-01-14

Time

UTC Mon 14-Jan-2019 20:00 (08:00 PM):

Timezone	Date/Time
US / Pacific	Mon 14-Jan-2019 12:00 (12:00 PM)
US / Mountain	Mon 14-Jan-2019 13:00 (01:00 PM)
US / Central	Mon 14-Jan-2019 14:00 (02:00 PM)
US / Eastern	Mon 14-Jan-2019 15:00 (03:00 PM)
London	Mon 14-Jan-2019 20:00 (08:00 PM)
Amsterdam	Mon 14-Jan-2019 21:00 (09:00 PM)
Moscow	Mon 14-Jan-2019 23:00 (11:00 PM)
Chennai	Tue 15-Jan-2019 01:30 (01:30 AM)
Hangzhou	Tue 15-Jan-2019 04:00 (04:00 AM)
Tokyo	Tue 15-Jan-2019 05:00 (05:00 AM)
Sydney	Tue 15-Jan-2019 07:00 (07:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Package%20Maintenance%20Team+Meeting+2019-01-14&iso=20190114T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Jan+14%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1Abo6TVPcu-PdeR9sIahfjwyAYYO-CsRErYpYcV3KH4U/edit

Agenda

Extracted from package-maintenance-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/package-maintenance

• Discussion: Baseline practices - brainstorm initial list #119
• Discussion: Node.JS Slack channel #118
• Which Problems Node.js OSS maintainers/authors face today? #113
• Process to identify and engage with "Key Packages" #105
• discourage use of unmaintained packages #93
• Suggestion: Provide template/guides/automation for common maintainer needs #17
• Suggestion: Display a projects business model #6

Invited

• Package Maintenance team: @nodejs/package-maintenance

Observers/Guests

Notes

The agenda comes from issues labelled with package-maintenance-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/431077278
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Suggestion: Provide alternate phrasing dictionary

A lot of common used phrasing is offending and should be avoided. For example master/slave can be replaced with primary/secondary (or anything else). See this medium article for example. There are a lot more phrases.

I'd suggest providing a dictionary with alternate phrasing which can be discussed here or somewhere else. Package owners should be advised how to avoid pitfalls and be as inclusive as possible.

(just saw @bnb comment at #59 which leads me to suggest this)