Applicant trial pickup proposal

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:

2 Likes

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
2 Likes

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.

2 Likes

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
2 Likes

I like your proposal; I can not think of any negative consequence of doing it like that right away.

2 Likes

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:

  • in the proposal, it’s a bit weird that you could be editor, but not approved (you could then approve yourself…)
  • partly the reason was that anyone can give trust, but it seemed useful to only let editors bestow this new approved role, but that still seems kinda confusing having this two parallel systems of role/status
  • I would if we can simplify it so users progress: newcomersapprovededitor?
  • perhaps changing the system so that only approved or editors can give trust? (I think we let anyone give trust to allow an overthrow of the group if some people dominated it, but maybe this is not needed/useful/realistic?)
  • … or a compromise approach: allow newcomers to give trust if they did an activity with the person (so prompting when giving feedback)
  • it would mean we can put more thought into improving the trust system too (e.g. for some groups the threshold should maybe be higher already)
  • I’m keeping in mind the idea to have roles per place too, but would not like to implement that yet

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.

3 Likes

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

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.

2 Likes

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”).

3 Likes

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

2 Likes

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?

2 Likes

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…

2 Likes

@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.

2 Likes