EffectiveStaticContract
The StaticContract is immutable in the sense that people can't go and change it once the consensus poll has started. But while it can't be change formally, the participants can effectively influence it in a way that the static contract informally becomes as mutable as the document itself. If participants are not happy with any part of the StaticContract, they can force it to change in the following ways:
Contents
What do we do if we are not happy with the GoThresholds ?
- Participants can set their status to NotYet in order to force higher levels of participation. In effect, for any participant who sets his status to NotYet , the process will need nine more participants to bring the consensus to 90%, so that two people by saying NotYet can force the GoTheresholds to go up to 20 while the minimum required number is even less than 10.
What do we do if we are not happy with the DoneTimer ?
- When the DoneTimer is running, any participants can edit the document to reset the timer. This will delay the expiry time of the DoneTimer, providing more time for the participants to realize that the GoThresholds have been reached.
Static contract actually static?
The consensus polling process is not "final." We can change it in any ways we like. We can experiment with it. In the minds of those that have used it the most so far, there are four pieces to any consensus poll:
- dynamic document (this is what we're working on, as the outcome)
- yesmeter (shows yes/not yet status of each participant and the yes percentages as we go)
- static contract (go thresholds plus done timer length) that does not change once the process begins
- forum for concerns (a place for discussion to take place on each person's concerns)
The static contract is the only one of these 4 that does not change. As designed, these cannot change during our work because if they can change, we'll never know if we're done. If we're running a race, we must know in advance where the finish line is, otherwise, how do we know when we're done?
GoThresholds immutable?
What are reasons people might change the GoThresholds?
- They are too high, and we'll never be done, because there isn't enough interest in this topic. For example, the LASIK first city done poll could've required 20 participants. Only 4 people actually care about the issue, so if we'd started with a gothreshold of 20, participants might have wanted to change the number downward.
- If GoThresholds are mutable, those participating could simply lower the thresholds. What happens if there is disagreement?
- If GoThresholds are immutable, a new consensus poll could be started with the lower numbers.
- They are too low. With an issue that concerns a really wide range of people, if the thresholds are too low, participants may not feel the need to do outreach.
- If GoThresholds are mutable, one participant feeling strongly that the numbers need to be higher for any reason can change the GoThresholds to force outreach to happen. Someone else is then free to change it back. How to break the deadlock?
- If GoThresholds are immutable, this person wishing higher thresholds could simply set her status to NotYet . For every person that does this, 9 more participants would need to be recruited to get the whole process to 90%. If the immutable threshold was 5 people, for example, one person feeling that 5 is too low could stay not yet until a new (informal) threshold was reached - 10, for example. If the minimum is 5 and one is NotYet , holding out for 10, the 4 that are at YES will likely find it easier to recruit more people than to change this person's mind. Note that if two people believe that the number should actually be 20, they have the power to delay acceptance of the solution until 20 participants are present.
DoneTimer
What are reasons people might want to change the DoneTimer length?
- If the process feels like it's taking too long, and the document keeps getting edited (which resets the DoneTimer)
- If the DoneTimer is mutable, someone might change the DoneTimer to make it shorter. Someone else might change it back. How to break the deadlock?
- If the DoneTimer is immutable, if the document keeps getting better, than patience is the answer. If not, the ClotureThreshold comes in.
- If people are still at status YES , and the document is about to pass even though it has significantly changed since these people lack checked in
- If the DoneTimer is mutable, someone might change the DoneTimer to make it longer, to make sure those people could be contacted.
- If the DoneTimer is immutable, someone can simply edit the document to reset the timer, as many times as necessary while people are being contacted to re-check the document and their status.
Conclusions / questions / comments
In either case, it seems that immutability does not cause undue problems. What are the advantages to allowing the contract to be edited mid-stream?
To be fair, as consensus polls have been used at AboutUs, we have not actually enforced the immutability of the static contract and the sky did not fall. Thoughts?
Asad and Ted talked about making an EffectiveStaticContract statement so participants know they can be NotYet in order to force higher levels of participation or edit the document in order to provide more time before the done timer expires.
- I like the idea. Obed Suhail