Proposal: a self-regulated hierarchy
Web of Trust
inspired by duniter's web of trust
(store contact, confilict management person, ...)
Step 1: collect data
Step 2: aggregating data
Step 3: using data
The text was updated successfully, but these errors were encountered:
I like the idea very much!
Some additional concerns:
As you are progressing quite nicely with the backend implementation, maybe we could clarify "Step 1". How would you display trust data to the affected user and to other users?
Further into the future, in response to your solution:
Generally nice idea, but needs to be smoothed around the edge cases. For example, if there is no trust and everybody is admin and then the first person gives trust, then there will be only one admin, excluding the trust giver. Seems a bit harsh ;)
This sounds a quite plausible analysis of it and as such I feel a bit unsure if this trust model is the right way to go (compared with the alternatives voting and/or undo - or would this compliment it?).
One approach would be to simply try it, but then it would seem useful to define some success criteria, and to replace it with an alternative system if it isn't working.
Which problem specifically that our user groups are facing is this solving? And perhaps in more concrete terms, can you think of a metric we can record to influxdb and graph in grafana that will show us if the feature is working? (or maybe it needs a more human process - feedback/trial within a particular group?).
Trust carrots are a nice idea to reinforce positive feedback to other group members and have the potential to build a web of trust and use that for assigning roles in a group. However, it needs significant testing with real groups before trust values should be used to assign roles in an automated fashion.
Unfortunately, people might not give trust carrots when they don't have any effect. So we need to find out one or more karrot user groups that are willing to test drive the trust carrots feature.
Further concerns with trust carrots:
(Short interlude) Bigger issues of karrot right now include:
One solution could be to have a role that allows removing users and this role would require a very high trust level. Until the trust carrots will be widely used, this could be set manually by server admins.
Related solutions to aforementioned issue of removing members:
I added steps to the implementation proposal #546 (comment) that are very closely related to this issue.
There are some key differences to this proposal:
I know that these choices are not optimal, but I think it makes it possible to implement a working feature soon and solve the problem with new members that don't know what they are allowed to click in a group.
Ideas from this threads are being implemented to address group newcomers - #546 is the more accurate issue for tracking this.
The more extended ideas discussed here about a trust system are not being implemented right now, although they could be implemented in the future. So, I close this issue now, but can be reopened if interest/implementation/ideas are renewed again!