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.