Csardelacal
commented
2 years ago I know all of these suggestions stem from a good place. But I still think that they over-engineer the issue and are a solution looking for a problem. I also think that the fact that it suggests being capped at 10 members is another obvious limitation.
This may be an unpopular opinion, but I still think that having two distinct roles among members of a group is a requirement. And there's a number of reasons for it:
-
Trust: In a group where you're contributing, you establish trust with the management. Whether it's the maintainer of a repository, the administrator of a forum or similar. It would be a costly due diligence for both members and administrators to vet members.
-
Responsibility: This is a side effect of the first. But if I entrust somebody they'll manage something properly and then they don't, I will want somebody to take responsibility. The current system removes responsibility from members because nobody is responsible for anything happening in the group. I have nobody to escalate issues to.
-
Ease of use: It's incredibly easy to set-up and understand a traditional structure. New members join, can see who manages the group and contribute. It just works as the users expect it.
Here's an example. Imagine a project that I've been contributing starts doing fishy things and I think I could manage it better. I can fork the repository, rename it and create a new Liberapay with my own terms, add the good team members and compete for the donations. If I actually do better than the existing project I will do better and get the supporters to move.
I would encourage reviewing the proposal from a practical and not a technical standpoint.
There have been some discussions around teams happening in https://github.com/liberapay/liberapay.com/issues/1948 and https://github.com/liberapay/liberapay.com/issues/2094 which are still ongoing and will most likely continue for a while as the suggestions there are fairly complex and it takes some work to figure out all the details.
While the conversation continues in those threads, this issue proposes a simpler and straightforward approach to teams, based on unanimous consensus between members.
That is, when a new member is invited into the team, every existing member has to give their approval. Similarly, in the unfortunate event that the team wants to kick a member this can be done only if all the members except the one being kicked give their approval. Note there's a special case when the team has 2 members, more on that later.
Income takes could be set by each member using the already existing system.
The obvious disadvantage with this format is that teams cannot scale to a very large number of members, as it's impossible for everyone to know and work with everyone else beyond e.g. 10 members, but we can worry about that limitation when we reach it.
About teams with 2 members: As is the case with everything related to teams, there are lots of ways to go about this. I'll propose here the simplest approach that came to mind, when a team has 2 members it enters a special state in which kicking is deadlocked, i.e. the members are stuck together in the team being unable to kick each other, and the takes are fixed to 50-50.
Lastly, this team structure wouldn't replace the existing format, but rather act as an alternative to it along with any other future ones and people who want to collaborate via Liberapay could pick the one which suits them best.