Yes, that would be great!
1 Like
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.
1 Like
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:
- Did you have problems reading, writing and sending very long replies on the chat?
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 ?
1 Like
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.
2 Likes
bonjour, l’outil de conflit est très bien , cependant lorqu’un membre est vraiment très problématique , y a t’il un moyen de l’empêcher de participer aux ramasses ?
y a t’il également une option de blocage des plannings
merci pour vos retours
nanou
1 Like
Hi,
we just had our 3rd conflict resolution and we definitely would recommend that there would be other option, like blocking someone for a month or two.
How is this discussion and plans going? Seems like many people would appreciate that!
Thanks a lot
Karolina from Warsaw
Thanks for all the input, this is definitely something we want to work on!
My feeling is that once we’ve built the first version of our new agreement / rules management feature then softer sanctions for conflict resolution will get our attention
But we can also keep the discussion going here until we have capacity to more actively work on. So in that spirit some more detailed replies:
Could you clarify what you mean by the last parameter and the confusion it causes?
The two themes of improvements to make seem to be:
- less severe “punishment” or “sanctions” as an outcome
- some way to start with a small conflict process (even one-to-one) and then incrementally escalate it if it’s not getting anywhere, eventually up to a whole group discussion
I wonder which is more useful to focus on initially?
Yes, I’m wondering too what other groups think about these. Personally I was favorable to focus first on softer sanctions. But from the experience we’ve had in my group so far when using the conflict resolution feature I’m more in favor now of starting with the second option of escalation, starting with a small circle for discussion leading to a whole group discussion if things do not get settled.
People in my group are now so afraid of being exposed in such an open process (we’re not a small group anymore) so that they will really avoid using the feature as it is now.
I would vote for the first point - the softer sanctions. But I’m also courious what comes up of the second one. This might be more complicated and take longer to implement, though… which would be an argument to start with the first one.
Sorry for being unclear! During a conflict resolution the first voting option is to remove the person in question, and the last one is to let him/her stay (or if it’s vice versa). They are very similar, only mirror-reversed to each other, and usually a person gets equally or nearly as many downvotes on the first option as he/she gets upvotes on the last option.
An option with more downvotes than upvotes gets a minus sign before the result. For some reason this confuses people, and they keep asking what it means. I don’t know why this causes any confusion as I think it’s quite clear myself. But as more voting options might be added it could also be good to keep it down to the most necessary ones, so maybe one of these two could be left out?
This has been discussed earlier in this thread, but I can’t find where as it’s getting quite long.
Hope I was being more clear this time.
1 Like
I think not quite mirror-reversed to each other, as a person could vote like this, for example:
- strong resistance to remove person from the group
- strongly in favor of extending discussion
- neutral about person remaining in the group
The key is that the option in the middle (further discussion) makes it possible to express your priorities when voting, but unfortunately people like to take very binary positions (the person should definitely leave the group, or the person should definitely stay and nothing should happen), in which case it doesn’t make so much sense to have this more nuanced score voting. I believe that has been the case with the conflicts in our group. I’m curious to know about other group’s experiences in this regard.
Yeah, I think we could solve that by having text only. But somewhere in the final result there should be the final score and maybe a little explanation.
Indeed! I remember when we were originally building it we had some similar discussions, it was quite fascinating, as to me it was obvious that we need both possibilities to be scored (to keep them in group, and a seperate one for removing them), and to others it seemed odd to have both.
To me it seems totally possible to vote in the same direction for both of them… I might not like either the idea to remove them or for them to stay because I am more interested in further options. The theory we borrowed the concept from is systemic consensus which says to always have the options to extend the process, and to keep the status quo (in our case leaving them in the group).
However, because we don’t have the possibility right now to add more options for people to vote on, it seems a bit odd. That’s why I’d love to add more options! In the systemic consensus process there is a time period for collecting options, before the voting period starts.
In a much improved version perhaps we can make it possible to add options into the process, either “automated” options (ones that require the software to do something, like removing them from the group), or “human” ones (that would just be some text, and might represent something that happens offline, or where the software doesn’t need to do anything).
There are some techniques to improve that, like giving a number of “voting points” that you can allocate across all the options. I don’t know if that would work when we have so few options available though.
I think it’s definitely a great idea to make the interface clearer and have an explanation, people are not used to these more complex voting processes.
1 Like
Hi everybody in this old thread, long time no see! To begin with, I’ve got some news on behalf of the Karrot team: there will be improvements in this feature on the upcoming months! 
We got some funding now and we plan to deliver something until October.
But the reason I’m writing here is actually to ask the opinion of people from other groups regarding one specific improvement…
Proposal: improving notifications
So when a conflict resolution begins, everyone in the group will get a bell notification about it, and only those with the “new conflict resolution process” notification enabled in their settings will be subscribed to the conversation and get an email about it. This notification is enabled by default, so the change we discussed and proposed was to not have this enabled by default, meaning that when a conflict starts, only an email and bell notification would be sent out to everybody, but not the e-mails about the conversation (unless you subscribe to the conversation manually, or write a message in it, which automatically subscribes you). Currently you cannot completely unsubscribe from the conversation at all, so this is a change in that behaviour.
And here’s the background story that led to this proposal…
In my group (Solikyl) during a recent conflict resolution process, people reacted to e-mails being sent out to the whole group and that this was too open and unnecessary, not the first time it happens. Other people even got confused about the e-mails they got, since it felt out of context and they thought it was sent directly to them, when it was actually part of this long conflict thread. I know something similar has been experienced in other groups, so I wanted to check if this actually would be an improvement and if you seen any downsides with this proposal.
Participate on further improvement of this feature
The above is only a minor change that is easy to implement and might be a good improvement for now. However, all the ideas and issues that have been discussed so far in this thread are still very relevant and we intend to start discussing, designing and implementing something more systematically in the coming months. So here’s my invitation to you all to participate in this collaborative design process! We’ll have a session on it one day during Karrot Days 2022 - July 16th & 17th!. I’ll send a reminder when the date is coming and let you know when we discuss this on other occasions. The more minds and wide representation from Karrot groups working on it, the better!
2 Likes
I’m closing this thread since it will get outdated with the changes were implementing here:
Some nice ideas that popped up here can still be revisited for future improvement of the feature.
For more updated info and discussion on this, check the following: