[Discussion] Karrot trust system and user levels

Karrot currently does not have user roles. Every group member is equal, there are no special powers. This follows an idealistic view and simplifies implementation, but there are problems coming with it. Especially new users might change group settings in unwanted ways, so groups might hold back from accepting new people into the group.

Here’s a new proposal!

As part of this Github issue, some concrete ideas emerged. Our current proposal is to introduce two user roles: newcomers and editors.

When joining a group, users start as newcomers. They can write messages, join pickups and give feedback, but not edit group settings, modify stores or modify pickups. Newcomers will be marked in a special way when they join pickups, so that it’s easy for other users to recognize and help them.

After they have gained experience, newcomers are supposed to become editor. The time frame depends entirely upon other group members. It can be after one week, but can also be on the same day they joined - or never. Group members need to explicitly express their trust in the newcomer. Once a certain threshold is reached, Karrot upgrades the user to be an editor.

An editor can do exactly the same things as current group members in Karrot. In fact, every existing group member will be made into editor once the new feature gets rolled out. This should make the transition as smooth as possible.

…but some questions are still open…

profile
Should people give trust on the user profile?

Before the feature can get implemented, we need to solve a few tricky questions. How can we make sure that most users become editors eventually? We strongly think that closed editor elites are detrimental for the success of foodsaving groups, so we want to make sure that the user roles are not being used for this purpose. Our current idea is to count trust not only from editors but from newcomers as well, as a way to “break” blockades.

Where’s the incentive for giving trust to fellow users? It should be seen as core part of being an active member of the group, similar as doing pickups and giving pickup feedback. We thought about hooking the trust into the pickup feedback. That means: if you did a pickup with someone you didn’t give trust yet, Karrot will ask you to give trust to the other person while giving feedback for the pickup.

Another hot topic was the question if newcomers should be able to join pickups at all. Two reasons speak against newcomers doing pickups: 1) possibly disturbing the cooperation when doing the first pickup alone and 2) lowered incentive to become editor. On the other hand, the newcomer role seems rather useless if one can only write messages, it does not seem different from being in the state of a group applicant. Also, if newcomers have the pickup information, they might just show up at the store, even without joining the pickup. That’s why the current proposal allows joining pickups, but adds some kind of badge to newcomers, so that experienced members can join them.

We’re aware that some members are happy with only doing pickups and don’t want to have the increased responsibility of editing the group. We’re not sure yet if we want to give users the possibility to abstain from becoming editor, but in any case it would be useful to inform them about the fact that they just became editor, and what additional powers it brings.

memberlist
Should we show trust on the group members list?

Your feedback please!

Ok, that’s it! What do you think of it? It’s the first bigger change to the group membership structure in Karrot, so we’re a bit nervous with it and would like to make sure that we implement something that benefits all existing and future foodsaving groups that use Karrot!

This proposal was worked out by me, discussed with @taistadam, @djahnie and @nicksellen. It is based on the “student mode” idea from Solikyl Gothenburg, on the trust system idea from Chandi and countless related discussions.

2 Likes

It is really difficult to handle this.
My opinion is that it’s better all users have no roles or restrictions. But the documentation should be programmed in the way that we can immediately recognize who made the change and talk to this user.
And in addition, before a user signs in, the rules should be read.

I know, it’s ideal if everyone in the group has equal permissions! I also like that having no roles makes the software much simpler :wink:

The “History” feature of Karrot already provides the information who changed what and you can talk to people about this, but the History not very accessible. For example, it doesn’t have a search functionality or filtering.

About reading the rules: we have another feature in Karrot called “group agreements”, but as we couldn’t figure out who should be allowed to change the agreement (everybody in the group? - there are no roles…), it’s currently not usable.
In the meantime, groups could put their rules into their public description, though I’m not aware of any group that does this.

These “newcomer” and “editor” roles could mean that the “group agreements” are getting revived. All editors could be allowed to change the agreement… but that’s something for future discussion.

Hi,

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!
    Karolina

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.