Another discussion about improving proposals

I was vaguely thinking something like: when a proposal is running, there is a way for anyone to 'suggest an alternative', which sits behind the current proposal in a kind of backlog.

People could up- or down- vote these 'proto-proposals', and they would editable by the author or coordinator, to allow consensus to build in a lightweight 'non-binding' way.

Then when the current proposal closes, someone could turn one of the proto-proposals into a real proposal, which would then open the formal voting round.

Very interested to get @alanna's take on this idea.

The simplest idea I can come up with is encouraging people to use short timeframes for proposals that are young/new. What if the default was 24 hour proposals, and if they "pass" (according to the feel from the group) then they move onto a second, longer round for more consideration?

Loomio could have strong,helpful recommendations built into the ui about proposal timeframes to increase turn around in groups with good engagement.

I think there is also a need for a less "blocking" style of collecting intention/direction from the group. By 'blocking', I mean, everything must wait for this proposal to end.

I would love to know what people think about a round for "suggestions" or "ideas" that could then be taken to a "blocking" proposal round when there was an idea that was worth focused consideration.

The problem I typically see is that people often are not involved in a conversation for their own reasons and they are not always concerned with or understand the concerns of others. People end up talking about related but slightly different issues in one "discussion".

The first step would be to make sure the problem being discussed is clearly and precisely defined. A proposal to "get money out of politics" is so broad it means different things to different people. Narrowing down the proposal to something more specific is what's needed.

@BenBurton that's not really what I see happening, and I think it's a different discussion to the one I want to have here.

Within the Enspiral group we had a clear proposal, and it was not quite good enough yet.. but there was a feeling from some that the process was too slow.

In this discussion I want to talk about how an engaged group with a reasonably actionable proposal can iterate constructively, and move with a satisfactory momentum.

Why didn't anyone in the group just write a post expressing their concerns and asking if others where had similar feelings. Surely this should happen regardless of whether a proposal is still open for voting or not?

I think the failure in the thread in question was with the person who started the proposal. If you raise a proposal and it's clear that people don't approve it and it's time for the next iteration, it's kind of up to that person (or other group coordinators, or anyone in the group who is empowered to take acts of facilitation, which depends on the culture of group), to shorten that proposal close date or close the proposal. Then they or someone else can raise the next iteration of the proposal that's emerging. I don't see this as a technical issue, but a human facilitation issue. I think we should be doing more to train people about taking acts of facilitation like "I see that this proposal isn't getting support, but another solution is emerging. We've had input from enough people that it's clearly time to close this proposal and move on to the next one." I'd rather help people get good at that than complicate our software right now.

@alanna maybe we could give some more facilitation hints within the software. I wonder whether it would be difficult to trigger Intercom to send some helpful message to the coordinator in the case of certain patterns of proposal engagement?

Yes to facilitation hints. I think that's an important aspect to help and training and onboarding.

Just to clarify, I am not against a "suggest an alternative" feature. I'm sure we've discussed it before. I just think it won't solve the underlying issue, which is that someone needs to make a call on the timing from moving from the first proposal to the alternative. And that's more or less the same thing functionally as closing the current proposal and opening a new on based on alternatives suggested in the comments.

Case in point - the person who started the long proposal and then kind of walked away for a while in the other thread has now come back and done exactly that, and that discussion is already back on track. Maybe all it would have taken was a nudge from Loomio going "Hey, looks like you started a proposal and a lot of people have participated but it's not really getting much agreement. Think it might be time to close it an try an alternative idea?" and that whole process would have been faster.

Thanks for participating everyone.

I am not advocating straight up feature development. I think this is about modelling and encouraging good behaviours combined with the right technical stuff to make the experience super easy and rewarding.

I hear @alanna saying that currently responsibility lies on the admins and proposal author, and I want to investigate if we can design solutions which prevent the worst cases of this, supporting people in that responsibility and making it easier for them to practice good facilitation.

It feels to me that we're closing in on an issue with proposals not being as flexible as some people would like. I'm not talking about the software features - I'm taking about how proposals end up being/feeling in practice. If we end up identifying that people/behaviours are at fault, then I'd like to talk about encouraging behaviour change - but I want room to discuss new aspects of the proposal process / technology too.

For instance:

Is there an amount of time that is "too long" for most proposals.
Should we warn people who make long duration proposals to consider shortening them?

Is there a perception that one proposal should "do it"? When really proposals following on from each other is the norm. If this is true, do people know it? Do they set closing times and details with this in mind?

If a proposal gets a strong negative or mixed response early, it might be clever to encourage the proposer to iterate quickly.
Maybe a day after you start a proposal we email you some tips to getting good outcomes?

I often see people calling out for the opportunity to start a new proposal when the group is dissatisfied.
What constructive things can we suggest to the group members to do at this point.
In what ways can the dissatisfied construct their ideas without drawing attention away from the proposal too early?

Often we see that the proposal is closed and a new one is started with amendments from the discussion?
Can we support the proposal author in this part of the process?

Two features we are missing. I apologize if these were discussed previously:
1. "bid driven" proposal, where each member has a limited pool of points that she/he can allocate across various options?
2. Selection between specific options and not just agree or disagree? or did I miss something?

