Applicant trial pickup proposal

Different pickups they could choose from. If all pickups with slots available to applicants appear to all applicants, then it is probably less complex and easier to implement.

The idea with a button at the application page or chat is just to make it easier to add these applicant slots to specific pickups. I’m thinking of cases in which the group members responsible for or active with onboarding can choose the pickups they will bring applicants with more flexibility and more spontaneously. They could greet the person at the chat, suggest a date and create a slot right away on a pickup that fits their personal schedule.

But now I’m having second thoughts on whether this idea would make things smoother or not. :thinking:

Thanks @danveg for the proposal! It’s definitely a topic that has come up before.

The “newcomer” thing shows people with a green bit under their little profile icon:

The discussion here so far is to get users to be able to do the introductory pickups before they get accepted to the group if I understand? Whereas these previous discussions were based on the idea they are inside the group, but with a special status that says they are not quite ready to do pickups.

I think this is quite a big difference to consider whether they are in the group or not. Not just from the code perspective, but for the person and the group.

My personal leaning (although maybe I am biased by the code perspective), would be to accept them to the group, but to then work in making the newcomer/trust/editor things more suitable for this trial pickup use case.

There is one idea (from the PR linked above) where after you do a pickup with someone you are prompted to give them trust, and I could imagine building on that by adding trial pickups for newcomers, and in the feedback the non-newcomers can decide whether to give them trust to get them beyond their newcomer state.

So, given we already have newcomer status in karrot, maybe it could be to just to be able to configure each activity (or series) to be:

  • anyone can join (current situation)
  • only non-newcomers can join
  • non-newcomers can join normally, newcomers can join special trial slots

The code perspective is that we make a lot of assumptions that access to data is controlled by which group you are in, not by which groups you have an open application to. It already causes us some complication to allow the applying user to see the right user information. If we expanded on what applying users can do (as described in the initial proposal), then I would actually consider revisiting our earlier decision, and making even applying user in the group, but with a special “applying” role…

Sorry if this is hard to understand, I realise it could be a bit confusing to read!

In our weekly call last week we thought it would be a good idea to talk through this in our weekly call on 2020-11-29T11:00:00Z so if @danveg is available then, we can do that, otherwise maybe we schedule a special call at another time?


Thank you @nicksellen for summarizing what has happened on this topic already!

I have not thought about building on the existing newcomer feature before. I guess I have not totally understood how this works. For example, I have only assumed that this newcomer highlighting disappears after some time automatically; I have not made a connection to the trust system yet.

Enhancing the newcomer feature would even be the better option because you keep both application and trial activities separated from one another. For instance, there could be people only interested in some types of activities. In Foodsharing Luxembourg, we only require trial pickups, but before that you can already volunteer on events and look after Foodsharing Points. Therefore, it would be great to be able to configure it for each activity as you suggest.

I am still pondering on when the newcomer status goes away at the moment and whether this could be made configurable.

I will join the call.


Me neither actually :slight_smile: From reading [Info] Karrot trust system and user levels it seems everybody who is in the group but doesn’t have editor rights is a newcomer.

I clicked the discussion thread about it too [Discussion] Karrot trust system and user levels and it re-awakened all those topics! I think there are some good ideas in there that tie into this topic too. Basically, iterating on the trust system…

I’m glad it makes sense to you too :slight_smile: and your example is a good one.

Yup, which also relates to these three proposed enhancements to the trust system and the idea of expiring trust from @bruno.

I think it wasn’t really sensible so far to restrict what newcomers can do, as giving trust to users maybe isn’t well enough understood anyway, but if we improved these aspects (e.g. prompting users in more places, like when giving feedback… or maybe after they write their first message on the wall?) then maybe it becomes more viable to restrict certain functionality for them until that trust is gained.

There was also a proposal in the discussion to call it approval rather than trust.

Great :slight_smile: Maybe we can prepare something in advance to focus our discussion. It can get a bit overwhelming with all the related topics that feed into it… one idea would be to draw a map of the system as it is right now (borrowing a practise from our design process we’re doing at the moment).


@nicksellen Could you point me do an example of that kind of map please?

