+<h2 id="_building_i3">1. Building i3</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>You can build i3 like you build any other software package which uses autotools.\r
+Here’s a memory refresher:</p></div>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>$ autoreconf -fi\r
+$ mkdir -p build && cd build\r
+$ ../configure\r
+$ make -j8</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p>(The autoreconf -fi step is unnecessary if you are building from a release tarball,\r
+ but shouldn’t hurt either.)</p></div>\r
+<div class="sect2">\r
+<h3 id="_build_system_features">1.1. Build system features</h3>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate\r
+ directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building\r
+ in a separate directory is common practice anyway. In case this causes any\r
+ trouble when packaging i3 for your distribution, please open an issue.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make check” runs the i3 testsuite. See docs/testsuite for details.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make distcheck” (runs testsuite on “make dist” result, tiny bit quicker\r
+ feedback cycle than waiting for the travis build to catch the issue).\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make uninstall” (occasionally requested by users who compile from source)\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make” will build manpages/docs by default if the tools are installed.\r
+ Conversely, manpages/docs are not tried to be built for users who don’t want\r
+ to install all these dependencies to get started hacking on i3.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+non-release builds will enable address sanitizer by default. Use the\r
+ --disable-sanitizers configure option to turn off all sanitizers, and see\r
+ --help for available sanitizers.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Support for pre-compiled headers (PCH) has been dropped for now in the\r
+ interest of simplicity. If you need support for PCH, please open an issue.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Coverage reports are now generated using “make check-code-coverage”, which\r
+ requires specifying --enable-code-coverage when calling configure.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_using_git_sending_patches">2. Using git / sending patches</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>For a short introduction into using git, see\r
+<a href="https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy">https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy</a>\r
+or, for more documentation, see <a href="https://git-scm.com/documentation">https://git-scm.com/documentation</a></p></div>\r
+<div class="paragraph"><p>Please talk to us before working on new features to see whether they will be\r
+accepted. A good way for this is to open an issue and asking for opinions on it.\r
+Even for accepted features, this can be a good way to refine an idea upfront. However,\r
+we don’t want to see certain features in i3, e.g., switching window focus in an\r
+Alt+Tab like way.</p></div>\r
+<div class="paragraph"><p>When working on bugfixes, please make sure you mention that you are working on\r
+it in the corresponding bug report at <a href="https://github.com/i3/i3/issues">https://github.com/i3/i3/issues</a>. In case\r
+there is no bug report yet, please create one.</p></div>\r
+<div class="paragraph"><p>After you are done, please submit your work for review as a pull request at\r
+<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>.</p></div>\r
+<div class="paragraph"><p>Do not send emails to the mailing list or any author directly, and don’t submit\r
+them in the bugtracker, since all reviews should be done in public at\r
+<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>. In order to make your review go as fast as possible, you\r
+could have a look at previous reviews and see what the common mistakes are.</p></div>\r
+<div class="sect2">\r
+<h3 id="_which_branch_to_use">2.1. Which branch to use?</h3>\r
+<div class="paragraph"><p>Work on i3 generally happens in two branches: “master” and “next” (the latter\r
+being the default branch, the one that people get when they check out the git\r
+repository).</p></div>\r
+<div class="paragraph"><p>The contents of “master” are always stable. That is, it contains the source code\r
+of the latest release, plus any bugfixes that were applied since that release.</p></div>\r
+<div class="paragraph"><p>New features are only found in the “next” branch. Therefore, if you are working\r
+on a new feature, use the “next” branch. If you are working on a bugfix, use the\r
+“next” branch, too, but make sure your code also works on “master”.</p></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_window_managers">3. Window Managers</h2>\r