A proposal for Combating Harrassment

The way I see it, harassment is a systemic and pervasive issue.
Anything built to address to harassment must be equally systemic and pervasive.

We are building a decentralized network on an open software model. To effectively address harassment, we need a solution that will decentralize the specialized knowledge and procedures necessary to mitigate harm as well as bring expert eyes onto the problem if it persists. As such, I propose we work to identify effective community response patterns both to improve the quality of our tools and to improve the level of preparedness of administrative and moderative users. These patterns can work as design documentation and feature rational as well as administrative and moderative response building blocks. If designed in this way, when a feature is implemented it will not only have a default behavior but also a default supportive strategy.

This project should be easy to fork so that communities can tailor it to suit their instance’s priorities. It should be dogfooded alongside beta releases and it should be treated in all other ways as a core (if API isolated) feature of Mastodon.

An imperfect analogy: We provide the ability for people to use mastodon with any interface they’d like, but we include one by default. This suite of advice would work much the same. I think we need to start viewing the intersection of the social and the technological sphere not only in the scope of the project but as core to it. The way people interface with the servers and each other as nodes should be as important to us as the way the clients and servers do.

We should build strong defaults and effectively distributed processes. These processes should be verified with probing tests. These processes should be open to critique and criticism in a collaborative environment. These processes should have regular success and failure analysis.

In short, my proposal is we treat moderation and administration procedures as code, give them the same status as a core module and integrate their feedback into our core design processes moving forward.


There are two related issues related to combating harrassment:

  • For one, some of us who are refugees from large social networking sites, do not want to jump from harrassment deluges under the umbrella of a police admin-controlled state

  • Secondly, federation enables us to regain a lost Holy Grail of the Internet - as the network grows, every organization (especially large social network) needs deal with hundreds of thousands or millions of (potentially misbehaving) users. That’s why the old model of fighting abuse (so called LART) no longer works.

Federation gives us a change to build a network based on small instances, where admins are still able to know their own users and react meaningfully to issues.

So, shall we need two steps:

  • making instance creation easy (just for a group of friends, if needed)
  • promote small, well-interconnected instances
1 Like

I don’t disagree, but I think a playbook is desirable. I’m not looking at a LART, I’m more looking for a resource to speed up discoverability of processes and best practices.
E.G.: A user on my instance is being harassed. I would like a resource that shows me how to effectively escalate through the tools available to me, how to effectively counter attempts to evade those tools and how to provide support to the user.

While the ideal may be small interconnected instances we will always have large instances, and we will always have inexperienced admins. I’m proposing we start creating a Knowlege Base that would be useful in those and other cases.

Are you looking for something like this?

Yes and No.
That’s more a list of resources and specific policy guidelines.
It doesn’t really give you any information on how to say, counter ban evasion or how to use those resources effectively. Publicly stating your policies is great and everything but I’d prefer to give someone a resource that directly helps with a practical guide. I’m not saying that those sort of policies would not be helpful, just that they are not giving information in the same context I’m considering.
This would be /part/ of that resource, but ideally this resource would be more holistic in scope and less specific in its procedural advication. It would likely be more writen to support specific actions and additionally provide a sample workflow.
“Here is a workflow diagram of typical interactions of this type:”
“Here are tools (both technical and social) available to deal with this sort of interaction.”
“Here is an example workflow of using these tools to rectify this interaction.”
“Here are common ways someone might try to subvert these tools.”
“Here is how to effectively respond to a pervasive threat.”
“Here are extra-instance resources you can draw on if the situation gets out of hand”

For block evasion they have this:

I encourage you to review Wikipedia’s policy and guides because I find them very (sometimes too much!) extensive, and it is difficult something that is … missing.

I am not suggesting re-using their policies or rules, but there is huge amount of experience there.

(full disclosure: I am one of the Polish Wikipedia “checkusers”)

