I resumed work on this again now 
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ā¦):
3 Likes
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.
2 Likes
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 
2 Likes
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:
- 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ā)
- 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. https://openbadges.org/).
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? 
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.
Thanks @nicksellen and @bruno for pushing this forward! I like the direction in which it goes. Also our group could make use of such roles / badges as we have similar roles to what you, @bruno, described. 
I like your thoughts about how to progress, @nicksellen, and add two comments:
- I would use ānameā instead of ālabelā for that additional field as the latter sounds quite techy and ātitleā too formal to me.
- Instead of āadvancedā, you could use something like āmore fine-grained access rolesā.
1 Like
Great! Itās been a long journey, but getting close!
Actually, there are a few further changes now since that one, but much in the same direction:
A few points:
- from our call today we thought to entirely remove the name/label/title field, and just rely on having the free text description field. It wouldnāt be a big deal to add it back in later if it seems useful, Iām trying to reach an āacceptableā state now!
- I added ānewcomerā as an actual role, so this should fit your case well @danveg (newcomer is someone without any other roles, so as soon as they get editor, or approved, they will lose the newcomer role)
- still need to add a nice little explanation of what the roles mean
- we display the āmemberā role as āanyoneā for clarity
- so far I have āUse participant typesā for the āadvancedā mode, but still not convinced thatās a good name for itā¦ something along the lines of āmore fine-grained access rolesā could work tooā¦
Ok, I think thatās all for now
3 Likes
Getting better and better!
Adding newcomer goes full circle back to the original proposal. 
Could you remind us again what is necessary for the newcomer to become a member?
EDIT: I found the description of a newcomer here [Info] Karrot trust system and user levels and itās basically someone who doesnāt have enough trust to become an editor. I was thinking mostly about the badge (the green stuff under the userās pic/avatar). Is it always there until the person reaches the trust threshold for becoming an editor?
I just noticed a little grammatical inconsistency. āLimit to anyoneā doesnāt really sound correct. Then maybe we could change it to āAllowā, āWhoās allowedā, or āOpen toā. Or maybe a better idea?
1 Like
HI there! After the last karrot calls Iāve been thinking about this topic and admit that I found it quite confusing at times. To get more clarity I followed a more structured approach. One outcome: I actually donāt think this so much about roles
I found it really helpful do define a needs statement. This is what I came up with:
- We want to support an on-boading process in the software.
- We want a more advanced way to configure activities.
- We want to build on excisting ideas and donāt add massive changes on code level.
From my point of view the discussion drifted a bit from these needs since last december with new ones coming in (something about group agreements, idea to display different āgroup rolesā like ambassodor, coordinator). I suggest to separate topics again and stay with the on-boarding feature for this one and start another process for roles/ group agreements (or maybe work on existing thoughts, I donāt have an overview of ideas 
).
Having said this, I see this feature pretty much coming to an end. I tried to synthesize the previously mendtioned ideas to one proposal:
-
There is the possibiliy to customize activities
- you can enter an advanced mode
- it is possible to define different participant types with a custom description
- e.g. one person with cargo bike, 2 persons helping with sorting
-
the trust system features 3 levels of permission
- everyone can read and write messages, private and on walls
- newcomer: can join newcomer activities
- user: can join non-newcomer activities
- editor: can join non-newcomer activities & edit places and the group
-
the sign-up for activities can be limited based on the level of permission of the user
-
when not using the advanced mode for activities, anyone (meaning newcomer, user and editor level) can sign up
-
when using the advanced mode for activities it is possible
- to set activity slots where only newcomer can sign up
- to set activity slots where non-newcomer can sign up
- note: there is no option for āeditors onlyā
-
-
newcomer can not vote in a conflict resolution process
-
levels of permission based on group size (also see https://community.karrot.world/t/info-karrot-trust-system-and-user-levels/108)
-
1 or 2 active group members
newcomer- user: 0 trust needed
- editor: 1 trust needed
-
3 or 4 active group members
newcomer- user: 0 trust needed
- editor: 2 trust needed
-
6 or more active group members
- newcomer: 0 trust needed
- user: 1 trust needed
- editor: 3 trust needed
-
note: the newcomer level becomes only relevant starting with a group size of 6
-
Happy to hear if this is helpful! I also took more detailed notes along the way: Karrot newcomer - HedgeDoc which is maybe more a summary of this thread.
2 Likes
Great job organizing the ideas floating around here @nathalie ! It helped me see that this feature, as itās been developed so far by @nicksellen, doesnāt really need to be explained at all in terms of roles, and it covers already some use cases itās been designed for.
I think it can be a good basis for developing custom roles for groups in the future, but weāve been thinking a few steps ahead and that brings some confusion, so better to save some of the things said here to a new feature and thread for discussion.
It seems to me that you have described the latest version developed by Nick, except that you use the word user instead of approved. Any particular thoughts on that? Iām not particularly happy with neither to be honest but cannot come up any better idea myself.
Iām not sure that the trust system with the different levels of permission has been developed like this in this feature so far, but it makes sense to me that itās based on group size like the trust for editor works now. I think we need to figure out what happens when the group grows in size: should the newcomer āstatusā be invisible until the group reaches the number of 6? Should the group get some notification or explanation tip when it does become available?
Thereās still some work to be done on the UI, like in the example above and for giving trust. On the latter I think Nickās sketch (below again) is fine, but getting rid of the Trust for role part and just use Trust forā¦
Thanks 
Is it? Thatās good, I tried to align it with what was already done. Although I didnāt really find a describtion of the āwhole pictureā, thatās why I thought itās a good idea at this point to synthesize ideas. A more detailed look on the different ideas is in the pad I linked at the endā¦
Maybe itās a bit confusing to change the terminology at this point, I also could have just stayed with approved as a working term. In general I would rather go with a descriptive term, donāt really like approved, but not super convinced with user either.
Here I see a difference to what is written in the proposal. In the proposal it would build up on each other, following a consecutive order: newcomer ā user ā editor, based on the number of karrots. Of course this can be discussed and changed, thatās the whole point of it
Hey, thanks so much for the summarizing @nathalie. I find that really helpful. We often have complex weaving of multiple needs an corresponding technical features that might support them.
Iād first like to correct a few bits of the description:
- There is the possibiliy to customize activities
- you can enter an advanced mode
- it is possible to define different participant types with a custom description
- e.g. one person with cargo bike, 2 persons helping with sorting
- there are 4 roles
- member (everyone) can read and write messages, private and on walls
- newcomer: anyone who doesnāt have another role yet
- approved if trusted for this role (by an editor)
- editor: if trusted for this role, will be able to edit place/group information
- note: these are currently called roles, but that could change
- note: in future development they would be customizable per-group
- the sign-up for activities can be limited based on the roles of the user
- when not using the advanced mode for activities, anyone can sign up
- when using the advanced mode for activities it is possible
- to set activity slots where a specific role is required
- to have multiple slot types (aka. participant types)
- newcomer can not vote in a conflict resolution process
- note: not sure on thisā¦ I think they can?
- levels of permission based on group size (also see [Info] Karrot trust system and user levels)
- 1 or 2 active group members
- approved: ? trust from editors needed
- editor: 1 trust needed
- 3 or 4 active group members
- approved ? trust from editors needed
- editor: 2 trust needed
- 6 or more active group members
- approved: ? trust from editors needed
- editor: 3 trust needed
- 1 or 2 active group members
A few thoughts/points:
- I keep referring to these things as ārolesā just because thatās what they are currently called in the software, and the interface, not because they need to stay that way
- the āroleā for everyone is called āmemberā, but displayed as āeveryoneā to make it clearer, some groups might consider people only become a āmemberā when they have done some trialsā¦ so could be confusing, but āmemberā builds on existing concept in the software that āall the people in the group are members of that groupā
- the question of āwhich roles exist and how do people get themā can be considered independently (from a technical implementation perspective) from the ācreate different activity slots and limit them by roleā
- I think it might be good to only add this approved role for groups that specifically want it right now (e.g. Luxembourg, and Gothenburg?), so we can see how it works out, and maybe wait for custom roles to be developed for the rest of the groupsā¦ (and weāve understood a bit more what weāre intending with them in a wider sense)
- with custom roles all these words (member, editor, approved, and more) could/should be customizable per-group to use what makes sense in the context of a group
And a specific reply:
That was not intended, the role-system in karrot doesnāt have any concept of this progression (currently, or in my work-in-progress for these changes). I donāt recall discussing having them as a progression before.
Interesting. And Iām glad you found it somewhat helpful what I wrote!
Iām still guessing a bit where in the process we are and now I feel that not only there is an existing proposal, but itās also mostly decided.
And I donāt think itās helpful to start citing all the previous posts now where I read about an idea
I didnāt specifically write my opinion, I can add a few thoughts:
- Iām generally fine in which direction it is going
- maybe itās useful to add the"applicant" as a role (at least in theory)
- still the progression applicant - newcomer - approved - editor seems natural to me, at least in activity heavy groups where basically everyone is asked to do the activity at least once (I think thatās the practice in most foodsharing groups).
- But I also see the advantage to be more explicit about it and give trust per āroleā. Doing that there are different ways of contributing. So it can happen that someone is really good at organising and therefore trusted as an editor, but was never approved for the specific activity-doing part.
- still there is this little progression of applicant - newcomer - person with role
- on the terminology, I would really like to āsaveā the term role for this group-roles to avoid future confusion. Or maybe name it karrot-role to indicate it is somehow connected to the software whereas other potential roles/ group-roles (e.g. coordinator, facilitator) are rather social. Than we can add descriptions per role and the duration is āas long as person A holds X trustā
- How karrot is now I would say you enter already with āapprovedā. So even if there technically is a newcomer-role, I donāt think itās an adequat term. Thatās the reason why the application process is relevant and thatās the place where the trial pick-ups are done. With this feature this is supposed to happen inside the group. As I see it the treshhold to get in the group is lowered, so I tend to restrict some power for newcomers e.g. the voting in conflict resolution in order to protect the existing group. Or maybe Iām making the wrong assumption, there still will be some kind of process to be accepted to the group, only the activity part is now inside the group (and people are generally good and to be trusted ). I noticed I started to question the definition of āmemberā and creating a āgroup within the groupā but actually I like the idea that inside the group everyone is equally a member, only there are some rules about activity-doing and editing.
I was describing what is already coded now (but not merged yet - itās work-in-progress), but we can still decide to rethink it before proceeding, or continue with what has been developed so far.
My preference would be to get what has already been developed merged as soon as possible, and iterate it from there, as itās a lot easier for people to understand what weāre talking about when itās something that can be clicked around, rather than text descriptions, voice conversations, envelope drawings, and screen recordings.
It would be a big change to make the applicant a role, as the way we developed the application feature is that they are not actually in the group during that time. Lots of parts of the software decide access based on being a group member (as the database sees it), rather than any roles in the group.
This post explains that a bit more with an image ā Applicant trial pickup proposal - #17 by nicksellen
ā¦ it could be though if we have this deeper use of roles (or whatever we call them), that it makes sense to change that, but thatās how things stand right now.
I really like this thinking about roles in the context of a group, I would really like to engage in this in a next iteration of the work though. roles is already in use in the current deployment of karrot - although thatās mostly just in the code, it doesnāt appear much in the interface (actually the interface has text like ālost editing permissionsā).
This would depend a lot on how a group decides to configure itās activities, as ultimately we need to accommodate quite a wide range of ways that groups want to organise their onboarding process.
For many groups it kind of makes sense to get a limited access to the group after being accepted (can read and write posts on the wall, join more public/open events, etc) and that is a good place to co-ordinate trial pickups. Thatās kind of how the newcomer thing (as it is now) came about, ā¦ so at least mark the people that have just joined, as they might need extra helpā¦ and to control everything using social processes rather than the technical ones (that we now develop).
I hope my text made enough sense! Itās quite a complex topic, and touches on many areas. I guess my immediate focus is: āhow do I get what is already developed, but not merged, into a state where itās in an acceptable state to mergeā
Meta: I think one part is to get to a common language, like generally on this software topic. Iām just thinking how much a call would be a more supportive environment. Making a write-up of my thoughts actually is a bit of effort to me. But your text @nicksellen does make sense!
on this one, I wanted to make clear that I rather meant something like ādonāt forget how the applicant plays into the onboarding processā and not āmaking the applicant part of the groupā. How I got it, the latter was quite quickly dismissed in the process.
But anyway, as I see the feature now, itās not a redesign of the newcomer-role (what I was maybe initially more thinking about), but rather adding a new role (with a second trust giving system) besides āeditorā, which is āapprovedā, to allow these activity-restrictions. Iām fine going in this directions with those karrot-roles.
Looking at the proposal again:
- newcomer can vote in a conflict resolution process ā Iām fine with leaving this to the status quo
- approved: if trusted for this role (by an editor) ā any reason for only editors? Iād propose editor and other approved
- to set activity slots where a specific role is required ā in my proposal I had this comment that there is no editors-only option and I see no reason to implement this (maybe you can give me one). I would rather like to see it as described, cause only newcomer and approved are āactivity-orientedā
- to set activity slots where only newcomer can sign up
- to set activity slots where only approved can sign up
- Iād go for always 1 trust needed to be approved
A bit of an outlook: I actually really like what I saw about the group agreements feature and I would rather work on that and afterwards come back to the roles topic, cause how I see it any futher group-roles are basically group agreements.
I agree.
Yes, go for it! To me itās already in a very acceptable state to merge
Hello, it took me some time to catch up. Thanks for all your efforts! It looks really good to me already.
Concerning the discussion about who approves: My concern is that not every member should be able to approve because in our group, for example, we have designated a person who checks whether the new person has fulfilled all criteria before approving them.