Difference between revisions of "EffectiveStaticContract"
Obed Suhail (talk | contribs) (New page: The StaticContract is designed to be immutable because if it keeps changing during the process we will never know where the finish line is. However, if participants are not happy with ...) |
Obed Suhail (talk | contribs) |
||
| Line 8: | Line 8: | ||
* 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 [[GoThreshold]]s have been reached. | * 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 [[GoThreshold]]s have been reached. | ||
| + | |||
| + | |||
| + | [[Category:ConsensusPolling]] | ||
Revision as of 09:15, 7 August 2007
The StaticContract is designed to be immutable because if it keeps changing during the process we will never know where the finish line is. However, if participants are not happy with any part of the StaticContract, they can effectively influence it in the following ways:
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%.
What do we do if we are no happy with the DoneTimer ?
- 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.
