Here’s what we have so far for the governing documents, also pasted below. Feedback / additions / changes would be much appreciated.
Lemmy Council
- A group of lemmy developers and users that use a well-defined democratic process to steer the project in a positive direction, keep it aligned to community goals, and resolve conflicts.
Voting / Decision-Making
Process
- Anything is open for discussion
- Voting done through matrix chat reacts (thumbs up/thumbs down)
- Require a simple majority for votes. (Maybe 2/3rds for more debated decisions).
- Once a decision is reached democratically, the dicision is binding and all group members have to follow it
- All members of the Lemmy council have equal voting power.
- Voting must stay open for at least 2 days.
What gets voted on
- Membership (joining, removing)
- Coding direction
- Priorities / Emphasis
- Controversial features (For example, an unpopular feature should be removed)
- Communication mediums
- Conflict resolution
- dev.lemmy.ml (domain and server)
- lemmy.ml and subdomains (excluding communism.lemmy.ml)
- git repo including mirrors (on github, gitea, etc)
- Any official accounts of the Lemmy project, for example the Mastodon account or the Liberapay account
- Changes to these rules
Joining
- We use the following process: anyone who is active around Lemmy can recommend any other active person to join the council. This has to be approved by a majority of the council.
- Active users are defined as those who contribute to Lemmy in some way for at least an hour per week on average, doing things like reporting bugs, discussing rules and features, translating, promoting, developing, or doing other things that aim to improve Lemmy as a whole. -> people should have joined at least a month ago.
- The member list is public.
- Note: we would like to have a process where community members can elect candidates for the council, but this is not realistic because a single user could easily create multiple accounts and cheat the vote.
- Limit growth to one new member per month at most.
Removing members
- Inactive members should be removed from the council after a few months of inactivity, and after receiving a notification about this.
- Members that dont follow binding council decisions should be removed.
- Any member can be removed in a vote.
Goals
- We encourage the membership of groups such as LGBT, religious or ethnic minorities, abuse victims, etc etc, and strive to create a safe space for them to express their opinions. We also support measures to increase participation by the previously mentioned groups.
- The following are banned, and will always be harshly punished: fascism, abuse, racism, sexism, etc etc,
Communication
- A private Matrix chat for all council members.
- (Once private communities are done) A private community on dev.lemmy.ml for issues.
Member List / Contact Info
General Contact @LemmyDev Mastodon
What an interesting idea!
Though I have a feeling it goes a bit against the spirit of decentralization ideology. As we’ve seen with Reddit these sort of groups get corrupted very quickly and I feel that open anarchy as opposed to elected democracy is a better fit for steering open projects.
In other words - wouldn’t it be better to be more open and include everyone in this?
I feel that has been the biggest mistakes mastodon has made - centralizing around private inner dev circles and .social pod which included grey tactics like shadow bans and personality cults.
As noted in the text, we would like to include everyone, but that is not realistic because we are on the internet, and a single person could easily create multiple accounts to cheat in votes. So what we have here seems like the next best option, but we are open to suggestions.
Afaik Mastodon works differently, there Eugen has complete control, and decides what gets implemented or not. Our goal is to have a system where the decisions of devs can always be overruled if there are good arguments against them (once there are more council members).
It might be helpful to make sure there’s an ideological balance among group members. This could help prevent biased moderation/leadership.
i think it’s important to have at least some governance, certainly over this instance and the software it runs. People are always free to make forks, but (especially for federation) there should be something that can be agreed on