I propose that the default files cover Security. Be it as text in the CONTRIBUTING.md, or via a SECURITY.md file. Ideally both, with the SECURITY.md going into the org's template directory.

Like the CoC, the security file will need some kind of unusual contact address.

If a project doesn't have trademarks (yet), should we just exclude TRADEMARKS.md and references to it?

cc @royaljust

The https://www.openwebfoundation.org/legal link on https://github.com/github/MVG/blob/main/org-docs/CHARTER.md is broken

A related note to #13 is that Security and the confidentiality note are at odds. I think the intent of the confidentiality section of the Charter is to remind everyone that there is no expectation of confidentiality within the project by default.

However, confidentiality relationships may happily exist between participants in the project, and the project itself is expected to have information that the project creates confidentiality expectations around - for example a non-public/embargoed security issue.

I like the 75% steering committee vote. I think you want to keep it to a minimum. Charter absolutely makes sense, and CoC makes sense simply because changes to a CoC can rip a community apart.

I think antitrust and trademark don't need the 75%. Really what they want for changes is "Don't change these unless you know what you're doing", and the same is true for the project's license, notice file, dependency-decisions (based on licensing) etc. Community norms will protect those two files from being unreasonably modified.

The LICENSE of the repo and the text in the footer of the template files says that the files are under the CC-BY license. The footers link to the CC-BY-SA license, though. The links should be fixed to avoid any confusion.

Something the project isn't very clear on is the expectations of size for the Steering Committee. Is it a mini-board, or is it the set of roughly all maintainers. I assume the answer is that it supports either version.

It would be valuable to add documentation that talks about this, listing values for both so that users can choose which way to go (and not arrive with prebaked differing opinions).

The Steering Committee blank has a "handle" box that is not present in the Maintainers. I wonder if there is any intent behind this and what should go in the "handle" box? Just a space for a nickname?

Howdy! I'm coming over from the CNCF where we're working on something similar, which you can see in our Project Template.

Currently the Charter document names a Steering Committee, but doesn't say anything about how that committee is selected. It would be useful to give some examples/options of how a committee could be selected.

Alternately, we decided that the actual MVG was the "maintainer council" model, where the people who have approver rights are identical to the people who have governance authority, which is the de facto way that most small independant projects run. Anyway, check out our repo for some ideas. Also happy to sync up directly at some point.

@spier feedback in PR #3 was to add internal links between documents. Good feedback and will fix.

Currently MVG inserts MIT as a default license chosen for the project's content (vs a CC license applying to MVG itself).

I think that's going to lead to surprises later on and the example license file should go more out of its way to flag its just an example.

That would really make the project more usable.

I believe it should be specified how the TSC is chosen, and if selection is for life or if there is periodic revisiting of membership (e.g. 2-year terms).

Any term limit policy should be stated, even if the policy is 'no term limits' (which I favor).

TSC governance should also include if there's are any rules on membership - eg no more than one TSC member per company/agency/organization.

When I started reading the MVG I had a bit of a hard time figuring out what is where, and what each file is meant to be used for.

I have some ideas but I don't fully know where I am going with this so rather than sending a PR for it right away, I am exploring the options here.

Idea 1: Formatting the two main folders in the README slightly differently

The README could make it more obvious that the main structure are these two folders.

It could look similar to this:

There are two folders:

• org-docs: Provides top-level organizational governance and polices for a technical steering committee (TSC).
• project-docs: Provides a template for individual project governance, subject to the polices and oversight of the larger organization.

Idea 2: Tree structure

Listing the main files in the README would allow to explain where to start, and what the purpose of each file is.

For example:

org-docs/
├── ANTITRUST.md - ...
├── CHARTER.md <= Start here
├── CODE-OF-CONDUCT.md - Code of Conduct based on the Contributor Covenant.
├── STEERING-COMMITTEE.md - Lists the voting members of the Steering Committee
└── TRADEMARKS.md - ...

project-docs/
├── CONTRIBUTING.md - ...
├── GOVERNANCE.md <= Start here
├── LICENSE.md - ...
└── MAINTAINERS.md - Lists the Maintainers of the Project

Alternatively one could add a new README.md file to each of the folders.
Those would serve as index pages, explaining what each file is meant to be used for.

So much for now. Looking forward to hear your thoughts on this.