I don’t doubt these resources are good, but they aren’t going to be directly relevant to Mastodon. I’d much rather hear how they address or do not address the items on the discussion table rather than read through them and attempt to determine your points. I don’t mind reading through portions, but I’d rather do so with commentary on how they demonstrate a good method rather than just to read through them.

Do they provide this sort of pattern first model?
I’ve not really seen it.
How do they handle discoverability of workflows?

They are useful resources, but I don’t think they speak for themselves, it seems a rather large burden to read through all of them. I’d really rather talk about the techniques they use to be useful with them cited as examples.

Sorry, I don’t know how to help you with this. What you are proposing here is reinventing the wheel.

There is already a wiki of administrative advice for Mastodon?

Not that not that I know of

I’m confused as to why this would be re-inventing the wheel then.
It follows that Mastodon, being decentralized and Wikipedia, being centralized, are going to have different challenges.Wikipedia’s documentation is extensive, but that is a significant barrier to use. It may have the sort of pattern-first browse method I’m thinking would significantly help discovery, but that’s not really reflected in any of the articles you’ve linked.

I understand Wikipedia has had to deal with this sort of challenge, but they also have a large userbase who has already traversed their network of documentation to create workflows that get transmitted to subsequent members. I do not know the first place to look for information regarding ban evasion. You do.

To Illustrate, It took reading through five articles to get from the Harassment page to the CheckUser page, and even then it’s just because I know that was the page I wanted to get to (It was a “see also” with five other options under the Sensitive issues and functionary actions subheading of Wikipedia:Dispute_resolution, gotten to through: Wikipedia:Harassment#Blocking_for_harassment -> Wikipedia:No_personal_attacks#Consequences_of_personal_attacks -> Wikipedia:Dispute_resolution#Resolving_user_conduct_disputes -> Wikipedia:CheckUser)

I’m not saying that we can’t get good resources from Wikipedia. I’m saying that I don’t think that as it is those resources aren’t well organized for getting someone up to speed quickly or providing good how-to advice for someone trying to figure out how to handle a situation as a Mastodon admin or moderator. Maybe this just requires some workflow pages to piece together the information that is needed, but I don’t think on their own and with no qualification, the Wikipedia articles make these arguments or imply the solution I was proposing.

Hense, Yes and No in response to your question.

Yes, those are good documentation and we should have something similar IMO for big instances.
No, they don’t do what I think is most important in making it easy to give an admin a blow by blow toolkit.

The original use of Wikis was documenting software design patterns.

I’m proposing we document harassment mitigation patterns.

What I thought would be useful to create a skeleton structure and for example link sample WP policies and guidelines to give some background information. Writing everything from scratch is a waste of time. Of course, if we find other resources of big sites documenting their policies in a similar way, but better - we should use that of course. I am directing to something I am familiar with, that’s all.

i don’t think you will be able to construct your decision tree without structuring types of problems (Wikipedia mentions for example personal attacks, legal threats etc., sockpuppeting as a block evasion technique, etc.). For that purpose, I do not think that Wikipedia is all that different (also, various language version constitute different instances and do not apply all rules of English Wikipedia uniformly).

My point was: I’d rather start with WP’s (and hopfully other sites’) work, structure it in a suitable way (your point is valid here!) and point of the differences (if any), but let’s not write everything from scratch. It is too early to build a case-by-case abuse fighting workflow, imho.

I agree that Wikipedia has a good starting point and could provide useful processes. I’m not familiar with them, and it’s a /large/ amount of reading to get familiar with them. That’s why I think it would be more useful if you gave examples (which you have here!) of their use.

I read the article on wikipedia:sockpuppeting, for instance, and that seems like a great starting point. It gives a way to identify the pattern, gives a contextualizing history of its use, and the mitigation tools available. That’s exactly the sort of organization I was thinking of.

(I think it suffers a bit from information overload though, and it’s really tied up in specific policy, but it’s obviously useful)

Yeah, don’t even try to get into the “Arbitration Committee” stuff… that’s a whole case law there :frowning: