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.
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.
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
The work comes in two parts really:
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)
Thanks @nicksellen for your work in the back-end and your UI suggestions!
I have a few comprehension questions:
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:
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…):
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:
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:
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:
Doing a bit more development on this, I’m wondering how this option we be, calling them:
“badges” has some use for at least sort of related things (e.g. https://openbadges.org/).
On your suggestions:
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:
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:
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:
Ok, I think that’s all for now
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?
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:
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
the trust system features 3 levels of permission
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
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
3 or 4 active group members
6 or more active group members
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.
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