Added rules for reviewing and merging governance document changes

[rprouse]

Fixes #9

A slight rewording of the change policies as outlined in the issue.

[rprouse]

I have pushed changes based on feedback.

[rprouse]

We have majority approval, so I am merging.

In the interest of being agile and because this is new, does anyone have feedback or suggestions on how the process is working?

[jnm2]

It may not always work to wait for every core member to respond, but perhaps we should try in case they have something to say that changes our minds.

[jnm2]

Oh! I don't expect that to be the case here though.

[CharliePoole]

Here is what our agreed upon decision making process in decisions.md says about this:

Consensus is usually explicit within the Core Team, as opposed to lazy. For the kind of issues we expect the Core Team to resolve, it's important to hear from each member. The Chair is responsible for getting each member's view and determining whether there is a consensus.

When a consensus cannot be reached, voting is used. Additionally, issues such as those affecting the strategic direction or legal standing of the project always require a vote. The Chair is responsible for determining the necessity of a vote as well as conducting the vote.

I would have pinged Terje before merging. His vote could not have change the mathematical outcome, but as Joseph says his comments could have changed minds. I too have no particular problem in this case, although I am now wondering if the PR process is completely consistent with the more general statement above. We may have to tinker with it but that applies to everything we are doing.

I don't think we are trying to be agile here. To keep with the governmental analogy, what we put down here is our constitution, which usually takes an effort to change in most countries. I think that there is a feeling of pressure right now because we are trying to do so much at once. Once this is all set up, I'm hoping that the work of the core team will be limited to major interventions.

Here's a thought for a possible governance change: set a 72 hour limit for changes that require a vote?

[OsirisTerje]

I am fine either way. A 72 hour limit is ok too, but when there is a majority of 80%, there is really no reason to wait. A comment from one may change minds, but then I don't think it really matters if it comes before or after a merge. It can always be reverted, changed or made more precise, in a second round. That way we can improve iteratively. :-)

[CharliePoole]

@OsirisTerje I'm thinking we need to figure out a way to distinguish different kinds of things. This was a relatively simple internal procedure. But if we were voting to accept a new member, to include or exclude a proposed contributed project or fundamentally change in some way what we are about, then a more serious approach is needed. Probably the distinction has to be made when the proposal is made. I'll give a bit more thought about how to implement that in practice and maybe propose something.

Once we are fully operational, important changes will need to be announced to the public. Reversing them is still possible, but kind of awkward. Obviously, we are testing out procedures meant to handle the big stuff on relatively little stuff right now, so it's hard.

[OsirisTerje]

@CharliePoole Ok, I first responded to the sentence "I am now wondering if the PR process is completely consistent with the more general statement above.", There is a difference of course between decisions that are more non-reversible and those that can easily be reversed. I was also thinking about policy changes. Whether to include/exclude persons and projects are more in the non-reversible category, and that could require 100% participation before a decision is made. But, one could separate on that.

Another thing here: One thing that concerns me a bit here, reading through all the discussions, is that there is a lot of back and forth on issues I am not even sure is really clear, and some seems very granular. It can be just me of course, but I find it hard to have strong opinions on a lot of issues which might or might not arise. I believe the core team might have to do some decision making as the projects go on, and that the governance should not be too detailed, but more setting up the general rules that should apply.

E.g: Do we really need very detailed rules for a PR?

[CharliePoole]

@OsirisTerje You have a good point. When I work in-person with a team, I use concrete examples to arrive at more general rules. Here we have been trying to make rules top-down.

[CharliePoole]

@OsirisTerje Another point on which people can disagree: I think that almost anything that is going to be publicly announced should not need to be immediately retracted if we can avoid it. It looks sloppy to me.