From da07053696cd0358db0cd5827dd4ed1d9a0e8a2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kat=20March=C3=A1n?= Date: Tue, 26 Sep 2017 15:31:49 -0700 Subject: [PATCH] rfc: add spec for public Moderation log [ci skip] --- rfcs/moderation-log.md | 98 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 rfcs/moderation-log.md diff --git a/rfcs/moderation-log.md b/rfcs/moderation-log.md new file mode 100644 index 0000000000..eaccc94674 --- /dev/null +++ b/rfcs/moderation-log.md @@ -0,0 +1,98 @@ +# RFC - Moderation Action Log + +Ever since the [Ayo.js Code of +Conduct](https://github.com/ayojs/ayo/blob/latest/CODE_OF_CONDUCT.md) was +ratified, the Moderation Team has been entrusted with following the processes +described there in order to promote the general health and safety of the +community. + +A reality of this is that, while the documented moderation process emphasizes +the importance of community members solving conflicts amongst themselves, the +Moderation Team itself has to get involved sometimes and apply the further +enforcement procedures. + +### Summary of RFC Actions + +* Create a moderation log spreadsheet with the required columns. +* Grant full public read access to anyone with the link. +* Grant full edit access to Moderation Team members. +* Add a link to the log directly to `CODE_OF_CONDUCT.md`. + +### Keeping a Log + +In the interest of openness and transparency, this RFC proposes that the +Moderation Team be required to keep a **public** log of actions taken whenever +they become involved in various situation. An important part of this goal is to +increase community confidence in the moderation process, as well as act as +concrete documentation whenever disagreement or confusion happens about whether +the actions taken were correct, or whether the process should be changed after +running into a particular situation. This does need to be balanced with other +concerns, though, such as privacy, and should be designed such that it does not +encourage further harassment or defamation of anyone involved. + +### Keeping a Balance + +This RFC intends to balance the following specific concerns: + +* Openness about process: people should have a good idea of exactly how often and in what sorts of situations the Moderation Team has gotten involved. +* Recordkeeping: For situations such as repeated violations (or lack thereof), or future analysis that can help the moderation process improve or change based on actual data. +* Privacy/Sensitivity: Some details about moderation are often private, and should stay that way. +* Prevent Further Harm: The log must not be a source of threat for users. It should not be seen or treated as a wall of shame of any sort. + +### Log Structure + +The log should be a spreadsheet with public read access, and edit access only +available to active members of the Moderation Team. Any time an event happens, +the log should be updated as soon as possible by the Moderation Team members +involved. + +The log will include the following columns: + +* Date - date of the *enforcement action* (not the event itself) +* Action Taken - official action taken by the moderation team, in accordance with the moderation process. +* Venue - Where the event that triggered moderation happened: Github, Discord, Conference, etc. +* Moderator(s) - Moderation Team member or members who took the action. +* URL - If the event happened on a URL-linkable **PUBLIC** location (such as Github), the URL of the issue or issue comment in question. +* Details - Freeform description of the event, with specific parties omitted. + This should be as dry and neutral as possible. This should not include names + of any involved parties except Moderators unless the event is publicly + documented elsewhere (such as on GitHub). + +### Scrubbing the Log + +In some cases, log entries may include personal details or other information +which may unfairly target one or more of the people involved. In these cases, +general community members may contact the Moderation Team through either public +or private channels to request a log line be scrubbed of details. + +When a log line is scrubbed, the URL and Details field should be cleared and the +Details field replaced with `[scrubbed on request]`. Unless circumstances are +considered to be extreme enough, the rest of the line, including the date, the +action, the venue, and the involved moderators, should be left intact. The +requestor may also ask that only certain details be scrubbed from the +description. + +Log lines should only be scrubbed when there is reason to believe that its +existence would: + +1. Cause harm to a community member, either physical, emotional, or career-wise. +2. Could be considered defamatory. +3. Reveals private details or information. +4. Incite targeted harassment in any way to any of the involved parties. + +There are some exception where even with the above, a scrub request may be +refused, at the discretion of the Moderation Team: + +1. The violation by the moderatee is extreme enough that they can be considered +a risk to the community. Concretely: physical violence, sexual assault, +large-scale inciting of targeted harassment campaigns, etc. +2. The edit requested would result in falsification of the log - that is, lying +about what actually happened. +3. The requestor is a third party uninvolved and unconnected to anyone the log +refers to. Requests may only be submitted by participants or their +representatives. + +The Moderation Team reserves the right to scrub any existing lines at will, +based on team consensus, at their best judgment, but unless the matter is +absolutely extreme, must retain basic information about events as mentioned +above.