-<a href="http://www.spheredev.org/wiki/Git_for_the_lazy">http://www.spheredev.org/wiki/Git_for_the_lazy</a> or, for more documentation, see\r
-<a href="http://git-scm.com/documentation">http://git-scm.com/documentation</a></p></div>\r
-<div class="paragraph"><p>When you want to send a patch because you fixed a bug or implemented a cool\r
-feature (please talk to us before working on features to see whether they are\r
-maybe already implemented, not possible for some some reason, or don’t fit\r
-into the concept), please use git to create a patchfile.</p></div>\r
-<div class="paragraph"><p>First of all, update your working copy to the latest version of the master\r
-branch:</p></div>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>git pull</tt></pre>\r
-</div></div>\r
-<div class="paragraph"><p>Afterwards, make the necessary changes for your bugfix/feature. Then, review\r
-the changes using <tt>git diff</tt> (you might want to enable colors in the diff using\r
-<tt>git config diff.color auto</tt>). When you are definitely done, use <tt>git commit\r
--a</tt> to commit all changes you’ve made.</p></div>\r
-<div class="paragraph"><p>Then, use the following command to generate a patchfile which we can directly\r
-apply to the branch, preserving your commit message and name:</p></div>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>git format-patch origin</tt></pre>\r
-</div></div>\r
-<div class="paragraph"><p>Just send us the generated file via email.</p></div>\r
+<a href="http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy">http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy</a>\r
+or, for more documentation, see <a href="http://git-scm.com/documentation">http://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. There are a few things which we don’t want to see in i3, e.g. a\r
+command which will focus windows in an 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 bugreport at <a href="https://github.com/i3/i3/issues">https://github.com/i3/i3/issues</a> In case\r
+there is no bugreport yet, please create one.</p></div>\r
+<div class="paragraph"><p>After you are done, please submit your work for review at <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="http://cr.i3wm.org/">http://cr.i3wm.org/</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>\r
+<div class="sect2">\r
+<h3 id="_which_branch_to_use">20.2. Which branch to use?</h3>\r
+<div class="paragraph"><p>Work on i3 generally happens in two branches: “master” and “next”. Since\r
+“master” is what people get when they check out the git repository, its\r
+contents are always stable. That is, it contains the source code of the latest\r
+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\r
+the “next” branch, too, but make sure your code also works on “master”.</p></div>\r
+</div>\r