update contribution guidelines, remove redundant files

[the-right-joyce]

No description provided.

[ggwpez]

I did not check all links but we can do another cleanup sweep through the while project afterwards

[davxy]

@the-right-joyce nitpick.

What about formatting these text files following some terminal friendly convention?

A lot of devs open these files in their terminal a not markdown-aware text editor (i.e. which doesn't render markdown) and IMHO is a good idea to follow some widespread de facto formatting conventions for documentation text files.

Like:

• give a max to line lengths (100 is a common value)
• leave an empty line between markdown paragraphs/chapters tags (before and after)

All this stuff is not important if you read/write markdowns on github. But can be annoying on the terminal

---

Some references:

• https://baymard.com/blog/line-length-readability
• https://richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/ (2023 and yeah, still relevant IMO 😃)
• https://en.wikipedia.org/wiki/Line_length

[davxy]

@the-right-joyce The first article says that the right choice is be between 50–75,
Well IMO that is too short as well. Again IMO the right value nowadays is ~100.

Again this is not super relevant, and if you can't automate it using the right tool then I can give these files a pass after merge.

[the-right-joyce]

@Rashmirreddy please check the documentation guideline copy and see if you'd like to leave the format as is or take the advised format from @davxy
If not, I will just delete it :)

[chevdor]

The idea to have properly formatted markdown is good but that should be done with clear rules and a linter such as markdownlint able to check them, not a list of text rules burried in some text somewhere.

Defining a linter's rules is usually a topic that requires consensus and sounds out of the scope of this PR. Since Markdown is also used by rustdoc, we need to carefully pick rules that will result in proper rustdoc as well.

I would suggest one pass of the standard rules of markdownlint to bring everything to a coherent state (I can commit to this PR if wanted). We can then address the linting topics in another PR and discuss the config of the linter.
NOTE: a pass of markdownlint will not address the line length issues automatically. Seeing the current values, a sane start would be to limit to a big value such as 120 to avoid insanely long lines. This can then be further reduced in the linting PR.

By the way, why are all the files all caps ?
This is usually done for a few important files at the root such as contrib or license, but we don't need to use CAPS for all markdown files.

[the-right-joyce]

By the way, why are all the files all caps ?

It was copied from the repos, just moved to one single folder to not have 3x the same docs

[chevdor]

It was copied from the repos, just moved to one single folder to not have 3x the same docs

ok, I understand this PR is more about bringing those files together so let's ignore the all CAPS for now if you want. We can address that in the linting PR.

[chevdor]

I created a new issue for the linting topics:
#1243

[Rashmirreddy]

@the-right-joyce - We can go ahead with the format you have suggested. We can make changes as we progress.