Conflict resolution with possibility to remove user from group

Hello dear users of Karrot!
This has been requested several times, so now we’re tackling it:

A conflict resolution feature with the possibility to remove a user from the group!

We have spend the last two days to figure out the basic setup of the feature and here’s what we want to make:

  • a conversation to openly discuss the issue
  • a dynamic score voting system
  • all editors are part of the process, newcomers excluded
  • the great term 'potentially problematic person, or ppp for the person the process is started against :wink:

Now to a more detailed description of what we want to do…

1. Triggering the process

  • only editors can trigger the process
  • only one user is needed start the process
  • should not be started lightly. Users get prompted to try out other methods of conflict resolution before using this heavy feature.
  • trigger button will be found on every user profile page (‘report conflict’ or something).
  • during the process the initiator and the ppp keep all of their editing rights

the button itself:

  • triggers a flagging-on-discourse style pop-up which
  • thanks for community service
  • explains the conversation and voting process
  • asks for an initial conflict summary from the the initiator
  • the group conversation and the vote will be started by an additional click

For reference, this is a screenshot of what you can see when you click ‘flag as inappropriate’ on a post in this forum:


Of course it would not look exactly the same, but we’d like to make a similarly complex popup, in which the initiator can write the initial message of the conflict conversation, as well as have some more information about the process and a thank you for not simply keeping quiet about the issue.

2. Conversation

  • all editors are automatically part of the conversation
  • newcomers cannot join
  • the chat can be muted
  • starts with the initial message from initiator (similar to the application questions in the chat of the application feature)

We decided to limit this to editors because of the potentially sensitive information in such a chat. The assumption is that people might talk more openly when they know that only experienced users are part of the chat and not every random person that just joined.

3. Voting mechanisms

  • same participants as in the conversation (including ppp)
  • score voting: 1-5 scale with positive, negative and neutral options. No weighting, sliders.
  • the vote can be changed at any time before the vote is over, since new information can appear in the conversation
  • fixed voting period (5-7 days, you can decide below this post!)

This is the core bit and we’re not yet completely sure on every little detail, but we’re definitely going for score voting. This means that you can give your opinion on every single proposal instead of only voting for one and against all others (as it would be in a binary voting scheme). The idea we go forward with now is something like this:
svg
With different questions and answers of course.

4. Proposals to vote on

  • remove ppp from our group
  • organize offline conflict mediation
  • keep discussing: the conversation continues + the vote restart anew + outcome from last vote gets displayed somewhere (at best within the conversation, but complex code), for same length of time as initial voting period
  • ppp remains in the group

We’re still making up our minds if we need both the negative (‘kick ppp out’) and the positive (‘keep ppp in’) thing to be voted on, but that doesn’t change anything on the basic layout.

5. Notifications

  • have an extra option in settings to disable notifications about conflict processes
  • have the normal mute method from conversations:
    • grey notification chip for the conversation appears for new messages when muted
    • when unmuted the chip is green
  • bell notification for all editors when a process is started
  • another bell notification for all editors when a process is finished

This touches the very tricky bit of informing everyone while not getting on their nerves… We will add another box to the notification settings page that let’s users disable the initial notification about a new process and mutes this type of conversation by default. This will then be completely the same behavior as for applications.

For reference, this is the page I’m talking about:


By default the new box will be ticked, so you need to untick it in case you’re annoyed by notifications about conflict processes.

6. Results

  • the conversation continues to exist after the vote has ended
  • list of current and past decision-making processes in its own new page, accessible through the sidenav
  • since applications are also decisions they will somehow also be included

It’s important to keep the record of past processes, especially if it’s about decisions that were made. That’s why we’ll make a new navigation element that leads to all ongoing and finished decision processes. The exact details are yet to be determined, but they will display the results of the decision making and provide a link to the whole conversation.

7. Longer-term goals

  • the voting feature could be used for all kinds of governance questions

In future we’d like to have more options to be voted on and probably also other cases in which voting could be useful. Imagine specific roles for individual users (like mediator or store coordinator) or huge changes to the group agreement or other things we can’t even specify right now. Having a means to decide something with the whole group is definitely beneficial!

8. Still puzzling

  • how long should the voting period be?

Of course there’s more than just this one thing that still puzzles us, but this one can easily be passed on to you to decide… :stuck_out_tongue_winking_eye:

