Discussion: Baseline practices - brainstorm initial list

[Emuentes]

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

[rxmarbles]

Great starting point @Emuentes. I currently help maintain the react module react-dropzone one way i was able to become a maintainer was the main maintainer asking for help via an issue react-dropzone/react-dropzone#479. Of course this lead to many people asking to help, however not many were added. I believe a good way to see if you can add maintainers as contributors (who have access to admin perms of a repo) is by how often they contribute. Just a few thoughts 😄

[wesleytodd]

adopting (some form of) module LTS

https://github.com/CloudNativeJS/ModuleLTS

[Emuentes]

@rxmarbles Excellent point about "how to establish trust of potential new owner", their current OSS contributions or at least their own development activity can be an helpful indicator of their likeliness to participate actively.

In my current role I interview many people for few roles so I sometimes have to pick between many excellent candidates.

Questions to folks following this discussion:

1. What might be some other indicators we can use to carefully choose between viable candidates for ownership transfer? What would you hope to see in the person that will be keeping your dependencies going?

2. How would you want to receive notice about a change in ownership?
   Emails, change log on the repo, blog post somewhere, notification printed out during the NPM install, etc. Where would you be most likely to look for this information?

3. @rxmarbles and other maintainers, how do you request help with your modules without handing over admin rights?

4. to @wesleytodd's point, how do we validate help maintainers hold themselves accountable to sticking with SemVer?

Maybe we could recommend or create an npm module that asks the right questions to make sure that maintainers who may not be clear on how to manage their SemVer have help validating that they are bumping the version correctly considering the level of change they introduced and encourage folks to use it.

1. What issues might we introduce by adopting (some form of) module LTS

2. At what point do we have too many dependencies?

3. How often should we recommend that maintainers update their dependencies and is there a practical way to facilitate the process?

4. What would you suggest maintainers do when they find themselves with no time / ability to fix their projects?

5. What would you do or recommend for folks to do if they need to back out malicious code contributions?

[mhdawson]

@Emuentes good questions, we'll need to figure out next steps for answering those.

[mhdawson]

Additional potential baseline practices:

• Testing (was mentioned in another thread with respect to Travis CI)
• Security reporting (guidelines on how to take respond to reports? , we should work with security-wg to define, but practice itself probably belongs along with the rest of them)
• Support
  • Support statement? Would it be good for the module owner to indicate if its a "hobby" or related to
    some "paid" work?
  • As a consumer it would also be great to know if anybody provides commercial
    support.
  • LTS strategy as mentioned earlier
• Choosing a licence? -> This might be controversial
• Choosing dependencies

[mhdawson]

Wondering about this as the title for the end result: "Node module maintainer's handbook"

[mhdawson]

Thinking about "Support" I'm thinking that we'd want to say the baseline practice is to state the level of support provided, and to make this easier for maintainers by documenting a set of levels that they could choose from. Similar to how there are standard licences and maintainers can choose the licence they want to support versus having to write one from scratch.

An initial list might be:

• Not recommended for use, module is deprecated or no longer maintained
• Use at your own risk - no active support
• Maintained, latest Node.js version only upates
• LTS as outlined in https://github.com/CloudNativeJS/ModuleLTS
• Something beyond LTS where older non-LTS versions are supported as well

For each level it should outline how SemVer is used, and what level of support is available for each SemVer major stream.

Just like the licence it would be good to have this as part of the Package.json which would let tooling check for changes to the policies for dependent modules.

[mhdawson]

A key thing for each baseline practice we should keep in mind as we work on these is what do we do (document, provide tools, etc.) to help maintainers follow the baseline practice as opposed to stopping at defining the practice itself.

[mhdawson]

This issue #5 has some discussion around tooling that might be part of what we recommend to make baseline practices easier to follow. Also provides some insight into what baseline practices are already being used in practice.