Projects:ConsensusPolls
Contents
Who
The Projects:ConsensusPolls is an OngoingProject
Why we're doing this?
Projects:ConsensusPolls is to develop a platform for collaborative decision making, to make whatever changes to the process are needed, and to recommend further work by development team.
It will be done when:
- Automation reaches a level where the processes require minimal management from the staff members
- When staged consensus polls are properly formulated and implemented
- A good number of community members have been involved
People
- Obed and Ted - development
- Brandon and Scott - Facilitation and outreach
Not involved yet but would like to be
Project Tasks
-
Defining Inactivity - ConsensusPolling:When NOT to use it
- Defining all consensus polling terms/processes clearly
- Automation of vote counting, percentage calculation and done timer
- Introducing staged consensus polls to the portal
- Patrolling ongoing polls
- Facilitate participants through discussions
-
refactor status/discussion transclusion process- one idea
- simple page like AboutUsLogo that hides discussion on individual status pages with noinclude and
- additional page like AboutUsLogo:Facilitation-Discussion where discussion would not be hidden
- simple page like AboutUsLogo that hides discussion on individual status pages with noinclude and
- one idea
- use css (class="consensuspolldiscussion") and javascript (show/hide) to display all discussion (initially hidden on status pages, using css instead of noinclude) with a single click
- how do we do this? look at Nathan for an example to learn from
Discussion
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
some concerns about the process
- "Not Yet" should be a possible outcome. If the participants think that "this" is a good idea, but the current implimentation proposal is not workable, then there could be an improved proposal submitted in the future for a new vote.
- "No" needs to be a status option and possible outcome, so people can express that this isn't even a good idea, and we should give it up, or completely reformulate it.
- My "Yes" "Not Yet" or "No" don't mean anything if the document then changes after I set my status.
