Being allowed to edit proposals seems to be more doing more harm than good, in my experience. There may be a way to rebuild the editing feature later on down the track but right now it contributes to bad process.

Here is some more information to hold along side this proposal.
- I have added a popup warning message to highlight the effects of this action and the preferred method of starting a new proposal if the change is significant.
- The edit proposal feature is only available to the Admin/Author.

Seems to me that being able to evolve a proposal in response to discussion is crucial to finding consensus. Can I suggest instead replacing the 'edit proposal' button available only to admin/ author with a 'fork proposal' button available to all participants in the group?

That way the original proposal and any votes on it would still be visible, and the new proposal could be voted on in parallel. So to take this proposal as an example, I would be able to 'fork' this proposal to add my suggestion about 'fork proposal' button (oh dear this is getting recursive ;).

Ideally, there would be a 'merge proposal' feature too. Again, using this thread as an example, Richard's proposal and my proposal could be merged into a third proposal:
"remove edit proposal button and replace with merge proposal button"

Not sure how you'd visualise all this though :)

Love the forking proposals idea, in theory it's not too difficult to implement but UI wise it could be a mess.

There is an interim workaround where you could just start another discussion and consider it a subdiscussion and the proposal a subproposal. (Which hints as to how this could be implemented)

Addressing the initial proposal though I think anything that changes a proposal's story (/history) is the wrong approach. Disabling an edit button after a proposal has votes would be fine short term.

The interface is the challenge alright ;)

One way to simplify things would be to reduce the number of options. Saying 'no' is effectively abstaining unless you block, and abstaining is effectively saying 'no but I won't block', otherwise you'd say 'yes', right? I suggest removing the 'block' vote, leaving:
Yes (I agree)
Abstain (don't agree, but will go with the group)
No (I don't agree, and wish to discuss further or suggest something else)

There are two main styles of consensus, one of which allows blocks, the other does not. For example, the Permaculture in NZ Constitution says:
"Consensus is an agreement to reach agreement. If a person does not agree he/she must [be at work with] an alternative proposal. Consensus is not to be used as a veto or as an obstruction to business."

With these three options, a group like PINZ could interpret a 'no' as a strong objection suggesting the need for further discussion or modification of the proposal. Groups which allow blocks could treat a 'no' as a block, and those not wishing to block could abstain.

If the goal of Loomio is to facilitate inclusive consensus, it occurs to me that a person making a 'no' vote should be required to fork the proposal, and a person making an 'abtain' vote should be encouraged to fork the proposal. A possible ways to visualize this:
1) A 'block' vote comment is a link to the fork proposal created by the person blocking (the same for any forked proposal created by a person abstaining).
2) Links to fork proposals could be included in the pie chart in place of 'block' votes. If a second person blocks, they can either add their support to the first person's fork proposal, or create their own (perhaps as a merge of the original and the fork?)

I would also suggest ordering the vote comments under the pie chart from, starting with 'no', then 'abstain', then 'yes'. This emphasizes the nature of any dissensus around the issue which needs to be dealt with in order to find full consensus.

Note: as I've said before, it would be a handy feature to be able to configure Loomio for different group processes. Now we have identified:
1) consensus - no blocks
2) consensus - allowing blocks
3) majority rules - usually no blocks
and potentially
4) majority rules - allowing blocks (probably not worth implementing until a group who uses such a process comes along)
There may be other group processes Loomio could work with.

I love what you are saying Strypey, Some customer feedback I have received is exactly on this idea that if you are blocking you shuld also be working on providing a solution,or working with others to find improvements in what is suggested,
I would love to see us define 4 cards like this<
yes
abstain, I have questions, and need more information before deciding
no, I disagree but OK with going with the group decision
block, dont agree, and wish to discuss further or suggest something else.

I suspect this is not exactly on topic but great it came up

+1 to forcing someone to create a new proposal if they block

