Thanks! I added your suggestions to this github issue
My thoughts in summary:
While I recognize the loophole, I don’t think that it’s urgent to implement a mitigation. If a user obviously acts against a group decision, I would accept requests from the group to remove them via my server admin powers (possible awaiting a Karrot coop decision beforehand).
I would release the feature tomorrow (Tuesday) evening, if no severe problem comes up until then.
@tomasz @bruno are you also interested in beta-testing the conflict resolution feature?
I think some summary of the outcome is needed because it’s currently not very clear what the group has decided:
I wonder why the first result has no score. Maybe it is zero and there’s a misguided check somewhere.
I released the feature to karrot.world just now!
The improvement proposals so far are collected here: Conflict resolution follow-up · Issue #1344 · yunity/karrot-frontend · GitHub
We had our first conflict resolution process in the group and it worked just fine! We were afraid that not a lot of people would see and participate but most of them viewed the process and about 25% voted on it.
One feedback I got was that it would be nice to have an explanation of the scores (that is the score of each option “disagree, neutral, etc”), at least after the results are out.
Idea for future development
Removing someone from the group is a drastic but sometimes necessary action. There are many other scenarios as well when more graduated sanctions could work, like temporarily prohibiting someone from doing pickups, for example. I hope we can get something like that implemented in the future! The notion of graduated sanctions is also present in Olstrom’s Governing the Commons, where she makes the case that this is one of the main principles that allow groups and communities to keep working and manage sustainably a common resource (in our case, food waste and cooperations).
We also just had our first process… uff…
Thanks for the feedback, really helpful to get input into how it works in the real world. I also saw that Foodsharing in Östersund have also been using the feature in the last few days, so maybe we can find a way to collect this together and find ways to improve it (ping @Teddy - are there are others from the group here too?).
But there could be other less drastic options within Karrot, yes.
I really like this approach. As @bruno said as well, especially fitting into this wider model of Ostroms theories and research on governing the commons 
People were complaining that the notifications are not that clear or visible and some people missed it. Could there be some extra powerful notifications for this?
By default, the notifications for new issue conversations are not enabled, and users have to enable it for in the settings:
… or once one has started, they can set it for the individual issue conversation (the bell icon):
I think the original thinking was that not everybody would be interested in participating in these processes, but maybe that is not true… and for your group it sounds like it would be super important that people know what is happening.
While I understand why, some people found it weird that not everyone was able to vote but only the ones with editing rights
I remember we spent some time discussing this when we originally added the feature, I don’t think it was clear to us either which is a good approach. I think we hoped that the trust system would be used enough that after a while all the active people would have editing rights. I could imagine either:
Hej,
just a quick thought for now:
A thing that came to mind for me when using this conflict tool is, that FINALLY people are engaging in discussions and sharing their opinion. As the active meetings don’t happen in Östersund at the moment, it was really hard to get people talking and answer on questions.
So what I would love to have, is that we could use this tool not to solve a conflict with a person, but as a tool to decide on foodsharing matters in general. Just now within the conflict resolutions going on, we are having general discussions on the rules.
So for FSosd, a general voting and discussion board could be a way to get people participating some more. So my idea is, that we could have this tool, but a little adapted and start topic discussions where everybody could discuss, decide and vote. I also like it a lot, that the time runs out, which gives a time frame to find a decision.
Yes, I totally support this idea! And I think it will be very useful for our group too!
Hey, nice that the feature helped you to solve some problems!
Re @Teddy @bruno: I think it would be great to have the “issue” feature in a general way, not just for conflict resolution. Actually it’s already half-implemented since the beginning, it just would need some more weeks of work. I would definitely support people working on that!
Re @karolina @nicksellen: we could make email notifications about conflict resolution opt-out instead of opt-in, they don’t seem to happen that often. What do you think about it?
Yes, that would be great!
I think this would feel more fair and equal. And the inactive members are inactive anyway.
To me, this makes sense too. Especially as you have to apply to join groups anyway, so you are already trusted to some extent.
I wonder if there are any counter points we should consider? Do you think that would work in the case of Östersund @Teddy? and Gothenburg @bruno?
I agree, it is a good idea to involve all active members. This way people also get involved in the group dynamics and see what is going on.
In Östersund I guess that some people don’t really understand the trust karrots and don’t know about the conflict feature. Thus they might be irritated if others talk about ongoing conflicts. But this is only a guess.
I can’t remember if I replied this in another context, but anyhow… I don’t think it would be a problem, but that’s also me guessing. 
I think it’s worth trying it out.
Anyway it’s something that is now up on the list so we can expect this to be changed not very far in the future: Allow all members to see and participate in conflict resolution · Issue #2062 · yunity/karrot-frontend · GitHub
A have a question for you all who participated in a conflict resolution in your respective groups:
In our group we experienced a few problems recently when we had a conflict with a lot of debate and long replies. I want to know if you had a similar experience.
Hello there,
just out of curiosity - how many conflict resolutions have there been , and was there any feedback on how did the process feel for the participants ?
Have there been considerations about other options for “punishment” except for excluding the person from the group ? e.g. not being able to participate in pickups/activities of places or not beeing able to write on walls ?
Here’s a screenshot of the stats:
(from our grafana the “Issues” dashboard, uses GitHub auth)
We have discussed it more informally, with people that participate in the calls, but no more structured assessment of it I think. It would be interesting to have a good written report gathering all the human feedback so far, but also that’s a lot of work.
As for the future, your thinking is exactly inline with ours. I think it’ll actually be really important to have softer sanctions like you described, and fits in well with Elinor Ostroms work which guides us a lot.
It was discussed as part of our governance design process, but we went in the direction to focus on the rules/agreements part now. I’m hoping we write up a roadmap of which other governance features are on the horizon too…
Hi everyone, we’ve had a couple of instances where the conflict function has been used here by now (Gothenburg, Solikyl, which is group 10 in the stats Nick posted), and here’s some feedback from me based on our experience so far:
More parameters is a good idea. Some useful ones that have already been mentioned in this thread are offline mediation and temporarily prohibiting someone from doing pickups. A few more could be cancellation of the conflict due to lack of clarity/valid arguments, suspension of the conflict starter in case of misusing the function, and one custom parameter to adjust for the conflict in question. As for the last parameter in place right now it seems to be causing confusion, so maybe it could be removed?
As an organization grows bigger it seems to get more and more intimidating for the one who’s the target of a conflict to say anything at all to his/her defense during the resolution. Even with only editors involved it seems people find it a bit drastic to even use this function in a very big group. I think a good idea could be to have an option to make the conflict go out to a defined group of people during a first week, and as a consequence of not resolving it, let it pass to a second week when it goes out to everyone in the whole organizaton. If a conflict is going to be taken to this second stage with many people involved it could work as an incentive to resolve it before that, during the first week. In this case I think earlier conflicts should be set to not visible to everyone, as they’ve happened before the change.