Formal meetings get around this as follows: An alternative or separate motion is not allowed until the current one is carried and becomes a resolution (or is lost). However, an amendment to the motion can be “put” by a participant during discussion of the original motion. This needs to be seconded. The important bit is that from this point only the amendment may be discussed. The amendment is discussed, and is then either carried or lost (i.e. voted on). If the amendment is carried, the original motion is amended and discussion continues on this. If the amendment is lost the original motion stands. Passing the amendment ONLY passes the amendment to the motion, not the amended motion. The process was to amend the motion, not to create a new one.

This may sound rather complicated but in reality would be very simple to implement intuitively on Loomio. Too much power to the proposer can impede the flow.

I think the amendment idea is really powerful, @deansatchell . I'm guessing that people will generally be concerned about slowing things down in an online process, dependent on people participating asynchronously and irregularly. For instance, if anyone could propose an amendment at any time, some people might be tempted to get really 'fussy' about others' proposals.

Requiring a 'second' helps, of course. I'm thinking that in an online group, it might be best to require more than a second in order to interrupt a current proposal with the consideration of an amendment. For instance, maybe people should need at least two supporters to create the proposal of the amendment-- or, perhaps they should need a percentage of participants to support the creation of an amendment proposal.

Perhaps a specific percentage of the number of people who have voted so far could be used to determine the creation of an amendment. I don't mean that people could only support the amendment proposal if they have already voted. I just mean that the amount of support which an amendment proposal requires could be proportionally tied to how much time and thought has already been invested in the current proposal.

For instance, say that an amendment is only considered after it receives support equal to 20% of the current 'vote' total, numerically rounded up. In that case, then if only 1 to 5 people have voted so far, then an amendment idea only needs one supporter (in addition to its creator) in order to become the official topic of business. If 6 to 10 people have voted, an amendment requires 2 supporters to become the official topic of business. Etcetera. For a really busy and active proposal, which has been around a while, you'd need a lot of people to like the amendment idea, in order for the amendment to become the official topic of business.

The determination of who likes the amendment idea could be as simple as counting the 'likes' for the amendment idea. Mechanically speaking, however, this would seem to require a new category of 'comment'/input which would be defined as an amendment suggestion.

I just made this all up, but it seems superficially sensible to me.

I'd like to note too that the currently planned 'Ideas' feature does overlap somewhat with the idea of amendments-- but, not very much. 'Ideas' can be entirely different than the current proposal, or they can be so closely related that an amendment might suffice.

For instance, if anyone could propose an amendment at any time, some people might be tempted to get really ‘fussy’ about others' proposals.

And this is where I loop back to my initial point of:

The first step would be to make sure the problem being discussed is clearly and precisely defined. A proposal to “get money out of politics” is so broad it means different things to different people. Narrowing down the proposal to something more specific is what’s needed.

Precisely defining a problem focuses the conversation and helps prevent it from spiraling out of control

Thanks for your feedback @gregorycassel. Again referring to formal meetings, once voting begins an amendment is not possible. A group seeking consensus would firstly discuss the proposal before voting and a time limit in place after the first vote is cast would ensure turn around.

@deansatchell , it's a very good point that once voting begins in a formal in-person meeting, amendments are not possible. I should note that I'm not trying to draw many parallels between what happens (or could happen) online and the things that occur in traditional meetings. There are lots of different possibilities, strengths and weaknesses, especially if people are comparing majoritarian voting per parliamentary procedure with consensus process.

For instance, in a traditional in-person meeting, everyone votes at once or quickly in succession, by show of hands or voice or by roll call. This can be done remotely by conference call, and it can be somewhat mimicked with scheduled online meetings, but it isn't really possible with the ways that people tend to relate to online social groups.

Loomio doesn't have a motion-which-is-not-yet-a-proposal stage. Of course, it would be technically possible. Also, I tend to think that a proposal should have some evidence of support before the whole group is stuck with it, as a good practice if not necessarily a technical requirement (such as a formal 'second').

If you have a specific idea of how Loomio could implement an amendment process before 'voting' begins, it could be helpful to see.

I certainly agree with you about precisely defining a conversation and creating highly valuable proposals, @BenBurton . I think the question here is whether or not Loomio could do anything technically to facilitate improved proposals, turn-around time or (if people are open to some form of this) proposal amendments. If people do think that Loomio could do anything to help, it could perhaps join the Ideas Backlog in the Loomio Roadmap. However, I have no idea how most people feel about the ideas in this thread.

I'm not much good at mockups but I'd previously suggested that amendment "layers" could go over the top of the previous proposal or amendment. Keep in mind that in formal meetings amendments can be made to amendments which can be made to amendments! This can get confusing for meeting participants but a tool like Loomio could transform this into an intuitive process. A resolved amendment disappears exposing the modified layer beneath.

Thanks for linking that old discussion, @deansatchell . Was there any follow-up elsewhere? It looks to me like it just kind of stalled and ended, which often seems to happen in online discussions. In fact, that's one of the reasons I'm so attracted to Loomio: the visual emphasis on proposals and consensus 'voting' seems to encourage focus and action.

I'm very open to the idea of proposals not going 'live' initially without at least one 'second'. If proposals did require action before going into effect, that period certainly could be a good time to apply amendments. However, I still currently think that the idea of desirable amendments coming up during voting is also potentially quite useful and efficient, if handled in a way which requires a lot of (proportional) group support. It could in theory 'save' a failing proposal, and also significantly improve proposals which are succeeding, but aren't anywhere near maximized in group value.

