Author's view:

Everyone else's view:

I think @vivienmaidabornloo could argue on the practical advantages of keeping discussions' integrity?

If we want to keep integrity, it means that we don't want to have someone writing a comment, another person replying to that comment and then the original poster deleting or editing his original comment. That's would disrupt the context of the discussion.

If integrity in important on Loomio, and I think it is, I would suggest that we are not allowed to edit or delete a comment after it's been replied to. In addition, I would block edits/deletes for comments that stay without replies for more than 24hours.

Not only this would keep discussions' integrity, but in my opinion, this would give words more power, comments more visibility, and posters more attention. When groups sit together and try to reach consensus, they usually speak in turn. Before your turn, you want to gather your thoughts so that what you say is going to stir the discussion in a direction that you're happy with. In this process, everyone has their moment. The value of what a person is saying is partly inherent to the fact that it can't be unsaid. It is their thoughtful contribution to an outcome that progressively emerges as everyone add their views into the mix. The evolving nature of a discussion implies that, of course, sometimes you will disagree with what you have said yourself at some earlier point in the discussion, but that's no big deal, and it probably added some value to the discussion anyway (e.g. people reacted to it…)

As it stands, I see various reasons why someone would like to edit/delete a comment:

• there are typos in it
• the author want to add some content for whatever reason
• the author want to rephrase some content for whatever reason
• the author want to delete some content for whatever reason

I think we should not enable these features without restrictions (e.g. until someone else posts) unless we can argue that at least one of these reasons justify disrupting the context of the discussion.

I'm not saying we should necessarily prioritise integrity over other aspects that are relevant here (privacy, flexibility for users to manage their data as they please), but I'm saying this needs more discussion.

Edit: this post was edited 3 times for typo and bad formatting.

My personal working definition of integrity is

acting in accordance with my values and ethics spontaneously - under pressure

So how does that relate to this conversation? I guess I think even if it doesn't come out right first time, I can always have another go.
In this discussion though I would focus on building a use culture about not changing posts if that changes meaning the of thread, but make it mechanically possible to do.
By the way. I think spelling mistakes are acts of sacred goddess of Random wisdom

Interessing @vivienmaidabornloo. I was actually referring to data integrity, which in simple terms means that the data (contributions / comments) remain consistent and reliable in its context (the discussion) through its entire life cycle. Funny how same words can have different meanings in different areas.

I was mentioning you here because I thought you wrote something about us being legally obliged to keep a complete history of people's contributions to discussions. It would potentially have been another reason to prevent people from altering old comments, but my main point was more to show the benefits of doing so.

@alannakrause and @nicolaswormser I really don't think abuse is a serious threat that we have to be vigilant against.

I'd actually prefer to have unlimited editing, and let the humans do the rest. I just put the 24hr limit in there to make @strypey happy :)

It's not about abuse, it's about confusion, and continuity of the conversation

@richarddbartlett I have to say I agree with @nicolaswormser and @alannakrause. Having been replied to is a condition I didn't think of in my original list of suggestions, and it makes a lot of sense.

The use case here is either:
a) a large organisation trying to make consensus decisions about mission-critical stuff
b) a small organisation with 2 or more strong factions, and a need for very rigorous decision-making to enable them to work together at all

In these cases, even the potential for someone to have rewritten older comments, creating work for others to check the current comment against a history, could be corrosive the to the trust required for consensus.

Just a few questions:

1. How many times have you had an experience on a forum where someone edited their post and it created a negative experience for you? For myself, since I started using forums in 2001 I can count on one hand the number of times where someone editing their own comment has been a problem.
2. Now how many times have you had a negative experience from posting something on a service that did not allow you to edit an erroneous comment that you made? For myself, I can think of many times in the past year alone.
3. How many times have you posted an erroneous comment to a service that allows you to edit your comment afterwards, and then been grateful that the feature exists? For me this happens regularly.

I really don't think editing comments will create a problem for the majority of groups that we're building Loomio for. We just need to provide an edit history so people can see what changed if they need to. And then communicate comment-editing etiquette to our users when they go to edit their comment.

If we implemented this feature it would be immediately useful. Let's put it in, and we can fix any problems it causes when and if they arise.

@jonlemmon I think edit histories of comment is over-engineering, and gave my reasons a few comments back (BTW comment numbers would be awesome!). Loomio is not a forum, it's a decision-making tool, and I value the ability to scroll down a discussion and understand at a glance how and why the accompanying proposals emerge. This can be very important to the comments or proposals I might make in a discussion, or the positions I might take on proposals in it. Comment histories nested into multiple comments would totally break that use case.

Seems like this result is indicating we could probably do better... can we come together and try to think of the best solution that accomplishes what @richarddbartlett is trying to do while taking into consideration the concerns people have raised?

I'd certainly be able to support this proposal if it is amended to take into account Jon Lemmon's point that "We just need to provide an edit history so people can see what changed if they need to." I think this is important in tracking conversations if it is ever needed (This would be very rare but I think in terms of integrity of the discussion it should be accessible if a post has been edited).

Also in terms of Richard's proposal I am unclear as to what he is meaning by the term "Comment authors" ... this may be a Loomio layout issue with a missing colon after the word "Comment" or it may be a term I am unfamiliar with as a Loomio newbie.

In writing up my position I came to the conclusion this should be an option decided by either each community, or the administrator of each community. The ideal would be to give various options which people administrating a Loomio community can change according to the needs of their community. For example someone using it in an informal way for a brainstorming a development will have different needs to those of a board of a social enterprise. Ideally it needs to be designed for both uses.

Thanks for your thoughts @neilmorris.

I'm nervous about giving people too many options, if it's at all possible to avoid. I'd prefer for us to collaboratively determine a good starting point, deploy it, and see how it performs in the field.

@Richard D. Bartlett Why are you nervous about giving people too many options? Why should there only be one way of doing things? How many options are too many?

In this situation having three different options, i.e. no edits, edits for a specific time period (which can be specified with a number of minutes or until the next comment), and unrestricted edits with the last two being with revision history would be my ideal.

Having flexibility on such issues improves the user experience. I'd prefer to have happier users of Loomio rather than users deciding it wasn't flexible enough for their needs.

@neilmorris every time you give someone a setting to configure, they have to learn what it is for and then do a cost/benefit analysis for each possible option.

When you have more than a few of these settings to configure for a group, that builds up to be a significant cognitive tax for the user, and a lot of design work and maintenance for the developer.

Personally, I prefer to use software that is opinionated (so long as I understand the reasoning behind the opinions).

@strypey @nicolaswormser I don't really understand what you're talking about :P

