Handle newcomers to group with simple trust system

[nicksellen]

The discussion got split about across a few issues, so this is a new issue for this specific feature request.

We are a foodshare called Solidarity Fridge or for short Solikyl (add .se for the site) in Gothenburrg (Göteborg) / Sweden that need the concept of having introductory pickups with one instructor and at least 2 students and customize messages accordingly. For example, when 2 students joins that are not listed as experienced, one of the teachers will be notified so they can join. Once one of the teachers joins the students will be notified and e-mail's etc. will be shared so they can arrange a meeting place together or the students will not be notified of a available pickup before a teacher have joined one such pickup. Preferably both options should be covered.

For details of why we want this particular setup, see the discussion here: yunity/foodsaving-backend#273 (comment)

Related:

• Initiation period for users a.k.a introductory pickups #99
• notification options in stores #363

[brnsolikyl]

Recently we've been having a lot of interest from new people to become foodsavers here in Gothenburg, which has made me think about this issue. I have one suggestion, which is not complete but maybe good to start the discussion:

When people join or are invited to the group they come in on student mode by default. The student mode allows the user to view and join the pickups (only those with more than one slot), the stores and members, just like any other user, although with no editing rights. After their first pickup is done, the user in student mode loses access temporarily until the other user(s) who accompanied the student in the first pickup unlock the student's access. The instructor(s) (users who joined the same pickup as the student) can be given the options, after the pickup is completed, of 1) full acceptance of the student, which grants the newcomers full rights in the system, 2) continuation of student mode, or 3) Ignore, which will keep the student's access rights blocked until options 1 or 2 are chosen at a later moment by the instructor(s). We could include a feedback to the student when these options are chosen in the form of a comment field that can be sent as a message.

Pros of this idea: flexible enough to let each group easily decide how many times a person needs to do an intro-pickup until they're recognized as an official foodsaver. If not enough trust is built, it is also easy to keep the person "blocked" from the system and not able to see and join pickups. We don't need to code for the role of an instructor. Anyone with full access rights can be one, or the group decides outside of the platform who can join newcomers as an instructor.

Cons: users in the role of instructor can easily hinder the participation of newcomers. This confers them some power that can be used unwisely. Another question is how to balance or decide the choices of more than one instructor in the scheme above (for ex. if one instructor chooses option 1 and the other option 2 or 3).

This issue also relates to #356 and #550

[Sliverriver]

Thinking outside the box :

I think this can be already be done without having this exact feature programmed.

1. Create a passwort protected group for your day-to-day pickups and everything your group does
2. create a "public" group without passwort.
3. just have the people there that are "new" or "instructors".
4. you just have to post the stores and dates that instructors choose to use for a pickup, and not having it cluttered with pickups they can't join.
   (there was/ is a request that people who join a group don't see all the stores right away till they are "full members", with having a seperate group for it, you don't have to post all stores, just the ones suitable for introductions and who might want to be ok with being more public exposure )

• in the history you see who has done how many pickups.
• take all the time you need for instructions whatever, teaching them about the website, etc.

5. once that person is "ready" they get the passwort for the real group.

you would again have a "superior" person who decides to share the password, so that problem of someone "hindering" to enter is not solved - but at least a lot of hierarchie features are avoided :-D

[nicco11a]

Good suggestion, but harder then you think to implement in practice because it would really make it complicated to get a unified picture of what pickups are available and who can join I think.

[tiltec]

This is likely to get implemented as part of user level 2 as outlined in #1062

[tiltec]

First implementation proposal:

Define a user role that can join and leave pickups, give and edit feedback, write messages and see all group information. I guess we would rather define the UL3 role that can do all things and migrate existing users to have it -> karrot-dev/karrot-backend#519

A user gets UL3 when the user was approved by 3 members, or half the number of UL3 that are active (we take the lower number).

Once a user has UL3, they can only lose it when they leave the group.

[tiltec]

We had some discussions yesterday about whether it could be useful to include a role that allows joining/leaving pickups (and prevents joining pickups if you don't have that role). My position is that it's not needed for the first iteration of this feature as the more important bit is the way how to progress from newcomer to editor.

[nicksellen]

I wonder if this is really just implementing admins - as the user without the group_editor role can do almost all the things that are useful to a normal member it kind of makes group_editor just the admin role.

I can imagine groups using it as if it's an admin feature as there seems not much incentive to progress people from their initial position in the group.

I think it's still a useful role to have, but I wonder if there should be a bigger incentive to progress people. The main one would being whether they can see/do pickups of course...

[tiltec]

I see it similarly. I'd also like to see a bigger incentive for people to give trust.

Another topic that just came to my mind: what if all editors become inactive, not accepting new members and not progressing newcomers into being editors?
Maybe an auto-accept and auto-trust feature would be useful, in a later implementation?

[tiltec]

Giving trust to users could be connected to giving pickup feedback. The UI would ask "You did a pickup with these newcomers. Do they seem trustworthy?"

This would create a certain pressure to give trust, maybe the selection could even be reversed and people have to be deselected. Although this would lead to the expectation that the people giving feedback usually also give trust to newcomers. An exception from this might need explanation why no trust was given, which makes things more complicated.

Maybe it would make it a bit easier if we only ask for trust when doing the second or third pickup together...

[tiltec]

Here's my meeting summary:

Participants: Nick, Tais, Janina, Tilmann
Location: Kanthaus Garden

We talked about the group editors role, potential problems and solutions.

The group editors role and the trust system are supposed to solve these problems:

• Prevent new people from accidentally breaking group settings (store settings, pickup settings etc)
• Make it possible to accept new members without granting full trust upfront

Potential new problems with the group editors role:

• What if there's not enough incentive to trust people, either because it's extra work or because editors want to be a closed group?
• Karrot users might not understand what "giving trust" means and why they should click the button
• If a newcomer becomes editor, all the new buttons might overwhelm them
• Doing pickups without proper introduction might mean people disturbing a cooperation or forgetting to show up there
• Should only editors be able to accept group applications? Should newcomers be able to participate in application chats?

Proposals:

• Add a hint to give trust in pickup feedback: "Do you trust this member to participate in your group?" or better phrasing
• For counting the trust to become editor, use trust from both editors and newcomers equally.
• Write a post in community.foodsaving.world to explain the feature
• Add alert dialog when user became editor
• Allow users to decline themselves becoming editor
• Allow newcomers to participate in group applications
• Only allow editors to accept or decline group applications
• Read again the text from @djembejohn about web of trust implementations and their problems (especially the creation of power circles)
• Prevent newcomers from joining pickups, to make the newcomer role less attractive as permanent status
• When users become editors, also grant them the agreement manager role (alternatively, require more trust)
• Record influxdb statistics about how much trust people give each other
• Record influxdb statistics about the distribution of editors to all group members
• Specify some criteria if the feature solves the problems successfully or whether we should consider to remove it again after some time

[tiltec]

A follow-up discussion with Janina, Tilmann and Tais revealed a potentially easier way to handle introductory pickups: we allow newcomers to join any pickup, but show them with a special color or badge. Editors should recognize this and add themselves to the pickup as well. If the pickup is not suited for introductions, it can be specified in the pickup comment or discussed in the pickup chat.

[nicksellen]

I updated the title to reflect the more focused approach we go with right now.