I really like the 'amendment layers' concept.

I think there's a lot that can usefully be done on the space of "ideas" and "proto-proposals" to address what I think people are wanting from amendments. This would be an earlier phase before something becomes and "official" proposal that people are voting on. This is in the backlog and has been discussed at length.

There may be some important fundamental differences to consider between methods proposed. I think this discussion should be around how these influence time frames. Proto-proposals have alternatives floating in the background but attention is still focused on the current proposal. This is a very gentle way of nudging (or "pulling") proposals in the right direction but will this in itself impact on the time frame of the proposal? Amendments force the focus to be on the change and the change alone. If no decision can be made sooner then the discussion will lead to another amendment being floated that continues to "push" the group to produce a decision around the proposal. It is important to understand that an amendment is not an alternative or new proposal, but just a method for improving the current proposal so it might pass.

Robert has brought this up having experienced first hand a turnaround shortcoming. Placing a deadline on proposals means a time restriction on discussing the proposal. This is just a bandage and is not addressing the problem... that the current process does not facilitate expedient decision making. Providing a tool for the group to work on an alternative proposal in the background (to float later) might be adequate, but I'd suggest that groups of people need someone to stick their neck out for a good discussion to ensue. Good decisions result from good discussion with forward momentum.

Also, just thinking out loud: If participants were aware that a time restriction only applied once the first vote was cast, would this influence their behaviour?

For me this still comes down to people paying attention and taking acts of facilitation, not to the software. While I'm sure there are features we could build to support and amendment process, right now it's perfectly possible to discuss alternatives in the comments, and to close a proposal and open a new one.

I don't think we should lean on software as a crutch to solve all facilitation issues. Until we develop perfect AI, we humans are still going to have to intervene to proactively keep discussions on track.

If people want a quick turnaround, and the group wants to engage in a short timeframe, then just raise a proposal with a very short deadline. I have turned around decisions in a matter of hours this way effectively. It's always a balance between speed and participation, but it's up to us humans to figure that out.

I could imagine a situation where someone raises a proposal which is not getting support, but for some reason refuses to close it, and that holds the group back. In that case, it seems appropriate that a coordinator would step in and close the proposal. Or that people would talk to the person who raised the proposal directly about how they are not acting constructively.

Perhaps in the future we could have a feature where if everyone has participated, the proposal closes automatically? But then the most powerful feature of all - the ability to chance your position after considering other perspectives - would be deprecated. Not worth it to gain a bit of speed, IMHO.

Or maybe someone could "suggest and alternative" and if a number of people support it, the proposal could swap to the alternative? Still don't see why that happening automatically, instead of manually, is so critical. Loomio is still early stage software. We need to focus on functionality that provides the greatest use value, and automating something that is easy to achieve manually doesn't seem that critical.

I'm not convinced that human intervention in group process should be offered as the solution. Participants will always come in with positions. It's human nature for people to dig their heels in and believe they are right and their protagonist is wrong, thus boundaries need to be either managed by the facilitator or the software.

In my view bypassing the need for a chairperson/facilitator in all possible situations is the most important technological challenge the Loomio team needs to pursue. The written group rules themselves need to be simple, with most "rules" unobtrusively written into the software as features.

Closing a proposal before its time opens a can of worms. Setting an arbitrary time deadline weakens the experience. Solutions each have positive and negative consequences to consider.

I'll try and point out where I believe suggesting an alternative falls short: If there is a proposal tabled already and someone suggests an alternative, participants will "side", dividing the group. This is no way to reach consensus decisions and the proposer would rightly see it as downright rude not to let their proposal run for the time set. This is why it is strictly off limits in a formal meeting setting - A decision MUST be reached on a motion (proposal) before an alternative can be put. As Alanna also points out the software already effectively facilitates this solution in the discussion (using "like").

In contrast amending a proposal is only offering a way for the current proposal to have more chance of passing. It is not discourteous to the proposer and is a proactive step towards a decision. Further amendments could be floated until the proposal is worded suitably for a decision. In the end the proposal stands or falls. Folks, this process is actually very very democratic and the power rests with the group rather than the proposer.

Although I suppose this process could be achieved with Loomio as it stands, it would not be intuitive. It's hard enough in a face to face meeting because participants must understand that discussion is now only on the amendment and passing this, NOT the proposal. Put an amendment to the amendment and confusion reigns! What participants need to understand is that everything comes back to the proposal... so passing the amendment means an amended proposal to then consider. Now imagine how easy this would be to implement in Loomio with layers in real time. The user doesn't need to understand any of the process because it simply unfolds. The moment an amendment is seconded the amendment becomes the proposal and discussion is a clean page. The moment a decision is made on the amendment the layer is removed and we're back with the proposal (which might now be amended).

In my view bypassing the need for a chairperson/facilitator in all possible situations is the most important technological challenge the Loomio team needs to pursue. The written group rules themselves need to be simple, with most “rules” unobtrusively written into the software as features.

In my opinion this would be hugely beneficial for the software. I think we all believe in communal decisions, hence our interest in Loomio. I think it would be really beneficial if Loomio helped facilitate the creation of proposals before they even go forward. If the process of writing a proposal can be given to a group instead of an individual it will have more strength and clarity moving forward and subsequently more success.