Sure! Here are 3 from the design sprint book ( pdf




… and you can see some of our maps over at Governance Meeting Notes - #5 by bruno - normally a bit more complex/messy, but I think that’s our world :slight_smile:

So, all of these ones are looking at “actors” (people of different types) having various interactions on their way to some kind of goal. So, in this case the boxes might have a new person, who applies to join, is accepted (or not), is able to participate a bit (in real life and/or online), and then gets some trust that enables them to some other pickups. Something like that.

I did a quick sketch…

A few points:

  • the trial pickup/activity bit would be the new bit, doesn’t currently exist, the rest already exists
  • maybe the term “editors” is not the best one, as it describes what they can do, not what they are… maybe “trusted”, or “approved” is more fitting?
  • I didn’t represent the possibility for activities to have these different options for different slots (anyone, only trusted, only newcomer), but it’s kind of implicit
  • I didn’t deal with how much trust is needed to be given
  • I wonder if the initial acceptance into the group could be put into the trust system somehow too… not sure how… (… could have an option to give trust when accepting them… if you already know them, for example)
  • as we try and facilitate discussions to happen at important points, I wonder if the is another place for a discussion, before/as they are “promoted” to trusted status
  • would be nice to have a bit more celebration aspect maybe, as people are accepted further (we have some notifications already, so maybe it’s OK)

meta: … would love to find a(n open source) tool to store these maps, so we can collaboratively edit, but also add comments/discussions on them over time … the whiteboard tools don’t seem quite right.


You are fast, @nicksellen! Thanks for preparing this topic. :slight_smile:

We had a very nice discussion last Sunday about this, the notes are here Weekly call about Karrot development 2019 - #89 :star:

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:

  • One option to add to the group settings to configure the number of trial pickups needed
  • How the filled slots look like - maybe with the “trial” as white overlay?
  • Number on member page of trial pickups done; This would disappear, and the name of the role would be added as soon as the treshold is reached.

Points to discuss

  • All from above :wink:
  • Which name should the additional role have? I suggest to call the new role “foodsaver”.
  • Impacts of the upcoming activities feature

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! :slight_smile:

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. :slight_smile:

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!

1 Like

@nicksellen @bruno The meeting will take place on 2020-12-22T17:00:00Z at Jitsi Meet Everybody interested is welcome! :slight_smile:


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

Today’s meeting notes

  • check in and expectations for meeting :slight_smile:
    • advance on the topic, not expecting ready made solution yet
    • make sure we have shared understanding of the topic and a clear concept (with details to refine later)
    • get a clearer picture of what the big open questions are, more than just adding another slot
  • agree duration
    • 1h from now (18:15 UTC)
  • recap and Daniel’s sketch
  • Questions to ponder on:
    • How much can a person in the “validated” role (Bob in Nick’s diagram) see?
      • activity slots would be available to 1) anyone, 2) only non-approved, 3) only approved
      • the rest of the information would be visible, as the application process is for deciding who should be in the group or not
      • what about participation in conflict resolutions?
      • set it in the activity (series, or one off activity) creation
    • What should the name of the “validated” role and “trial” activity?
      • aim for neutral name (i.e. not “foodsaver”)
      • “approved”?
      • or custom name?
      • “trial member” and “full member”
      • we have “newcomer” and “editor” roles already
      • “experienced”? gives a sense you’ve done something
    • It should be possible to not use this trial pickups feature at all!
      • if it’s working already fine, no need for it!
      • if the group is too small, just got started, also not much reason for it
      • instead of a threshold, have it on or off
    • How does this relate to the trust carrot system?
      • could actually get trust and be an edit but not be in validated role
      • seems like we would have 2 parallel systems of approval (trust carrots and trial activities)
      • use a different currency, such as “points”?
      • streamline into trust carrot system by having different levels based on number of carrots?
    • How does somebody get the “validated” role?
      • number of trial activities or approval button chat as in application process?
      • number would be set for the whole group, and the role would apply to the whole group not specific places
      • default could be 0, so every new member is marked as “approved” on joining, then as they understand karrot more they can increase the number
      • manual approval? going to the profile of the user to set certain roles (probably just “approved”), already automatically accept people if they’ve come from other groups
      • if the user misses the trial pickup (but the system still thinks they did it), it might need manual override
      • could integrate into the feedback step to give trust carrot, and other manual actions?
    • How should it look for the users to understand their “approved” status?
      • role showing on profile?
      • somewhere to see the status? transparency to see the process, for anyone to be able to see
      • maybe show on the avatar somehow?
      • could also be a chance to make the editor status clearer with the trust carrots
    • How does it relate to all activity types?
      • “Validate” role applies to all the different activity types at first.
      • It could be refined with more complex rules later if needed.
    • Would this work for other groups?
      • for Solikyl could feel like adding (yet) another step to application approvals, or maybe it works nicely! how would it feel to be kind of “half way” in the group? depending on how much is visible/hidden to non-“validated” people
        • could be useful for high demand pickups, to use trial ones to ensure the same people don’t always do the good ones, making it easier for new people to get involved
        • currently use the application chat to “manually” arrange two different trial pickups with two different people
      • seems like should also work for non-foodsaving groups, generally participating in some activities before getting full access, works as an intermediate level between joining a group and getting editing rights
    • Other types of activity slots?
      • could it be a base for organising activities that require a number of different roles, e.g. a cooking event needing 3 people cooking, 2 to welcome people, and 2 to lock up at the end, or during meetings having a faciliator and notary
      • perhaps they could be defined in the activity types?
      • could support people to participate at a lower level in the group, simpler tasks that can be done with more experienced people
      • could add a lot of complexity if adding a lot of activity slot roles and corresponding user roles?
      • use current activity system with different entries for the same time and the description field explaining the role
      • also thinking a bit how this relates to public events/information to make it clearer for people outside the group to know what is going on
  • idea for minimal viable implementation
    • to include
      • “activity slot roles”: three different ones: for anybody OR for “approved” people and for “non-approved” people (switch for displaying sliders in activity creation)
      • additional “approved” role (whatever to call it)
      • show on the profile page how many trial activities they did
      • editors can choose manually approve based on that
      • switch in group settings for activation/deactivation
        • if turned off: everybody has the role
        • turning on: sliders in activities and info on profile page appear
    • to leave out for now
      • additional stuff during the feedback process
      • ability to set automatic approval based on a threshold
      • everything else
      • putting the moon on a stick
  • next steps
    • reflection time
    • sketches needed for profile page and group settings, hopefully will help get the words right
    • discuss on forum, consider scheulding a call if seems useful
    • consider doing a prototyping phase (like we’re doing with the governance design process)
  • check out

Happy New Year! :four_leaf_clover:

Settings page

Note:The radio button should be a checkbox, which I could not find on another page to reuse for this prototype.

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.

1 Like

Activity settings

1 Like

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:

  • in groups that don’t use trial activities, the approval role is not important (although it would still be visible on the profile page… )
  • only when you configure an activity to use trial slots would it become relevant
  • then everybody will want to get approved status!
  • we could maybe default to giving all editors approved status? (to get it going…)
  • after that the process as described above would be used (editors have a button to give approval)

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:

  • release note / post explaining the feature
  • seeing a new approval section on a users profile
  • editing an activity and seeing a new option about the slots