We had a very nice discussion last Sunday about this, the notes are here Weekly call about Karrot development 2019 - #89 
The outcome was written as: Daniel will make some sketches to post on the forum, then another call in 10+ days
I was also add, if you are not finding time @danveg to do more sketches, we can also do some during the next call, more like a working call/session. We had quite good experience in our governance process of doing that.
Here are two mockups:
One pickup with two slots for foodsavers and one slot for a non-foodsaver on trial:
New slider that starts at 0 ( which is a bit confusing with the one above that starts at 1) in the pickup settings:
What else:
Points to discuss
What are your general availabilities? I will create a poll. @nicksellen I like your idea of doing some more sketches together during that meeting.
@nicksellen @tiltec @bruno Here is a poll to find a date to meet up for some discussion and prototyping around this topic. I have tagged you as you have been involved in this thread somehow. Feel free to forward the invite to others. Everybody is welcome! 
Oh, interested for sure! But typical that the time slots are not really fitting to me, I would just click maybe on all of them. Usually around 12 or later in the evening are better for me because the kid is asleep, but that doesn’t make it’s impossible to make other times work if I plan it well, so I’ll just see when the others can and try to join.
Btw, I like the mock-up! I have some comments…
I think I’d prefer to keep it open for manual approval of applications as it is now, because not always participation on pickups is a guarantee of a good introduction. Some groups might decide that some people would need more or less trial pickups than others applying to the same group.
Or just leave it as “applicant”, more neutral. Foodsaver can be confusing even for established foodsaving groups. For example, in Gothenburg and in Stockholm we use them differently, foodsaver in one is the member already on Karrot and on the other is the people who come get food that is distributed by members/volunteers.
I think it would fit very well!
@bruno Thanks for your feedback! I have added 20:00 options for all days in the poll, so feel free to add your availabilities.
I think I’d prefer to keep it open for manual approval of applications as it is now, because not always participation on pickups is a guarantee of a good introduction. Some groups might decide that some people would need more or less trial pickups than others applying to the same group.
Having different rules about the number of trial pickups needed is a good point for not setting a fixed number. I agree and like your idea of having a manual approval for these people as well.
Or just leave it as “applicant”, more neutral. Foodsaver can be confusing even for established foodsaving groups. For example, in Gothenburg and in Stockholm we use them differently, foodsaver in one is the member already on Karrot and on the other is the people who come get food that is distributed by members/volunteers.
Are all of your members foodavers? If not, what do your non-foodsavers do? For me, an applicant is a person that has just sent their application; They are not in the group yet. I suggest to leave this system as it is and to add the trial pickup feature in a way that groups can opt in to use it for members, i.e. for the people whose application is already accepted. To make it easier to spot members who have already done their trial pickups, I would call them differently. I hope this clarifies my mental model a bit as I imagine there might have been some confusion.
I think there is still some confusion here about how this is related to applications. I made a diagram to hopefully make it clear!
I think we should really get this totally clear, so if that doesn’t fit your thoughts, please share, and we can adapt it, or you can adapt to it, or we can keep more open multiple different solutions still!
@nicksellen @bruno The meeting will take place on 2020-12-22T17:00:00Z at Jitsi Meet Everybody interested is welcome!
Reminder for 25 minutes!
Date: 2020-12-22 17:00 UTC
Participants: Nick, Bruno, Daniel
Faciliator: everyone and yet no-one
Discussion: Applicant trial pickup proposal
Happy New Year! 
Settings page
Profile page
As soon as you are “approved”, both button and badge change their color, similarly to the karrot circle. If you click on the button, you see a popup with the text “x trial activities completed” followed by a list with the activities: type icon, date and place. Members with editor rights see a button to approve (or to disapprove if already approved) and are asked in another popup for confirmation.
I started looking at how we might implement this in the backend code now, and a few thoughts came up.
I wonder if we can manage without the group setting for trial activities the thinking was that in groups that don’t use it, we would need to give every user the approved role and that all the activities would required approved role by default.
…but I think we can manage without it like this:
The main advantage would be removing this big decision for a group of having to turn on trial activities, and removing the complexity of understanding how it works.
Perhaps the first time they would notice it would be:
I like your proposal; I can not think of any negative consequence of doing it like that right away.
I started coding on it → Add activities with role requirement by nicksellen · Pull Request #1105 · yunity/karrot-backend · GitHub
… and I get even more thoughts the more I put the topic in my brain.
I am wondering again if we can somehow unify the trust system with this again … a few thoughts off the top of my head for now:
ponder ponder!
… also reflecting on the original intention that highlighting newcomers was supposed to faciliate introductory pickups:
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.
I guess it didn’t quite work out this way, but does add more to my thought to try and unify newcomers/approved/editor into a coherent system.
I have read in the meeting notes of today’s weekly call that you have also talked about this topic there, so I link it here for easier reference: Weekly call about Karrot development - Date: 2021-01-18 12:00 (UTC+1)
- maybe have 3 trust carrots to get approval, and 5 to get editor (for example, would vary with group size)
While I think the flow newcomer -> approved -> editor can work, I think this needs more thought.
First, I think it is important to make these thresholds configurable, or, alternatively, have a way for groups to accept or reject such an automatic upgrade. For instance, in our group, people need to do 3 test pickups - and more if they do not turn up.
Second, I imagine new projects emerging in groups, which would ideally be represented by activities. However, a new member would have to transition through the approved role into the editor role to be able to create such an activity. In other words, this flow reduces flexibility in the case of different activities’ needs. For example, in our groups, only pickups require trials, whereas you could directly set up and manage a new Foodsharing Point. One option could be to configure what you can do with both approved and editor roles, which I am not totally convinced of and just put here as I have not had a better idea yet. 
Leading back to:
- in the proposal, it’s a bit weird that you could be editor, but not approved (you could then approve yourself…)
While this may seem a bit odd, I think that the group’s history would easily reveal such a misuse.
Ah, great you saw them!
Yup, thanks for the examples where it doesn’t quite fit. Perhaps there are many cases across the groups where a linear model like this is too simplistic. I think the aim from me behind that idea is not so much to make it linear, but to make it understandable - and perhaps the key thing here is to just display more clearly on the profile the roles that a user has, and how they might get ones that they don’t have.
The other bit I’d really like to feel clearer about is whether we can unify giving trust and manually assigning a user a role (which is also kind of like giving trust… in the case of our proposal above an editor manually approving a user is like an editor being able to give a special kind of trust that has power to immediately give them the new role…). But my head gets a bit fuzzy when I think about it, so I think the concept is not so clear to me yet. Maybe they are worth keeping as seperate concepts, or maybe they can be unified.
I really like the general approach of what we came up with though - being able to limit some activities to requiring a specific role (I actually programmed it in this more general way), and optionally allow people without that role to sign up for a trial (or “introduction”).
The threshold for becoming an editor has long been a question of debate, maybe worth revisiting the topic now that some time has passed: [Discussion] Karrot trust system and user levels
So either we start considering making the thresholds configurable for each group, or finding some magic number that works sufficiently well for the groups. So far it hasn’t been a big deal apparently with the 3 carrots to become an editor. One might wonder if that’s the case by adding another level. 1 carrot to approve and 3 to become an editor? 3 to approve and 5 to become an editor?
Anyhow, what I understood from our discussion at the weekly meeting is that approving (in other words, giving trust to approve someone) would be a manual process and not strictly connected to how many trial pickups the person has done. If the threshold for approval is low (1 or 2 carrots) and the threshold for becoming an editor is the same as now (3) or one more carrot (4), then I believe the following would not be an issue anymore:
The only issue with the case above would then be that the person could possibly join pickups.
Anyhow there might be a trade-off between making things easier to understand for groups and more flexible to different use cases.
This kind of got deadlocked trying to think about how the roles should work (which is the fate that led to group agreements never being usable). It is a tricky topic!
The other part of the backend API work (setting activities to have max trial slots and accepting trial participants) is actually done now.
I had a little ponder about it again, and wondered about a concept of “trust for role” (which has come up in past discussions before - you might trust someone to do one thing, but not anything… in general).
Here’s (literally) a back of an envelope sketch:
(… in this way it’s actually like a basic role voting election system … although no mechanism to remove the role again …)
A few points:
Maybe we schedule another call with @danveg and @bruno (and anybody else interested) soon to give it a kick into life again!
(it might be our new Freiburg team are up for building some nice UI/UX too! 
)
So, let me see if I get it… We’d start with the 2 following roles with their respective capabilities:
The roles are not strictly connected in my understanding, meaning that you can become an editor and not be approved and vice-versa?
I like the idea of having approved roles to specific places, I think it would be useful in our group, but I agree this should be left out now.
The idea can be very good if we work very carefully on the UI/UX. That is probably where we should start.
I’m up for a call, but for me at least in two weeks, or maybe March?