I've been following these comments closely. I mostly agree with you @deansatchell regarding the potential benefit of amendments, and the harmful fracturing which can occur when people consider an alternative while a proposal is live.

At the same time, I understand that groups can achieve similar effects internally, as @alanna suggestions, and-- this could be seen as crucial-- the Loomio Cooperative is working hard now to create solid stable features for the release of 1.0 . I can see where an amendment feature could be seen as a luxury or extension of Loomio. I currently lean, instead, to thinking that it could be a very effective basic feature in the long term, if proper development proved feasible.

If an amendment feature were ever added, which would temporarily override the consideration of a proto-proposal or live proposal, I strongly think that it should be contingent upon significant, proportionally-determined support (inside a given discussion) to change in the order of business.

I think @deansatchell @BenBurton and @gregorycassel are all correct.

It would be amazing to create a feature that facilitates a proposal evolving as the group engages with it. This is getting close to the heart of what we're trying to achieve with Loomio - software to facilitate the fantastic potential of group decision-making when it goes right, and different perspectives come together to constructively build up a solution that no one came into the discussion with.

One way we could help the process would be providing tools and knowledge at earlier points in the decision-making process to work through alternative possibilities and synthesis diverse input, so that once a proposal actually goes to a vote it's already carrying that richness.

Right now, what we have is a simple solution that only facilitates the most basic version of this process, supplemented by quite a bit of manual human intervention. We're stretched extremely thin, and the priority right now is on creating a stable, integrated Loomio 1.0 release. Features being discussed here will require a lot of careful thought and design to get right, and we're not likely to have that luxury for a little while.

I am feeling so grateful for all your thoughtful comments in this discussion and your evident commitment to dialogue. I am proud to be part of this community! :-) I really like where this discussion was going and I hope the features discussed can see the light of day at some point.

I have two possibly related feature ideas, which come from my experience with Loomio so far.

The first is that it would be nice to have a dedicated space to indicate which comment or comments the proposal is the result of. I do think this is something that can also be done manually by adding the link to the comment in the proposal description, but the advantages of having a dedicated field to indicate the comment(s) at the origin of the proposal being created would be important for the intuitive nature of Loomio.

For example, when creating a proposal, clicking on the (optional) field to link related comments would open a column with checkboxes next to the comments, and the user creating the proposal could check the ones that have relevance to understand the context of the proposal at hand or where it came from. (We have a context panel for the discussion, why not a way to show context for the specific proposal?)

Those comments would then show a colored line or would be shaded on the side, intuitively indicating a relation to the current proposal, which can show similar colors. I know we may also want to think of those who are color-blind, and related comments could also show up in a separate tab/window, or can be highlighted on the screen when one clicks on a dedicated "show related comments" link with the proposal description/panel.

Sometimes there are many comments in a discussion and it would be valuable to see clearly which ones gave rise to a specific proposal so that users can understand its purpose more clearly.

The other idea is related to the fact that, in my experience, the yes/no proposal structure is useful to define the whether and the what, but not the how. Put another way, many details about what taking an action really mean actually come up after the proposal has started and people have started voting.

My idea is that it would be useful to have a simple text panel on the side of the proposal where anyone could add various details about the proposal. (I am not sure how this overlaps with the idea of alternative proposals / amendments to the proposal, or if it's a slightly different way to frame specifics of a proposal and when and how they are discussed.)

In our case, I have used the context panel at the top of the whole discussion to add details, which works but is not ideal.

I know this also conflicts with the idea of not changing the proposal description after voting has started, but I do think there are cases in which it is useful to have a space for keeping track of ideas emerging regarding details of the proposal, implementation, etc.

For example, when discussing the specific items to be included in a mandate for representatives, we've used the context panel to keep track of the various points the representatives elected would be mandated to act on (which evolved over time), with the proposal being about agreeing to the current mandate described there. I know this brings up the issue of people being notified when the text is changed so they can possibly change their vote, but we've had a discussion on new features about that already.

If this could be done on a dedicated text field next to the relative proposal, it would be easier to understand.

Another example would be creating a joint letter.

I realize that those needs derive from the fact I am dealing with a geographically dispersed community of people who never meet in person and thus we need to rely more heavily on online tools.

This second idea may also be related to integrating Google docs or other tools into Loomio without having to click on a link and go to a different page.

Creative as usual @olover :) I don't personally fancy the first suggestion, because I think it could pressure some people to think too reductively about how a proposal emerged. It's true that some proposals may seem to derive directly from a specific event, but in other cases, they may evolve gradually from a dialectic spanning several pages of comments.

On the other hand, I find the second suggestion intriguing. I wonder if it's possible to implement in a way which does not implicitly create the feeling that people are 'extending' the proposal by tacking promises onto it. Of course, it's quite possible to offer implementation ideas without them feeling like promises. I might personally prefer for people to just include those ideas in the discussion panel, possibly tagging people who seem skeptical about the possibility of successful implementation.

I think I'm more interested in an amendment feature, as previously discussed in this thread. Very glad to be remembering this thread now.

