Closed CharliePoole closed 4 years ago
I think less explicit is the way forward, so we can adapt the process to how we need to work at any one time.
I agree with Chris. At least I would often miss a 72 hour deadline due to family obligations, regular work etc. And the email notifications from Github resemble each other, so messages in the teams "repo" are drowned but by regular messages
@mikkelbu Hmm.... My point about 72 hours was that we don't require a response in any particcular amount of time, we only ask project leads to wait 72 hours before taking action so everyone has a reasonable chance to see the thing being discussed. We say nothing about a time limit of any kind in the Core Team decision-making section of the docs.
To me, it seems a bit of a contradiction that we say the core team only handles a very limited set of super-important decisions but then have no particular way to ensure those decisions are dealt with in a timely manner.
The problem may be that most things that come up will proceed even if we don't comment. That's what Lazy Consenus is all about. But a few things, all associated with the Core Team, are blocked if people don't respond.
Can we figure out a way to making those potential blockers show up more clearly?
I'd welcome suggestions of stuff we could remove from the governance docs to make things less explicit. With my background in government bureaucracy I know how to add stuff already. :wink:
I may give it a try with two different PRs.
I also agree with making it less explicit. I'm taking that to mean doing our best to specify as little as possible that still allows us to steer toward better outcomes.
https://github.com/nunit/governance/pull/39/files#diff-476744470f74a3417de19853c14ea737R27:
If the Chair is unavailable and no advance provision has been made, a temporary replacement may be selected by the team. In some cases, the team may choose to proceed with one or more decisions without formally naming a replacement, in which case the team as a whole is responsible for following the process described here.
This part got me thinking. It places inherent trust in whole team to be self-governing at times when the Chair is not available. What if such trust would also be safe when the Chair is available? Do you think we could end up being more efficient overall by simplifying the structure?
Any specific ideas for simplifying? I don't think you were around when we started creating the governance rules, but I drafted them in the role of a facilitator, trying to put in what everyone wanted. It took us more than a year to agree on them and I'm pretty sure we don't want to start a new effort of that scope. At least I don't. :confused:
Understood. The reason I asked was not to begin a process but because I like to hear what people are thinking and learn why things are the way they are.
A recent experience led me to feel that our decision-making rules need to be clarified. After proposing a project lead for the documentation project, and waiting a week without a response from the team chair, I ended up violating the rules by "calling" the election myself and notifying the individual.
Either I was wrong to do that and ought to be censured or the written rules should change in some way, allowing me and others to stay within our comfort zones and still get things accomplished.
The key discrepancies I see in the existing governance docs are as follows...
In
governance.md
it is stated that "The Chair has no additional authority over other members of the Core Team: the role is that of a coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the deciding vote in case of ties."These two sentences are contradictory. The second sentence gives the Chair additional authority!
In
decisions.md
it is stated that "The Chair is responsible for determining the necessity of a vote as well as conducting the vote." In addition, the document tells us that "It is the responsibility of the Chair to collect the votes from the members, in case some of them do not respond immediately."Elsewhere within
decisions.md
it is indicated that we should allow 72 hours for a consensus to develop. It's not clear if that was intended to apply to core team decisions, but maybe it should.I'm prepared to draft some changes for a PR. I see two general ways to go...
Make the process more explicit, clearly stating when we use lazy consensus, explicit consensus or voting.
Make the process less explicit, allowing leeway as we do with decisions within each project.
I think we also need to indicate what to do when the Core Team Chair is not available.