New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Brainstorming] Process to remove user from group #853

Open
tiltec opened this Issue Jan 21, 2018 · 9 comments

Comments

@tiltec
Copy link
Member

tiltec commented Jan 21, 2018

Joining and leaving a group on karrot is easy, but only if the user actively does it. I think there might be two reasons where removal for other reasons seems valid: inactivity and kick request.

  • due to inactivity: notify and mark as inactive after 1 month (grey out in member list), notify again after 2 months, remove from group after 3 months
  • due to kick request: anybody can ask to remove another person from the group, using a process.

Process proposal

  1. Requester describes reasons why X should be removed from group
  2. X can answer
  3. After one day, all members from the group are added to the conversation and can vote if X should be removed from group
    • options: "yes", "no", "don't care"
    • additional yes/no selection: "Do you have enough information?" (control proposal)
    • voting period: until 50% of active group members voted, plus 3 days (arbitrary, to give everyone a chance to vote). Immediately ends if 100% active group members voted.
    • personal decision can be changed during voting period
    • results are only shown when vote is over (to prevent strategic voting and bias)
    • if less than 50% of active group members voted after 2 weeks, process is stopped and archived
  4. Everybody can write comments into the conversation
  5. Result is the comparison of "yes" and "no" votes
    • if more people say they don't have enough information than people saying "yes" or "no", then the process continues until it is not the case anymore (extended voting period), but only to a maximum of 2 weeks. Then the process gets archived, without removal
    • if "yes" < "no", process gets archived, without removal
    • if "yes" > "no", X gets removed as a group member

While the process is ongoing, X keeps being a member of the group but temporarily gets most rights revoked (to prevent revenge actions; only join/leave pickups and leave the group keep active). During the extended voting period, rights are reverted to how it was before the removal process (to avoid blocking someone without a decision).

Further comments / questions

  • Does this work with open groups and password-protected groups? The removed user could just join again. I guess it would need some kind of approval process before joining the group
  • Would it be reasonable to prevent new members (joined the group less than 2 weeks ago) from voting?
  • Is it harmful if somebody wants to troll an active user by starting the removal process against them? The rights would get removed until to process is over (worst case for 2 weeks)
  • The process is very complex. How can it be simplified without much chance for harm?
  • The server admins always have full power and need to be trusted. Wouldn't it be OK to have trusted admins with almost full power per group? Most people are honest, should we really make process that complex for the few cases where people aren't?
  • Can the process be generalized for other group decisions and would this add enough value to karrot to warrant the complexity?

Mockup

I made a mockup of some parts of the process, you can visit the page here: https://karrot-remove-proposal.netlify.com/

Screenshots:

image
image
image

@SylviaSchneider

This comment has been minimized.

Copy link

SylviaSchneider commented Jan 21, 2018

For the above example there is no clear indication to remove the member.
But there are indications, for the necessity to remove a member. E.g former member does not want to be member anymore, but does not remove himself and does not respond, ...Or a member goes mad and is clearing all expanations for the shops in the system etc.

@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Jan 23, 2018

Does this work with open groups and password-protected groups? The removed user could just join again. I guess it would need some kind of approval process before joining the group

I think with an approval process too, it would work work fine.

Would it be reasonable to prevent new members (joined the group less than 2 weeks ago) from voting?

Maybe only if it's been observed that people are abusing the system by signing up and voting. And would presumably not be an issue were there an approval process.

Is it harmful if somebody wants to troll an active user by starting the removal process against them? The rights would get removed until to process is over (worst case for 2 weeks)

I would not remove rights by default, then see how it goes.

The process is very complex. How can it be simplified without much chance for harm?
The server admins always have full power and need to be trusted. Wouldn't it be OK to have trusted admins with almost full power per group? Most people are honest, should we really make process that complex for the few cases where people aren't?

One idea it have it representative democracy - have people vote for who is an admin (or more fine grained roles).

Can the process be generalized for other group decisions and would this add enough value to karrot to warrant the complexity?

I think it could be nice to go in that direction, for example:

  • should we let a member join
  • should we change the agreement document
  • should we changed from an open group to a closed one
@brnsolikyl

This comment has been minimized.

Copy link

brnsolikyl commented Feb 6, 2018

I find these discussions fascinating because they are clearly a question of governance, and we can choose to which degree group governance and decision-making should be built into the tool. That's why we need to consider how different groups organize themselves offline and how they try to solve conflicts outside of the tool, and what kind of powers and liberties the tool would grant individuals in a group.

One example here in Gothenburg is that there is a person responsible for a store and he had issues with one food saver, so for a while he could just tell this person to not come by and be on stand by, until we solved the issue. He had the contact with the store and therefore was able to keep out anyone from a pickup without resorting to excluding the person from a pickup on Karrot.

This made me think about another option (to complicate things further... hehe):
an admin role for stores, a person who can do the editing of pickups, exclude people from pickups and eventually ban someone from doing pickups on a store. This is not a group solution. A really problematic person would go on trolling and fucking up other stores and pickups. On the other hand it's less concentrating of power than the admin role for the whole group and might better reflect real power dynamics that occur and are better solved away from the keyboard. But then again, for this issue it would be good to hear from other places, how they organize, solve conflicts and their power relations.

@djahnie

This comment has been minimized.

Copy link
Member

djahnie commented Feb 7, 2018

I guess we all agree that having people solve their conflicts outside of Karrot is preferable. Still, sometimes it boils down to power who wins, and that's where good processes are really helpful. So generally I'm definitely in favor of having some kind of decision making system in Karrot.

The store admin role @brnsolikyl describes sounds a lot like foodsharing.de's store coordinator role. It has its benefits for sure, but the question remains the same: who decides who can become store coordinator? What to do if a person with more rights abuses their power?

I think a good decision making system is a great failsafe for situations of conflict resolution and therefore absolutely worth implementing.

@brnsolikyl

This comment has been minimized.

Copy link

brnsolikyl commented Feb 7, 2018

Isn't the decision about who becomes a store coordinator also done outside of fs.de, and wouldn't it be usually the same for groups using Karrot? The person assuming this role is usually someone more engaged and taking the responsibility not only for pickups. With great power comes greater responsibility. heheh

But I'm also positive about a decision-making system like the one sketched out by Tilmann. When we look at the governance system of big commercial platforms, usually it's this democratic approach that is missing.

@djahnie

This comment has been minimized.

Copy link
Member

djahnie commented Feb 7, 2018

It's also about the timeframes we think about. In the long term a decision making system for conflict resolution is a must imho, but for now it's way to complex anyways...

@SylviaSchneider wrote to me again and requested the removal of inactive users with specific cases already named. For removal of inactive users no democratic process is needed, we just need to decide on some parameters like:

  • What counts as activity? (read or write access, imho read is enough)
  • What is the process and what are the timeframes? (e.g. that what @tiltec proposed in the initial post)
@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Feb 7, 2018

Thanks for all the feedback already 😄

Isn't the decision about who becomes a store coordinator also done outside of fs.de, and wouldn't it be usually the same for groups using Karrot?

Foodsharing.de has hierarchical power authority. There's always some greater authority that makes these decisions, usually without software support by making a request via chat and having informal categories. For example there are people with site-wide admin rights, with group-wide admin rights and with store-wide admin rights. Site-wide admins rights are necessary to give someone group-wide admin rights, and so on.

In karrot we avoided this so far by granting everyone the same limited rights (as long as you are member of the group). This seems to be not enough, we get two kinds of requests from time to time:

  • "I need more power to do x" (for example to remove a user from a group)
  • "I want these kinds of users to have less power" (for example to prevent new users from changing group and store settings)

I think both requests are valid but problematic. They both lead to greater power inequality, reinforced by software.

That's why I'm looking for ways to grant the same power to everyone while trying to avoid bad side effects when people abuse their power. This brainstorming is part of it.

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Oct 31, 2018

This has been inactive for a while, but I think it's still important. Maybe we should discuss this in a wider context of moderation tools in karrot (related to user content, but also to users themselves). Would like to have a meeting about this in the next weeks.

@taistadam

This comment has been minimized.

Copy link
Contributor

taistadam commented Jan 4, 2019

This is becoming the main feature goal of the Winter Month of Karrot (January!).
Wireframing session planned today with hopefully a plan and key questions to relate to the forum afterwards.

@tiltec tiltec referenced this issue Jan 9, 2019

Open

Conflict resolution / cases #616

7 of 9 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment