Fixed carousel, started work on PR guide, fixed all sorts of things.

contribute/index.html

@@ -29,9 +29,88 @@ root: ..
 </div></div>
 
 <div class="container">
+    <h2>So you want to make a pull request</h2>
     <p>
-    Code style guidelines, what we look for in a PR, links to git tutorials.
+    Pull requests are the way that community members like you can get your code
+    pulled into the official Torque 3D repository for everyone else to use. We
+    accept community contributions that align with our vision for the engine -
+    especially bug fixes, enhancements to existing features, and revisions of
+    old, slow, or ugly code. Pull requests are the way that code gets reviewed
+    before it's accepted into the engine - even cod that we, the Steering Committee,
+    write ourselves.
     </p>
+
+    <p>
+    In order to ensure the quality of the engine code going into the future, we
+    have strict rules about what code we can and cannot accept. We also have
+    some soft guidelines that inform our decision-making progress in trickier
+    cases.
+    </p>
+
+    <h2>Pull request rules</h2>
+    <p>
+    Pull requests not adhering to these rules <i>cannot</i> be accepted, so pay attention!
+    </p>
+
+    <ul>
+        <li>Obviously, your contribution cannot contain any code that is not
+        legally compatible with Torque 3D's MIT license. In addition, to legally
+        protect the engine and everyone affiliated with it, we require that all
+        contributors create an account on
+        <a href="http://garagegames.com">GarageGames.com</a> and sign the Open
+        Source Software Agreement there. For more information on the OSSA, please visit
+        <a href="https://github.com/GarageGames/Torque3D/wiki/Contributing#open-source-software-agreement">this page in our wiki</a>.</li>
+
+        <li>Contributions must adhere to our
+        <a href="https://github.com/GarageGames/Torque3D/wiki/Code-Style-Guidelines">code style guidelines</a>.</li>
+
+        <li>Pull-requests against the master branch cannot be accepted. All requests
+        must go to development, or an appropriate topic or maintenance branch.</li>
+
+        <li></li>
+        <li></li>
+        <li></li>
+        <li></li>
+    </ul>
+
+    <p>
+    In many cases, if any of these rules are breached, we will first ask the contributor
+    to resubmit their pull request, or add commits to it that resolve our issues.
+    In exceptional cases, a committee member may perform that work themselves.
+    Sometimes, we may also ask contributors to rebase large numbers of commits
+    into a single commit before the request is pulled.
+    </p>
+
+    <h2>Pull request guidelines</h2>
+    <p>
+    Here are some of the things we look for in a great pull request. These aren't
+    hard-and-fast rules, but following these guidelines will increase the chances
+    that your request is pulled!
+    </p>
+
+    <ul>
+        <li>Our favourite requests are ones that work directly towards the goals
+        laid out in our <a href="{{page.root}}/engine#roadmap">roadmap</a>. We
+        are more likely to help out and fix slightly broken pull requests if
+        they align with our goals, and chances are your request will move faster
+        through our process.</li>
+
+        <li>Each pull request should be <i>focused</i> and <i>concise</i>. If
+        it has a very clear intent and a small set of changes towards a specific
+        goal, it's easy for us to decide whether we want it, and to then test it
+        and make sure it works as advertised and doesn't break things.</li>
+
+        <li>If you're fixing a bug, we need you to provide steps to reproduce the
+        bug, so we can verify that exists and that your patch actually does fix it.
+        We'd also appreciate platform and compiler information.</li>
+
+        <li></li>
+        <li></li>
+        <li></li>
+        <li></li>
+    </ul>
+
+    <h2>The pull request process</h2>
 </div>
 
 <div class="banner"><div class="container">