Add governance doc

[Elchi3]

Rendered version https://github.com/mdn/browser-compat-data/blob/ac7abfe89485764f6acf30be5f5dcacd3c1f3b0c/governance.md

This document aims to clarify how this project is governed and how we aim to give out permissions and with what privileges and responsibilities these permissions will come. For now, I've added the current peers, but the goal is to have more peers so that more people can review and merge the high amount of PRs this project is seeing.

[ddbeck]

I'm really excited by this governance doc, Florian. I really like that you're putting some thought into broadening community involvement in the project. I also like that it's derived from other projects' governance docs, not invented from scratch.

One area that caught my attention is that owners are responsible for doing releases. This makes sense to me, but as someone who has done a few releases for you in the past, I thought it might be helpful, as a practical matter, to allow for some kind of owner-delegate rule (riffing a bit on Python's old "BDFL-Delegate" process). Something like this, maybe:

Owners may, at their discretion, nominate an owner-delegate to carry out a task or make a decision ordinarily carried out by an Owner. Delegation should be limited in duration or scope, or both; delegation may be withdrawn by any Owner at any time. For example, an Owner may nominate an owner-delegate to approve an infrastructure PR or to publish npm packages for a set time or number of releases.

I think this might satisfy some practical needs of the project, like doing releases, or bringing in someone to help make a decision on an infrastructure change. For instance, this might've been a good step to do in #3004—instead I took a leap, which would've been (rightly) out-of-bounds under this governance doc.

I don't have my heart set on this being included, but I thought it might formalize something we've been doing haphazardly. Or I can just stop doing releases while you're on holiday. Whichever. 😆

[Elchi3]

Note to self: When granting people commit permissions, we probably also need to mention https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ in there and somehow record this statement from future peers: "I have read, and agree to abide by, the Commit Access Requirements.”
See also the "Becoming A Mozilla Committer" procedure here https://www.mozilla.org/en-US/about/governance/policies/commit/

[chrisdavidmills]

Nitpicky review coming up...sorry about this ;-)

I also had a couple of general queries:

• We were discussing possibly adding something here about priority by which we should try to review PRs. Did you think this should not go here? I'm happy either way really.
• Also, should we include here something about process for reviewing a PR, e.g. making sure you call for a review by at least one Peer/Owner, etc. Or again, is this not suitable here? I'm just trying to make sure we don't lose anything.

[chrisdavidmills]

I'm having a hard time with this bit — this sentence implies that any dissent will stop a motion going forward, and require discussions to resume. But then the following paragraph says that if a consensus (which is basically a majority in this context?) cannot be reached, a vote can be called for to close the issue. Does this mean close it without action, or vote what solution to the issue should be moved forward with? In which case, this is a call for a majority anyway?

Surely we should keep discussing the issue until all points of view have been heard, once that is done put the options for a way forward on the table, and then vote for which option is best in the case of a disagreement? Is this what the text is supposed to be saying anyway? If it is, it is a bit of a confusing way to say it.

[Elchi3]

thought it might be helpful, as a practical matter, to allow for some kind of owner-delegate rule

Thanks @ddbeck! I've now added this as a section. Great idea!

Note to self: When granting people commit permissions, we probably also need to mention https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ in there and somehow record this statement from future peers: "I have read, and agree to abide by, the Commit Access Requirements.”
See also the "Becoming A Mozilla Committer" procedure here https://www.mozilla.org/en-US/about/governance/policies/commit/

I have now added this to "Becoming a Peer", but I still need to double check what the standard Mozilla procedure is for contributor access to GitHub repos.

Nitpicky review coming up...sorry about this ;-)

Thanks for your review. I have addressed many of your points now, but I left a few unresolved as I still need to get to them.

We were discussing possibly adding something here about priority by which we should try to review PRs. Did you think this should not go here? I'm happy either way really.
Also, should we include here something about process for reviewing a PR, e.g. making sure you call for a review by at least one Peer/Owner, etc. Or again, is this not suitable here? I'm just trying to make sure we don't lose anything.

I'm not sure yet where or if this fits into this document. I think Peers and Owners will have their own review style and as long as the project runs healthy overall, it should be fine. PRs should have clear intents and standard pings for (re-)requesting review or or gentle nudging is standard practice. Maybe such guidelines fit better into the contributing doc?

[chrisdavidmills]

Thanks for your review. I have addressed many of your points now, but I left a few unresolved as I still need to get to them.

This is fine. There were a lot of points here, and what you've done in response massively improves the document. I think it is OK to iterate after publication.

I'm not sure yet where or if this fits into this document. I think Peers and Owners will have their own review style and as long as the project runs healthy overall, it should be fine. PRs should have clear intents and standard pings for (re-)requesting review or or gentle nudging is standard practice. Maybe such guidelines fit better into the contributing doc?

I'll leave it in your hands to consider adding somewhere later if we feel it is needed.

[jpmedley]

How do I apply for peerage?

[wbamberg]

I think this looks great, basically. I had a couple of questions. (I feel like I've commented on this document before...).

[chrisdavidmills]

@jpmedley see the section of the doc following "To become a Peer one must"

I am happy to nominate you.

[jwhitlock]

This is a thoughtful and complete governance doc. Great work @Elchi3. I support rapid publishing and iteration as needed.

[Elchi3]

Thanks for your feedback, John! I've added the links you've suggested and also removed you as a peer. Thanks for everything you have done for BCD and thank you specifically for the predecessor project which was inspiring and helpful for BCD to take off.

[Elchi3]

This document was also reviewed by members of Mozilla's Open Innovation team (https://wiki.mozilla.org/Innovation#The_Open_Innovation_Team). I want to thank them and all previous reviewers (members of the MDN team and members of the MDN Product Advisory Board [PAB]) as well as everyone who provided review in this PR.