Like @jonlemmon said, in your experience of other online platforms, when has an edited comment ever caused you a problem?

Designing, building and maintaining any constraints on this feature just feels like overengineering to me as a developer, communicating those constraints to users sounds like a pain to me as a writer, being constrained by software is frustrating to me as a user, and it all just feels like it is coming from an untrusting place.

@richarddbartlett I've flagged two issues, a technical and a political. The technical issue relates to the potential for multiple versions of multiple comments to make for significantly larger pages, for minimal benefit. I'm not the expert in this domain though, so I'm going to leave this objection to others who may be able to comment with more specifics about whether or not I'm right.

The political issue is that Loomio is not a forum (which is precisely why I like it). It's not primarily a discussion tool, it's a decision-making tool. Specifically, it's a consensus tool, not a voting tool.

In general chit-chat systems like web forums, FB or Twitter, what's important is the current comments, not the history. However, for groups using Loomio, the discussion threads and proposals serve as the "minutes" of decision-making processes; they are an essential part of the institutional memory of the group. Understanding any given proposal, and the positions taken on it, will often require reviewing the full comment history leading up to and through the duration of the proposal. It's essential that these records cannot be altered on a whim,

I have seen a web forum where a grumpy user replaced every one of their comments with a fullstop before they left in a huff, breaking the flow of every discussion they were involved in on that forum. This is merely annoying on a public chit-chat forum, but when the discussion history being broken is part of the institutional history of an organisation...

@richarddbartlett I think @alannakrause and @nicolaswormser have made good arguments for the 'edit until new comment added' approach. You seem to be arguing that users should be trusted to edit their comments whenever they like. If this is the case, would you then support a proposal to allow users to change proposal texts whenever they like?

@alannakrause @strypey If someone is going to go back and edit their comment in a way that harms the discussion, that to me would be evidence of a social problem: e.g. the author is being manipulative or is feeling alienated.

I would prefer to solve that problem with social means: building a context that promotes honesty, trust, good faith, inclusion, etc.

To my mind, that kind of culture is created by being generous, open and flexible. Yes we can develop technical constraints to curb certain behaviours, but every constraint is going to curtail a certain amount of benign activity too.

One of the powerful things about consensus is that every participant has the power to block. Trusting everyone with that potentially disruptive power brings out the best in them. I believe that better behaviours emerge in more free systems.

Also it's less code :P

If we are building a system based on goodwill and trust, why shouldn't people just forgive each other's typos? Or be understanding when someone posts a new comment to clarify a misunderstanding from their last comment? Maybe I need to understand more about the use cases for needing to edit comments, because to me none that I can think of are as important as conversational integrity.

Even in completely benign situations, I don't want comments edited. For example person A says X, person B misinterprets as Y, person C comes along and explains to B that A meant X not Y. Everyone's happy and the comment flow makes sense.

But if person A then edits their comment to clearly say Y instead, then person B's comment looks silly/nonsequiter/random (at best) or argumentative (at worst) and anyone reading afterward would be confronted with a strong of comments that no longer make sense.

Thanks for updating the context panel @strypey - nice summary!

This is an interesting one - I think there are some good arguments on both sides, and that maybe it would be helpful to agree that what we're looking for is a starting point rather than a final solution.

I really like @neilmorris' suggestion of multiple comment editing options - if we had the development resources to put into it, I think giving group admins the option between a time-based and activity-based cut-off for comment editing and seeing how the feature is used in the field would be ideal. I don't think I share Rich's concern about giving admins too many options in this case, but I do appreciate that our resources are severely limited. Would be good to hear from some of the devs about how much extra development time this would take to put things in perspective - @jonlemmon , @robertguthrie ?

@strypey, I understand your concern about breaking the continuity of discussion, but in the abuse-of-feature scenario you described (the forum user who changed all their comments to full stops out of spite), wouldn't a history of comment edits have been sufficient to resolve the problems caused?

I think it's also good to keep in mind that users can currently delete their comments completely, and that we've never seen that feature abused, or had any problems with discussion continuity as a result.

@alannakrause from a user experience perpective, what you're suggesting is kind of a nightmare. Imagine spending time editing your comment, and then you click submit and you get an error saying there's been new activity and you can no longer edit your comment.

@jonlemmon, I think it's an interesting metric to be counting personal instances of editing problems on ones hand, but I think it's important to clarify the nature and purpose of the forums you're referencing.

Specifically, were any of them forums in which you were making impotant deccisions? [sic]

Suggestion: you can edit comments anytime but only to add to them, not delete or change what was already there. Would that be a good compromise?

Great for fixxing typos, and used responsibly, even better for really interesting, clearer discussions. an engaged community will spot abuse really fast, and comments should be marked as edited with date stamps.

I know the people advocating for this might be frustrated by the no's but I just want to point out that this is what Loomio is all about - I honestly trust the process and think if we stick with it we'll come up with something even better than the ideas that have been suggested so far, because we have differing viewpoints working together to solve the problem. Why can't we come up with something different and better than what's been done before?

This discussion reminds me of running a political campaign where you quickly achieve your first goal and so add to it, then never feel like you are achieving anything because it becomes too complex. I wonder about going back to the original job and seeing these bigger issues as a longer conversation?

Loomio works when people want to engage in good faith collaboration - if they don't then no amount of features or security mechanisms will make a discussion successful.

In my opinion, the tool should be optimised for the 99.9% of use cases when people wouldn't abuse it and then make the other 0.1% visible so moderators can deal with it however they see fit.

I think I might change my vote to yes if we implement this feature with a design where "EDITED" is super super obvious, like in a different color. In my experience on forums it's usually too subtle.

I do however think even if this does become the first iteration we should keep our minds open to new solutions in the future. Usually when this group disagrees there's some creative opportunity to be realized.

Totally agree Alanna, consider it done.

@jonlemmon >> Imagine spending time editing your comment, and then you click submit and you get an error saying there's been new activity and you can no longer edit your comment. <<

This would indeed be frustrating. One solution would be to allow any edit initiated before another comment is made. Knowing that this is the case would discourage major rewrites, and encourage people to only use it for to quickly fix typos, broken links, unfinished sentences etc

@benjaminknightloom >> I think it's also good to keep in mind that users can currently delete their comments completely, and that we've never seen that feature abused, or had any problems with discussion continuity as a result. <<

Currently, I only use this to delete comments so I can post an edited version, as above. I think this option also should be disallowed after a reply is made in the thread (and perhaps removed entirely once the edit features is available).

@joshuavial and others are focusing on malicious misuse of an edit feature, which I agree is an edge case. I think the real concern here is about confusing use, which is much more likely, especially in large organisations, where a proportion of users in the group at any given time are learning to use Loomio.