So, how long should the voting period be?
5 days? 7 days? More? Less?

Please tell us what you think!

Thanks for reading!

And even more thanks for replying, adding in your thoughts and helping us make this the feature you really need! :slight_smile:

7 Likes

maybe another point could be: take away editing rights?
It could be that a person is okay to be a member of the group but is just messing with the page?

I really like that one, for example to vote on rules, as we would

I think 7 days would be good. I’m thinking for example of the working people who might not take much time to go online within the week, but in the weekend to take part in such a voting.

At the moment this would split the people who could join in our group pretty randomly, as many “old” members have editing permissions, even if they have little experience or are even untrusted. Also because the trust-karrot function is used extremely sparesly at the moment. but I guess that could be triggered a bit.

2 Likes

Hi,
great that you are developing it! Looks very complicated, but that’s fine, we’ll learn it. I would vote for 7 days.
Karolina

1 Like

Yes for sure! We are very fond of the idea to extend the possible options! It’s just too much for the first iteration.

Yes I understand that. My preferred solution for this is to add prompts that ask people to give out more trust karrots, to add the possibility to revoke editing rights in conflict resolution, and to automatically remove inactive users after a certain amount of time.

This problem with old users having editing rights without having earned them is hopefully one that will resolve itself after some time passes and more control over the group is handed to the group via new features like this one.

2 Likes

Hi all!
Here are some mega high-tech visuals of what the feature should look like.

As always, feedback very appreciated!

3 Likes

I like it, in theory. I hope I’ll also like it in practice, :wink: . So far we did not need it

7 days seems fine to me.

And long term goals of governance are admirable. Loomio beware! :smile:

2 Likes

Are there any updates on the feature? Unfortunately, we need it and we can’t wait until we can test it!

Yes, we’re on it and it’s about 80% done.
Unfortunately there still was a lot to do after January ended and @taistadam left. Working on it mostly alone I got pretty slow. Thanks to your poking we will speed it up by bringing @tiltec and @nicksellen into the active coding, starting with a meeting tomorrow at 10am.

1 Like

Wowow! Thanks. Apparently I need to write more than this, so thanks again!

I released the conflict resolution feature to dev.karrot.world yesterday. @djahnie wrote a manual: Conflict resolution with possibility to remove user from group

To test it on dev.karrot.world:

  1. join the playground group: Karrot
    You will immediately gain editing permissions (as it is a playground group).
  2. visit a member profile, e.g. Karrot
  3. click the new action button and read through the setup stepper

If there’s already a conflict resolution with this user, you will find a red action button. It leads you directly to the issue, where you can chat and vote.

1 Like

It’s great it’s ready for testing! Good work! I have a comment though connected with this comment:

It makes a lot of sense, however, it’s currently super easy to get editing rights. Current settings give editing rights to a user who is trusted by three other users. Do you think it’s restrictive enough? In small groups of 20 people, maybe it is. But in bigger groups this is hardly any limitation. In our group in Warsaw we have about 80 users. A lot of them have joined because they were recommended by other members so they already have someone who will trust them. So it’s only a matter of finding two more users who will trust them to get editing rights. As a result new users who have just joined the group may be given editing rights and can also take part in conflict resolutions on users they may now even know.

I added some proposals how to further restrict editing rights here: [Discussion] Karrot trust system and user levels - #23 by mzpawlowski

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

1 Like

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?

2 Likes

I think some summary of the outcome is needed because it’s currently not very clear what the group has decided:

image

1 Like

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

2 Likes

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

3 Likes

We also just had our first process… uff…

  • We have earlier stages of solving the problem and a “yellow card” and this was our “red card”. But there could be other less drastic options within Karrot, yes.
  • We still need to translate everything to Polish.
  • 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?
  • While I understand why, some people found it weird that not everyone was able to vote but only the ones with editing rights. Especially as the notifications were not that visible, we reminded all that there is a process going on, but then not all could see it as they didn’t have these rights, which gave an unfair feeling.
1 Like

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 :+1:

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

issueheader

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:

  • making “giving trust” a more prominent action, encouraging people to give it when they do trust the person, so more people can participate in issues
  • allow all active members of the group to participate in the issue process
1 Like

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.

5 Likes