[Discussion] Karrot trust system and user levels


great that this is comming! I do have some thoughts about it:

  • Time is not everything. We (Warsaw) have some users that are here a long time, but never did a pickup. Number of pickups wouldn’t be a solution either as there can be some users that do a lot of pickups, but are actually not trusted. The carrot/banana trust sign could be a good thing…
  • If there is a trust button, this should be anonymous and not forced in any way, people should be giving it from their own initiative, not (for example after a pick up). There are big cultural differences in this respect and some people in some cultures might feel that they need to give an OK when asked, even when they think this people wasn’t reliable.
  • Will there be 3 levels? Applicant, newcomer and editor? This would make sense!
  • In Warsaw we do have our rules, but yes, they are not in the public description. We’ll think about it :-).
    Looking forward to these changes!

Thanks for the feedback!

Will there be 3 levels? Applicant, newcomer and editor? This would make sense!

Yes. We have applicant and editor right now, the newcomer role will come in the next months.

If there is a trust button, this should be anonymous and not forced in any way, people should be giving it from their own initiative, not (for example after a pick up). There are big cultural differences in this respect and some people in some cultures might feel that they need to give an OK when asked, even when they think this people wasn’t reliable.

Good reminder! I’ll try to make it not pushy, more as a reminder that if someone seems trustworthy to press the trust button.

I think making it anonymous makes the problem worse, because then you don’t know who actually pressed the trust button. Why do you think it should be anonymous?

To the anonymous - why do we need to know? I mean the system would have this info somewhere, but it would not be visible. I think that some people might be pressed my the fact that it is not. For good and for bad - there might be a peer or a group pressure to give an OK when if we think that the person isn’t trustworthy. I would avoid such processes, we are social humans and even if in some countries people speak their mind openly, in others people don’t.

One more comment to it. I thought about it myself and now an extra person independently asked about it, so it must be an important point :-). Will there be a distrust button? I like all vegetables so it’s difficult to come up with one for this, but you know what I mean. Or maybe some other way not only saying the person that something was really not OK, but also noting it somewhere? Of course we all try to be the best versions of the human being, but sometimes something happens and this might be useful and important feature.

To the anonymous - why do we need to know? I mean the system would have this info somewhere, but it would not be visible.

Karrot usually has transparency by default, not need-to-know. On foodsharing.de, there’s a lot less transparency, but the trust bananas details are visible to every user across regions.

I didn’t fully understand the effect you mentioned - because trust is visible, users will feel the pressure to click the trust button?

I think every group on karrot might use the trust feature differently, according to their own rules. So while in some groups, you should get trust after the first successful pickup, in other groups it might take 10 pickups and showing up on 3 meetings. It’s easier to check this if trust is transparently shown.

Will there be a distrust button?

I didn’t plan it for the initial release because it seemed a bit complex to handle it together with the bootstrap process (you just need 1 trust when the group is small etc). It would be a bit hard to predict for the user when they have editor rights and when not, as it could change back and forth from one day to the other.

The trust feature is not intended for conflict resolution, that would need more thoughts. For example [Brainstorming] Process to remove user from group · Issue #853 · yunity/karrot-frontend · GitHub, but the described process is still a bit too complex, so it won’t arrive before next year.

A post was merged into an existing topic: New Group Application feature coming up!

Another idea is to have trust only valid for a certain period of time. Like, for example, after 6 months any given trust expires and disappears if not renewed. But we thought it could be a bit annoying to people to always have to press the trust button again, and if they don’t, their leaders could actually loose their rights.
This is not trivial. I am generally in favor of making trust not automatically last forever, but the implications of people losing trust and thus also losing editing rights, need to be managed wisely.

To the point of conflict resolution: I agree, that removing trust should not be the way to ‘get rid’ of somebody, but trust is not binary either. Meaning: Could be that I trust someone fully in the beginning, but after a while I see that this person is actually not as amazing as I thought. I still wouldn’t want to kick them out of the group, but I’d feel more comfortable if they did not have this virtual badge of my trust that enables them to make severe changes to the group’s setup.

Great! We’re looking forward to testing it in Warsaw.

Will there be something like anti-carrots? Let’s say we have 1000 users and one user that, for example, turned out not to be trustworthy, but has 3 friends who gave him/her a carrot. What now? Maybe 100 people would like to give him/her an anti-carrot? I understand that a proportion is tricky with large numbers, but the rotten carrots would be a solution. One would need to have some good proportion (75%?) of good ones over bad ones.

I like the feature but it’s kind of unpredictable the very different use cases and rules (if any) which different groups will define to give away trust. In any case, I think it’s important either to be able to recall your trust (I don’t trust this person anymore) or for the trust to automatically expire after a while (might be a pain in the ass though if people forget about this and suddenly you loose your editing rights when you most need it).

The best thing is to start testing now and collect feedback and stats later from different groups! :slight_smile:

Your responses triggered a lot of thoughts in me and I probably do not have enough time to explain them well.
But in short: I didn’t want to build a conflict resolution tool or a web-of-trust system, and neither was the trust system intended for voting about a user. Untrusting, expiring trust or anti-trust would add quite much in complexity, so I wouldn’t be able to implement them before next year.

Another thought: maybe “Trust” is the wrong word after all for what this feature is about? It’s more like an “approval”, so I’m wondering if I should rename before releasing (and make the icon a check mark).

By the way, I’m thinking a lot about tools for mediation and conflict resolution the last weeks. But that’s something for another forum post…

Just as an addition for the sake of transparency: @tiltec and me talked about this yesterday and the idea to change the name from trust to approval is due to the origin of this feature:

  • It is not meant to display real-life trust in people!
  • It is only meant to smoothen a newcomer’s arrival in the group.

The name ‘trust system’ has completely different connotations (like everything we discussed above) and was never intended by Tilmann - at least not at this point in time. I also thought it was, but apparently it’s not… And since he still is the one main person to implement stuff and think about the complexity in the background, I guess we’ll have to deal with it… :sweat_smile:

(But I really like the term ‘rotten karrots’ for anti-trust, @karolina! :wink:)

I released the user level and trust system feature today, without changing the name. I hope the benefit is greater than the downsides :wink:

1 Like

You’ve mentioned here somewhere about trust expiring automatically after a while. Is something like that implemented already? What do you think about trust expiring after inactivity time? When a user has been inactive for more than 30 or 60 days…

In our group we have quite a lot of users who would really not be suited to have editing permissions, but they have it because they signed up before the feature was implemented. That’s one thing. But even for future users who acquire trust and editing permissions it seems reasonable that if they are not active at all for a longer period of time they’d lose editing permissions.

No, right now trust stays forever and as soon as a user has editing permission, they are permanent.

It sounds reasonable - after this time, users are unlikely to be familiar with day-to-day operations and there’s no good reason why they should edit the group.

That sounds interesting, are they not suited because they don’t need it or because they might change something out of accident? Did people abuse their editing permissions already?

We talked about these topics with Foodsharing Warszawa too and the concept of social control seems to be quite powerful - if a respected person (e.g. somebody speaking “for the group”) tells people they are not allowed to do something, they usually don’t do it.

Of course, there’s always a chance that somebody acts against it and for this reason I want to implement something that groups can remove users. I think this is especially important because members who rightfully have some power (because they manage a store or take care of group administration) have more ways to abuse the power. Hence a need for checks & balances, and user removal.

Both because they don’t need and because they might change out of accident. But no, so far we haven’t had any problem with abuse. I guess the only very small annoying incident that I’ve observed is an inexperienced user who never did a pickup accept an application of a new user who completely ignored one of the important questions asked in the application, about reading and accepting our guidelines. Btw, it’s the case that only trusted users can accept or decline an application, right?

This feature has not been needed so far in our group but will certainly be appreciated if/when the time comes.

Yes, that’s the case, accepting an applicant needs editing permissions.

I thought about introducing a new role that is about handling applications, because usually every group has their own procedure how they would like to accept applicants and it needs some knowledge, like you describe. But the priority of adding this role is quite low compared to other tasks.

It is the same in our group. We did not have any abuse as far as i know either, but i guess it is only because most people really don’t know that they even CAN change anything. Most people don’t go beyond the first page and maybe the feedback option. I think everybody justs assumes that i am the admin of the group.
Most people don’t even get what the trust karrots are about or even see that they are there.

I like that idea as well, as we have quite some people who are inactive (almost half of our members). This will hopefully change now, as we also have an application feature and will soon probably have more stores. Otherwise it doesn’t really matter so much, because our inactive members wouldn’t probably just come and change stuff.

Would be cool to add something that makes sure people who deserve trust carrots also get them.

If we would require that trust is needed to keep editing permissions, then some people might get stripped of their rights even if they need them. Could implement a warning beforehand though…
It might be even worse if trust expires or if trust requirements change dynamically (e.g. needed trust is relative to group size and the group grows)

I think problems with people bringing chaos into group(-settings) can be resolved when we released the user removal (“conflict resolution”) feature - expect another post today or tomorrow!

Some time went by, I’d be interested how you find it now. Do you think enough people receive trust? Or too many?

In my opinion too many. 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.

My proposal is to restrict editing rights more :

  • Number of people who needs to trust a user to give him/her editing rights should be higher. 5 is a minimum in my opinion and this number should be agreed by each group separately. This limitation ensures new users who get editing rights are verified by a bigger number of other users.
  • To get editing rights, a user should be trusted by at least X (e.g. 1) user with editing rights. This limitation ensures new users are not just members of small cliques who trust each other but are also trusted by someone who is already trusted.
  • New users shouldn’t get editing rights immediately after getting enough trusts. There should be a waiting period, e.g. at least a month after signing up, which has to past before a new user can get editing rights. This limitation ensures new users will have enough time to know the group more and become more able to make reliable decisions.
1 Like