Consider this: is it wise to give every contributor to an open source project commit access to change their own code contributions at any time, since after all, open source projects only work with goodwill etc There are really good reasons that even the most open collaboration systems have strict rules which protect the integrity of their data (be it source code or documentation of decision-making processes).

Like I said I might change my position to go with the group, but the truth is I agree with Strypey :/ It's not about malicious use, it's about conversation flow.

@alannakrause I'm presuming the vast majority of edits will improve the conversation flow, that's why people make the changes.

The reason you guys want the edit feature is for convenience, but you don't consider that in the task of making decisions, there might be some much more important considerations to have.

I think the one, among others, that @strypey, @alannakrause and I are defending here is called coherence. But the picture is much larger than that...

I see discussions as an improvised collaborative wall painting in which the artists would get involved in without knowing what it's going to look like in the end. But as people step back and see what the others are painting on different parts of the wall, a shared vision of what the whole thing should look likes emerges. This continuous and iterative process of mutual observation and reflections will allow the unique result that will emerge from that, and all the artists will probably feel quite united to the work of the other artists, and to the artist themselves.
In this senario, if one of the artist would paint over what he'd had created before, this would confuse the other artists in their current perception of the coherence of the whole painting.

Think also to jam sessions in music, @joshuavial , think of choral improvisation and drums, they work the same way! (but the task is easier since it's technically impossible to unplay/unsing the sounds you create). The beauty of improvisation lies in the fact that it can not be edited. I think Loomio should be all about evolutive collaborative improvisation.

My guts are telling me that there is a great potential in trying to assess what makes a conversation worthwhile in non-virtual life and that enabling such complex mechanisms in Loomio might mean cutting down on a few liberties that technology is offering us, but only to get more freedom.

Yes, I feel so strongly about this that I will like my own comment.

I hear all the points about coherence of conversation but the 99% use case of an edit feature is to fix a comment just after you've made it and not to substantially change your message.

A simpler version might just be to timebox the edits so you can only change stuff in 15 min after posting as well as keeping the revision history.

the 99% use case of a helmet is it doesn't get used.

• explicitly, in maths-speak, for those who read:* Total_Goodness = Σ P(use case) * Outcome(use case)

where Outcome can be + or -

---

I suggest that while amendments may be something we want to do, this conversation is indicating that the current proposal is not the best way to progress.

the 99% use case of a helmet is it doesn't get used.

explicitly, in maths-speak, for those who read:

 Total_Goodness = Σ P(use case) * Outcome(use case)

where Outcome can be + or -

---

I suggest that while amendments may be something we want to do, this conversation is indicating that the current proposal is not the best way to progress.

Looking forward to the emergent solution that will jump out and satisfy everyone :)

I'm not imagining this to achieve everything at once, but how would people feel about a 'preview comment' feature, so people can opt-in to reviewing their comments before posting? Would go some way towards giving people an opportunity to catch typos etc. Does that sound like an ok starting point?

In any case, I don't think there's any pressing urgency on resolving this, and that it's great to have space for the discussion to play out.

@benjaminknightloom The Preview function sounds like an excellent idea. I can imagine after clicking the 'Preview' button, from the perspective of the user, the comment is posted as normal, but with a big 'PREVIEW' warning above or next to the name (and maybe a different background colour or border?). Other users don't see it until the 'Post Comment' button has been pressed to commit it. Before this, the user can edit if needed, by clicking an 'Edit Comment' button to the right of the 'Post Comment' button. How does this sound?

Perhaps @neilmorris is onto something. Allowing comment editing (with no history, just 'Edited') would be fine for a small, informal or ephemeral group, which needs to Loomio to work through urgent decisions now, and will seldom or never need to review past ones. For larger, more formal, and longer-term organisations, no comment editing would be better, and the preview option can provide for the use case for which comment editing was proposed (minor edits like typos etc).

I can't help thinking that a shared Preview box for shaping a proposal text before people start taking positions might help too. Some time back we thought the Context Box could do that, but it seems clear to me it is serving a different and incompatible function.

This discussion thread has become a high-tension space. I have felt some strong emotions about this discussion, and clearly some important design principles are being hashed out here.

Since nobody has objected to the Preview feature @benjaminknightloom proposed, perhaps he could put it up as a proposal in a separate Feature discussion? Assuming it passes consensus, once it is implemented, we can come back to this discussion and see if there is still a need to edit comments after posting. How does that sound?

I would only support a 'preview comment' feature, so people can opt-in to reviewing their comments before posting, if it's use was optional. I find them frustrating and that they use valuable time which I would prefer to use on other things! ....

This proposal is going for a position which is at one end of the continuum.

I think we need to have several proposals to reach a final consensus here.

Is the flow of decisions which need to be made more like:
1. should authors of comments be able to edit their comments;

If yes, the next proposal could be:
2. should we give groups that use loomio the option to choose the options which suit their group

If this is agreed then a proposal needs to be put as to the options to offer groups using Loomio
i.e. i) for ever;
ii) for a specific time (with the ability to specify the time);
iii) until the next comment is made;

If 2 isn't agreed then we need to have a series of proposals for how long authors of comments be able to edit their comments:

i) for ever;
ii) for a specific time;
iii) until the next comment is made;

Would such a series of proposal work?

I do agree with @strypey that some important design principles are being hashed out here, but also perhaps even more than that. To me it seems like it is a question of which direction does Loomio head in; does Loomio decide on the options, or does it facilitate groups that use Loomio to decide what works for them.

Thanks for acknowledging the tension @strypey, I've been meaning to take the time to do the same.

I thought it might be good to stop and look at this thread from one step back and go, hey this is a contentious issue, lets ignore the feature for a second and see what can we learn from the tension.

e.g. I think it's no coincidence that a lot of the Yes's are coming from people that spend a lot of time together, and are closely involved with the project. The Blocks are from people that don't spend time at 'headquarters'. That would indicate to me that one factor contributing to the polarisation could be that there is incomplete transfer of information going on.

In the office today we agreed to take some time next week to talk about our decision-making protocol and our design and development principles, so that proposals like this can be delivered in a more comprehensive context.

There has been extensive discussion about this feature in the office. It's been really informative and has shaped thinking a lot.

@neilmorris - any solution that is proposed or anything that is implemented will be refined and changed over time.

We're all in agreement about wanting feedback and collaboration on Loomio as it is built. A really important part of this process is listening before and after we make anything. Personally I am confident that even if we try something that isn't perfect, we have the capacity to build it well enough and implement solutions to any problems fast enough that they won't be significant problems.

@richarddbartlett that's a valuable insight.

FYI I'm still blocking on this because if the proposal were implemented as it stands, I would have to recommend a number of the groups I'm in to stop using Loomio, or propose a fork, either of which would be heart-breaking. I strongly recommend that this proposal be closed (I think this should have happened automatically, as I've said in the discussion on using blocks), and a more nuanced proposal made that integrates the various concerns and options in this thread.

@richarddbartlett Yes, I think it's time to close that proposal and share more of what @johnirving mentions has been discussed in the office before making a new one.

Or even let that simmer down for a few days before coming back to it.

Whatever implementation is decided, users obviously need to be able to edit their comments. I quite often make typos I'd like to correct.

I think this is really quite urgent. At present the only way to edit a comment with a mistake is to delete and re-post over and over. This sends out loads of emails to people, which then makes them think Loomio is just a spam engine. :(

I actually built this feature in a branch.. without permission/discussion with anyone else.. It's stting on github, people can edit their own comments and you can see a diff (exactly like on github) between the current and the previous comment. It won't be long before we have something in loomio to support this (I hope). We could even make it optional per group if there was serious contention.

@robertguthrie good skills! hopefully it comes here sooner rather than later! :)

btw @robertguthrie does your solution include previews too?

Nope, just edits with history/view changes. I would prefer to talk about the features independently I think.. I have trouble agreeing to the proposal currently.

OK, @robertguthrie @richarddbartlett I've made it one - even more specific - proposal :)

@robertguthrie could you please provide us with some screenshots of your existing implementation?

Great work on specifying the outcome of the previous proposal @josefdaviescoates

I was inclined to say "yes" to this, because it would solve the really annoying bug that people receive multiple notifications / emails as we delete and recreate comments. But after all, preventing the removal of old comments and pushing that "preview comment" feature would also solve the problem, and would provide more consistent discussions in my opinion.

But still, I think that an "edit before other reply" feature would be useful, and could avoid some frustration.

Just to say that we currently allow free editing of comments in Econsensus. I think the use will probably vary group to group - we trust each other and haven't had an issue with this. Maybe it could be an option for each group. We're also about to implement "a minor edit checkbox" so that emails don't always go out when minor changes are made - again, open to interpretation or even abuse, if you don't trust your group!

We're thinking that making it clear what has changed is the way forward, as then "something changed" email notifications can be specific and less like noise, and we get full transparency. And then if users still find it weird, we can make it an option to turn on or off by admins.

This discussion has become quite circular. My understanding is that there is consensus that editing of comments would be acceptable if it was limited - ie comment edits can only be initiated until another comment is added to the thread (one initiated, an edit can be saved).

Another possible approach is illustrated by theDailyBlog.co.nz, who have a 5min limit for edits, before the comment is moderated and approved.

@tomlord The concerns raised in this discussion and the reason for restricting edits is not that the feature would be abused. This is not about trust. This is about acknowledging that editing breaks the flow of the discussion and that a design restricting edits is key to preserve the authentic nature of what's being discussed.
Thanks @miguelpradosrodrig for bringing in the notion of deliberation. I think it is important to stress that on Loomio, what is important is not one specific comment or the outcome of one specific proposal, but the whole process of the deliberation. The journey, not the result. This is our Graal, the written record of the story that led us to co-construct that shared understanding. It is part of our common culture. Any tweaking of any part of the story makes it fake, useless and a barrier for any newcomer to learn the real story.

@strypey & @nicolaswormser fully agree

If a group agrees to work in a way that allows editing while not documenting absolutely everything that was entered into the system, then I think they are the ones to decide if it's ok for them, and it's a valid use-case. Of course, not every system has to cater for every use case :-)

We allow almost unlimited editing at the moment, too much editing for a number of cases and groups (imagine if I could edit your comments!)

And... we're happy with the results so far, and we do occasionally edit things, and we haven't come up with the use case where we try to exactly re-create a decision from the notes in our system. To me that does start to talk about trust, because the way I can imagine wanting to go through things with a fine-tooth comb is where something has gone really wrong. And then we would just revisit the decision anyway.

For us, any discussion of significant complexity will come to a face to face meeting anyway, in which case an online tool is highly unlikely to capture all the discussion in this format - even detailed meeting minutes aren't 100% accurate, and interactions happen outside of the online tool all the time - and we would have to try to reconstruct a big picture of what actually happened from fading divergent memories and maybe uploaded pictures of the notes we took in meetings. So at the moment we're less worried about capturing absolutely everything ever typed in, but if you suspect that is critical, then that's interesting! Thanks for the food for thought, @nicolaswormser.

We haven't got Loomio's user sample size so I have no idea how other groups are finding this right now. I suspect it depends on the size of the group and whether it is able to have more in-person discussions. I can imagine smaller, more face-to-face groups being more up for flexibility, and larger groups that can only really communicate online wanting more of a total record. I think it will be interesting to see how this plays out - maybe an answer is to see whether/how groups use different options, and see if positions change as the implications become apparent. At the moment, I think we're going to make a lot of preferences such as these a per-group configurable option.

@strypey erm, re:

would break Loomio for organisations who use it as a static record of decision-making, equivalent to meeting minutes.

1) Meeting minutes never record everything, moreover
2) You can already delete comments completely, which surely ruins the record more than editing them does!

/me is therefore utterly baffled by this line of argument.

I've had lots of members of my groups saying "why does loomio keep send me so much spam" but not a single person say "how dare you change what you said by destroying the record of conversation by deleting and re-posting comments".

@nicolaswormser

re

This is about acknowledging that editing breaks the flow of the discussion

what, and deleting comments completely and then re-posting (possibly completely different) comments doesn't?

Also @strypey

re:

record of decision-making

The proposal at it stands would actually greatly improve loomio in this regard, since there is revision history to edits in @robertguthrie's implementation. At present there is basically no record of deleted comments.

Can we please have the details of how @robertguthrie existing branch implementation of comment editing actually works.

I believe that a history of all edits, with time stamps, needs to be accessible somewhere within Loomio, in case of dispute. I believe this is needed for the integrity of the system.

I believe the best way of resolving this issue is for groups that use Loomio to have the option to choose the options which suit their group.

Interesting to see what a polarising topic this can be! This definitely makes me think that giving groups the option of allowing/disallowing comment edits makes more sense than anything else.

Just to add, I personally trust people enough to not completely change what they said (what would be the point?) and to use edit features to fix typos and mistake - like I want to, but I'd also be very happy with a solution that implements an edit window of say 5-15 minutes, as is common in many platforms.

I also think most people are intelligent enough to understand what revision/ edit history is. And, besides, we've already got it for the context text!

But, yes, an option for groups to allow edits or not sounds like a sensible idea too, given how strongly some people seem to feel about this.

