chore: first pass at maintainer covenant, fix #586

[broofa]

First pass at a Maintainer Covenant. This is pretty rough, but let's get this to a form where it's helpful to people and then we can iterate.

Goals:

• Primary: Help users answer the question, "Can this project be trusted?"
• Secondary: Document the steps we have and, more importantly, have not taken to insure the integrity of this project
• Secondary: Provide inspiration and a template for other projects to do the same

A note about "criteria"

I found myself drawing inspiration from ESLint, of all things. I felt it was important to have specific, measurable (or at least evaluatable) criteria by which to assess a project. Giving these ESLint-like names (e.g. no-shared-accounts) makes it easy to refer to and discuss each specific point. It also gives maintainers a way of easily enumerating what it is they do / don't comply with.

The criteria I've listed so far are pretty specific to security, but I can imagine other stuff outside of that. E.g. unit-tests or typed-language that speak more to code quality. A part of me thinks this would be useful, but another part of me feels that sort of thing should be out of scope. Thoughts?

[Note: I accidentally pushed this to master then had to revert... and added the "no-main-commit" criterion as a result. 😂 ]

[LinusU]

Nice! Looks like a great start 👍

[LinusU]

The criteria I've listed so far are pretty specific to security, but I can imagine other stuff outside of that. E.g. unit-tests or typed-language that speak more to code quality. A part of me thinks this would be useful, but another part of me feels that sort of thing should be out of scope. Thoughts?

I'm a bit on the fence here, I think I'm leaning towards this being out of scope. TypeScript has been discussed in another issue and I felt that the general consensus was that it introduces complexity without adding significant value...

[ctavan]

Agreed with @LinusU, this is a great start! Thanks for pulling this together, @broofa!

[chrisgilmerproj]

This timeline may depend on the product. I generally restrict access to things like this:

• No activity after 90 days: Force to renew credentials
• No activity after 180 days: Remove from roles and enforce new credentials

For open source this could be completely different and for some stable code bases maybe nothing changes for 12 years. But worth maybe coming up with a set of actions with the timeline.

[chrisgilmerproj]

Some of these things can be set in the repository settings and programmatically tested. Might be worth setting up a Github action check that will fail merges if these are disabled or tampered with.

[chrisgilmerproj]

I suggest using the pre-commit tool for enforcing this. The most common way credentials get added is by accident. Having and enforcing the use of standard pre-commit checks can go a long way to protecting a repo. You can even have these checks run in your CI/CD pipeline as well for extra safety.

[chrisgilmerproj]

Incident response is hard if you are relying on email communication. It might be worth discussing how you and the other maintainers intend to communicate if you don't have an automated way to have a vulnerability disclosed to you for a response.

I'd ask, if you were in charge of the repo with the recent security incident how would you have wanted things to work in an ideal situation?

[chrisgilmerproj]

I love projects that have a folder named docs and inside that folder I find things like:

• Architectural Design Decisions (docs/adr)
• Manual Operations Guides (docs/manual)
• Incident Response (docs/incidents)
• How To (docs/how-to)

And by using these folders you can keep a sort of history on what's going on directly with the code in the repo. Just a suggestion.

[chrisgilmerproj]

@broofa - sorry for the comments all over your code. My biggest suggestion here is to automate as much of this with code as possible. The promise of your maintainer covenant is stronger with automation than without and I think its also more sustainable.

[broofa]

@chrisgilmerproj This is all great feedback. I especially agree with your point about automation. For example, in an ideal world much of this document could be auto-generated by a script with GitHub integration that just looks at the team and project configuration.

Hell, in an ideal world the entire covenant is auto-generated from the project docs and configuration.

The problem is time and resources. This first pass is just proving out the MVP™ of this idea. Assuming it gains traction, much of this will follow.

[defunctzombie]

This makes me very nervous. Usually open source licenses specifically call out that the software is provided "as-is" and with no liability on part of the maintainers. I do not think it is a good idea to use words like covenant or indicate additional responsibilities that make it sound like the project and developers are somehow liable if they are not followed.

I would re-word this document into a MAINTAINERS.md](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md) style document that outlines a workflow for release management and steers clear of any accountability language or language that tries to indicate any security guarantees.

[broofa]

News: coa and rc packages compromised source

[TrySound]

Funny thing, I maintain svgo, which depended on coa in v1 which I deprecated recently.
v1 still has 1M downloads. Interesting if anybody will upgrade.

[broofa]

Closing this, as I think there's a better approach (basically a separate site that projects can link to) and I'd rather not complicate this project further.