Disabled all the rules violated by the Markdown posts files

[jonasbn]

Hi @kevinsimper

I have added a job more in the Travis CI config doing a Markdownlint check of the contents, namely the files in _posts.

Currently I have disabled the following Markdownlint rules, so it does not break the build.

• heading-increment (MD001)
• no-bare-urls (MD034)
• line-length (MD013)
• blanks-around-headings (MD022)
• no-trailing-punctuation (MD026)
• no-multiple-blanks (MD012)
• no-inline-html (MD033)
• single-title (MD025)
• no-hard-tabs (MD010)
• no-trailing-spaces (MD009)
• no-missing-space-atx (MD018)
• single-trailing-newline (MD047)
• no-emphasis-as-heading (MD036)
• heading-style (MD003)
• no-blanks-blockquote (MD028)

I will address each of these in separate PRs and I will find out where and if Editor Config or Prettier as I commented in issue #192. Rules like no-hard-tabs can and should be handled by other tools. And perhaps rules like no-bare-urls should remain disabled since we decide it makes more sense.

I will be cautious of changes which change layout or communication value and I will point these out. I just got my local instance working as I wanted (please see question #194).

Please let me know what you thinks before I start producing PRs, yes it is Hacktoberfest month

[kevinsimper]

I still don't know what you want to change? #192 (comment)

What are the things that you want to change about the old files that needs to be improved?

[jonasbn]

Hi @kevinsimper

I have made an example of what could become a PR.

This branch addresses the Markdownlint rule MD022 (blanks-around-headings).

This rule indicates the good practice of surrounding a heading with blank lines.

So the following Markdown snippet:

# Heading 1
should not be written like this

Should be written as:

# Heading 1

should be written like this

[jonasbn]

The whole idea is to build a Markdown writing environment for future posts, where linting and tools can be used to get the optimal Markdown included in the project and for publication on the website. Enabling this requires CI integration and hence addressing existing issues and defining a base rule set for future additions based on. Alternatively we could ignore all old posts and enforce the rules on new posts only, but that does mean that consistency and uniformity across content formatting will be missing.

[kevinsimper]

But I think it is different as these posts are not documentation that needs to maintained and updated :)

I don't want to introduce linting on posts, it should more be for broken markup.

I use prettier in all my projects to correct and format my markdown, I never have a linting error in a CI step :)

I think it makes sense in documentation, also were multiple people are working on the same project. And I can also see it in CopenhagenJS with more people adding posts to the website, but I would wait to add it after I see a problem.

There are a few things that it would be awesome to solve:

• A template to create new posts for upcoming meetups
• Better speaker profile of the people that are going to speak at the meetup
• Better time table so that it is not part of the description
• Connecting the youtube videos to which meetup they were recorded at
• Adding better information about hosts and how to find the meetup

If we are more people solving these problems and editing markdown, then I could see the benefit of markdownlint. I would need a command to run before commiting so I wouldn't need to wait for Travis to run also 😄

[jonasbn]

Thanks for briefing me on your thoughts, based on that the PR should be rejected. I will evaluate if I can contribute in some of the other areas instead.

Btw. do you use the Gitter chat, I think it was set up by @Munter. It could speed up this sort of communication and perhaps some better development guidelines, I will see if I can write a draft for the latter, based on my notes from my work with my latest PRs and branches.

[kevinsimper]

I would still prefer issues so that it is easily searchable and also so you have time to formulate ones thoughts :)

We did have Discourse for a couple of months, I am also on Discord, twitter is also a favorite, but Github Issues also solves a lot of the same problems.

[jonasbn]

I will stick to GitHub issues then :-)