Must admit I'm still fairly baffled as to why there is so much opposition to something quite a few users clearly want (especially given that it is, undoubtably - to my mind - negatively effecting the reputation of loomio).

I trust and respect many people who are supporting unrestricted editing of comments, but I need to be honest - I think it's a bad idea. Loomio is not a casual discussion forum. Having a reliable record is very important.

Sorry to the people who have taken the time to talk to me and try to convince me otherwise. I know you're sincere and I do respect your opinion deeply. But this is one of those times where I feel I have to say 'no' for the good of the project.

I have myself written typos many times and went and deleted and reposted comments. I agree the current situation is not ideal. (I actually don't think we should be able to delete comments either but that's another discussion).

Here are some solutions I think would help:

• editing a comment makes it turn a different color or some other extremely obvious visual cue that it's been changed, with an easy to access edit history available, OR

• comments can be edited, but only until there's any other changes on the discussion such as a new comment or statement of position, OR

• comments can be edited only for a very short amount of time, like 10 minutes

Hi I've been on holiday for the last week and will be for this one. I'll definitely be adding a group admin option to enable or disable the feature for their group before proposing adoption. Otherwise the feature works exactly how @neilmorris has described his ideal solution.

What a crazy looking graph!

I just thought it might be helpful to pull together some of the common themes popping up in this discussion which seem to have fairly broad agreement:

• it's important to have an accurate record of a discussion where changes aren't hidden from view

• it's not nice to get notifications about minor edits and typo fixes

• it would be good for groups to be able to enable/disable comment editing

Overall I'm hearing that people feel it would be good to have a way of fixing mistakes in comments, but it's important that this doesn't damage the integrity of a discussion.

Is that a reasonable interpretation? Anything to add?

@josefdaviescoates said:

I've had lots of members of my groups saying “why does loomio keep send me so much spam” <<

And the answer is, "because you are letting Loomio post you every comment made on the site, rather than just important stuff like new discussions and proposals." If you want that much email, use an email list! (mutters in a curmudgeonly fashion about noobs ;)

You're right that good meeting minutes only record decisions taken, and maybe tasks accepted. We rely on our memory of the face-to-face meeting to fill in the rest. Where there is no F2F, the comment thread is the record of the discussion.

Nobody is arguing that deleting comments and reposting to fix typos is a good solution. I agree with @alannakrause that getting rid of comment deletion (or at least severely limiting it) should be part of a good solution. Hopefully once the preview function is implemented, a lot of the typo style problems will be solved.

It's not about trust. It's about integrity. Would you agree to a proposal to give users the power to change each other's comments? Why? Don't you trust your group members? I don't think people should have the power to retrospectively change their own comments for exactly the same reason. Too many options and powers makes a tool less user-friendly, not more.

As I said some weeks ago, it may be that there are groups for whom a reliable record of discussion in unimportant. For many of the groups I use Loomio with, including an Incorporated Society and a Co-operative Company, reliable records are indispensable. In my experience, if a group wants to revisit a consensus decision, the first thing we do is dig up the minutes book and try to remember why the decision was made. We haven't yet done this with Loomio, but I'm dead certain as some point we will. At that point, I don't want to have to soft through multiple edits, on multiple comments, most of which are just fixing typos.

Just want to keep this discussion going because I'm never going to be happy with loomio until it is possible to edit comments!

I agree that the optional ability to preview comments, as discussed over at https://www.loomio.org/discussions/5240 would greatly reduce the need to edit comments, but it would not eliminate it.

Just a moment ago I wanted to edit a comment to add additional information and links. I should've been able to do so, and I would've wanted to do so regardless of the ability to preview.

An edit window (I say of at least 15 minutes) would be fine by me. And of course there would be a revision history to maintain the integrity should anyone want or need to check exactly how a discussion went.

@strypey if you're really concerned about integrity, could you be happy if we added an option for a user to view a discussion in "paranoid mode" where all the edits to comments show up chronologically in the discussion as new events?

Hey @josefdaviescoates, thanks for keeping this discussion alive.

Just an update to keep everyone in the loop - we've had our heads down working really hard on everything we need to get ready before moving into open beta over the last few weeks, and have at least another week or two of intense dev priorities to get through before we'll be able to think about a solution for this.

Thanks heaps for your understanding - if you could convey this to your group members who are getting frustrated by unnecessary email notifications that would be great :)

Will keep everyone posted!

@josefdaviescoates AFAIK nobody is objecting to a limited edit function (eg until the next comment is posted, or with a time limit of a few minutes). I'm objecting to an edit history for comments for reasons I've already explained in previous comments.

@jonlemmon if you're going to make the edit appear in the comment stream, why not make it a new comment?

I'm just not sure why people need to be able to insert new thoughts into the comment stream long after the fact. If there really is a use case for this, perhaps you could add a feature which allows threaded comments (comments on comments) or annotations on comments (Medium-style)?

Just been reading 'Possibilities', a 2007 collection of essays by David Graeber. I think this is relevant here, and I quote: “…the predominant approach to democratic decision-making in the literature since Rousseau… tends to see 'deliberation' merely as the balancing of interests rather than a process through which subjects themselves are constituted, or even shaped.”

Each comment made in a Loomio discussion is not merely a representation of discrete thoughts “owned” by the person commenting. It is just as much an emergent of the preceding comments by others (and comments in other discussions), and in turn, adds to the ground of understanding which shapes the comments that come after it.

In other words, once I've read a discussion and posted a comment, it's no longer just “my” comment, it's part of a stream of consciousness which belongs to the group in which I'm posting. Thus, I don't accept I have any basic rights to edit “my” comments any more than I do to edit “your” comments.

For the record, I think 5 mins is probably too short and that perhaps we should have threaded comments too.

@vivienmaidabornloo I just think Ben summed it up nicely in this sentence I added to the Context:
“Overall I'm hearing that people feel it would be good to have a way of fixing mistakes in comments, but it's important that this doesn't damage the integrity of a discussion.”

I've added a summary of the user requirements as I understand them to the Context.

@benjaminknightloom AFAIK it's not possible to produce accurate estimates of coding time, but even if it was, I think the usability of the software is a more important criteria for decision-making. I think agile, user-driven development has been one of the keys to the rapid evolution and successful adoption of Loomio. I'd hate to see that change, particularly without a serious discussion about the reasons for such a change.

Hey Strypey, totally totally agree with the importance of staying agile, user-driven and iterative, and hope it didn't sound like I was suggesting a change to that approach.

Was really just trying to express that I feel like I only have partial info at the moment, so can't form a personal view right now about whether I think the proposal captures the most appropriate next iteration. Hope that makes sense!

Really looking forward to getting past the launch milestone so we've got capacity to start thinking about exciting feature development like this again!

Just an example of what "compromising conversational integrity" looks like in practice.

Nothing malicious happened here at all. Yasmine didn't think her comment was important, so she deleted it before realizing I'd already made another comment referring to it.

If she had not noticed and voluntarily re-typed her list of questions (something relatively unlikely to occur in this situation I think, since it took her by chance noticing my comment and being proactive and having a good memory and extra time) my comment would not have made sense to anyone reading later on.

Furthermore, and perhaps more important than making sure I didn't look I was posting a non-sequitur, is that my comment building on hers actually opened a new phase of the discussion where we headed down a productive path to address a complex topic (following up the Appreciative Inquiry results). If she had not come back and reposted the comment, the conversation would have been damaged... You cannot always predict which comments will progress the discussion. Just because you made the comment does not mean you will know its effect.

For me, what @strypey said nailed it:

In other words, once I've read a discussion and posted a comment, it's no longer just “my” comment, it's part of a stream of consciousness which belongs to the group in which I'm posting. Thus, I don't accept I have any basic rights to edit “my” comments any more than I do to edit “your” comments.

@nicolaswormser I agree, but there is a separate discussion for the Delete function. Maybe best to put up a proposal there, to avoid making this one too complex? Especially since it seems like it might actually have consensus as it stands ;)

Wow, this thread just keeps getting juicier!

I feel like we've surfaced some really important questions, both about the specific feature, and the feature development process generally, and those questions are not necessarily best answered by just looking at this one proposal in isolation.

I wonder how people would feel about putting this proposal on hold for a minute?

Just a suggestion, but I'm thinking it might be more productive to put in some baseline work before coming back to the specific decision about how we implement comment editing. To my mind that baseline work would be something like a) developing a feature roadmap for context, and potentially b) some deeper discussion about process.

What do you think?

Also, I appreciate that any thread with multiple Blocks can involve a fair amount of emotional stress that is not necessarily best processed through text format!

If anyone would prefer to talk rather than type, email rich@loomio.org and we can set up a Skype call or Google Hangout.

@neilmorris always different groups have different needs. That is why i think Loomio must have options for those who need something different can enable/disable from the group options...

@neilmorris I have to say I feel frustrated that you are misusing the power to block on this decision. In this context, a block means something like 'this action would undermine the core principles of the app and I would consider not using the app if it was implemented', and it was because I felt this way that I blocked the previous proposals for unlimited editing.

Implementing a set of edit options co-ordinators can choose between might be good. It also might be surplus and confusing. In either case, it's a separate issue, and unless this specific proposal for limited editing breaks the app for you and your groups (and if so I'd like you to explain how), I ask you to withdraw your block, and let this consensus pass so we can have some kind of editing. Then you can put up a proposal for multiple options.

I have extended the close date out for another week so you don't have to consider my request under heavy time pressure.

Wow, this is an interesting one. We've never actually had a need to define what a 'block' means in the Loomio Community group, but maybe we're getting to that time.

Given that there's currently no definition set in stone in this group, I think it might be fair to interpret Neil's 'block' as highlighting a concern he feels is serious, which is a good flag that the proposal isn't the best solution we can come up with. Is that an ok assessment Neil?

I'd like to echo Rich's suggestion of putting this proposal on hold for a while so more background work can be done. I feel like some there's some process work to do on our part before we can move forward with this.

@strypey A block according to the proposal system is for when "I have strong objections to this proposal and am not OK with it going ahead.". Given I have strong objections to the proposal that I have stated, I have used it. I can see no reason to withdraw the block.

Making decisions in collaboratively requires flexibility in approaches, Loomio needs to enable this.

I too am frustrated by the lack of editing availability within Loomio currently. The current proposal though would just replace these frustrations with a different set of frustrations for the next x months. It would also have the potential to become the de facto Loomio standard for editing discussions. I think we can do a lot better than this.

I agree with @richarddbartlett when he says that "I feel like we've surfaced some really important questions, both about the specific feature, and the feature development process generally, and those questions are not necessarily best answered by just looking at this one proposal in isolation."

Developing a draft road map for the overall development of editing discussions is a possible next step. I see this proposal with some amendments being part of it.

Here are two considerations that need to be thought about in developing the current proposal.

A user of a group may express they need longer to edit items, than the x minutes specified under the current proposal. This may be an accessibility issue for the user. If this is set at x minutes (as under the current proposal), then that group couldn't change it to meet their needs. Having an option to set the number of minutes however would ensure that the person's needs could be met.

An organisation run on Loomio may use discussions in a sub-group to plan a party or some other event. Someone in the discussion may have come up with a list of things which are needed and seek volunteers to fill these. A logical way of this happening is for people to edit the list by putting their name against the item they are taking responsibility for. If the current proposal was implemented this couldn't be done.

@neilmorris if you example they could just use the context panel. Or link to a google doc. Those are dynamic, collaboratively editable media. Comments are not - they are person individual expression.

I'm not against the idea of group level options around editing comments, but we need to be realistic - getting the default settings right is key because only a tiny percentage of groups will bother changing them, and how well the defaults work will determine the effectiveness of the app for the majority of users.

@alannakrause I fully agree that you could use other services or use the discussion context to keep lists as per my earlier example. My preference of course would be to do them where it is easiest, and for me that is within within the actual discussion so it flows..however If it required a lot more development time it would be another matter.

If we're just looking at what the defaults should be my position would be a little different. For base editing of discussion comments I'd be happy for the current proposal with a minimum 30 minute editing period.

I'm also totally realistic that a lot of this sort of development depends on developer time. I naturally don't have any idea of this which is partly why I 'd be keen to see a road map of the proposed development where all options considered.

@benjaminknightloom I missed your comment earlier. I must have been writing my response at the same time as you wrote yours. I then didn't notice it later when looking at the discussion using my phone.

I just want to acknowledge that your assessment of my block as "highlighting a concern he feels is serious, which is a good flag that the proposal isn't the best solution we can come up with. " is an accurate representation of my position.

I deliberated over a number of days how best to represent my concerns about the proposal. I finally decided to go with the block because I just see this proposal replacing the current difficulties of a lack of editing, with another set of problems which might take (for example) a year to tackle, and therefore I thought "I'm not happy with this going ahead", and therefore I used the block as I expect a better solution will come forward.

I think though that there needs to be an interim solution which does tackle the lack of editing at the moment. I think part of the push for a decision on this issue is because not having some form of editing is causing people difficulties. I would urge the development team to prioritise the issue.