In addition to the idea of amendments, there is the basic subject of proposals being related to separate documents. I'm currently been using a Loomio style proposal with respect to a complex external document which is subject to editing while the proposal is live. This is tricky, of course-- I've implemented a procedure to help people be aware of edits as quickly as possible, and to require a final confirmation to indicate acceptance of the document's current form before the proposal closes. It's a very interesting experience, and I will try to share any personal lessons I get from it.

Thanks @gregorycassel :-)

I actually also see the problem with linking proposals to specific comments, though I still think it would be valuable to be able to indicate what have rise to it without having to re read the whole discussion or, worse, assuming the proposal is intended to address an issue out of which it actually didn't arise. This could give people the impression we're talking about the same thing here when we may not be. I don't have a solution for the dilemma though.

As for the proposal specifics field, I do think it would be valuable to be able to keep track of implementation and other specifics by having all that info in one place instead of having to reread through all the comments to gather what people have agreed to over the course of the voting period. It also helps those who are joining the discussion late in the game to know the status of things right away.

Another idea is to have a checkbox when posting a comment that allows the user to indicate whether fhat comment is an idea about refining the details of the current proposal, in which case the comment would be added fo a list of comments with that tag, and those could be easily retrieved by clicking on a specific link somewhere on the proposal panel. However, I am not sure about how to make sure that only substantial implementing ideas or specifics be given that designation instead of any idea related to the proposal.

As I said, I'm also very interested in the amendment or alternative proposal feature higher up in this thread.

@gregorycassel, I would love to know what procedure you've devised to deal with changing input on a document the proposal refers to, if you care to share. :-)

Within my group, @olover , I initially suggested zero tolerance of attached-document edits during live proposals. It's a nice ideal, but perhaps not so efficient when people are presented with binary yes/no proposals regarding the formal adoption of complex official documents.

I certainly think that discussion, deliberation and (when used) co-authoring should be strongly used before anyone makes a proposal. However, I think it's helpful to allow some fine-tuning after people start thinking (and communicating) in a yes/no sense, but before the final decision.

So, I'm currently empowering team members to use their discretion in making minor edits to documents which are attached to live proposals. I encourage them to seek feedback first, and to only make edits which they sincerely expect others to agree with. Crucially, I want people to immediately and conspicuously indicate exactly what they've done to the document.

For context, this procedure is for official actions by a small group of people who administer a much larger group. These official actions are rare, and should be rare. I'm using formal consensus in which any proposal can pass after all members have registered a position, and at least 2/3 vote 'Agree', and no one votes 'Block'. There's no time limit. So, a proposal may be 'ready' to pass as soon as everyone has registered a position. This brings us to the formal part of the adopting any document-edits which occur during a live proposal.

The formal part is simple. If a proposal is otherwise ready for adoption, and it's attached to a document which has been edited during the live proposal, then everyone is asked to 'like' a specific comment which indicates their acceptance of the latest version of the document.

This is a pretty organic procedure which will IMO require practice. I think it will probably work for a small group of co-authors.

In theory, I would prefer that every little edit is directly endorsed by each team member as the proposal progresses. My group's highly asynchronous participation makes that unrealistic. So, I'm trying to find a practical balance which neither slows things down too much, nor creates any coercion, nor forces people to abandon proposals and start anew.

Thanks a lot for your reflections and sharing. I'll let it simmer and inspire me for our group. Nice idea to have people "like" the comment that refers to changes made while the proposal was being voted on.

Does anyone feel like summarising this discussion or proposing some outcomes from it? I feel like there is a lot of richness here, but we'd need to clarify the essence of what we've learned to decide what steps to take.

@alanna I'll try to make time to reread this discussion carefully, and to provide my personal summary feelings later. Hopefully tomorrow. It's quite a fundamental subject to me personally. I don't consider myself objective, however, so I encourage anyone else to also follow up here!

I just saw this and it seems like a good place to throw out an idea that came to me the other day.

I've never really been excited about the idea of amendments (I guess they seem too complex, and have too much potential for stalling a decision), but I thought of a version of them I think I'd like. So you have a proposal, it's frozen as usual, and people are voting and adding comments to their votes. When they do so, they have the option of giving a reason/complaint/suggested amendment as a separate piece of text. This piece of text lives at the top of the list of votes instead of attached to an individual vote. When you vote, you have the option of (in addition to writing one of these amendments) supporting an existing amendment. The support should crucially not be seen as a vote, just as a rough approximation. The goal is really to end up with a summary of the kinds of ways people disagree. So at the end of a vote, maybe you have three amendments, and one of them has a lot of support, and you can easily see that a good next step would be to discuss that amendment and turn it into a proposal.

I'm thinking it would be good for large groups where understanding the vote might be hard. My group is small so I'm just guessing! The main issue I can see is guiding people away from the desire to make it a poll. But by linking your amendment activity to your vote, it would be hard for facilitators to set up a poll on purpose, at least.

Thanks @presley for that amendment conception; sophisticated and definitely worthy of consideration!

I'm trying to develop a personal overview on this thread so far, right through Presley's comment. Considering the magnitude and complexity of this subject, I'd like to develop my own overview in an interactive way.

@robertguthrie , your discussion context hit things right on the head IMO, in a way which is still 100% relevant. I think we're looking for ways to speed up the iteration of less than 100% satisfactory proposal ideas.

