drop documentation for branching conventions

Author: darobin

generator/content/how-to/create.html

@@ -44,11 +44,8 @@ <h2 id="forking">Forking</h2>
       for you.
     </p>
     <p>
-      Check it out and create a new topic branch. The rule for branches is very simple:
-      <code>master</code> is for things that have shipped in implementations and are well-tested, and
-      <code>develop</code> is for stuff that doesn't yet pass tests but that does have clear
-      implementation commitments from browser vendors. If not in either of the previous two
-      categories, just pick a self-descriptive name that you like.
+      Check it out and create a new topic branch. There are no specific rules for branches, but if
+      making a proposal for a specific feature do try to pick a descriptive name.
     </p>
     <p>
       You will then need to edit your specification. WebSpecs can come in two formats. If you see a

generator/content/index.html

@@ -191,14 +191,6 @@ <h2>How Things Work</h2>
       world, simply make a pull request to have it linked to from
       <a href="https://github.com/webspecs/the-index">the index</a>.
     </p>
-    <p>
-      One thing that is important to note: we ascribe specific meaning to some <code>git</code>
-      branches. We reserve <code>master</code> for specifications that are well supported in
-      implementations (as demonstrated using a credible test suite) and <code>develop</code>
-      for specifications that are in the process of being implemented by vendors (i.e. they have
-      shown genuine interest and some buggy, partial code is being worked on). For specifications
-      that are still just proposals, please use any other branch name.
-    </p>
     <p>
       That’s it! Or at least, that’s all you need to understand to get started. We are building
       extensive documentation. And like everything we do, if you don’t like it,

generator/content/policy/principles.html

@@ -47,14 +47,10 @@
     </dd>
     <dt id="tested">Tested</dt>
     <dd>
-      There is only one difference between a WebSpecs specification sitting in a topic branch and 
-      one that’s taken into the <code>master</code> branch: testing. If a specification
-      has a good enough (for sane values of “good enough”, perfection not being of this world) 
-      test suite in our sister <a href="https://github.com/w3c/web-platform-tests/">Web Platform
-      Tests</a> project and that test suite has a <em>good enough</em> pass ratio in at least a
-      couple of major browsers, then that specification is good to merge to <code>master</code>.
-      If it is being implemented but isn’t yet tested well enough, it’s in <code>develop</code>.
-      Otherwise, it’s a proposal.
+      Web Platform Specs and <a href="https://github.com/w3c/web-platform-tests/">Web Platform
+      Tests</a> are obvious sibling projects. The same spirit that prevails here applies there, and
+      all WebSpec projects are strongly encouraged to contribute testing relevant to their
+      specification to WPT.
     </dd>
   </dl>
   <p>

how-to/create.html

@@ -69,11 +69,8 @@ <h2 id="forking">Forking</h2>
       for you.
     </p>
     <p>
-      Check it out and create a new topic branch. The rule for branches is very simple:
-      <code>master</code> is for things that have shipped in implementations and are well-tested, and
-      <code>develop</code> is for stuff that doesn't yet pass tests but that does have clear
-      implementation commitments from browser vendors. If not in either of the previous two
-      categories, just pick a self-descriptive name that you like.
+      Check it out and create a new topic branch. There are no specific rules for branches, but if
+      making a proposal for a specific feature do try to pick a descriptive name.
     </p>
     <p>
       You will then need to edit your specification. WebSpecs can come in two formats. If you see a

index.html

@@ -206,14 +206,6 @@ <h2>How Things Work</h2>
       world, simply make a pull request to have it linked to from
       <a href="https://github.com/webspecs/the-index">the index</a>.
     </p>
-    <p>
-      One thing that is important to note: we ascribe specific meaning to some <code>git</code>
-      branches. We reserve <code>master</code> for specifications that are well supported in
-      implementations (as demonstrated using a credible test suite) and <code>develop</code>
-      for specifications that are in the process of being implemented by vendors (i.e. they have
-      shown genuine interest and some buggy, partial code is being worked on). For specifications
-      that are still just proposals, please use any other branch name.
-    </p>
     <p>
       That’s it! Or at least, that’s all you need to understand to get started. We are building
       extensive documentation. And like everything we do, if you don’t like it,

policy/principles.html

@@ -72,14 +72,10 @@ <h1 class="onlyTitle">Core Principles</h1>
     </dd>
     <dt id="tested">Tested</dt>
     <dd>
-      There is only one difference between a WebSpecs specification sitting in a topic branch and 
-      one that’s taken into the <code>master</code> branch: testing. If a specification
-      has a good enough (for sane values of “good enough”, perfection not being of this world) 
-      test suite in our sister <a href="https://github.com/w3c/web-platform-tests/">Web Platform
-      Tests</a> project and that test suite has a <em>good enough</em> pass ratio in at least a
-      couple of major browsers, then that specification is good to merge to <code>master</code>.
-      If it is being implemented but isn’t yet tested well enough, it’s in <code>develop</code>.
-      Otherwise, it’s a proposal.
+      Web Platform Specs and <a href="https://github.com/w3c/web-platform-tests/">Web Platform
+      Tests</a> are obvious sibling projects. The same spirit that prevails here applies there, and
+      all WebSpec projects are strongly encouraged to contribute testing relevant to their
+      specification to WPT.
     </dd>
   </dl>
   <p>