I think a pop-up warning and strong group culture around when to edit/not-edit proposals is a better way of doing things than enforcing something harsh like this. What about when someone makes a typo? I'd say a better solution would just be to make it very obvious that the author has edited the proposal, along with version history so you can see what the changes were.

Process point: there are a lot of other conversations regarding bigger issues being brought into discussion which is meant to be focused specifically on editing proposals. Maybe those other topics deserve their own discussion thread? I have a lot to say in response to Strypy's comments but I don't think they belong in this thread.

Regarding editing proposals, I think the best solution would be to remove the edit feature and force people to create new proposals. Otherwise it's very unfair to people who stated a position based on one thing, but are being represented by something different after editing. If the proposal needs to change, there should be a new one.

I think issues such as clarifications and typos can be fixed by making comments in the discussion or editing the context panel (when we have that). If a proposal is poorly formed (unclear, incorrect info, etc) people should not say yes on it and it should fail so a better one can be raised.

Forking and merging proposals is an interesting idea, but one that will require a lot more thought and discussion to implement well.

With the feature as it is right now, we are introducing bad process to group decision making. There have been a couple examples lately in the 19 Tory St group of proposals changing significantly after I've stated my position on them.

I'm sure there is a good way to do editing, I'm just suggesting that the way he have it set up right now does more harm than good and should be disabled until we've found a better one.

Alternatively, if people think it would be better to keep the Edit Proposal function but add an Alert feature so that it's super obvious and highlighted when the proposal is edited (and maybe sends a notification to everyone who's already stated their position). Thoughts?

So there currently is a pop-up warning already (implemented a few days ago).

Ben is going to edit the text of it. I personally think this could suffice until we improve the edit functionality (make it very obvious that the proposal has been edited and potentially email everyone who has already stated their postion).

But if you guys would rather remove the functionality for now I'm happy to go along with it. Consider my "no" to be soft and flexible. =)

I think keeping the edit history clear in the timeline and notifying everyone who's voted will keep the proposal story in tact and is a good solution.

Does make for a nicer way to add clarification etc.

I still don't like the idea that a proposal could be changed in the last few minutes and everyone's votes remain in tact. Short term could you atleast disable the edit button for the last x amount of time?

I think long term Strypey's idea would be amazing to see in action.

The popup is better than nothing but IMHO inelegant like a poke in the eye. At very least if we're keeping this feature I think having a notification in the timeline is a prerequisite.

I would suggest that we allow editing for the first 15 minutes after a proposal is created to catch any typos obvious errors and then disable it after that - clean simple solution for now.

If I could fork the current proposal I would...

@Viv, this is something that's already been problematic at Tory St, so will definitely be a problem for other groups.

I agree with Paul that just making it super obvious when a proposal is edited (highlighted in the discussion thread, edited text is highlighted in the proposal details, and a notification is sent out) is the best solution.

Can I suggest closing the current proposal and reopening it with this idea?

I feel we are suffering from the tyranny of the status quo on this one: the feature exists so we are keen to let it stay, even though the UX is bad.

I made a new proposal as per suggestions.

I think it is dumb and we should just kill the feature until we have specced it out properly but I'd be happy if we at least get this change made.

mmm I would have liked to see the result of the last proposal without it being closed. It seems closing the proposal prematurely is almost as bad as editing it. Once someone votes it seems quite logical to disallow editing from then on.

This feels like a micro example of what a multi proposal discussion could look like where individuals take proposals and improve them and people shift their votes to the one that they like the most.

In this case you can see me forking the disable one saying let's disable it after a certain time and then alanna goes and forks that by adding in after someone has voted as well.

I can start to see how fluid and dynamic this could be if it was easy for an individual to click a fork/ammend proposal button and then for users to quickly get an overview of all the proposals on the table.

I can also see how that could scale out to threaded loomios for complex decisions (think writing a piece of legislation)

The time-limited edit proposal function would be a step up from what we have now, but the downside is that it doesn't allow for dynamic proposal-editing through the discussion (which might have actually been pretty useful in this very discussion, rather than closing and re-opening) -

I think changing the proposal in response to new developments in the discussion is an important thing (encouraging the group to end up at a proposal that's better than the one they began with), and that it's only problematic if it's not transparent.

Thoughts?

There are two reasons a proposal gets edited:

1) you made a typo
2) the proposal has evolved.

Case 1 is no big deal; it can easily be accommodated by allowing edits only until the first vote has been cast or until a timer runs out.

Case 2 though is way harder to deal with. What does it mean to edit a proposal after someone has already stated their opinion on it? I'm sure there's a place for features like forking, merging, & concurrent proposals to handle Case 2. I think it is going to be a significant challenge to get this working.

The point is, right now I think the feature is worse than nothing. If we disable the edit feature (either entirely or only after the first vote has been cast), then Case 2 is handled by closing the proposal and starting a new one. Proposals are cheap, this seems to be a perfectly logical place to start.

The way it currently works is super bung. Let's say someone's stated position is "No, but I will agree with this if you change X to Y", then once you have edited the proposal they have to come in and change their position. At the same time you've added a question mark to all the Yes's your proposal has already received, so they may have to change their positions too. At the very least they should all be notified. (In many cases you can assume that everyone will agree with you but that is an inherently centralised decision for one person to make.) In other words, it's just as much work to close and start a new proposal as it is to edit one fairly.

The final solution to Case 2 is likely many iterations away. I don't really understand the attachment to the current (IMO) broken feature.

Richard does make a good point. Even sending a notification that the proposal has changed is still problematic. The reason being that, as Richard says, it puts all of the existing positions in an ambiguous state, which is not very fair to the users.

I reckon the 15 minute limit sounds like a good idea for now. And in the future we can think about better ways to deal with this (e.g. forking, etc.).

