<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 16, 2014 at 3:50 PM, Matt McCormick <span dir="ltr"><<a href="mailto:matt.mccormick@kitware.com" target="_blank">matt.mccormick@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">It would be good to have some quantifiable, well-defined, objective</span><br>
</div>
criteria on what new classes should be merged.<br></blockquote><div><br></div><div>+1 I think it's certainly a good idea to have an objective policy in place, as it ensures consistent standards and can prevent contributing developers from taking code rejection too personally.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">   - 84% code coverage or better</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  - Expected Nightly green within 2 weeks<br></blockquote><div><br></div><div>I assume these 2 criteria would only apply to migrating classes out of Review. Obviously we can't measure these 2 things until a new submission is merged to master, and then its too late (unless you just revert the merge).</div>
</div><div><br></div>-- <br>Brian Helba<br>Medical Imaging<br>Kitware, Inc.<br>
</div></div>