Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add community rules in markdown #288

Merged
merged 3 commits into from
Aug 9, 2023
Merged

Add community rules in markdown #288

merged 3 commits into from
Aug 9, 2023

Conversation

JoshDevHub
Copy link
Contributor

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.

Copy link
Member

@01zulfi 01zulfi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we can get rid of icons entirely, and use Unicode emojis they'll render everywhere. ✅ ❌

I'm assuming, the file as it is would be easy to parse on the site; I don't think that's the case for the bot. On the bot, we want to extract each rule as its own object for further use.

We could make do with some complication regex, but I feel we can make the process better. Here are two suggestions:

  1. I've not used regex a lot, but I'm assuming we can make the parsing easier with defining a 'start point' and 'end point' for each rule. For example:

        <span name="rulestart">
    
        ### this is a rule
        
        lorem ipsum asdf
    
        </span>        
  2. We avoid regex. Put each rule in its own file. This will also allow us to leverage front matter of markdown files (using gray-matter library). This would what the modmail.md would look like:

    ---
    rulename: "modmail"
    ---
    
    ### Report misconduct with modmail
    
    lorem ipsum

For 2. I'm not sure if fetching/parsing on the site might get complicated.

So yeah, thoughts and suggestions are welcome

@JoshDevHub
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@JoshDevHub
Copy link
Contributor Author

@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 🙃

@JoshDevHub
Copy link
Contributor Author

JoshDevHub commented Aug 5, 2023

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
Copy link
Member

01zulfi commented Aug 7, 2023

@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
Copy link
Contributor Author

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.

@JoshDevHub JoshDevHub merged commit 71a6261 into main Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants