Index: xdocs/legal/drafts/process-draft.xml
===================================================================
--- xdocs/legal/drafts/process-draft.xml	(revision 676819)
+++ xdocs/legal/drafts/process-draft.xml	(working copy)
@@ -31,14 +31,26 @@
 intended for those who are interested as to what the ASF do to manage the ownership of their products. </p>
 </section>
 
+<section><title>Contributions</title>
+<p>
+Contributions are covered by the Apache License. See its clear
+<a href="/licenses/LICENSE-2.0.html#definitions">Definitions</a> of the terms
+"Contribution" and "Contributor" and the condition
+"<a href="/licenses/LICENSE-2.0.html#contributions">Submission of Contributions</a>".
+As explained there, if a submission is intended to be "Not a Contribution", then
+it needs to be conspicuously marked as such and the issue trackers provide a
+mechanism.
+</p>
+</section>
+
 <section><title>Incoming code</title>
 <p>Source code enters the foundation in one of the following ways: </p>
 <ol type="i">
 <li>An existing third party project joining Apache</li>
 <li>A large one off code contribution</li>
 <li>Repeated contributions applied directly to the source</li>
-<li>Patches applied to issue trackers</li>
-<li>Small patches submitted to the mailing list</li>
+<li>Patches contributed via the issue trackers</li>
+<li>Small patches contributed via the mailing lists.</li>
 </ol>
 <p>Each of these methods has its own process:</p>
 <ol type="i">
@@ -49,8 +61,8 @@
 <a href="http://incubator.apache.org/ip-clearance/index.html">IP Clearance page</a>. </li>
 <li>Individuals who want to directly contribute to the project sign a <a href="/licenses/icla.txt">Individual Contributor License Agreement</a> (CLA). Sometimes they and their employer will also want to sign a 
 separte <a href="/licenses/cla-corporate.txt">Corporate CLA</a> with the ASF, depending on the situation. Usually these contributions take the effect of commits to the source code repository, another example is for access to updating the website through a content management system. </li>
-<li>Patches to the JIRA issue trackers contain a checkbox that users must check to 'Grant license to ASF for inclusion in ASF works'. Developers using the Bugzilla issue tracker have to check for this . </li>
-<li>Mailing list patches are applied and expected to be simple. The same applies for inline comments in the issue trackers, or any other form of conversation. None of these tools easily support complex patches. </li>
+<li>Patches provided via the JIRA issue trackers contain a checkbox that users must check to 'Grant license to ASF for inclusion in ASF works'. Developers using the Bugzilla issue tracker have to check for this. </li>
+<li>Patches contributed via mailing lists are expected to be simple. The same applies for inline comments in the issue trackers, or any other form of conversation. None of these tools easily support complex patches. </li>
 </ol>
 
 <p>No matter how the code gets in, when it hits the source code repository an email is sent out to the mailing list in charge of that repository detailing the change. At which point the relevant Project Management Committee (PMC) are able to review the code. In some rare cases review-then-commit is used instead of commit-then-review and the patch has already been reviewed prior to committing. </p>