Transform the CONTRIBUTE file into a Contributing Guide

CONTRIBUTE

@@ -1,43 +0,0 @@
-                       * ****************************** * 
-                       *        Yamagi Quake II         *
-                       *  http://www.yamagi.org/quake2  *
-                       *    http://github.com/yquake2   *
-                       * ****************************** *
-                                    
-                                    TODO List
-
-=============================================================================== 
-
-At this time there're no open tasks regaring Quake II. Nevertheless some hints
-for working with the code:
-
-- Sign up for a Github account and fork our yquake2 repository. This allows the
-  easy integration of upstream changes into your branch and sending of pull
-  requests. You'll get a wiki and a bugtracker for free.
-- To contribute your changes back into the main project send pull requests via
-  Github. It's much easier to review and merge pull requests than patches.
-  Please send only pull reqeuests from a distinct branch at not from your
-  "master" branch!
-- Quake II has a very fragile and broken codebase. Even after years of cleanup
-  it's still a disaster. Therefore: 
-  - Do only one change at a time!
-  - Test after each change (play at least through base1.bsp)
-  - Commit early and commit often to create a fine grained history. This helps
-    "git bisect" to find bugs and errors.
-  - Do not try to clean up things or even rewrite code that you do not
-    understand to 110%! Even small behavioral changes can introduce gameplay
-    changes and trigger new bugs! Especially everything that depends on map data
-    (e.g. path finding or collision detection) is very likely to break in
-    interesting ways!
-- Do not add new dependencies. If you must add a new one contact the Yamagi
-  Quake II developers prior to it! Everything that adds dependencies should be
-  hided behint preprocessor macros.
-- If your changes change the gameplay experience, make them optional by
-  introducing a new cvar. 
-- Linux is not the only operating system out there. All changes should be
-  portable to other platform (writing pure ANSI-C or C99 is recommended but not
-  always applicable).
-- x86 ist not the only CPU architecture. All changes should be done in pure C
-  (e.g. no inline assembler) and in an endianess independed way.
-- gcc is not the only compiler. Test your changes with clang.
-

doc/01_index.md

@@ -21,3 +21,4 @@ The documentation is split into several documents:
 * [Configuration Guide](03_configuration.md)
 * [List Of All New Console Variables](04_cvarlist.md)
 * [Packaging Guide For Maintainers](05_packaging.md)
+* [Contributing Guide](06_contributing.md)

doc/06_contributing.md

@@ -0,0 +1,32 @@
+# Contributing Code
+
+You want to contribute code to Yamagi Quake II? That's good! We're
+always interested in contributions, as long as they're in the scope of
+our little project. It doesn't matter if your sending new features,
+bugfixes or even documentation updates.
+
+As a general note: **Ask before writing code!** Nobody was ever hurt for
+asking if his or her idea is in scope for Yamagi Quake II. And an early
+"no" is always better then rejections after having put tens of hours
+into the idea.
+
+Some rules to follow:
+
+* Use Github! Sign up for an account, fork our repository and send a
+  pull request after you're satisfied with your work. We won't accept
+  patches send by mail or - even worse - as pastebin links.
+* Create a history of small, distinct commits. Several small commits are
+  always better then one big commit. They make your changes more
+  understandable and ease debugging.
+* Never ever add new dependencies. We won't accept code that add new
+  dependencies. If in doubt, because you really need that nice little
+  library, ask.
+* Make sure that your code is compiling without warnings with at least
+  current versions of gcc and clang. Also make sure that it's working on
+  both unixoid platforms and Windows. 
+* Don't do unnecessary cleanups. Yes, your linter or sanity checker may
+  complain. But that's you problem and not ours. Cleanups often bring
+  next to no advantage, Quake II has always been a mess and it'll stay a
+  mess until the sun collapses. And cleanups are hard to test, often
+  introduce new bugs and make debugging harder.
+* Stick to the code style of the file you're editing.