Get away from adoc

CONTRIBUTING.adoc

@@ -1,66 +0,0 @@
-Contribution Guidelines
-=======================
-
-*Note*: contributing implies that your contributions get licensed under the terms of link:LICENSE[LICENSE] (MPL 2.0).
-
-Opening issues
---------------
-
-. Make sure you have a GitHub account.
-. Include steps to reproduce, if it is a bug.
-. Include information on what version you are using.
-
-Submit changes
---------------
-
-Commit messages should be both _clear_ and _descriptive_. If possible they should start with the _verb_ that describes the change.
-Don't be shy to include additional information, like motivation, for that change below the initial line.
-
-Other developers should be able to understand _why_ a change occurred, when looking at it at a later point in time.
-
-Coding Style
-~~~~~~~~~~~~
-
-Make sure you adhere to the coding style, or your pull request might not get merged.
-
-. Use blocks even when just putting a single statement
-+
-This makes it easier to add more lines later, and we avoid two other discussions. This also doesn't break when you use a macro that expands to multiple statements.
-
-. When things are related, use an `enum`.
-+
-Should be common sense. Seen too much code without it though.
-
-. Comment `// FALLTHROUGH`, `// EMPTY` and `// NOTREACHED` where applicable
-+
-Explicit is better than implicit.
-
-. Don't test against booleans or `NULL`.
-+
-Use the not operator instead.
-
-. Test against numbers
-+
-Don't abuse that `0` is falsey.
-
-. Put headers in this order
-.. `#include "file.h"`
-.. Standard lib headers
-.. POSIX headers
-.. Library headers
-.. Own stuff
-
-. Put blocks of headers in alphabetical order
-+
-If not possible comment which header requires the out-of-order one.
-
-. Use clang-format
-+
-This should auto-format the rest: `find . -iname '*.c' -o '*.h' | xargs clang-format -i`.
-
-Why am I this pedantic?
-~~~~~~~~~~~~~~~~~~~~~~~
-
-I hate it when I look at code written by 10 people and I see 15 different coding styles, and got to wrap my head around every single one. I don't really care _what_ is used, but it needs to be consistent.
-
-That said, if anything is unclear or I missed something feel free to open an issue.

CONTRIBUTING.txt

@@ -0,0 +1,19 @@
+Contribution Guidelines
+=======================
+
+Note: contributing implies that your contributions get licensed under the terms of MPL 2.0.
+
+Opening issues
+--------------
+
+- Make sure you have a GitHub account.
+- Include steps to reproduce, if it is a bug.
+- Include information on what version you are using.
+
+Submit changes
+--------------
+
+Commit messages should be both _clear_ and _descriptive_. If possible they should start with the _verb_ that describes the change.
+Don't be shy to include additional information, like motivation, for that change below the initial line.
+
+Other developers should be able to understand _why_ a change occurred, when looking at it at a later point in time.

README.txt

@@ -17,7 +17,7 @@ In the future there might be a base to base your stuff on, but at the moment thi
 Dependencies
 ------------
 
-- https://github.com/swaywm/wlroots[wlroots]
+- wlroots (https://github.com/swaywm/wlroots)
 - meson (build)
 - ninja (build)
 - git (build, optional, to fetch the version)
@@ -45,7 +45,7 @@ You want to contribute? Great!
 
 Future requests, bug reports and PRs are always welcome.
 Note that pull requests without a valid issue are ignored to decrease the amount of duplicate work.
-Also read link:CONTRIBUTING.adoc[CONTRIBUTING.adoc].
+Also read CONTRIBUTING.adoc.
 
 If anything is unclear, feel free to contact me.