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.
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
ā¦ 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: newcomers ā approved ā editor?
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.
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.
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.
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ā).
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.
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:
making it clear on the profile the situation of a given user
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
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! )
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 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ā.
ā¦ 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:
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ā¦
)
to my post, maybe we can proceed with engaging the Freiburgians if they are up for itā¦