(i've come around)

I'm kinda torn between the two, but having read the discussion so far I think disabling after 15 min is the "least worse" option.

It's just going to make proposals really rigid until something forkingish arrives.

Think about it this way: in an alternate universe where the 'edit proposal' button didn't exist, if I proposed to add it, everyone would agree it was a dumb idea.

Hey guys - hope you don't mind me putting up a few ideas I had while reading through...

Closing a proposal and starting a new one seems to be the most logical option for evolving a "proposal chain" as the discussion drives consensus or other options on an issue (Richard's Case 2 below). Previous votes are still visible and nobody is left with an ambiguous or conflicting vote because the proposal has changed. One possible way to make this more obvious I thought might be helpful would be to bring the previous proposals up as condensed tabs (which can be expanded) underneath the proposals chart but above the individual proposals so the chain of evolution is clearly visible, as well as being viewed without navigating away from the current page.

Editing a proposal before the first vote is cast/15min sounds good for correcting typos as Richard mentioned in Case 1 below.

The forking idea for evolving a proposal rather than editing sounds cool but leads to new questions like 'are two proposals mutually exclusive?', does a yes on proposal one reflect a no on proposal two. In the case here the two proposals in this discussion would be mutually exclusive - making edits more prominent implies that edits are not disabled. This seems like it could be simplified into one proposal with a forked set of options - either make the edits more prominent or disable them altogether.

When proposals are closed, I'd love to see a little summary appear in the discussion feed. It might list the proposer, the duration, whether it was closed early, and a little pie chart.

@James - awesome to get your input here, please keep it coming! And feel free to encourage others in your group to get involved too!

Can I suggest having a list of closed proposals above the current proposal? This gives users a history of what proposals the discussion has produced at a glance, before they start evaluating the new proposal. Even better would be making it an expandable list, where clicking on a closed proposal brings up the contact, pie chart and the positions people took.

James said:

The forking idea for evolving a proposal rather than editing sounds cool but leads to new questions like 'are two proposals mutually exclusive?', <<

Forking proposals would be where they are mutually exclusive, as in this discussion. Where they are not mutually exclusive, it would make more sense to me to fork the discussion, so there is a separate comment thread on each proposal.

This is more "blue skies" thinking from me, but would be cool to have a way to link multiple proposals and/or comments in multiple discussions, to illustrate that they are connected/ dependent on each other in some way.

Agree with Strypey and James that making the closed proposals visible from the top would give added context to the current proposal. Maybe implemented with some sort of tab styling. We have been thinking of adding an icon and count of closed proposals to the previews on the dash also. Seem to be getting into one of those forked discussions being talked about so I will stop.

Sorry for being such a stick in the mud here, but I'm actually still not convinced.

People tend to vote on proposals pretty quickly. So I would imagine that from the time you click "edit proposal", make your changes, and then click "save changes", someone else could very likely have already voted, and the application would stop you from making the changes.

It seems like a really weird flow to be honest -- an interim solution which probably isn't worth the development time.

I've pretty much come full circle around to Rich's perspective. The current functionality is broken. Why don't we axe the feature and it'll put pressure on us to figure out how to implement it correctly? Either that or we leave it as is until we can come up with something that is actually better (instead of just a weird hack).

My main point is... I don't think it's worth the time or effort time code a half-developed feature idea. I think we should flesh this thing out and do it properly. And if we decide that we have to get rid of the button in the meantime I'm okay with that.

(As usual, if the group decides that they want to go along with this proposal for now, I'm happy to defer to the group.)

KILL THE FEATURE

I would go along with simply killing the feature

I love it that the most contentious discussion we've had yet is also one of the least important!

Do people feel it's time to close this proposal down and fire up a brutal feature killing proposal in its place?

I'm very happy to if so!

If we were living in a village setting we'd all be at The Feature's door with pitchforks and flaming torches right now

I do agree the feature is broken but now that it's there I do want to be able to preview a proposal and have a minute or two to change it, sometimes you just need to add a couple like breaks to make something more readable that's not clear when you're editing a text box.

Even if forking proposals was implemented I think having a few minutes to double check your formatting and spelling is actually good practice.

@Ben - this is a well-documented phenomenon and was mentioned in the book I've been reading on managing an open-source project.

http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

Hey look, auto-linking doesn't work on apostrophe's! =(

Paul how about a 'Preview proposal' button? I reckon we're going to want a Preview Comment button when markdown gets implemented anyway :)

+1 Preview buttons.

My suggestions:
* Clicking 'edit proposal' automatically closes the current proposal, and when the edited version is saved, creates a new one
* Move the 'closed proposal' box to the top of the proposal column
* List only closed proposals which at least one person has taken a position on (when proposal is edited to fix typos, improve sense of text etc, the auto-closed proposal is just clutter)

I actually disagree that this discussion is trivial. There's been a lot of good discussion about how the design of Loomio can facilitate productive discussion, and sound decision-making.

I'm happy to just kill the feature until something better is ready - if you make a typo just close proposal and copy/paste/edit

A preview proposal button would definitely be nice, I'm fine with killing the feature short term till we've got a proper solution too.

Regarding the timed edits there could be an option on a new proposal for a 5-15? minute window before it is actionable (you could even delay the notification e-mail being sent), so when a proposal is posted it's in an editable unvotable state for the period of user review.

I also wonder if Papertrail might be good for this, could have like version controlled Proposals... on second thought it's probably overkill again but worth mentioning.

The edit button does seem trivial but I think it hits an underlying question of discussion/proposal authenticity vs user experience.

I am liking this idea of Pauls now. I feel we should not do a quick fix and think that a good solution is not that far away. We have some good ideas here and are best to nail it while this is all current. I am changing my position to abstain on this proposal in favor of a new proposal based on a non-actional window where the proposal can be talked about in the discussion and editable by the author.