Add community rules in markdown

[JoshDevHub]

Because

The rules currently reside on an erb file in the main site. This makes it more difficult for tools (like the odin-bot) to interact with the rules. Transferring to a Markdown document will make the rules easier to parse programmatically. See the associated issue for more information about this.

This PR

• Adds the rules in a markdown file
• Preserves the icon stylings that are currently on the page for the main site.

Issue

Issue on Main Site repo

Additional Information

I left in the font-awesome icons. I like the way these look on the site, but they won't render properly in a plain Markdown file. Maybe it's better to get rid of them?

I also didn't give a ton of thought to the name of this file (community-rules.md) or its position in the directory structure of this repo. Will gladly take any thoughts on that.

[JoshDevHub]

@01zulfi

Yeah that makes sense to shift to using unicode symbols. I'll get that changed.

With the parsing, there are probably a lot of ways you could do it. You can do it manually with the file as-is without getting into heavy regex stuff. Here's something I threw together in 10 minutes: gist

The big thing I'd think about for doing it with the bot: how often do you expect the format of the rules markdown to change? If there's an expectation that even if the rules change, the layout of them is stable, then I think you could get away with something simple like what I have above. But if it's something that may change frequently, that script could easily get annoying to maintain.

I also know that there are Markdown parser libraries. This is how it's converted on the site, using a Ruby library called 'Kramdown'. Maybe there's a JS Markdown tool that could help.

[JoshDevHub]

Hmm, that grey matter library looks interesting. I'd have to ask Kevin if going that route would overcomplicate things on the site.

[JoshDevHub]

@01zulfi Spoke with Kevin about this some last night. He says it'd make it messy on the app to have the rules in different files, so I think we'll try to keep it in one.

I'm down to think about "delimiters" of some kind (like your first span tag idea) if you think that'd make things easier to maintain. I think the "hope" is that the rules are in a stable place now and are unlikely to change in structure/organization going forward. But these things are hard to predict :upside_down_face:

[JoshDevHub]

There are a couple of delimiter ideas I might like more than span tags. One would be Markdown "comments"

[rule-name]: # (Modmail)

### Report misconduct to ModMail
Use Modmail to report misconduct, private harassment by a community member, or if anyone makes you or others feel unsafe, uncomfortable, or unwelcome in our community.

That [rule-name] line just won't appear in the parsed markup at all, either on Github when viewing the rendered Markdown or on the main site. But it would exist in the plain text file to maybe help with parsing.

Another thing is Markdown supports passing ids to headings like this

### Report misconduct to ModMail {#modmail}

The rendered output will have <h3 id="modmail">Report misconduct to ModMail</h3>, which is fine I think. And then there's this {#rule-name} string in the plain text file that can be used to help with parsing.

[01zulfi]

@JoshDevHub Sorry for taking long on this.

Great use of split! I didn't even think of that. Regex has corrupted my mind 😆

I would love having delimiters of any kind. I'll leave which one to implement to you. Reason being that it will help with parsing on the bot side plus it'll give us a one (or two) word name for each rule. This name will allow us to use in commands and such. What I'm thinking a rule object will look like (after parsed on the bot):

const rules = [
   ...,
  {
     name: 'modmail', // this will come from the delimiter
     title: 'Report to modmail lorem ipsum',
     description: '...', 
  },
  ...,
]

The object could be simplified even more as I don't think there's a need for goodBehavior, badBehavior, title, or description. Just { name: 'rulename', content: 'all of the rule content' } should suffice. But this is work that comes after; let's get this PR merged and make the relevant changes to the site repo.

[JoshDevHub]

Added labels using the "markdown comments" method. We can always revisit it later, but I figured it would set up some pretty comfortable parsing with split() and maybe basic regex matching.

Going to go ahead and merge this so I can try to get started on writing code for the main app to parse this file.