Another discussion about improving proposals
Consider this a fork of a discussion within the Enspiral group where a proposal was raised for 7 days, it had good engagement - with quite a lot of "i think we can do better" but there was some sense that it was hard to move from that place and onto the next iteration - especially while the proposal was still running.
On this discussion I would like to ask people to suggest ways to decrease the turn around time in situations like this. - I want to focus on doing things that allow the failure to happen faster.
With my proposed adaptations, intend:
1- use the time destined to a vote, to move forward and to improve
2- facilitate the participation of members through voting, even requesting an adaptation
3- Always principal is the vote on the proposal as a secondary level the adaptations
4- is not compulsory voting the adaptations
5- the result of adaptations are informative, for that reason only exists a positive vote, because it is not a proposal
The level of engagement here is awesome. I don't have time now to keep up with all aspects of this complex flow of ideas-- like a river with many rocks, cross-currents and eddies-- but I do want to highlight @presley 's response to one part of @olover 's thorough conception--
" In your idea, there’s the proposal and any number of amendments being voted on simultaneously. The problem with that is that all of those votes are dependent on the others. You might only like the proposal if an amendment passes. You might like either of Amendment 1 or Amendment 2, but not both together. I think it’s important to make one decision at a time while not wasting any opportunities to gather information."
This is quite close to my concerns.
In a small group with sufficient engagement, it would be possible to create separate options such as "original + amendment A + amendment B" or "original without amendment A, + amendment B"-- however, it can get very complicated.
Olover, I believe you did mention the possibility of requiring a final 'ratifying' sort of vote for a proposal after all 'passing' amendments have been attached. This could help, but I think there is still a danger of a proposal slowly (and inefficiently) dying by the 'death of a thousand cuts' of 'decision by committee', if the standards for each transformation of the proposal are not strict enough along its path towards being finalized.
Perhaps there is a way to assure that each amendment is decided upon subsequently, by order in which amendments achieve unanimous support, and deactivating (by 'fading out', without destroying a record of them) the current positions on the original proposal and on each amendment suggestion on each occasion in which an amendment has been applied.
In the picture we see a proposal that voted 5 members of the group and 3 adaptations, they can vote all 5 members that voted exclusively.
The first adaptation has a 100% approval, the second approval of 20% and the third did not approve nor the member who suggested it.
It is logical to establish that the proposal will be approved, along with the approval of the first adaptation
@gregorycassel and @presley I started a response yesterday, before the last two posts here and it started me onto a path of really exploring the details of this. My response does address your concerns of possible complication. Will post here as soon as it's ready! It will be little long, but I think it will help us get further in our thinking.
Ok folks, here are my thoughts. :-) It's long but worth the read, I hope! You'll also see I've thought about lots of details, so please forgive me if there's too much information at once. I hope I'm not repeating things that have been discussed elsewhere, and that my thoughts can in nay case contribute to a good discussion. :-)
@presley, thanks for your comment. I think having a summary of positions related to each amendment at the top of the proposal panel (in addition to the list with each user's views on proposals, amendments and details) is a good complement to what I described.
I do want to give as much flexibility as possible to users to use Loomio as they want. I was just thinking, as a design feature, that Loomio would gather/harvest information in a certain way during and at the end of the vote, so that people have an easy way to look at the direction in which the group wants to go, and possibilities for this (this refers to which amendments result uncontroversial and should be highlighted for the users, for example). We can discuss whether such clear visualization should be available to everyone or only the person writing the proposal outcome, but I tend to favor everyone. In any case, the person writing the proposal outcome would then use this information to determine an outcome according to whatever agreements are in place within the group as to how to interpret or use that information in order to move forward. I hope this clarifies that point for you?
I understand your concern with too many things being decided on simultaneously. That's why I proposed that proposals not be changed by votes on amendments, which are separate. That means that one expresses her/his opinion on each item individually, and votes for each item are tallied separately. However, their influences on each other are also registered by Loomio.
After having given this some thought, let me clarify how I see things could happen.
I proposed an induction phase a while back. I think it could be useful here too. In relation to proposals specifically, it would enable the following:
Users or the proposal initiator define for their group or for the specific proposal, respectively, whether “disagree” votes on amendments are considered passing or not passing. Users could decide whether to set a rule or to allow proposal initiators to choose each time. This only affects whether amendments receiving “disagree” would then be visualized by Loomio as possible ways forward during the voting process and at the closing of the voting period, as you'll see below. Users determine in a similar way if they want Loomio to make visible in a summary/harvesting only “block” or also “disagree” votes on the proposal itself.
Users or the proposal initiator define for their group or for the specific proposal, respectively, whether there should be an objection period after the vote has closed for spotting a conflict between two amendments that have appeared separately non-controversial.
Many other settings could provide the flexibility of Loomio we want to give users, including settings on how to visualize information Loomio would analyze (more on that later).
This post
For simplicity, all examples below assume only one voter, one amendment, that “disagree” votes on amendments are considered not passing, and that users chose to visualize “disagree” votes on proposals in the harvesting.
I am also working from the assumption that amendments can be useful ways to improve proposals, and that amendments to amendments actually take the form of new amendments (better amendments can be shown to have greater support in the end, or worse amendments can be retracted by those who proposed them if a better alternative amendment is formulated). Further, while users are not obligated to vote on proposals, users who have voted on a proposal would be required to express a vote on all amendments (they can vote “abstain”). Alternatively, they could not be required to vote on any amendments, which would effectively be considered as abstentions.
Possible scenarios
No “block” vote on proposal + “disagree” or “block” vote on amendment = proposal passes as formulated originally, amendment is ignored
No “block” vote on proposal + “agree” or “abstain” vote on amendment = proposal passes integrating this amendment
“Block” vote on proposal + “disagree” or “block” vote on amendment = proposal does not pass, amendment is ignored
“Disagree” or “block” vote on proposal + “agree” or “abstain” vote on amendment = this is the real point we want to focus on, because of the potential to change the “disagree” or “block” votes on the proposal to something more positive through an amendment.
Voting Process
Voting on a proposal leads to a page where (as is the case currently)
- I choose my position
- I can add a voting statement
Voting on an amendment leads to a page where
- I choose my position on each of the amendments proposed to date
- I indicate my views on the relationship between each amendment and the proposal by selecting from drop-down menus the appropriate combination (see how below).
- I indicate my views on the relationship between each amendment and other amendments by selecting from drop-down menus the appropriate combination (see how below).
- I can edit my voting statement
- I can edit my position on the proposal as it stands, without any amendments (see more on this below)
Exploring point 2. of voting on amendments: Relationship between each amendment and the proposal
Next to each amendment there is a sentence such as: "If this amendment were adopted, I would/would not change my agree/abstain/disagree/block vote on the proposal to agree/disagree/abstain/block".
Clicking on “would/would not”, which can be a slider, shows or hides the underscored part of the sentence, as appropriate, and “would not” would be the default. Perhaps the first of the two drop-down menus in the sentence, which refers to the vote on the proposal, should either be an non-editable reflection of my position on the proposal, which I can change by editing my position on the proposal elsewhere on the screen first, or a drop-down menu that, if changed, would edit my position on the proposal.
The relationships between amendments and the proposal can be calculated by an algorithm, which would also calculate any logical contradictions between selections on the drop-down menus.
Here I would like to focus for a moment on the potential an amendment might have to change my negative vote on a proposal. Thanks to the process above, if my vote on a proposal is "disagree" or "block", I can indicate that a given amendment would make me change my vote on the proposal by:
agreeing to the amendment
indicating the relationship of the amendment to the vote on the proposal
explaining this in the voting statement
However, since the proposal isn't changed by the amendment, my "disagree" or "block" vote on the proposal would stay for duration of the voting period no matter the influence that an amendment would have on it. Amendments with potential to remove “disagree” or “block” votes from a proposals are then harvested and visualized by Loomio (not by the user), as indicated below. The user can still use the voting statement to explain this, for the purposes of the dialogue process – but Loomio does the legwork of figuring out viable solutions from the options selected and visualizing them.
Exploring point 3. of voting on amendments: Relationship between each amendment and other amendments
Next to each amendment there is sentence such as: “I consider this amendment as mutually dependent on/mutually independent of/mutually exclusive of other amendments”.
The default would be “mutually independent of other amendments”. Selecting one of the other options in the drop-down menu would change the underscored part of the sentence to something like “amendment 1 / 2 / 3 /...”. The user would then select the relative amendment and a similar (and reversed) text would appear next to that other amendment. (A second line can be added for each amendment by clicking on a “+”sign, which would enable defining a second relationship between amendments.)
The setting of a relationship between each amendment and other amendments to something other than mutually independent would mean that my votes on the two amendments I put in relation to one another are now influencing each other.
For voting, that means that if I change the default mutually independent relationship to
mutually dependent, Loomio would “lock” my vote on one amendment and my vote on the other amendment together, so that changing one will prompt me to change the other (or to change the relationship set for them).
mutually exclusive, Loomio would only allow both amendments to have an “agree” or “abstain” vote. In all other cases, Loomio would prompt me to change either my votes or the relationship set for the two amendments (or would ignore my votes on these amendments, or consider them mutually independent - tbd).
The relationships between (or among) amendments can be calculated by an algorithm, which would also calculate any logical contradictions between selections on the drop-down menus, both between/among votes and between votes and relationship kind.
For tallying votes, it means that
In the case of two mutually dependent amendments, at least one of which has an “agree” or “abstain” vote: The amendment(s) with the “agree” or “abstain” vote is/are counted by Loomio as non-controversial and valid only if the other amendment on which it is mutually dependent has not received from anyone else a different kind of vote from the kind of vote given by this user, meaning either “agree/abstain” or “disagree/block” (This can change based on the settings of the induction phase mentioned above). If the vote on the second amendment is “disagree” or “block”, for example, it needs to be one of those two options for all other voters, in order for the vote on the first amendment to be considered “agree” or “abstain”, as the case may be. Same thing if the vote on the second amendment is “agree” or “abstain”.
In the case of two mutually dependent amendments, both of which have a “disagree” or “block” vote: The amendments are considered controversial and do not pass.
In the case of two amendments that a user would like to either see happen together or not happen at all, the user would indicate whether (s)he prefers the former or the latter possibility by setting the relationships between them as mutually dependent and voting “agree” or “abstain” on both, or voting “disagree” or “block” on both, depending on what outcome the user considers preferable. (For the purposes of the influence that votes have on each other, I am proposing that “agree” be considered equal to “abstain” and that “disagree” be considered equal to “block”. Again, this can be adjusted in an initial induction phase or determined as a setting by the group or proposal initiator. The nuances between “agree” and “abstain”, as well as between “disagree” and “block” remain nevertheless useful for the dialogue around the issue during the voting period.)
- In the case of two mutually exclusive amendments: Loomio only allows both to have an “agree” or “abstain” vote, and considers approved the one with the highest number of such votes between the two, excluding the other one.
The influences of amendments on each other and on a proposal are factored for each user first, then the votes of others are taken into consideration and allowed to change each user's votes as determined by them, producing a new result of the votes of each user. In essence, Loomio would be calculating each user's reactions to other user's votes. For example, if I've set two amendments I both agree with as mutually exclusive, and the one with the highest number of votes according to all users enables my “block” on a proposal to become an “abstain”, Loomio has helped to unblock a situation by showing which solution is best. (I am sure there are other scenarios in which things would be more complicated, but I think we can solve those if we explore this possibility.)
Loomio can thus translate various votes on possibilities and expressions of relationship between amendments into a roadmap of what is viable at any given moment.
Visualization during course of Voting Period and Harvesting Process
Loomio can use an algorithm to calculate if there is anything impeding the group from going forward with a proposed amendment, or with a controversial proposal if one or more amendments were adopted. Often the problem is that we don't see that we would all agree to something - and Loomio can be useful in making that potential visible. In practice, Loomio can process all the votes and make clear on a table/list below the following outputs (list of outputs below is an example):
If there are “disagree” or “block” votes on the proposal that would not be changed positively by any amendment currently on the table (possibly listing “disagree” and “block” votes separately in order to clearly identify “block” votes). This allows to see the ways in which the proposal still needs more work/amendments in order to be made viable or gather more support.
Which amendments have the potential to remove “disagree” or “block” votes from the proposal (again possibly in two separate lists). This allows to see the ways in which the proposal can be made viable through amendments.
Which amendments have no “disagree” or “block” votes. These amendments would be non-controversial and listed as such. (Again, the vote on the proposal and on the amendment are still separate, but users understand that the proposal will be adopted as amended if there are no “block” votes on the proposal and no “block” or “disagree” votes on the amendment.) This allows to see the ways in which the proposal is improved.
Which amendments fulfill both requirements in points 2. and 3. (unblocking potential for proposal and are non-controversial). This allows to see whether there is consent or consensus on breakthrough amendments. This is the crucial point that can turn an otherwise dead proposal around.
Which amendments have the potential to remove any remaining “disagree” or “block” votes from the proposal (possibly on two separate lists) but were deemed by at least one user as mutually exclusive of another amendment that received more votes and thus was chosen instead. This allows to see which amendments can be important to create consent or consensus (as the case may be), but are outvoted by alternative amendments that are more popular.
Which amendments received no “disagree” or “block” votes but were not sufficient to remove a “disagree” or a “block” on a proposal. This allows to see ideas for future proposals.
These are only some of the many combinations of data that can lead to useful information. The possibilities are endless! We can talk about which other combinations there might be, which would be most useful, how Loomio would visualize such information, and whether users can choose the kinds of information they want to calculate and visualize from a proposal. The uses of Loomio as well as the number of people potentially involved in decision-making are many and varied, and such functionality would be very powerful.
In any case, all of this data can be made clearly visible by Loomio in a dedicated graph or table that is visible to everyone throughout the voting period. At the end of the voting period, the person publishing the outcome of the proposal can use that information to formulate the outcome in narrative form. Loomio could even propose a ready-made draft summary outcome to publish, on the basis of its analysis of the voting data.
Additionally, Loomio could show a dialogue progress bar live during the voting period that shows the level of engagement, the progress made by the effect of the amendments proposed, etc. in order for users to get a sense of whether they are making progress in coming to solutions or not.
A related idea is to have a dialogue scorecard that can show, at the end of the voting period, various levels of achievement in certain areas (those below are possible examples):
Formulation of initial proposal (high score if it was close to what was approved in the end, low score if it required many amendments to be approved or if it wasn't approved)
Formulation of amendments with unblocking potential (percentage of amendments for which users indicated they would improve their vote on the proposal). This is related to measuring the progress made in formulating through dialogue and amendments, a proposal that was finally approved.
Formulation of non-controversial amendments (percentage of non-controversial amendments)
Dialogue score (combination/overlap of scores 2. and 3. or percentage of amendments that are both unblocking and non-controversial)
Overall score (combination of scores from 1. and 4. above)
The dialogue scorecard for each proposal can then also be used by Loomio to calculate if there is an improvement over time in the way the group develops good decisions or not. This can be good data on which to develop supports within the group to be better able at carrying out dialogue and come up with better decisions together.
Overall process
In the whole voting process, I have mentioned the proposal, amendments and voting statements, and the publication of the proposal outcome. Let us keep in mind there is also the side discussion taking place during the voting. Besides the information that can be visualized by Loomio described above, there are additionally:
- The list of votes, similar to the current one, but including votes on amendments and possibly their relationships according to each user
- A summary of support for the various amendments, which can live at the top of the proposal panel
Yet another thought is the possibility of an objection period to spot potential conflicts between amendments after voting on a proposal has closed. However, these conflicts are likely to be spotted and identified as such by users setting the relationship between two amendments as “mutually exclusive”.
This whole long description omits the idea on implementation details I have mentioned before, which I think would be valuable, but I think it's easy to imagine how it would fit since implementation details would be voted on and implemented in a manner similar to that for amendments described above.
Again, several of the details above may be determined by the users, with defaults determined by Loomio.
Would love to hear your thoughts on all this!
Thanks for putting so much thought into this, @olover !
You've addressed the interdependence of the simultaneous votes, but I'm leery of two things: 1) it seems like so much automation of things humans could do that I'm worried it won't work as well in messy practice as it does in theory, 2) it might ask a lot of people in terms of analytical thinking and reading/remembering instructions. Inclusiveness is important, which means simplicity is important.
It would also involve a lot of development effort, I think.
So I think the right question to ask is whether the simultaneous votes are worth the downsides. The same decisions are already possible via new proposals. So the question is more precisely, how important is it to finish the decision-making process within one proposal, and why?
@presley, yes I had that thought too. Of course we'd have to try it out to see how things would actually work out for the users.
I think the importance of automation here is just to calculate things that would be difficult for humans to calculate, such as the result of various combinations of votes. Humans could do that, but it would take much more effort. Loomio would thus simplify that data analysis. Of course the human users can decide what data to analyze, and how to use that data to inform their final decisions / proposal outcomes.
I also hear what you're saying on remembering instructions, but I think there are ways to phrase things so that it becomes easy to understand how to interact with Loomio. I think that given the complexity of the calculations, what I wrote may seem daunting, but ultimately for the user it would not show all of that, but only prompt input of a certain kind. The average user doesn't need to know all the inside workings of the algorithm (which can be explained on a specific page for those interested, but doesn't need to burden the user experience).
In any case, the level of complexity of Loomio could be decided by the users themselves in what I called an "induction phase", so that ultimately certain users could keep it bare-bones, while others could use all the bells and whistles.
Yes, I think it would involve a lot of development, and I'm thinking of what Loomio could become long-term here.
Your question is important, and I do think it is worth doing all this in order to avoid having new proposals. There are several reasons.
Firstly, the person starting a new proposal needs to be able to integrate on their own any new input and votes that have come in, and, given large numbers of people, it can become unfeasible to process all that.
Secondly, amendments give a way to condense a lot of talk into a specific bit of information that users can vote on. This translates information into something calculable (as far as support for it goes). Even if those calculations are not done by Loomio, at least the change in direction in the discussion is measurable. If there is no amendment feature, someone would have to formulate amendments out of the discussion on their own, with a greater risk of coming up with something that doesn't accurately reflect the direction in which the group wants to go.
Thirdly, at present you can only have one proposal open at any one time, so starting new proposal requires closing the previous one, which doesn't necessarily allow all users to give input on the original proposal. The timing of the closing of the proposal and the creation of a new one then becomes itself an issue of opinion, and that can create a meta-debate that takes energy away from the issue being discussed. Others could look at the second proposal and think it doesn't actually reflect the input from the discussion, creating a meta-discussion and potential for either conflict or confusion if they then decide to then replace the second proposal with a third one, and so on. For example, you might then have users complain that the first proposal was better, and it would be hard to know how and when to decide to start yet a new proposal, and how to integrate the input, and so on. If, given new input, a third proposal is created that is closer to the first one, then, this would give the group the impression it is backtracking and not getting anywhere.
Fourthly, the phrasing of (new) proposals, which would have to include all input to date, would assume absolute importance, and centralizing the input in one element (the proposal) would lead to potential debates about phrasing rather than distributing attention over a series of smaller pieces of the puzzle in the form of amendments. If a new proposal is criticized, the whole proposal fails and needs to be replaced, with the new proposal having the same risk of failure. On the other hand, if an amendment is criticized, it doesn't affect the proposal. All in all, creating a new proposal creates the potential for criticism, while creating an amendment doesn't affect the proposal itself if it is controversial, and can instead help bring useful elements to improve a proposal that is controversial.
Fifthly, each new proposal would require users to restate their position, and users can become tired of having to vote over and over again on what they might consider to be the same issue. With an amendment, their vote on the proposal would stay, but they would have the option to vote on the amendment as well. If they don't, it counts as an abstention on the amendment. But if I have to vote on a new proposal, and I don't think the change from the previous proposal is substantial, I will either not be happy with having to vote again, or I won't vote - and dwindling votes on newer proposals would create confusion as to how people are feeling about that proposal, besides creating potential issues of legitimacy for that vote. All in all, having to iterate through various proposals can discourage group cohesion or, inversely, can create a "cost" that would bias users towards settling for the first formulations of a proposal rather than coming up with the best solution out of everyone's input.
Sixthly, as a general point, from a psychological point of view, creating a new proposal feels heavier or more radical than offering an amendment, so people would be more reticent to give input that might lead to a new proposal (the iteration between proposals suffers from this currently). There would be the tendency to see how this proposal goes down before starting a new one, which would take longer and might frustrate people if they don't feel like progress is being made. On the other hand, having the possibility of creating amendments and voting on them would allow more flexibility and more creative engagement with the discussion, I think. Changes on proposals would happen more easily, and there would be more of a feeling of co-creation rather than passing/failing one person's idea and someone else's idea superseding it in the form of a new proposal.
In general, having amendments makes it less "costly" to improve the proposal at hand than having to start a new proposal, and thus would make Loomio more useful in facilitating or catalyzing productive discussions.
These are my thoughts so far.
@olover congratulations
I need to read your comments again, but things lighter
As Presley said, thanks so much @olover for putting so much thought into this. I lack capacity to give 100% attention to each nuance of procedure you have suggested, so it's possible that I'm missing something. My initial thoughts, however, are that this system would be trying too hard to 'logically' calculate the potential relationships of various possible amendments. For instance, I do not think it's possible to accurately define amendments as being mutually exclusive of each other. I'm sorry but I just don't perceive natural language that way. I think everything is organically related.
I mentioned an idea before which would be challenging, but simpler-- in which any amendment which received 100% support of previous voters would be automatically applied while a proposal is live. I guess that such a system would need to wipe out everyone's votes on other possible amendments at the time that an amendment were applied. In fact, some other amendments might become incoherent upon the application of an amendment, due to deletion (or significant transmutation) of the material which they refer to.
Such a system would perhaps create a kind of competition of amendments, but I think it would be a mostly positive competition. After all, no amendment would be applied without the support of every previous voter, including people who offered potentially conflicting amendment suggestions.
I currently think that such a system would make sense. I don't think it would actually result in a lot of successful amendments, except possibly in the early stages when only a few people are considering the initial proposal-- but, those early stages are IMO quite important. It would be really good for people to be able to improve on proposals, instead of sinking or swimming with an initial formulation which is often based more upon "who's got the initiative here?" than upon collective intelligence.
I think those of us who have been active in the conversation the past few days have expressed our opinions pretty thoroughly, so I thought I'd provide a summary of some of the recent ideas, and step back until people closer to Loomio weigh in. I'm just going from memory so I'm sure I'm missing some and I hope I don't misrepresent anyone's idea.
- draft proposals: proposals can start out in a mode where they are editable by anyone, and votes don't really count until the mode is changed and they are reaffirmed
- objections: people can add reasons for disagreeing during a vote, and others can upvote existing reasons. Upvotes don't count as a true vote, but can inform the design of the next proposal.
- adaptations: people can add suggested changes to the current proposal during a vote, and others can upvote existing adaptations. The upvotes are not a true vote, but could influence the final decision if the group's opinion is very clear.
- formal amendments: an amendment can be introduced in the middle of a proposal. Voting on the proposal pauses for a vote on the amendment.
- unanimous amendments: an amendment can become part of a proposal during a vote if everyone who has voted on the proposal so far agrees to the amendment.
- parallel voting: votes happen simultaneously on the proposal and any number of amendments. Voters provide information on their beliefs about dependencies among the various votes.
OMG @presley thanks for the summary! I was wondering how I was going to digest all this text :)
I notice that there is some really in-depth thinking about this. I wonder what the easiest way to prototype these ideas is, to get real use feedback about how well they work in practice.
In response to @olover:
Absolutely, one-liners. Much like @carlosgallogaravan's visualization of adaptations. Right now a vote shows a list of Positions with a position icon, name, and comment. I'm imagining a list above Positions, but formatted similarly - number of supporting voters, name of author, and short text. The supporting voters could be named in small text the way people who Like a comment are.
I'm not clear on which parts of your idea are things you'd like to become convention, and things you'd like to be hard-wired into the system. I think hard-wiring the meaning of votes on amendments would be a bad idea, as it goes against the freedom Loomio gives groups to define their own rules - but you seem to be on the same page as me there.
But even having conventions about what votes on amendments mean is problematic with all these votes happening in parallel. I was imagining only one vote at a time being a full, valid vote - the proposal. In your idea, there's the proposal and any number of amendments being voted on simultaneously. The problem with that is that all of those votes are dependent on the others. You might only like the proposal if an amendment passes. You might like either of Amendment 1 or Amendment 2, but not both together. I think it's important to make one decision at a time while not wasting any opportunities to gather information.
Would anyone like to state what they think are the problems that need to be solved? I feel like it would help me understand these ideas better if I knew their motivations. There was some talk about this earlier in the thread but ideas may have evolved.