Applicant trial pickup proposal

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.

1 Like

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:

  • initially might be best to keep to a set of fixed roles, but keeping a mind open to custom roles
  • … we could be starting down the path of creating “admin roles”! … if you can customize what they can do with a given role… need to refer back to our values here to make sure we don’t encode hierarchical practises without thinking
  • as this adds complexity to the trust system, and it’s already one of the more confusing features, so I think we really need some good UI/UX to make it clear to people how it works, two parts in particular I think about:
    1. making it clear on the profile the situation of a given user
    2. prompting to give trust in more places (e.g. activity feedback)
  • there is also some overlap with the concept of working groups (and also the use of places without a location as discussion/working groups), but maybe we don’t need to think about that right now
  • potentially also giving trust in the context of a role and a place could make sense, but again would like to leave that concept out if possible :slight_smile:

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! :crossed_fingers:)


So, let me see if I get it… We’d start with the 2 following roles with their respective capabilities:

  • approved - person can participate in every activity of the group and not just trial activities
  • editor - person can edit but not necessarily participate in every activity if the person is not approved?

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?


Yes! your description matches the concept I described.

And I very much agree on the “very carefully” caveat for the UI/UX part.

Well, I’ll be around for a call when we’re ready. Although, given @danveg gave a :heart: to my post, maybe we can proceed with engaging the Freiburgians if they are up for it…


@nicksellen @bruno I appreciate your initiative to drive this topic forward! I am available for another meeting. Alternatively, or additionally, feel free to involve the “Freiburgians”. :slight_smile:

1 Like

Hello @nicksellen @bruno Have you talked to the “Freiburgians” about this? I have not followed all other thread in detail.

1 Like

Thanks for the reminder, I just made a proposal for them to take it on, so let’s see!

I think the concept still seems good to me.

1 Like

At the request of the Freiburg group I created a GitHub issue to describe what is needed to be developed to progress this → Role based trust + activities · Issue #2361 · yunity/karrot-frontend · GitHub

It still seems a bit long! And hopefully still makes sense…

Would appreciate if @danveg, @bruno, or anybody elses wants to read through.


I’ve continued working on the backend part again → Add activities with role requirement by nicksellen · Pull Request #1105 · yunity/karrot-backend · GitHub :slight_smile:


The work comes in two parts really:

  1. limiting certain activities by role + open/trial participants (backend PR nearly ready)
  2. giving trust for particular roles (backend PR nearly ready)

I also just started on the UI part for 1, and would appreciate a bit of feedback where it makes sense so far. The UI for 2 has not been started.

This would be setting up an activity as it is now (access is “Any group member”):

… and this would be to set it up suitable for trial activities (access is “Group members with approved role” + setting the number of open slots to 2):

Personally, I think the concept of open slots might not be clear enough, and maybe it needs to be somehow combined within the bit where you specify “access”, so perhaps using the “guest” terminology, something like this:

(note: the reason I avoided the “trial” terminology is I think the feature is useful for more than just trials, so would limit the usage of it)

1 Like

Thanks @nicksellen for your work in the back-end and your UI suggestions!

I have a few comprehension questions:

  • Regarding the second slider “Max Open Slots” in your second picture: Would the maximum of this slider be the maximum number of slots defined with the first slider “Max Slots”? Or would there be 4 for group members with approved role and 2 additional ones?
  • Regarding your third picture: In case of the “Allow guests” toggle, the “Access” field would not be necessary, or would it? If so, in which scenario?

We (me, @bruno, @danveg) discussed this today (at the end of a prototype user testing call). And a few notes/thoughts for how to continue with the UI for restricted access:

  • making it clear which sliders are for which level of access is important (somehow grouping the access + slots slider together?)
  • having an activity preview (showing what it will look like) would be useful
  • guest is not a good term, open also isn’t always clear, depending on context… might need to keep the question unresolved for now…

I resumed work on this again now :slight_smile:

I’ll see what I can come up with…

Ok, trying again at the UI to address the points from above:

new bits restrict access by role and show preview, but otherwise as normal:

restrict by role, grouped next to the slots:

adding open slots (still unsure of good terminology):

and the preview bit (I put it behind a toggle, so it doesn’t look cluttered by default):

And a video talking you through it (as I can’t deploy it yet for you to try…):


Wow, thanks for the screenshots and the screencast! I find this flow really nice now. I also still don’t have a better term yet, but this is something we can easily change later.


I subsequently decided to go for the more ambitious change of allowing totally flexible role slots, so not just role + open, but any combination of roles. This will support more use cases.

This needed adding the role of “member” that everyone in the group will always have by definition (and when customized roles are available you could also set the name to something meaningful for the group, e.g. food saver).

Here’s a video showing some UI work, it’s a bit rough, but gives a sense:

A few points:

  • I think having the “restrict by role” toggle might still be useful, to kind of have a simple and more advanced mode
  • I wonder if it needs a negation option, e.g. these slots are for anyone without the approved role (as opposed to with the member role) … maybe that could be a future refinement

It is quite some complexity to add in frontend/backend, but I think it will be great, although also getting a bit overwhelmed with it! I don’t have a lot of time in my life to work on it, and have many other karrot things to do :confused:


I really like this iteration! It’s much less confusing than the previous one imo, and adding label to the hard-coded roles is a good solution. Maybe that could work well in the future when we implement custom roles for the group, which could be then suggested when creating the activity. Since this somehow sneaks in custom roles in activities, I wonder what @dave_goodman_jr thinks of it.

Sorry if I’m jumping ahead now, but it actually brings up a question relevant for this feature: Do we have the terminology right? I’d rather change role, as it is now, to permission or trust level (something like that), and change label to role. It makes more sense for me at least…

Yes, one of greatest concerns I have with this is how to make the UI simple enough and intuitive for smaller groups that won’t actually care about this at all. Maybe the toggle is a good way. Should the default be for members then?

I cannot think of a case in which that would be really really useful. You could still go around with what’s given now.

1 Like

I guess somehow, but not the kind of roles as we’ve discussed them so far (which are within a group, and could be like badges on your profile).

I agree the terminology can maybe be addressed, there are two things here to my mind:

  1. group-level “roles” - which would be part of the trust system, and apply to the user in the context of the whole group (e.g. “I trust x to have editor role”)
  2. activity-level “roles” - which are only about what people need to do for that specific activity (or series) (e.g. “we need 1 driver, and 2 collectors, and can take 1 trial person”) - which might also correspond to group-level “roles”

By adding the “label” field, I opened up the difference between these two, but we need to get really clear on them. If we are not clear, the users have no chance!

Also, how I’ve made it at the moment, you can only use each group-level role once per activity (so, for example you can’t have “cook” slots and “dishwasher” slots which are each restricted to “approved” role, you can only use the “approved” restriction once). That made some sense before I added the “label”, but less sense after…

Yup, members is equivalent to have it works now (anyone can join them).

The original case for this thread (trial pickups) is one case that I think fits that, so that only people without approved role can sign up to a trial slot (and only people with approved role can sign up to a normal slot). But I also agree it would be usable without the negation case.

So, right now here are my thoughts to progress:

  • keep the role terminology to the group-level ones
  • rename the activity-level ones “participant types” (currently “participant roles” in the code…)
  • keep the “label” field, but think of another name (perhaps “title”? or “name”? something else?)
  • add in an “advanced” toggle (not sure the best label though)
  • remove unique role/activity restriction

Doing a bit more development on this, I’m wondering how this option we be, calling them:

  • badge for the group-level “role”
  • role for the activity-level “role” (slot type)

“badges” has some use for at least sort of related things (e.g.

On your suggestions:

  • permission: sounds a bit too technical I think?
  • trust level: seems inaccurate to me, as it implies a linear hierarchy of levels (1, 2, 3, 4…etc), whereas how we’ve discussed it there could be different “badges” for different things/skills

I quite like “badge” right now!

Just to be clear on one thing, since we have only been throwing around some ideas in different places on the topic of roles… One thing I’ve imagined, since we did the governance design process, is that having some “badges” (custom-made defined on the group level) on the avatar and profile of a user could be very useful and informative for many reasons, and that they would not be necessarily connected to any trust system. Here’s some actual use case for them that I’ve seen in my group:

  • early on there’s been a need to identify and look for individuals with cars in my group for certain pickups
  • we’ve got people on the board (also important to identify for accountability purposes) and we’ve got people on the welcoming/onboarding team, which making them visible would facilitate some interactions and make clear they’re responsible for applications
  • we’ve got some other roles (ambassadors, food savers and hosts/distributors) which I’m not sure would be useful to as a badge

I’ve noticed other groups establish clear roles with their own terminology, and that seems to be a common pattern in any more or less organized group, but I’m not sure how and if they would benefit from the kind of badge system I described. It is also clear that these group-level roles often overlap with the activity-level roles, which is why it still makes sense (to me at least) to call both of them roles.

Any kind of custom role as in the examples I gave above would not necessarily be unlocked by any kind of trust system, but rather defined at the group level and self-assigned. If that is an idea worth developing, then I’d rather keep the term badge for the visual representation of a role, like an actual badge.

With the terms permission and trust level I tried to convey the idea of what the software actually does, so more descriptive and less abstract. I don’t think permission is too technical, and I fully agree that level is not the right word. Then maybe, trust permission? :thinking: :laughing:

It’s hard to find the right terms if we don’t have the concept very clear! But it’s a lot my fault for bringing in more ideas and speculation.