Loomio
August 4th, 2012 22:24

Editing Proposals

Richard D. Bartlett
Richard D. Bartlett Public Seen by 106
Richard D. Bartlett

Richard D. Bartlett August 4th, 2012 22:24

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.

Richard D. Bartlett

Richard D. Bartlett started a proposal August 4th, 2012 22:25

Remove 'edit proposal' feature Closed 11:53pm - Monday 6 Aug 2012

The 'edit proposal' button should be disabled once the first votes have been cast.

[I just edited the proposal as a test.]

Results
Agree - 4
Abstain - 4
Disagree - 4
Block - 4
7 people have voted (0%)
Aaron Thornton

Aaron Thornton August 4th, 2012 22:43

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.

Danyl Strype

Danyl Strype August 4th, 2012 22:54

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 :)

Paul Smith

Paul Smith August 5th, 2012 00:20

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.

Danyl Strype

Danyl Strype August 5th, 2012 02:32

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.

Matthew Bartlett

Matthew Bartlett
Agree
August 5th, 2012 05:09

 vivien maidaborn

vivien maidaborn August 5th, 2012 07:44

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

Joshua Vial

Joshua Vial August 5th, 2012 22:32

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

Joshua Vial

Joshua Vial
Abstain
August 5th, 2012 22:32

I can live with either disabling it or just having the alert aaron mentioned.

Jon Lemmon

Jon Lemmon August 5th, 2012 22:48

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.

Jon Lemmon

Jon Lemmon
Disagree
August 5th, 2012 22:51

To me this seems quite harsh on the users and potentially frustrating if someone made a typo or just wants to make a couple sentences more clear. It doesn't seem like a black-and-white issue to me. I'm happy for someone to change my mind though.

Alanna Irving

Alanna Irving August 6th, 2012 00:26

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.

Alanna Irving

Alanna Irving
Agree
August 6th, 2012 00:27

This needs to happen, otherwise people will be shown as having a position on something they haven't had a chance to consider because it's been changed since they voted

Richard D. Bartlett

Richard D. Bartlett August 6th, 2012 01:46

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.

Benjamin Knight

Benjamin Knight
Agree
August 6th, 2012 02:03

Definitely keen for this to happen! But very open to hearing alternative ideas for getting the same result

Benjamin Knight

Benjamin Knight August 6th, 2012 02:09

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?

Jon Lemmon

Jon Lemmon August 6th, 2012 02:40

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. =)

Paul Smith

Paul Smith August 6th, 2012 07:24

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.

 vivien maidaborn

vivien maidaborn
Abstain
August 6th, 2012 09:17

feels like we are putting a huge amount of energy into a 'high risk' low liklihood of happening category. Seems to me everyone agrees its just priioritising it

Richard D. Bartlett

Richard D. Bartlett August 6th, 2012 10:07

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.

Joshua Vial

Joshua Vial August 6th, 2012 12:16

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...

Benjamin Knight

Benjamin Knight August 6th, 2012 20:59

@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?

Aaron Thornton

Aaron Thornton
Disagree
August 6th, 2012 21:23

As long as the change is recorded and transparent. I dont see this removing admin functionality as an issue

Aaron Thornton

Aaron Thornton
Agree
August 6th, 2012 21:26

Rethink

Richard D. Bartlett

Richard D. Bartlett August 6th, 2012 21:53

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.

Richard D. Bartlett

Richard D. Bartlett started a proposal August 6th, 2012 21:55

Make edits more prominent Closed 1:22pm - Tuesday 7 Aug 2012

When a proposal has been edited, the changes should be announced in some way, e.g. in the timeline, in the proposal itself, as a notification, and/or optional email.

Results
Agree - 2
Abstain - 2
Disagree - 2
Block - 2
6 people have voted (0%)
Richard D. Bartlett

Richard D. Bartlett August 6th, 2012 21:57

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.

Aaron Thornton

Aaron Thornton August 6th, 2012 22:08

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.

Matthew Bartlett

Matthew Bartlett
Agree
August 6th, 2012 22:26

This is okay; but I prefer Josh's 15-minute suggestion.

Jon Lemmon

Jon Lemmon
Abstain
August 6th, 2012 22:51

Hmm, sounds like you're not actually happy with this proposal. Why not Josh's idea about a 15 minute time-limit? I'd be happy to compromise with that.

Alanna Irving

Alanna Irving
Disagree
August 6th, 2012 23:16

I think a better solution is to not allow edits at all after a certain time or after someone has voted

Joshua Vial

Joshua Vial
Disagree
August 6th, 2012 23:27

+1 to disabling edits after a certain time limit or after someone has voted.

Joshua Vial

Joshua Vial August 6th, 2012 23:35

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)

Benjamin Knight

Benjamin Knight
Agree
August 7th, 2012 00:07

best interim solution before forking is developed

Benjamin Knight

Benjamin Knight August 7th, 2012 01:50

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?

Richard D. Bartlett

Richard D. Bartlett August 7th, 2012 04:35

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.

Jon Lemmon

Jon Lemmon August 7th, 2012 06:38

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.).

Jon Lemmon

Jon Lemmon August 7th, 2012 06:38

(i've come around)

Paul Smith

Paul Smith August 7th, 2012 07:05

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.

Richard D. Bartlett

Richard D. Bartlett August 7th, 2012 08:56

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.

Aaron Thornton

Aaron Thornton
Disagree
August 7th, 2012 10:48

I am feeling users need to be notified or a new proposal started

James McCann

James McCann August 7th, 2012 11:52

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.

Benjamin Knight

Benjamin Knight started a proposal August 7th, 2012 22:12

That the 'edit proposal' feature be disabled once the first person has stated their position Closed 10:16am - Saturday 11 Aug 2012

Context: At the moment, the person making a proposal can edit it right up until it closes, without any notifications or visibility in the discussion.

This means that people might agree to one thing, then come back to the discussion to find that the proposal has substantially changed, possibly into something they wouldn't have agreed with.

This has already been problematic in some of the 19 Tory St discussions, despite the pop-up warning that's already implemented.

Allowing proposal editing up until the first person has stated their position is proposed as an interim solution, until we can figure out a smooth way of forking proposals.

This seems less arbitrary than a 15-minute cut-off, and more relevant to the process (since it's only problematic/misleading to edit the proposal after a position has been stated), and allows for the fixing of typos or addition of context soon after the proposal has been put up.

Results
Agree - 4
Abstain - 4
Disagree - 4
Block - 4
11 people have voted (1%)
Matthew Bartlett

Matthew Bartlett
Agree
August 7th, 2012 22:18

Matthew Bartlett

Matthew Bartlett August 7th, 2012 22:20

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.

Benjamin Knight

Benjamin Knight
Agree
August 7th, 2012 22:34

I'm thinking that pop-up+visibility is a pain to implement and still isn't enough - I think this is the best interim solution

Benjamin Knight

Benjamin Knight August 7th, 2012 22:38

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

Andrew Cobb

Andrew Cobb
Agree
August 7th, 2012 22:45

Aaron Thornton

Aaron Thornton
Agree
August 7th, 2012 22:57

Paul Smith

Paul Smith
Agree
August 7th, 2012 23:29

 vivien maidaborn

vivien maidaborn
Agree
August 8th, 2012 00:44

can we move on now?

Alanna Irving

Alanna Irving
Agree
August 8th, 2012 00:51

Richard D. Bartlett

Richard D. Bartlett
Agree
August 8th, 2012 01:06

Richard D. Bartlett

Richard D. Bartlett
Agree
August 8th, 2012 02:58

Happy with this but would prefer we remove it entirely til we've built a proper feature

Danyl Strype

Danyl Strype
Agree
August 8th, 2012 06:38

I support this as a short-term fix. Sounds like it will be fairly trivial to implement, and incorporates most of the points raised in the discussion.

Danyl Strype

Danyl Strype August 8th, 2012 06:46

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.

Joshua Vial

Joshua Vial
Agree
August 8th, 2012 07:00

Sounds like a plan, just consider the use case where an admin clicks edit, someone votes, then admin clicks save.

Aaron Thornton

Aaron Thornton August 8th, 2012 09:15

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.

Jon Lemmon

Jon Lemmon August 8th, 2012 22:47

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).

Jon Lemmon

Jon Lemmon
Disagree
August 8th, 2012 22:47

See my latest comment. (Sorry for being such a stick in the mud!)

Jon Lemmon

Jon Lemmon August 8th, 2012 22:48

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.

Jon Lemmon

Jon Lemmon August 8th, 2012 22:50

(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.)

Richard D. Bartlett

Richard D. Bartlett August 9th, 2012 01:16

KILL THE FEATURE

Richard D. Bartlett

Richard D. Bartlett
Disagree
August 9th, 2012 01:25

KILL THE FEATURE

Alanna Irving

Alanna Irving August 9th, 2012 01:38

I would go along with simply killing the feature

Matthew Bartlett

Matthew Bartlett
Disagree
August 9th, 2012 02:22

I agree with JL

Benjamin Knight

Benjamin Knight August 9th, 2012 02:37

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!

Benjamin Knight

Benjamin Knight August 9th, 2012 02:38

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

Paul Smith

Paul Smith August 9th, 2012 03:13

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.

Jon Lemmon

Jon Lemmon August 9th, 2012 04:13

@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

Jon Lemmon

Jon Lemmon August 9th, 2012 04:13

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

Richard D. Bartlett

Richard D. Bartlett August 9th, 2012 09:59

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

Danyl Strype

Danyl Strype August 9th, 2012 13:06

+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.

Joshua Vial

Joshua Vial August 9th, 2012 20:35

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

Paul Smith

Paul Smith August 9th, 2012 22:59

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.

Aaron Thornton

Aaron Thornton August 9th, 2012 23:46

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.

Aaron Thornton

Aaron Thornton
Abstain
August 9th, 2012 23:47

See my latest comment

Benjamin Knight

Benjamin Knight
Abstain
August 9th, 2012 23:54

See Aaron's last comment

 vivien maidaborn

vivien maidaborn
Abstain
August 10th, 2012 18:45

Happy for others to decide

Andrew Cobb

Andrew Cobb
Abstain
August 10th, 2012 22:16

Happy for others to decide.

Alanna Irving

Alanna Irving started a proposal August 10th, 2012 23:30

Kill the feature Closed 11:51am - Tuesday 14 Aug 2012

Proposing we simply remove the edit proposal feature all together until we can consider and test it properly and re-implement something that addresses all the issues brought up in this discussion.

If people need to change a proposal, they can simply close it and raise a new one as a workaround for now.

Results
Agree - 7
Abstain - 7
Disagree - 7
Block - 7
7 people have voted (0%)
Richard D. Bartlett

Richard D. Bartlett
Agree
August 10th, 2012 23:48

Muhahahah

Jon Lemmon

Jon Lemmon
Agree
August 11th, 2012 05:22

Paul Smith

Paul Smith
Agree
August 11th, 2012 05:26

Burn it and respec

Benjamin Knight

Benjamin Knight
Agree
August 11th, 2012 05:35

Keen for the feature to die, and a glorious preview button to emerge from its ashes

Matthew Bartlett

Matthew Bartlett
Agree
August 11th, 2012 22:37

Alanna Irving

Alanna Irving
Agree
August 12th, 2012 07:39

Joshua Vial

Joshua Vial
Agree
August 12th, 2012 12:06