In analysing the proposal further there are two other comments I would make. Once comment editing is allowed, no restriction can realistically be made on the purposes it is used for. People who use it will use it for what ever purpose they want.

In terms of not having "no edit history" what is actually meant? Is it that there is no edit history shown in the discussion? or Is it that there is no edit history shown in the discussion, however there is a log file (or a data base entry) kept of the entry which can be accessed if ever needed? In larger, less closely connected groups, especially those with open public access, I think the later is needed.

I would like to support some further background work and thinking on this thread from both an editing comments point of view but also process. I am conscious of the huge time and energy, thinking, writing, responding and participating time people are investing in this thread. I totally hear that editing is a real priority for people investing time here. It hasn't come up for me once with the wider user group though. I think we at Loomio need to be able to communicate the process of how we put priority on feature development. Somehow there needs to be a fit between timing in the detail development and focus in the Loomio features thread and the developers attention. We risk wasting everyone's time when these elements are not in sync. So I really support agreeing a time frame to come back to this with some more research, options analysis and an ability for the code team to put a priority on it.

@benjaminknightloom @vivienmaidabornloo I guess the question for core Loomio crew right now is to what degree you are responsible for facilitating these conversations between users (including you as users) about what we want/ need from the app. I think, within reason, you would be well within your rights to get on with your own priorities, and leave us to duke it out (in a friendly way of course) ;)

@neilmorris this kept my awake for a while last night, thinking about how to engage constructively with what you've shared. I hear that you have a feature idea; a non-default option for indefinite editing of comments, for groups which want this. If I am I understanding you correctly, I have no problem with this feature idea.

I respectfully suggest you are doing yourself and your feature idea a disservice by blocking the current proposal. If this proposal passes, a significant chunk of the code needed for your feature idea would need to be written in order to implement the 'limited editing' feature. If this proposal passes, we can all breath a sigh of relief at not having to 'delete and report' to correct typos, and give full attention to your feature idea in this discussion, and how to implement it in a way that everyone can live with. Come on bro, let's not let the perfect be the enemy of the good, eh?

@neilmorris as you put it:

If we're just looking at what the defaults should be my position would be a little different. For base editing of discussion comments I'd be happy for the current proposal with a minimum 30 minute editing period.

Sounds fine to me. Could it be possible consensus emerged, and we just took a while to notice? :)

@benjaminknightloom Does this satisfy your objections?

@strypey I'd gladly drop the block if the proposal was refined into being a default interim solution, with a minimum 30 minute editing window and that there will be a log kept somewhere of edits made, in case there ever was disputes.

The coding time for this would be basically the same as the current proposal.

@strypey I didn't see your last comment until after I posted my latest one.

@neilmorris the reason I worded the proposal to leave the specifics to the coders (what time limit etc) was so that whatever limits they chose to set would prevent any possibility of disputes by design, thus avoiding people wasting their time trawling through edit histories on multiple comments to resolve them.

30mins is far too long for the stated purpose of this editing function (fixing typos or making other immediate corrections). It's plenty long enough for a number of new comments to be added, creating the sort of confusion @alannakrause gave an example of, and thus avoidable disputes. To me this is bad design for a discussion tool of any kind.

I'm really struggling to understand why you want a 30min minimum. Can you elaborate?

I'm struggling to understand why this proposal would be blocked, there doesn't seem to be any defendable case being presented. I'm struggling to understand why a log would be required based on the conditions set out in this proposal. @neilmorris would allowing the group admin to set the "given" time limit for editing comments when the discussion is set up, from say one minute to perpetuity, work for you?

@benjaminknightloom has offered no sign he is at work on a counter-proposal (this is often a requirement for allowing a 'no' or 'block' to stop consensus is larger, formal organisations like Permaculture in NZ).

Since @neilmorris counter-proposal clearly creates exactly the problem it claims to solve (disputes over editing), and more work for the coders implementing an otherwise unneeded version history. I would go with 'consensus-1' (a common method used by open source groups to prevent filibustering by people who are being difficult) and Neil and Ben can 'suck it and see' ;)

I've not been participating in (or reading ) this discussion for a long time because I don't like the tone of it and I don't see the point in trying to design features in this way. We can do much better.

Many weeks ago I thought this thread should have found it's natural end. There was some nice summarisation and understandings and they seem to have been ignored.

The thing is that this discussion has taken time away from developing features and It actually makes me feel pretty stressed out too.

I just hope everyone can chill out for a while on this one little thing. It's obvious we need this functionality in some form - we'll build it, and we'll probably change it after we built it too.. And it won't be as a result of what happened in here - so best not take it too seriously.

Thanks to everyone who participated trying to make an understanding in the group - it's hard because the context or purpose wasn't really that well defined.. or has changed over time. Discussing feature ideas has been fun most of the time, but deciding exactly how we should and when we should do something isn't what we're here to do IMO.

Hey @strypey, I am surprised to see your interpretation of the last proposal. I've been reflecting on why I haven't felt comfortable participating in this discussion, given that I am one of the developers building the software. I feel like some of your behaviour has stepped over the line of facilitation and has started to feel at times like bullying. For me, this discussion hasn't felt like a safe place for me to express my opinions or reach a productive outcome.

@robertguthrie @jonlemmon I'm sorry you feel that way. Here's how I see it. I blocked the proposal for unlimited editing because I believed it would have fundamentally broken the app. Because I was blocking, I felt obliged to be actively at work on a counter-proposal which met the needs addressed by the original proposal, as well as those brought up by myself, @alannakrause and others.

I can't deny that the discussion around the unlimited editing proposal got my back up, and that I felt frustrated to the point of angry when @neilmorris came in at the eleventh hour with what I still consider to be an unprincipled block. I admit some of my comments here have been terse, but I'm also aware that people can project their own emotional content onto terse comments, and I really don't feel that calling terse comments "bullying" is justified.

I stand by my outcome description as an accurate summary of the positions taken on the proposal. I look forward to seeing what editing solution the coding team come up with in due course.

BTW Preventing bullying is actually another important reasons not to allow unlimited comment editing. Imagine I had made all sorts of nasty comments, and when you called me out, I went back and edited them all to make them pleasant and friendly...

Thanks @strypey. We've been using this discussion as a learning exercise a lot recently.

I think the thing to consider is that this is not a decision making forum, you don't need to feel obliged to counter propose or come to a definite outcome. As I see it, we're here to discuss how features might work and how they might be implemented without coming to exact decisions. We can learn a lot about how features might or do affect people without the decisions.

So, thanks for your input - I really do value it and consider it when I'm thinking about how to implement and design.

