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.
Yes, we’re on it and it’s about 80% done.
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:
- join the playground group: https://dev.karrot.world/#/group/6/
You will immediately gain editing permissions (as it is a playground group).
- visit a member profile, e.g. https://dev.karrot.world/#/user/22
- 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.
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
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).
I would release the feature tomorrow (Tuesday) evening, if no severe problem comes up until then.
I think some summary of the outcome is needed because it’s currently not very clear what the group has decided:
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: https://github.com/yunity/karrot-frontend/issues/1344
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).
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.
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
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):
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
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.
Yes, I totally support this idea! And I think it will be very useful for our group too!
Hey, nice that the feature helped you to solve some problems!
Re @Teddy @bruno: I think it would be great to have the “issue” feature in a general way, not just for conflict resolution. Actually it’s already half-implemented since the beginning, it just would need some more weeks of work. I would definitely support people working on that!
Yes, that would be great!
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 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.
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: https://github.com/yunity/karrot-frontend/issues/2062