Refactor markdown files

.github/CONTRIBUTING.md

@@ -1,68 +1,67 @@
-# Contributing
-
 Contributions are welcome! Here's how you can help:
 
-- [Contributing code](#code)
-- [Reporting issues](#issues)
-- [Requesting features](#feature-requests)
-- [Translating](#translations)
-- [Donating](#donations)
+* [Contributing code](#code)
+* [Reporting issues](#issues)
+* [Requesting features](#feature-requests)
+* [Translating](#translations)
+* [Donating](#donations)
 
 ## Code
 
 1. [Fork](https://help.github.com/articles/fork-a-repo/) the repository and
    [clone](https://help.github.com/articles/cloning-a-repository/) your fork.
 
 2. Before you start coding, consider opening an
-   [issue at Github](https://github.com/minetest/minetest/issues) to discuss the
+   [issue at GitHub](https://github.com/minetest/minetest/issues) to discuss the
    suitability and implementation of your intended contribution with the core
    developers.
 
-   Any Pull Request that isn't a bug fix and isn't covered by
+   Any pull request that isn't a bug fix and isn't covered by
    [the roadmap](../doc/direction.md) will be closed within a month unless it
    receives a concept approval from a Core Developer. For this reason, it is
    recommended that you open an issue for any such pull requests before doing
    the work, to avoid disappointment.
 
-   You may also benefit from discussing on our IRC development channel
-   [#minetest-dev](http://www.minetest.net/irc/). Note that a proper IRC client
-   is required to speak on this channel.
+   You may also benefit from discussing on one of our IRC development channels
+   [listed here](https://wiki.minetest.net/IRC). Note that a proper IRC client
+   is required to speak on these channels.
 
 3. Start coding!
-    - Refer to the
+    * Refer to the
       [Lua API](https://github.com/minetest/minetest/blob/master/doc/lua_api.md),
-      [Developer Wiki](http://dev.minetest.net/Main_Page) and other
+      [Developer Wiki](https://dev.minetest.net/Main_Page) and other
       [documentation](https://github.com/minetest/minetest/tree/master/doc).
-    - Follow the [C/C++](http://dev.minetest.net/Code_style_guidelines) and
-      [Lua](http://dev.minetest.net/Lua_code_style_guidelines) code style guidelines.
-    - Check your code works as expected and document any changes to the Lua API.
-
-4. Commit & [push](https://help.github.com/articles/pushing-to-a-remote/) your changes to a new branch (not `master`, one change per branch)
-    - Commit messages should:
-        - Use the present tense.
-        - Be descriptive. See the commit messages by core developers for examples.
-    - The first line should:
-        - Start with a capital letter.
-        - Be a compact summary of the commit.
-        - Preferably have less than 70 characters.
-        - Have no full stop at the end.
-    - The second line should be empty.
-    - The following lines should describe the commit, starting a new line for each point.
+    * Follow the [C/C++](https://dev.minetest.net/Code_style_guidelines) and
+      [Lua](https://dev.minetest.net/Lua_code_style_guidelines) code style guidelines.
+    * Check your code works as expected and document any changes to the Lua API.
+
+4. Commit and [push](https://help.github.com/articles/pushing-to-a-remote/) your changes
+   to a new branch (not `master`, one change per branch)
+    * Commit messages should:
+        * Use the present tense.
+        * Be descriptive. See the commit messages by core developers for examples.
+    * The first line should:
+        * Start with a capital letter.
+        * Be a compact summary of the commit.
+        * Preferably have less than 70 characters.
+        * Have no full stop at the end.
+    * The second line should be empty.
+    * The following lines should describe the commit, starting a new line for each point.
 
 5. Once you are happy with your changes, submit a pull request.
-     - Open the [pull-request form](https://github.com/minetest/minetest/pull/new/master).
-     - Add a description explaining what you've done (or if it's a
-       work-in-progress - what you need to do).
-     - Make sure to fill out the pull request template.
+    * Open the [pull request form](https://github.com/minetest/minetest/pull/new/master).
+    * Add a description explaining what you've done (or if it's a work-in-progress -
+      what you need to do).
+    * Make sure to fill out the pull request template.
 
-### A pull-request is considered merge-able when:
+### A pull request is Considered Mergeable When:
 
 1. It follows [the roadmap](../doc/direction.md) in some way and fits the whole
    picture of the project.
 2. It works.
 3. It follows the code style for
-   [C/C++](http://dev.minetest.net/Code_style_guidelines) or
-   [Lua](http://dev.minetest.net/Lua_code_style_guidelines).
+   [C/C++](https://dev.minetest.net/Code_style_guidelines) or
+   [Lua](https://dev.minetest.net/Lua_code_style_guidelines).
 4. The code's interfaces are well designed, regardless of other aspects that
    might need more work in the future.
 5. It uses protocols and formats which include the required compatibility.
@@ -73,18 +72,18 @@ If you experience an issue, we would like to know the details - especially when
 a stable release is on the way.
 
 1. Do a quick search on GitHub to check if the issue has already been reported.
-2. Is it an issue with the Minetest *engine*? If not, report it
-   [elsewhere](http://www.minetest.net/development/#reporting-issues).
+2. Is it an issue with the Minetest *engine*? If not, report it.
+   [elsewhere](https://www.minetest.net/development/#reporting-issues).
 3. [Open an issue](https://github.com/minetest/minetest/issues/new) and describe
    the issue you are having - you could include:
-     - Error logs (check the bottom of the `debug.txt` file).
-     - Screenshots.
-     - Ways you have tried to solve the issue, and whether they worked or not.
-     - Your Minetest version and the content (games, mods or texture packs) you have installed.
-     - Your platform (e.g. Windows 10 or Ubuntu 15.04 x64).
-
-After reporting you should aim to answer questions or clarifications as this
-helps pinpoint the cause of the issue (if you don't do this your issue may be
+    * Error logs (check the bottom of the `debug.txt` file).
+    * Screenshots.
+    * Ways you have tried to solve the issue, and whether they worked or not.
+    * Your Minetest version and the content (games, mods or texture packs) you have installed.
+    * Your platform (e.g. Windows 10 or Ubuntu 15.04 x64).
+
+After reporting, you should aim to answer questions or clarifications as this
+helps pinpoint the cause of the issue (if you don't do this, your issue may be
 closed after 1 month).
 
 ## Feature requests
@@ -108,20 +107,22 @@ translated by editing a `.tr` text file. See
 ## Donations
 
 If you'd like to monetarily support Minetest development, you can find donation
-methods on [our website](http://www.minetest.net/development/#donate).
+methods on [our website](https://www.minetest.net/get-involved/#donate).
+
+
 
 # Maintaining
 
 * This is a concise version of the
-  [Rules & Guidelines](http://dev.minetest.net/Category:Rules_and_Guidelines) on the developer wiki.*
+  [Rules & Guidelines](https://dev.minetest.net/Category:Rules_and_Guidelines) on the developer wiki.*
 
 These notes are for those who have push access Minetest (core developers / maintainers).
 
-- See the [project organisation](http://dev.minetest.net/Organisation) for the people involved.
+* See the [project organization](https://dev.minetest.net/Organisation) for the people involved.
 
-## Concept approvals and roadmaps
+## Concept Approvals and Roadmaps
 
-If a Pull Request is not a bug fix:
+If a pull request is not a bug fix:
 
 * If it matches a goal in [the roadmap](../doc/direction.md), then the PR should
   be labeled as "Roadmap" and the goal stated by number in the description.
@@ -137,33 +138,33 @@ Pull requests should be reviewed and, if appropriate, checked if they achieve
 their intended purpose. You can show that you are in the process of, or will
 review the pull request by commenting *"Looks good"* or something similar.
 
-**If the pull-request is not [merge-able](#a-pull-request-is-considered-merge-able-when):**
+**If the pull request is not [mergeable](#a-pull-request-is-considered-mergeable-when):**
 
 Submit a comment explaining to the author what they need to change to make the
-pull-request merge-able.
+pull request merge-able.
 
-- If the author comments or makes changes to the pull-request, it can be
+* If the author comments or makes changes to the pull request, it can be
   reviewed again.
-- If no response is made from the author within 1 month (when improvements are
+* If no response is made from the author within 1 month (when improvements are
   suggested or a question is asked), it can be closed.
 
-**If the pull-request is [merge-able](#a-pull-request-is-considered-merge-able-when):**
+**If the pull request is [mergeable](#a-pull-request-is-considered-mergeable-when):**
 
-Submit a :+1: (+1) or "Looks good" comment to show you believe the pull-request should be merged. "Looks good" comments often signify that the patch might require (more) testing.
+Submit a :+1: (+1) or "Looks good" comment to show you believe the pull request should be merged. "Looks good" comments often signify that the patch might require (more) testing.
 
-- Two core developers must agree to the merge before it is carried out and both should +1 the pull request.
-- Who intends to merge the pull-request should follow the commit rules:
-    - The title should follow the commit guidelines (title starts with a capital letter, present tense, descriptive).
-    - Don't modify history older than 10 minutes.
-    - Use rebase, not merge to get linear history:
-    - `curl https://github.com/minetest/minetest/pull/1.patch | git am`
+* Two core developers must agree to the merge before it is carried out and both should +1 the pull request.
+* Who intends to merge the pull request should follow the commit rules:
+    * The title should follow the commit guidelines (title starts with a capital letter, present tense, descriptive).
+    * Don't modify history older than 10 minutes.
+    * Use rebase, not merge to get linear history:
+      `curl https://github.com/minetest/minetest/pull/1.patch | git am`
 
-## Reviewing issues and feature requests
+## Reviewing Issues and Feature Requests
 
-- If an issue does not get a response from its author within 1 month (when requiring more details), it can be closed.
-- When an issue is a duplicate, refer to the first ones and close the later ones.
-- Tag issues with the appropriate [labels](https://github.com/minetest/minetest/labels) for devices, platforms etc.
+* If an issue does not get a response from its author within 1 month (when requiring more details), it can be closed.
+* When an issue is a duplicate, refer to the first ones and close the later ones.
+* Tag issues with the appropriate [labels](https://github.com/minetest/minetest/labels) for devices, platforms etc.
 
-## Releasing a new version
+## Releasing a New Version
 
-*Refer to [dev.minetest.net/Releasing_Minetest](http://dev.minetest.net/Releasing_Minetest)*
+*Refer to [dev.minetest.net/Releasing_Minetest](https://dev.minetest.net/Releasing_Minetest)*

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,19 +1,19 @@
 Add compact, short information about your PR for easier understanding:
 
-- Goal of the PR
-- How does the PR work?
-- Does it resolve any reported issue?
-- Does this relate to a goal in [the roadmap](https://github.com/minetest/minetest/blob/master/doc/direction.md)?
-- If not a bug fix, why is this PR needed? What usecases does it solve?
+* Goal of the PR
+* How does the PR work?
+* Does it resolve any reported issue?
+* Does this relate to a goal in [the roadmap](https://github.com/minetest/minetest/blob/master/doc/direction.md)?
+* If not a bug fix, why is this PR needed? What usecases does it solve?
 
 ## To do
 
 This PR is a Work in Progress / Ready for Review.
 <!-- ^ delete one -->
 
-- [ ] List
-- [ ] Things
-- [ ] To do
+* [ ] List
+* [ ] Things
+* [ ] To do
 
 ## How to test
 

.github/SECURITY.md

@@ -10,11 +10,11 @@ See the [releases page](https://github.com/minetest/minetest/releases).
 We ask that you report vulnerabilities privately, by contacting a core developer,
 to give us time to fix them. You can do that by emailing one of the following addresses:
 
-* celeron55@gmail.com
-* rubenwardy@minetest.net
+* <celeron55@gmail.com>
+* <rubenwardy@minetest.net>
 
 Depending on severity, we will either create a private issue for the vulnerability
 and release a patch version of Minetest, or give you permission to file the issue publicly.
 
 For more information on the justification of this policy, see
-[Responsible Disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure).
+[Responsible Disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure).

README.md

@@ -1,5 +1,4 @@
-Minetest
-========
+# Minetest
 
 ![Build Status](https://github.com/minetest/minetest/workflows/build/badge.svg)
 [![Translation status](https://hosted.weblate.org/widgets/minetest/-/svg-badge.svg)](https://hosted.weblate.org/engage/minetest/?utm_source=widget)
@@ -10,30 +9,17 @@ Minetest is a free open-source voxel game engine with easy modding and game crea
 Copyright (C) 2010-2022 Perttu Ahola <celeron55@gmail.com>
 and contributors (see source file comments and the version control log)
 
-Table of Contents
-------------------
-
-1. [Further Documentation](#further-documentation)
-2. [Default Controls](#default-controls)
-3. [Paths](#paths)
-4. [Configuration File](#configuration-file)
-5. [Command-line Options](#command-line-options)
-6. [Compiling](#compiling)
-7. [Docker](#docker)
-8. [Version Scheme](#version-scheme)
-
-
-Further documentation
-----------------------
-- Website: https://www.minetest.net/
-- Wiki: https://wiki.minetest.net/
-- Forum: https://forum.minetest.net/
-- GitHub: https://github.com/minetest/minetest/
-- [Developer documentation](doc/developing/)
-- [doc/](doc/) directory of source distribution
-
-Default controls
-----------------
+## Further Documentation
+
+* Website: https://minetest.net/
+* Wiki: https://wiki.minetest.net/
+* Developer wiki: https://dev.minetest.net/
+* Forum: https://forum.minetest.net/
+* GitHub: https://github.com/minetest/minetest/
+* [doc/](doc/) directory of source distribution
+
+## Default Controls
+
 All controls are re-bindable using settings.
 Some can be changed in the key config dialog in the settings tab.
 
@@ -73,8 +59,8 @@ Some can be changed in the key config dialog in the settings tab.
 | F10                           | Show/hide console                                              |
 | F12                           | Take screenshot                                                |
 
-Paths
------
+## Paths
+
 Locations:
 
 * `bin`   - Compiled binaries
@@ -100,46 +86,43 @@ Where each location is on each platform:
     * `share` = `Contents/Resources`
     * `user`  = `Contents/User` or `~/Library/Application Support/minetest` or `$MINETEST_USER_PATH`
 
-Worlds can be found as separate folders in: `user/worlds/`
+Worlds can be found as separate folders in `user/worlds/`
 
-Configuration file
-------------------
-- Default location:
-    `user/minetest.conf`
-- This file is created by closing Minetest for the first time.
-- A specific file can be specified on the command line:
-    `--config <path-to-file>`
-- A run-in-place build will look for the configuration file in
-    `location_of_exe/../minetest.conf` and also `location_of_exe/../../minetest.conf`
+## Configuration File
 
-Command-line options
---------------------
-- Use `--help`
+* Default location: `user/minetest.conf`
+* This file is created by closing Minetest for the first time.
+* A specific file can be specified on the command line: `--config <path-to-file>`
+* A run-in-place build will look for the configuration file in
+  `location_of_exe/../minetest.conf` and also `location_of_exe/../../minetest.conf`
 
-Compiling
----------
+## Command-Line Options
 
-- [Compiling on GNU/Linux](doc/compiling/linux.md)
-- [Compiling on Windows](doc/compiling/windows.md)
-- [Compiling on MacOS](doc/compiling/macos.md)
+Use `--help`
 
-Docker
-------
+## Compiling
+
+* [Compiling on GNU/Linux](doc/compiling/linux.md)
+* [Compiling on Windows](doc/compiling/windows.md)
+* [Compiling on MacOS](doc/compiling/macos.md)
+
+## Docker
 
 - [Developing minetestserver with Docker](doc/developing/docker.md)
+
 - [Running a server with Docker](doc/docker_server.md)
 
-Version scheme
---------------
+## Version Scheme
+
 We use `major.minor.patch` since 5.0.0-dev. Prior to that we used `0.major.minor`.
 
-- Major is incremented when the release contains breaking changes, all other
-numbers are set to 0.
-- Minor is incremented when the release contains new non-breaking features,
-patch is set to 0.
-- Patch is incremented when the release only contains bugfixes and very
-minor/trivial features considered necessary.
+* Major is incremented when the release contains breaking changes, all other
+  numbers are set to 0.
+* Minor is incremented when the release contains new non-breaking features,
+  patch is set to 0.
+* Patch is incremented when the release only contains bugfixes and very
+  minor/trivial features considered necessary.
 
 Since 5.0.0-dev and 0.4.17-dev, the dev notation refers to the next release,
 i.e.: 5.0.0-dev is the development version leading to 5.0.0.
-Prior to that we used `previous_version-dev`.
+Prior to that we used `previous_version-dev`.