We (the developers mostly in Wellington) have been talking about how, recently, we've been a pretty closed group when developing the features - and we want to open that back up. Setting the context for that is going to be really important to making it a great space for ideas to develop.

Meanwhile most of our development has been business model related and that explains some of why we've not been so active in here recently.

@robertguthrie

I think the thing to consider is that this is not a decision making forum

That's certainly an important thing to consider! I guess it's a good example of how environment shapes behaviour; when I'm in an ice rink I skate, and when I'm in a Loomio group I try to make decisions. It's actually a real testament to the effectiveness of what you've built.

I actually don't think the details of this issue are all that important right now. Regardless of what I think of editing comments, I think this process and way of approaching the issue was ineffective and often destructive. This is not due to any one person, but how the process played out as a whole.

I'm guilty of jumping in and mucking about in the debate without thinking about the bigger picture of how this all fits in with the code team's process - I take responsibility for that. Usually I am all for jumping into practical details, but in this case I really think we need to take a giant step back and work on the bigger picture of how this community should be working together, how we communicate, and design a proactive and effective process for accepting user feedback without it going down this kind of rabbit hole.

I don't feel like we members of the Loomio Co-op have put enough proactive energy into designing that invitation for engagement, or being clear about what discussion and proposals here will actually mean to the process. We are learning along with the whole community about how collaboration and discussion around this project should work. We are committed to user-driven development, transparency, and community engagement, but that needs to happen in a much better facilitated way in the context of all the other parts of the app design process.

The way this discussion played out ended up alienating some of the key people we would most want involved, and that's a really bad outcome. Who is right and who is wrong about the details of this feature is pretty much beside the point right now. We need a clearer decision making process, and to do more work to give more context around discussion like this.

Personally I have a very thick skin developed from years of fighting in the gladiator arenas of abusive online forums, as most online forums tend to be. But here at Loomio we need to do much, much better than that. This whole experience has highlighted for me that it's time to focus more energy on facilitating our community engagement and communication, and I'm keen to work on that.

This has been a bit of a roller coaster ride, but I am actually feeling grateful because it's provided us a lot more clarity about the work we need to do to achieve really good community engagement, and highlighted areas where we have not been clear enough about our process. I hope that everyone involved will move forward with us with patience and understanding so we can work together to improve all of this. We absolutely value contributions from our wider community, and we're committed to developing good processes for that engagement.

@strypey heh totally!
The context and purpose of the group was not clear from the start.. and I think that I myself have gone through different understandings of what the group is for.

We need to agree on the purpose of the group. I think we can avoid this kind of thing happening again, while hopefully promoting more great feature discussion.

BTW It just occurred to me that folks my have misinterpreted my use of the phrase “suck it and see”. This is a slang phrase which means 'try it out, and see what you think'. @benjaminknightloom and @neilmorris my apologies if you thought I was telling you to 'suck it up', which is a slang phrase which means 'accept what's being done to you without protest'. That would definitely have been bullying.

Tēnā koutou katoa te whānau o Loomio

I'd like to formally apologise to everyone who has felt alienated by my comments in this discussion. After a voice chat with @richarddbartlett and @benjaminknightloom today, I can see that in a lot of cases I have been communicating right past other people, and misunderstanding their motives, and their needs.

When I summarized the outcome of my proposal as:

Almost universal agreement, with a 'block' from one user, and a solidarity 'no' from another.

This reflected a mistaken assumption on my part that the code teams lack of engagement in the latter stage of this discussion, was because they were feeling frustrated by being blocked from implementing an editing feature that everyone agrees is required (even if we disagree about how it should work). I thought I was helping them by removing obstacles to their progress. I'm horrified by the thought that the reason they were not participating was because they felt bullied by me!

During our conversation, it also came up that Loomio development is no longer the 'agree on it, code it, roll it out' process it was during the Beta stage. You'd think I would have noticed this when the 'Preview' feature got easy consensus but didn't appear soon after, but again, I mistakenly assumed. I thought that if I didn't block the 'unlimited editing' proposal, it would pop in the app any day. I'm imagining that @neilmorris was working on a similar assumption, and that his block, like mine, may have been driven by a sense of panic. To quote Dune, "fear is the mindkiller", and no doubt this sense of urgency contribute to the intensity which made this thread such an alienating space. Again, I have to take my part in the responsibility for this, and I apologise to all for not picking up that the 'rules of engagement' in this group had changed.

I love Loomio, and I love everyone involved in it, and my intention is to do what I can to help it become even more awesome. Please feel free to let me know when my contributions are hindering this effort, not helping it.

He mihi aroha ki a koutou
Strypey

Communicating past other people and misunderstanding their motives is the norm in all meetings. Its human, and simply dividing a forum up into two columns, Discussion and Proposals, will not overcome misunderstandings, nor subdue emotions. Collaboration and consensus decision making still requires control. Someone always has to be in charge of the meeting and rules need to be in place prior to engagement. Its fantasy to think otherwise because contentious issues always crop up and that's when things get heated ...and then unreasonable.

This discussion was enlightening for me because it provides a sample of disagreement without resolution, quite rare here because you lot are all such polite and sensitive individuals. Now, throw this software as it stands into the lion's den that is my community organisation and the group behaviour will be quite different. Everything will be blocked by somebody, no decisions will ever be made and chaos will ensue.

Its actually harder to communicate via the written word and misunderstanding is a big issue. In a meeting the chair is in charge of getting things back on track. If somebody blocks a proposal they should really be required to come up with a counter-proposal, or at least justify their block and seek consensus ... or be overruled.

Its got to be about the process.

@deansatchell really interesting ideas in here, I want to think and come back, perhaps to a new thread

@matthewbartlett seems to be on the right track with Ideas (proto-proposals), maybe group decisions, collaboration and consensus could be achieved without having someone in charge, provided the software has good processes in place. Now that would be a great outcome.

I have been on holiday and am just catching up.

I just want to say to @strypey I hear your frustration. I have to admit also to being frustrated that there is no edit function.

You may have missed that I attempted to reach consensus by offering compromises on my position if suitable assurances could be given or changes to the proposal to incorporate what I regarded as minimum requirements were added.

I think it is worthwhile though making it clear though that my intention to block the proposal was fully my intention. I didn't just want to say 'no'. As I stated in my block the proposal didn't cover different needs for different uses of Loomio. For example not having any edit history in a public meeting place to me would make me very reluctant to use it in that context. Given it is those sorts of places where I am wanting to use Loomio it would curtail my use of Loomio significantly.

I did also reach out to the Loomio development team to offer to lift my block if it would have helped them.

I think there have been lots of lessons learnt about the use of Loomio in the different elements of this discussion. I am glad I have been part of that, even if I feel a little bruised along the way.