@richarddbartlett , you suggested the possibility of proto-proposals, which could be created as alternatives to live proposals, and upvoted or downvoted. Does this overlap somewhat with "Ideas"? I understand Ideas however to be attached to a discussion, and not to proposals? Could we get an update on the status of "Ideas"? (From either of the two tagged gentlemen, or anyone else.) Not sure if Ideas is still a thing!

Yep @gregorycassel Proto-proposals and Ideas are probably the same thing. I haven't given it a lot of thought lately.

I think the crux is that editing is good for consensus building, but needs to be disallowed once people are in "binding vote" mode.

I don't have strong opinions about the form this distinction takes. How about this:

What if we had a Draft Proposal: you start a draft proposal just like a regular proposal, but it doesn't notify everyone in the group. People can state their position and they're recorded as non-binding votes. The draft proposal can be edited throughout. If necessary, you can then switch from draft to "published" or "binding". This converts it to a regular proposal, which notifies everyone. The existing votes are still there, but they are marked to indicate they were on a draft text so should be reaffirmed if you want to make it binding.

Does that make sense? What do you think of that @alanna?

"I think the crux is that editing is good for consensus building, but needs to be disallowed once people are in “binding vote” mode." -- 100% agree @richarddbartlett .
I don't want to assess your Draft Proposal concept too quickly, but it seems like a potentially elegant solution to a fundamental concern! I think it would be important for the previous votes to be made conspicuously inactive (probably faded out) after a draft proposals was converted into a full/published proposal.

In a very broad way, this concept seems functionally analogous to the handling of [proposals connected to externally editable documents] which I suggested earlier here. All positions are non-binding while external editing occurs. This suggestion for Loomio however would add a great deal of flexibility.

I think the best system would probably allow any group members to edit live Draft Proposals, but would create radical transparency in that editing process, would promote active feedback for each edit (perhaps even a direct upvoting and downvoting), and might even create some friction such as requiring a 'second' for each suggested edit to go live.

@presley I'm particularly interested in your views on Rich's last comment above, because your suggestion was more complicated but was also quite creative and IMO robust. Especially considering that you're not a core team member like Rich. :) I'm also quite interested in Alanna's thoughts; Rich has already tagged her.

I came across a process in about 2008-9 ... I think this was a feature of Ideascale though I'm not sure. https://ideascale.com/.

As I recall, someone could make a proposal which people could start voting on, however, the proposal could be edited and improved by anyone, even as voting proceeded. The platform was a bit like a wiki which recorded all the edits and who had change what. I can't remember now if people who had voted were notified of changes to the proposal and prompted to reassess their support. I can't remember if voters were prompted to give reasons for their votes - I think they were as it seems logical that the edits would be prompted by the reasoning.

Wow. I love the simplicity of the draft mode for proposals.

I also love what @presley said:

The goal is really to end up with a summary of the kinds of ways people disagree.

Insightful!

I feel like draft proposal could be a very slight change to the UX and code, and has the potential to unlock some more power from the process, and give proposals that flexibility I have been wanting.

It also seems like it could be quite easy to strongly convey the concept that a proposal is in draft mode, visually

I've always been a bit skpetctial of 'Ideas', or rather - something that becomes another 'thing' that has a button and text box and different way of displaying etc, but lives inside the discussion, aiming to provide a way for the seeds of proposals to rise out of discussions.

I think we should be adding more sorting, ranking and impulse action (think 'like') features to comments, consolidating them into a more general purpose tool (think trello) so that groups can use them how they need, rather than how we designed/limited them.

That is, I think great ideas can float the the top of view as comments. without being all rigid about a piece of text being put in the idea box or the comment box. Proposal drafters/creators should be able to use the comments view to harvest input.

My thinking on draft proposals is still evolving - I'll post a comment when it stabilizes! In the meantime, here's a thought in response to @robertguthrie:

I think we should be adding more sorting, ranking and impulse action (think ‘like’) features

I actually came up with the pseudo-amendment idea I described when I was thinking that I'd prefer aggregation (like the disagreement summaries) as a solution to the too-much-information problem rather than sorting or any kind of negative feedback. Those sorts of ideas come up a lot and I worry that they would have a negative effect on culture. They work great at Reddit and StackOverflow, but those sites are also known for having problematic cultures, and I think promoting cooperation and inclusion is critical to a place like Loomio. But I'm sure you've thought about it way more than I have, so I'd love to hear your thoughts.

On the other hand, I love the Like button. I see it as a social feature more than an efficiency feature, so I like Like for the same reason I would dislike Dislike ;).

I like what @presley is suggesting. However, in my mind It is very important to not confuse alternative proposals with amendments. An amendment simply makes the CURRENT proposal more acceptable. Once a proposal closes, the next proposal cannot be an amendment at all, but is an alternative proposal.

One reservation I have is that the process of a successful agreement could get drawn out. The proposal still needs to close before an alternative proposal can be put forward. That said there could be merit in an alternative proposal evolving in parallel to voting on the current proposal. However, then there is the potential for conflict resulting from multiple proposals being dealt with together rather than separately. More than one alternative, each with sufficient support to "float", would then surely require a process to decide which one has priority as the next proposal. So what advantage does discussing alternatives while the proposal is running hold anyway? Shouldn't the focus be on the decision, with alternatives only requiring discussion if it fails?

Okay, I went back and forth a lot, but right now I don't see draft proposals as creating more value than alternatives. I broke it down into these two use cases:

Use case 1: You need to collaboratively create or edit a multi-part document. Other apps already have sophisticated functionality for this. I wouldn't object to Loomio recreating that functionality, but it doesn't seem like a good use of resources.

Use case 2: You have a proposal and it's not good enough yet. That case is solved by closing the proposal and creating a new one. Yet people aren't quite happy with that solution. I think that's because editing a proposal feels more lightweight than replacing it. So there are two ways we can go: change how people feel, or let them edit. Draft proposals do the latter, but they're limited in their usefulness if they're only allowed before binding voting starts, because sometimes you'd realize the fatal flaw too late. They also have the potential to create proposals with incompatible parts, even when people mean well. So I think changing how people feel would be more helpful, if it's feasible.

I have two ideas for how to make iteration feel better. One is the one I just gave - not proposal-pausing amendments, but informal, along-the-way logging of types of disagreement, which can point to the need for a new proposal or the need for more discussion. I think it might make the life of the proposal feel like time well spent even if the proposal doesn't pass, without slowing things down.

The other is to just flag (officially or in the text) proposals as non-binding. I think this already what people mean by "temperature checks," right? Making it an official option would guide people to use it. Closing a temperature check early isn't as sketchy as closing a binding proposal early, so it might help people iterate through full proposals the way discussions help people iterate through pieces of proposals.

@deansatchell, good points. I think you're imagining a more complex system than the one I have in mind, so I'll give you a concrete example of what I intended.

Say I propose "let's go to the moon."

Alice disagrees and writes a new objection (I don't know what word is best but I'll use that for now): "too expensive."

Bob disagrees and adds support to Alice's objection.

Carol disagrees and writes a new objection: "Just the moon? Let's go to Mars!"

And so forth. The proposal closes and doesn't pass. Nothing happens automatically. Without this feature, anyone would be free to propose anything, and with this feature, that's still the case. The objections are just information, and just rough approximations, at that. Maybe one objection would have a lot of support, and someone would feel empowered to make a proposal based on it. Maybe support would be split between Earth and Mars, making it clear that no proposal will pass until there's more discussion on the cost of fuel and vastness of space. But no meta-proposals are needed, and although I can see the value in discussions on objections, I'd be against it for simplicity's sake. That can happen in the main discussion, after all.

So that's how I was thinking of it - I like the way Loomio works and I tend not to want to add too much to it.

