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
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:
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… 
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! 
