freeCodeCamp Moderator Guidelines

freeCodeCamp Moderator Guidelines


The Pillars of Moderation

Above all else, remember that your purpose as a moderator is to serve our community:

  • Listen
  • Be Helpful
  • Don’t abuse your power

A note on free speech

Sometimes people will defend something offensive or incendiary that they said as “free speech.”

This XKCD comic perfectly summarizes most communities’ thoughts on free speech. So if someone defends something they’re saying as “free speech” feel free to send it to them.

Moderating Facebook

If you see anything that seems to break our Code of Conduct, you should delete it.

Sometimes people will post things that they think are funny. They don’t realize that what they said or what they shared could be interpreted as offensive. In these cases, their post should be deleted, but the person who posted it doesn’t necessarily need to be banned. By getting their post deleted, they will hopefully come to understand that what they posted was inappropriate.

But if it is an egregious offense that can’t reasonably be attributed to a cultural difference or a misunderstanding of the English language, then you should strongly consider blocking the member from the Facebook group.

Moderating Gitter

Here’s how moderators deal with violations of our Code of Conduct on Gitter:

  1. Make sure it was intended to violate the Code of Conduct.
    Not all violations of the CoC were intended as such. A new camper might post a large amount of code for help, not knowing that this can be considered spamming. A friendly request to use services like Codepen or Pastebin next time, is sufficient in these cases.

  2. If the camper clearly violates the Code of Conduct, the moderator will proceed as follows:

  • Ask yourself if the offence warrants a ban.
    Keep in mind that a ban is a pretty severe punishment. It can put campers on the offence and cause a lot more trouble than needed. Sometimes words can be far more effective and keep everyone happy in the long run. Do you think you can solve the issue by talking privately with the camper? Perhaps a kick from the room to send a clear message will do?
  • If you decide to ban the offending camper, don’t warn or threaten them. Instead, quietly ban them from the room(s), including the Admin room.
  • Send the offending camper the following private message:
This is a standard message notifying you that I had to temporarily ban you from freeCodeCamp's chat rooms.

I am a moderator acting on behalf of our open source community. I can consider unbanning you, but I need you to do something first.

1. Read our [**Code of Conduct**](
2. Please confirm that you've read it.
3. Explain to me why you think I should unban you.
  • Report a short summery of the event and how they responded to it in the admin room. Here’s an example of what such summaries might look like:
Banned: _@username_
Reason(s): _Spamming, trolling_
Evidence: _One or more links to the offending message(s)_
CoC: _Sent_

I’ve unbanned ` @username `. I sent them the Code of Conduct. They just today realized they were banned and apologized for what they did.
  • Based on the offenders reply, the moderator will decide whether to unban the offending camper. If they seem respectful and apologetic, the moderator can unban them. As a matter of policy, moderators will be polite during this process, no matter how poorly the offending camper has behaved.
  1. How to ban and/or unban
  • In order to ban someone, type the following into the chat room:

/ban @username

  • If they cooperate, you can later unban them with:

/unban @username

  • This only works for that single room, so you may need to ban them more than one place.

    If a camper continues to jump from room to room causing problems, moderators can request a global ban in the admin room.

  1. Deleting messages
    Moderators have the ability to delete messages on Gitter. They should only exercise this ability in three very specific situations:
  • Someone has posted a pornographic or graphically violent image.

  • Someone has posted a link or code that is malicious in nature, and could harm other campers who click on it.

  • Someone has flooded the chat with lots of spam messages to such an extreme extent (usually involving bots) as to render chat completely unusable.

    In all other situations - even situations where the code of conduct is violated - Moderators should not delete the message as these are an important historic record.

  1. Don’t use @/all
    Don’t use @/all under any circumstances! Every single person in that chat room will get a notification. In some cases, tens of thousands of people.
    Instead, if you want people to see an announcement, use a heading text size. You can do this by putting a # in front of your first sentence.

  2. Don’t threaten to ban
    If a camper is breaking the code of conduct, don’t threaten to ban them, and never warn them in public. Instead, talk to them privately, or quietly ban them. Then private message them and proceed according to the above protocol. No one else in the room needs to know that you banned the person. If a violation was clearly unintended and doesn’t warrant a ban or private conversation, make the offending camper aware of his / her actions without making it come across as a warning. For example:

  • Camper posts a wall of code to request help

    Moderator: @username Please use Codepen or Pastebin when posting large amounts of code.

  • Or if you really have to explain why:

    Moderator: @username Please use Codepen or Pastebin when posting large amounts of code, because it disrupts the chat for everyone and could be considered spamming according to our Code of Conduct.

  1. Don’t brag about being a moderator
    Do not see yourself as above the community. You are the community. And the community has trusted you to help protect something rare that we all share - a welcoming place for new developers.
    If you brag about being a moderator, people may feel uneasy around you, in the same way that people may feel uneasy around a police officer, even if they’re doing nothing wrong. This is just human nature.

  2. Don’t contradict other moderators
    If you disagree with the action of a moderator, talk with them in private, or bring it up in mod chat. Never override a ban, and never contradict the other moderator(s) publicly. Instead, have a cool-headed discussion in mod-chat, and convince the moderator that they themselves should reverse their ban, or change their point of view.
    Remember: we’re all on the same team. We want to dignify the role of moderators and present a unified front.

  3. Talk with other moderators
    We have a room for moderators only. Use it! If you feel uncomfortable with how to handle a certain situation, ask other moderators for help. If you think something should be discussed, do it. You’re part of the team and we value the input of every team member! Even if you totally disagree with anything in these guidelines or the Code of Conduct!

  4. Temporarily inactive
    If you’re not going to be active as a Moderator for a while due to vacation, illness or any other reason, make sure to let the others know in the moderator room. This so we know if we can count on you or not.

Moderating GitHub

Moderators are volunteers who have the ability to close issues and accept or deny pull requests.

Moderators have two primary responsibilities regarding GitHub:

  1. Evaluating and responding to Issues
  2. QA’ing and Merging Pull Requests

Evaluating and Responding to Issues

freeCodeCamp is an active open source project. We get dozens of issues each day, all of which need to be triaged and labeled.

There are several general classes of Issues:

  1. Code Help Requests, which are not appropriate for Issues.
    If an issue is clearly someone asking for help, paste the following message, then close the issue.

Thank you for reporting this issue.

This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the **“Help”** button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our [**full list of official chatrooms**](

If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

  1. Bug or Clarification issues Confirm the bug yourself if possible. Seek additional details as necessary, such as Steps to Reproduce. Once the issue has been reproduced - or at least deemed legitimate - label it confirmed. Then:
  • If it’s a simple change to an existing challenge, flag as help wanted and, optionally, as first-timers-only. Use other tags as appropriate.
  • If the issue is more significant, flag as bug.
  • Label Usage Guide
    If there is any ambiguity as to the proper course of action on an issue, feel free to tag @freeCodeCamp/moderators to get opinions from other moderators. Flag as Discussing.
  1. Duplicate Issues If an issue is the same as another reported issue, the prior reported issue should take precedence. Flag as Duplicate, paste the following message replacing #XXXXX with the issue number, then close the issue.

Thank you for reporting this issue.

This is a standard message notifying you that this issue appears to be very similar to issue #XXXXX, so I am closing it as a duplicate.

If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

  1. Fixed in staging Some issues have been fixed in staging, but don’t have another issue on the same topic. Paste the following message, then close the issue:

Thank you for reporting this issue.

This is a standard message notifying you that this issue is present in production, but it has been fixed in staging. Because of that, I’m closing this issue. When staging will be pushed to production again, your issue will be resolved.

If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

  1. Bike Shedding Bike Shedding is an example of Parkinson’s law of triviality. Some issues are simply not worth fixing. If you believe an issue isn’t worth the effort, flag as bikeshedding, paste and fill out the following message, then close the issue:

Thank you for reporting this issue.

Give a short explanation of why this is bikeshedding, a form of Parkinson’s law of triviality, so I’m closing it.

If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

Moderating Pull Requests

Pull Requests (PRs) are how contributors to freeCodeCamp submit changes to the repository for consideration. It’s important that these PRs are properly formatted, and undergo thorough Quality Assurance Testing prior to being merged.

Pull Request Requirements and Formatting

All PRs must meet the following requirements before they should be accepted:

  1. It must reference at least one open issue, and the body should also include closes #XXXXX for each issue number it addresses (replacing #XXXXX with the issue number)
  2. It must be against the staging branch
  3. It must be from a properly named non-staging branch, on the user’s personal fork of freeCodeCamp
  4. The title should describe the change made
  5. Its title should NOT have an issue number in it
  6. Its body should give details about the change, as well as level of testing (i.e. untested, tested locally)
  7. Related changes should be squashed to single commit. But relevant or notable changes may have separate commits.
  8. Code must pass all tests and linting

If the PR does not meet one or more of these requirements, open a GitHub review specifying which of the 8 requirements is not yet met. New Contributors may be referred to the Contributors Chat room. At a moderator’s discretion the issue may be closed.

Quality Assurance (QA)

Assuming that the basic requirements for the PR are met, all PRs should undergo some level of QA testing. The most basic QA process is to check out the PR locally on your computer and test the changed functionality.

  1. Make sure you’re able to reproduce the issue locally.
  2. Verify that the PR actually fixes the issue.
  3. You can reply to the issue with “LGTM”, which means “looks good to me”.
  4. If you have any doubt as to whether the PR should be merged, let a second person QA it, and then they can merge it.
  5. If there’s already an “LGTM” and you successfully QA the PR as well, you should merge it.

If there is any doubt about the functionality, you may mention @freeCodeCamp/moderators to get a second opinion.

Special Requirements

PRs which change the underlying function of the site or make non-trivial changes to the UI or UX of the site should be approved by @BerkeleyTrue or @QuincyLarson. If you have any doubt, tag them in a comment and/or draw their attention to the PR via Gitter Chat.

Other Rules Governing Moderators

Though you will have write access to freeCodeCamp’s repository:

  • you should never push code directly to the freeCodeCamp repository. All code should enter freeCodeCamp’s codebase in the form of a pull request from a fork of the repo.
  • you should never accept your own PRs. They must be QA-ed by another moderator, just like with any other PR.

Moderating the Forum

Moderating the forum follows the same principals as moderating Gitter. The following describes the slight variations, to account for the differences from Gitter on the Discourse platform.

Forum moderators are responsible for making our community an enjoyable place for anyone to learn and get help. Forum Moderators will deal with flagged posts and handle spam, off-topic, and other inappropriate conversations.

Deleting forum posts

Forum moderators have the ability to delete user’s posts. You should only do this for the following instances:

  1. Someone has posted a pornographic or graphically violent image.
  2. Someone has posted a link or code that is malicious in nature, and could harm other campers who click on it.
  3. Someone has flooded a thread with lots of spam messages.

Dealing with spam

For the first spam post of a user, send them a message explaining the problem, and remove the link or post as appropriate. Leave a note on the user’s profile explaining the action you have taken. If the problem persists, then follow the process above. Quietly block user from posting, then send warning with Code of Conduct. Check the box in the private message indicating that your message is a “formal warning.”

It is not necessary to use the Gitter admin room to report incidents on the forum. If you have questions, please ask in the staff forum section.

Dealing with off-topic conversations

Posts or topics that seems to be in the wrong place, can be re-categorized or renamed to whatever would be appropriate.

In exceptional circumstances, it may be appropriate for a moderator to fork a discussion into multiple threads.

Again, if you have any problems or questions, make a post with your actions in the Staff category, and tag another moderator if you want them to review your moderating actions.

How to become a moderator

Have you been contributing to our community, and desire the additional power/responsibility that comes with being a moderator?

Gather evidence that shows your helpfulness on GitHub issues, and/or helping campers on Gitter and our forums, and PM it in Gitter to:

Additional requirements:

  • You must enable Two Factor Authentication on your GitHub account.
  • Your GitHub profile should at least have your first name.
  • Your GitHub photo should feature your face.

If you are approved, we will add you to our Moderator Team.

After you’ve been accepted as a moderator, you will receive a Github repository invitation. You’ll need to head over towards FCC Repository Invitation to be able to accept the invitation. This is required for us to be able to give you your Moderator status.

How we retire inactive moderators

Please note that we will frequently remove issue mods whom we think are inactive. When we do this we will send the following message:

This is a standard message notifying you that, since you don’t seem to have been an active moderator recently, we’re removing you from our Moderator team. We deeply appreciate your help in the past.

If you think we did this in error, or once you’re ready to come back and contribute more, just reply to this message letting me know.

How our Contributors room works

Anyone is welcome in the Contributors room. It is the designated chat room for moderators and other campers who are contributing to our community in any number of ways, including through study groups.

Our assumption is that contributors will read anything in this room that directly mentions them with an @username, or is directed to @/all. Everything else is optional. But feel free to read anything anyone posts in there and interact.

How to become a moderator on this forum

If you are already a moderator, you can request moderator status on this forum as well. Message @michaelhenderson here on the forum and he will verify your Moderator status on GitHub, then grant you moderator status here.

Dealing with solicitors

You may be approached by organizations who want to partner or co-brand with freeCodeCamp in some way. Once you realize that this is what they’re after, please stop talking to them and tell them to talk directly with Quincy Larson. He get proposals like this literally every day and is in the best position to judge whether such a relationship will be worth it for our community (and it rarely is).


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.