Loomio
Sat 4 Aug 2012 10:24PM

Editing Proposals

RDB Richard D. Bartlett Public Seen by 106
RDB

Richard D. Bartlett Sat 4 Aug 2012 10:24PM

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.

RDB

Poll Created Sat 4 Aug 2012 10:25PM

Remove 'edit proposal' feature Closed Mon 6 Aug 2012 9:53PM

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

[I just edited the proposal as a test.]

Results

Results Option % of points Voters
Agree 57.1% 4 AI AT BK MB
Abstain 28.6% 2 JV VM
Disagree 14.3% 1 JL
Block 0.0% 0  
Undecided 0% 893 RG RDB NW SW MT AC CWH G DS RF AR AC HM C J DB DMA RM KA LG

7 of 900 people have voted (0%)

JV

Joshua Vial
Abstain
Sun 5 Aug 2012 10:32PM

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

JL

Jon Lemmon
Disagree
Sun 5 Aug 2012 10:51PM

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.

AI

Alanna Irving
Agree
Mon 6 Aug 2012 12:27AM

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

BK

Benjamin Knight
Agree
Mon 6 Aug 2012 2:03AM

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

VM

vivien maidaborn
Abstain
Mon 6 Aug 2012 9:17AM

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

AT

Aaron Thornton
Disagree
Mon 6 Aug 2012 9:23PM

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

AT

Aaron Thornton
Agree
Mon 6 Aug 2012 9:26PM

Rethink

RDB

Poll Created Mon 6 Aug 2012 9:55PM

Make edits more prominent Closed Tue 7 Aug 2012 11:22AM

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

Results Option % of points Voters
Agree 33.3% 2 BK MB
Abstain 16.7% 1 JL
Disagree 50.0% 3 JV AI AT
Block 0.0% 0  
Undecided 0% 893 RG RDB NW AC CWH JG RW MS G AR AC DB CR J JT DMA RM S LG ML

6 of 899 people have voted (0%)

MB

Matthew Bartlett
Agree
Mon 6 Aug 2012 10:26PM

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

JL

Jon Lemmon
Abstain
Mon 6 Aug 2012 10:51PM

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.

AI

Alanna Irving
Disagree
Mon 6 Aug 2012 11:16PM

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

JV

Joshua Vial
Disagree
Mon 6 Aug 2012 11:27PM

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

BK

Benjamin Knight
Agree
Tue 7 Aug 2012 12:07AM

best interim solution before forking is developed

AT

Aaron Thornton
Disagree
Tue 7 Aug 2012 10:48AM

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

BK

Poll Created Tue 7 Aug 2012 10:12PM

That the 'edit proposal' feature be disabled once the first person has stated their position Closed Fri 10 Aug 2012 10:16PM

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

Results Option % of points Voters
Agree 36.4% 4 JV AI DS PS
Abstain 36.4% 4 AT BK AC VM
Disagree 27.3% 3 JL RDB MB
Block 0.0% 0  
Undecided 0% 889 RG NW JC CWH BH G JG DS MS RF N AC HM C J SZ DB CR J JT

11 of 900 people have voted (1%)

BK

Benjamin Knight
Agree
Tue 7 Aug 2012 10:34PM

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

VM

vivien maidaborn
Agree
Wed 8 Aug 2012 12:44AM

can we move on now?

RDB

Richard D. Bartlett
Agree
Wed 8 Aug 2012 2:58AM

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

DS

Danyl Strype
Agree
Wed 8 Aug 2012 6:38AM

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.

JV

Joshua Vial
Agree
Wed 8 Aug 2012 7:00AM

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

JL

Jon Lemmon
Disagree
Wed 8 Aug 2012 10:47PM

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

RDB

Richard D. Bartlett
Disagree
Thu 9 Aug 2012 1:25AM

KILL THE FEATURE

MB

Matthew Bartlett
Disagree
Thu 9 Aug 2012 2:22AM

I agree with JL

AT

Aaron Thornton
Abstain
Thu 9 Aug 2012 11:47PM

See my latest comment

BK

Benjamin Knight
Abstain
Thu 9 Aug 2012 11:54PM

See Aaron's last comment

VM

vivien maidaborn
Abstain
Fri 10 Aug 2012 6:45PM

Happy for others to decide

AC

Andrew Cobb
Abstain
Fri 10 Aug 2012 10:16PM

Happy for others to decide.

AI

Poll Created Fri 10 Aug 2012 11:30PM

Kill the feature Closed Mon 13 Aug 2012 11:51PM

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

Results Option % of points Voters
Agree 100.0% 7 JV JL AI RDB BK MB PS
Abstain 0.0% 0  
Disagree 0.0% 0  
Block 0.0% 0  
Undecided 0% 892 RG KC MT JC AT CWH BH G JG RW G RF N AR J SZ DB J DS DMA

7 of 899 people have voted (0%)

RDB

Richard D. Bartlett
Agree
Fri 10 Aug 2012 11:48PM

Muhahahah

PS

Paul Smith
Agree
Sat 11 Aug 2012 5:26AM

Burn it and respec

BK

Benjamin Knight
Agree
Sat 11 Aug 2012 5:35AM

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

AT

Aaron Thornton Sat 4 Aug 2012 10:43PM

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.

DS

Danyl Strype Sat 4 Aug 2012 10:54PM

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

PS

Paul Smith Sun 5 Aug 2012 12:20AM

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.

DS

Danyl Strype Sun 5 Aug 2012 2:32AM

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.

VM

vivien maidaborn Sun 5 Aug 2012 7:44AM

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

JV

Joshua Vial Sun 5 Aug 2012 10:32PM

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

JL

Jon Lemmon Sun 5 Aug 2012 10:48PM

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.

AI

Alanna Irving Mon 6 Aug 2012 12:26AM

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.

RDB

Richard D. Bartlett Mon 6 Aug 2012 1:46AM

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.

BK

Benjamin Knight Mon 6 Aug 2012 2:09AM

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?

JL

Jon Lemmon Mon 6 Aug 2012 2:40AM

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

PS

Paul Smith Mon 6 Aug 2012 7:24AM

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.

RDB

Richard D. Bartlett Mon 6 Aug 2012 10:07AM

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.

JV

Joshua Vial Mon 6 Aug 2012 12:16PM

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

BK

Benjamin Knight Mon 6 Aug 2012 8:59PM

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

RDB

Richard D. Bartlett Mon 6 Aug 2012 9:53PM

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.

RDB

Richard D. Bartlett Mon 6 Aug 2012 9:57PM

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.

AT

Aaron Thornton Mon 6 Aug 2012 10:08PM

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.

JV

Joshua Vial Mon 6 Aug 2012 11:35PM

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)

BK

Benjamin Knight Tue 7 Aug 2012 1:50AM

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?

RDB

Richard D. Bartlett Tue 7 Aug 2012 4:35AM

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.

JL

Jon Lemmon Tue 7 Aug 2012 6:38AM

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

JL

Jon Lemmon Tue 7 Aug 2012 6:38AM

(i've come around)

PS

Paul Smith Tue 7 Aug 2012 7:05AM

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.

RDB

Richard D. Bartlett Tue 7 Aug 2012 8:56AM

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.

JM

James McCann Tue 7 Aug 2012 11:52AM

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.

MB

Matthew Bartlett Tue 7 Aug 2012 10:20PM

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.

BK

Benjamin Knight Tue 7 Aug 2012 10:38PM

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

DS

Danyl Strype Wed 8 Aug 2012 6:46AM

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.

AT

Aaron Thornton Wed 8 Aug 2012 9:15AM

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.

JL

Jon Lemmon Wed 8 Aug 2012 10:47PM

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

JL

Jon Lemmon Wed 8 Aug 2012 10:48PM

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.

JL

Jon Lemmon Wed 8 Aug 2012 10:50PM

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

RDB

Richard D. Bartlett Thu 9 Aug 2012 1:16AM

KILL THE FEATURE

AI

Alanna Irving Thu 9 Aug 2012 1:38AM

I would go along with simply killing the feature

BK

Benjamin Knight Thu 9 Aug 2012 2:37AM

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!

BK

Benjamin Knight Thu 9 Aug 2012 2:38AM

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

PS

Paul Smith Thu 9 Aug 2012 3:13AM

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.

JL

Jon Lemmon Thu 9 Aug 2012 4:13AM

@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

JL

Jon Lemmon Thu 9 Aug 2012 4:13AM

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

RDB

Richard D. Bartlett Thu 9 Aug 2012 9:59AM

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

DS

Danyl Strype Thu 9 Aug 2012 1:06PM

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

JV

Joshua Vial Thu 9 Aug 2012 8:35PM

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

PS

Paul Smith Thu 9 Aug 2012 10:59PM

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.

AT

Aaron Thornton Thu 9 Aug 2012 11:46PM

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.