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.
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!
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…
(But I really like the term ‘rotten karrots’ for anti-trust, @karolina! )
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!
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.
Thanks for your thoughts on this, @mzpawlowski!
Did you have bad experiences with users abusing their editing rights or do you only assume that it might happen? I’d like to point out that we never intended the editing rights to turn into admin roles which only a few people have. The danger a group faces when needing approval of someone who already has editing rights is that elites form and the once open group actually closes down. I think it would be a shame if that happened.
I do agree that the number of trusts needed could adapt more to the size of the group. I’m not completely sure how it works right now, but I think it already adapts a little. Can you maybe shed light on this @tiltec? (I might write a manual page for this feature as well, if I get all the info… )
When it comes to the waiting time, I also think that this could make sense, but am unsure how long it should be. Are there more opinions on this?
No bad experience so far with editing rights being abused. I’ve been just pointing out the possibilities to consider
As long as I might understand your idea to have a group where everyone is equal, there are no admin roles or so called ‘elites’, I don’t think this is very safe. And there are probably not many examples of the systems which work this way. When a group is getting bigger and bigger, the small probability that a user has bad intentions can eventually materialize. With editing rights and bad intentions we could run into serious problems.
Imagine the following situation:
Michal who has editing rights in Karrot tends to abuse some rules and someone has finally decided to open a conflict resolution case against him. Voting takes 7 days during which Michal has signed up to Karrot using 3 new e-mail addresses and accepted his own applications form old e-mail which has editing rights. In total Michal has 4 accounts now. Each of them can be trusted by 3 other accounts which belong to him. As a result, all 4 accounts will get editing rights. Even if everyone in the voting has decided to get rid of Michal (his first account), he will still have 3 more account with editing rights. New cases can be opened against them but as long as Michal is not restricted by anything or anyone, he can continue this procedure forever.
This may sound unrealistic but it’s theoretically possible. I believe we have been able to avoid any situations like this in Warsaw because of two reasons:
We have a recruitment process when we can evaluate a candidate before he/she joins a group on Karrot.
Not many Karrot users are aware of the rights they have.
But there is no guarantee it won’t happen. That’s why I think we need more user levels and / or user roles. For example, if there was a special user role who accepts new applications, the situation with Michal couldn’t happen (if Michal didn’t have rights to accept new applications).
I’m aware it might be against your idea behind Karrot development but I just want to highlight that it also poses serious risks.
A bit of dreaming ahead: now that we have the “issues” system in place for conflict resolution, we could also implement it for other areas, for example:
should we change the group name?
should User Y be the coordinator for Store A? (then nobody else can change store A’s settings)
should User Z be responsible for accepting newcomers to the group? (then nobody else can accept applications or invite users)
That’s essentially the idea of “direct democracy”, but also “task delegation”, which I think are both very important for bigger groups.
)