Conflict resolution with possibility to remove user from group

discussion
news

#1

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:


[Info] How does the conflict resolution feature work?
Collecting (and voting) on feature requests for Karrot, Spring 2019
[Info] How does the conflict resolution feature work?
New: upload your group logo!
#2

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.


#3

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


#4

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.


#5

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

As always, feedback very appreciated!


#6

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:


#7

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


#8

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.


#9

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


#10

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: https://dev.karrot.world/#/group/6/
    You will immediately gain editing permissions (as it is a playground group).
  2. visit a member profile, e.g. https://dev.karrot.world/#/user/22
  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.


#11

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


#12

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


#13

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?


#14

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

image


#15

I wonder why the first result has no score. Maybe it is zero and there’s a misguided check somewhere.


#16

I released the feature to karrot.world just now!

The improvement proposals so far are collected here: https://github.com/yunity/karrot-frontend/issues/1344