Thanks @presley for the example. People are currently free to make alternative proposals in their comments when they vote, but (please correct me if I'm wrong) you are suggesting facilitating this?

Lets consider another example:

Say I propose “let’s go to the moon, there is gold. We could bring gold back to Earth and get rich.”

Alice disagrees and writes a new objection: “too expensive, costs will outweigh revenue.”

Bob disagrees and adds support to Alice’s objection.

Carol disagrees and writes a new objection: “Just the moon? Let’s go to Mars! Gold is more abundant there and costs will be lower.”

John disagrees and writes a new objection: “Mars is too small. Let’s go to Jupiter! It will cost more but there is so much gold there that it is sure to be the most profitable option.”

Sarah disagrees and writes a new objection: "Gold isn't worth as much as diamonds and is too dense to get out of Jupiters gravity. Lets go to jupiter and get diamonds".

The point being that ideas can build on top of each other and the original proposal gets lost. Offering reasons for disagreement in my view are quite different than offering alternatives. It's only human to suggest another option in response to somebody else's proposal, but isn't discussion the place for this? Surely the proposal at hand is the only proposal that needs consideration when voting?

It is very clear that we must improve the proposals

I have an idea: the coordinator or creator of the proposal adds a new section called "Adaptations" with suggestions or comments on the proposal to commented other group members.

To take advantage of the current proposal and gain time, these suggestions can only be voted positively and once for each member of the group, as shown by the number on the right side.

At the end of the current proposal, any of these adaptations can be transformed into new proposals.

See the attached images

People are currently free to make alternative proposals in their comments when they vote, but (please correct me if I’m wrong) you are suggesting facilitating this?

@deansatchell, yes - very much the way vote comments already suggest that you explain your vote succinctly, with the added feature that a later voter who feels the same way you do can make that visually salient by increasing the number associated with your objection. Otherwise they could like your comment, but who knows what that means, or they could write that they agree, but that's more difficult to see at a glance.

Offering reasons for disagreement in my view are quite different than offering alternatives.

Yes and no. Sometimes the reason you dislike a proposal is simply that you realize a better one is possible. I don't have a strong opinion on whether these things would be better phrased as objections or as adaptations like @carlosgallogaravan suggested.

Surely the proposal at hand is the only proposal that needs consideration when voting?

I agree that the proposal at hand shouldn't be derailed, which is why I prefer this system to one where amendments can stall voting on the proposal and why I think objections should be limited in length, like vote comments. But I think it's important to reaching the best solution that people express their ideas about alternatives. Your example doesn't worry me - if a vote turns into a brainstorming session, maybe the vote was premature and more brainstorming is needed. The objections in your example are responding to other objections, but the votes are responding to the original proposal, so it's not getting lost in the fray.

I've been quite busy today and only reading quickly here for now, but I'm really glad to see creative thought continuing on this very basic subject.

Since ideas seem to be flowing freely, I will suggest one I had previously which seems pretty robust--

If someone (anyone) were to use a special new feature called "suggested amendment", and got every single person who had voted so far on the proposal to 'like' or upvote the suggestion at any point in time, perhaps the amendment suggestion could be automatically applied.

I mean that anyone who took any of the four positions could suggest the amendment, and everyone who took any position at all would need to upvote the suggestion. Each person's suggested amendment would naturally, IMO, be interpreted differently based on which of the four positions they have taken with respect to the current live proposal. "Agree" could be read as "I agree, and I'd like it even more if [suggested amendment]", and a Block might seem to imply "I block this, but I may not block it with [suggested amendment] ". And regardless of each voter's attitude towards the current proposal, if they all agreed on a specific amendment, it seems like it would be a valuable edit. (Unless everyone, including the person who made the proposal, were moving farther away from the interests of the people who had not voted yet.)

I am really enjoying this conversation, thanks everyone for your ideas. I would like to highlight two of them.

I think it can be very valuable to have a way to see intuitively in which ways people's opinions differ, as @presley suggested. I am not sure what this would look like (and would love to get a clearer idea of what you are thinking, @presley), but perhaps it can be harvested in nuggets or one-liners, which I'll elaborate on below. (Another idea is a mind map, which would need more thought.)

This is connected to the second idea I want to highlight, which is that of having a space for possible amendments or adaptations, as @carlosgallogaravan has shown. I think that can make proposals more flexible and create space for improvements on the proposal to become visible.

I can easily imagine this has been discussed before, so forgive me if I'm repeating:

We could have an open text field directly on the proposal panel, wherein anyone voting can write the way in which they would improve the proposal at hand. This creates a list of adaptations. These adaptations are then considered to be sub-proposals within the deadline and framework of the main proposal. Others are notified of a new adaptation following the setting they have for notifications on new proposals.

Adaptations can have the same 4 voting options, but with no dedicated text field for the rationale of those sub-votes. Sub-votes are merged into the list of votes, so that the list indicates each user's vote on the proposal and next to it the way in which the user voted on the various sub-proposals/adaptations, so that the sub-votes can be properly understood as reinforcement of the current vote or as an adaptation that, if applied, can change one's vote in a positive sense. When voting on adaptations, users are prompted to edit their voting rationale, which can then reflect the new rationale for votes on the proposal and on any adaptations.

Voting on the proposal and amendments/adaptations are separate, so that the initial proposal doesn't change because of the existence of a proposed adaptation, and the respective votes are not automatically influenced by each other (except on the level of possibly getting new ideas), but have to be manually changed by the user.

At the end of the voting period for the main proposal, adaptations are visualized by Loomio according to the kinds of votes they have received. Only adaptations receiving votes that are neutral, reinforce a positive vote or can change a block or disagree to an agree float to the top or are included in this harvesting/summary (this means all adaptations receiving no "disagree" or "block" votes). At this point, if the main proposal also has no "block" votes, either

1. the proposal is automatically considered as passed with the adaptations that also have no "block" votes, or

2. the automatic summary of proposal and successful (not blocked or disagreed-with) adaptations is created, with a period for objection/"block" of a certain duration, after which the proposal is passed as amended. (This can make things a little longer but can provide more space to notice potential conflicts between two adaptations that have been consented to separately.)

Proposals and adaptations/amendments that are not passed can serve to create a new proposal. However, making it easier and quicker to amend a proposal in the way I described above perhaps addresses the iteration question as well.

I realize I have set a different standard for proposals and amendments, allowing for “disagree”s in proposals but not passing amendments with “disagree” votes. This is insofar as Loomio would automatically create an easy visual of all amendments on which there is consent. Of course the proposal initiator or the group can decide that even amendments receiving “disagree” votes can pass, as long as they have no “block” votes, and include those amendments accordingly in the outcome.

These musings make me think of the difference between adaptations that add something to or explore the details of the current proposal (perhaps similar to implementation details I've mentioned above) and adaptations that change something in the proposal as it currently stands. This difference should be made clear when contributing ideas to a live proposal.

So we could have two text fields (or one text field with a slider to indicate which kind of input on the proposal it is), which then feed the respective input into two columns within the same proposal panel, perhaps with the headings "details" and "improvements", respectively. The selection process for "details" would be similar to that for "improvements" (adaptations) described above.

Since the adoption of an amendment/adaptation can influence implementation details, voting on either an amendment or an implementation detail should take the user to a page where (s)he can easily see all her/his votes (on main proposal, all amendments and all implementation ideas) so that they can all be adapted at the same time as needed, together with the rationale.

The proposal outcome would then be written by whomever started it, integrating the main proposal, any amendments, and implementation details in narrative form so that there is clarity on what's going to happen.

Now, regarding this “details” idea, I know @gregorycassel has expressed concern about attaching "promises" by defining the details of something. I now realize that the importance of these implementation details for me is that they provide more information on the mandate the group is giving to whomever is entrusted with carrying out a certain decision. The how is often very important, in my experience, so I want to create a space for ideas on the how to be expressed.

Of course this overlaps with implementation aspects that would then be discussed and managed in a tool like Trello, but I would like to see Loomio provide a space for a proposal to develop to a stage where it is more mature. That way we reduce the potential for backlash due to a proposal implemented in ways that may be seen contrary to its purpose on the part of those voting initially.