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:
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?
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
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.
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 withoutapproved role can sign up to a trial slot (and only people withapproved 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)
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”.
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…
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?