diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d5357198924e722a65a91911d0b45c3c19a52b43..824362d77e64c56bb895f9923ad50a5bf2af6245 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,8 +6,8 @@ different communities with different expectations and requirements, it is both
 essential and difficult to have contributions from the communities. While they
 are sometimes necessary to adapt Gluon to the needs of the communities, they
 also have to be adaptable enough to fit as many needs as possible. On the other
-hands, very special needs are better addressed in packages in [community
-repositories], because the Gluon maintainers would not use or test them and
+hands, very special needs are better addressed in [packages] in community
+repositories, because the Gluon maintainers would not use or test them and
 thus couldn't do their "job" of maintaining them.
 
 To ease the work for the maintainers and to reduce the frustration of
@@ -25,10 +25,9 @@ after merging the changes, too.
 
 The preferred way to discuss in the IRC channel ([#gluon] on irc.hackint.org)
 or on the [mailing list], however, you can also open a new issue on Github to
-discuss there. We maintain a [list of rejected
-features](https://github.com/freifunk-gluon/gluon/issues?q=label%3Arejected)
-and we'd like to kindly ask you to review it first. In general, looking for
-duplicates may save you some time.
+discuss there. We maintain a [list of rejected features] and we'd like to
+kindly ask you to review it first. In general, looking for duplicates may save
+you some time.
 
 Develop on top of master
 ------------------------
@@ -53,7 +52,7 @@ Most changes are trivial enough to fit in one single commit in order to not
 clutter the history. While developing a new feature, you are free to use
 multiple commits, but if your feature is to be merged, reduce the number of
 commits to a minimum. Even huge feature introductions like the 802.11s mesh
-(commit 2a93c58) fit into a single commit.
+(commit [2a93c58]) fit into a single commit.
 
 If you developed your change in multiple smaller commits, you can easily
 [squash] those before opening the pull request. While discussing, it is okay to
@@ -62,7 +61,9 @@ the pull request. This way, your change always consists of only one commit and
 can be merged in the instant everybody is content with the whole thing.
 
 
-[community repositories]: http://gluon.readthedocs.org/en/latest/user/site.html#packages
-[#gluon]: irc://irc.hackint.org/gluon
+[packages]: http://gluon.readthedocs.org/en/latest/user/site.html#packages
+[#gluon]: https://webirc.hackint.org/#gluon
 [mailing list]: mailto:gluon@luebeck.freifunk.net
+[list of rejected features]: https://github.com/freifunk-gluon/gluon/issues?q=label%3Arejected
+[2a93c58]: https://github.com/freifunk-gluon/gluon/commit/2a93c580428d10724116b0d2d1238e2745715a14
 [squash]: https://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits