Let’s start the design process for the ‘roles and permissions’ feature! This is part of our recent nlnet funding. My part is to facilitate the design process.
Join us on a 6 week journey! Here is a brief timeline, we’ll see how this goes:
CW: Calendar Week
CW 39 - Week 1: First meeting Stage 1
CW 40 - Week 2: Second meeting Stage 2
CW 41 - Week 3: (possibly send me more sketches)
CW 42 - Week 4: Third meeting Bring together
CW 43 - Week 5 Prototyping
CW 44 - Week 6: Karrot team meeting, feedback and decision
CW 45 → ready for development
If you’re interested, select your availabity for the first meeting in two weeks:
Intro text from funding application:
We will allow groups to create custom roles, configure them as they wish and support multiple methods by which people get a new role. In addition to getting a role by receiving trust from their fellow members, some roles are suitable for self-assignment. To make these more useful, it will be necessary to break apart the “editor” role into a flexible set of permissions, which can then be assigned to roles as the group desires, e.g. “manage group”, “manage places”, “manage activities”, “manage applications”, “start membership review”.
(some pieces of this can be up for discussion still, but that’s the rough idea)
Proposal: Tuesday October 8th 20:00 CEST <— that’s the day we meet again
Bruno: how to get more ppl in the call:
make a poll, contact more ppl. All days would work
Vasilis: best Oct 8, have summary of today’s outcome, build motivation: you want to jump on?
Nick: any of dates is fine, key question is how to get participation? how to factor the reality in? its hard to get participation, busy expert, be available to ppl specificially to get some input on the call, and then info distributed around, asking ppl to do async can be more tricky. Tomek, Dave, David exisisting intel/ideas they ve shared that we can bring in
Nathalie: can do all of these days, glad managed to put the banner up!
propose to have it in two weeks: do more advertising, 8th of Oct, advertise it to the community cafe.
lux wanted/introduced the approved, went wonky in the process
in solikyl we tried to introduce approved, was adopted in a few pickups, the was no high pressure to do the pickups
give approved role to everybody in group already when introducing it
changed in solikyl into sweedish
use the group logic to adapt to their context
make rules that can fit to what the group/community understands
Goal of the Process
We will allow groups to create custom roles, configure them as they wish and support multiple methods by which people get a new role.
Reactions/ Questions in regard to the goal
I like the goal and the flexibility as in how one gets a role (nathalie)
did wonder, why create custom roles? supporing the self-organisation (nick)
self-organisation connects with having custom roles, being accountable, taking responsibilty, we do have the request from the group to work on this, positive about the phrasing (vas)
nothing to add. agree with what was shared (bruno)
Difficult questions
What needs to be true in order to achieve the goal? How could we fail?
How might we…
1. get closer to having custom roles, by developing 2-3 prototype roles that groups can adapt to their needs, even by simply naming them the way that fits their needs
2. develop roles that can cover more complex needs regarding self-organisation and governance, yet be ‘easy’ to be adopted
3. make sure it seems useful for established groups and the roles they already have?
4. make it inviting for new groups to start assigning their roles?
5. not confuse people with all the different permissions and roles required?
6. make roles useful also as a working group?
7. make the trust system easy understandable?
8. integrate roles with the trust system?
9. respect the groups own voting mechanisms?
10. have a clear understanding of the difference between giving trust and voting?
11. make a lean system of permissions?
12. not overwhelm users with too many buttons?
13. encourage enagement through roles?
14. encourage healthy community organising rather than domination-based approaches?
15. ensure the groups actually use it and not confuse them?
16. handle who initially gets new roles? and subsequently? given groups have their own processes which are offline sometimes…
17. communicate about it to groups and to potential new self-organised groups? as it’s a unique/powerful part of karrot!
18. handle the varied and complex needs of the groups?
19. weave the roles/permissions into existing features of karrot?