-
-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion to democratise the Server Covenant list #344
Comments
I think this is a great idea, the instance I operate contacted joinmastodon over 3 months ago (With a reminder sent 1 month ago in case it got lost), but we've yet to receive any response. Having a covenant panel would reduce the burden of Mastodon gGmbH and time spent managing this list, while also greatly improving response rates to changes and additions to the website. |
I would also add to this that it would be cool to have links to other (pre-approved) lists. |
I really like this idea in general. Personally, I think a 60/40 threshold might be a bit too low though. As I understand it, the main thing required to become part of the Mastodon covenant are a strong effort to moderate hate speech and discrimination, so very basic ground rules basically. If there are still 40% of voters who don't think that is happening on the server, that seems like a worrying amount to me. |
I also encourage Mastodon gGmbH to contact other entities in the free software/free knowledge world where we've had to navigate similar issues. For example in Wikimedia we have the Language committee to admit new subdomains: it's by no means perfect, but it's been refined with 20 years of painful experience. |
Hello.
Overview
This is a proposal to ensure that the list of servers in the Mastodon Server Covenant receives regular updates in a fair and timely way. The decision making would be appointed to an elected group of volunteers overseen by Mastodon gGmbH.
Goals
Today's process
As of the time of writing, Mastodon gGmbH controls the entire flow for the Mastodon Server Covenant. From making the rules, to accepting submissions, to reviewing and publishing the final list.
There is little transparency in this process for server admins. It seems like it's not always a high priority to keep this list updated.
Here's the flow:
Decentralising the process with the introduction of the Mastodon Covenant Panel
In order to resolve common frustrations in today's process, it seems appropriate to decentralise the flow a little. This frees up some of the time and responsibility of Mastodon gGmbH, yet still gives them some control.
Shortly after the elected panel is formed, both Mastodon gGmbH and the Covenant Panel review and publish the rules for being part of the covenant server listing. This gives the chance to introduce new rules, alter existing ones, or remove out-dated rules.
Servers can be nominated by posting a new GitHub thread. This will allow the panel to review and discuss the submission in a transparent way and vote YES or NO to accepting the server into the covenant within a set timeframe. This also allows for discussion on changes the server needs to make if they wish to be included and a clear accountability from both sides. There should be a clear majority vote (60/40) before a submission is accepted.
A public GitHub listing will also mean there is a space to "Report" servers that shouldn't be in the Covenant and these can equally be reviewed and voted on by the panel based on whether the server meets the pre-agreed rules (and not the latest #FediBlock drama).
Periodically (every 30 days, for example), the Mastodon Covenant Panel can push the latest changes to Mastodon gGmbH for publication on the site and API to be pulled by third-party devs. There could be a review process by Mastodon gGmbH at this point if they needed it for whatever reason.
Conclusion
Would love to hear other people's thoughts and opinions on this. It might not be something Mastodon gGmbH wishes to consider right now - but I thought I would throw it forward as a suggestion anyway.
The text was updated successfully, but these errors were encountered: