<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I've <a moz-do-not-send="true"
        href="https://reviews.llvm.org/D99305">posted a patch</a> to
      document our norms around reverts.  I was recently surprised to
      not find anything in this spirit.  A lot of newcomers find our
      norms a bit odd, so having this explicitly spelled out seems very
      worthwhile.</p>
    <p>I tried to stick to stuff that is uncontroversial in the
      community. If you see something here that less than 90+% of the
      community would agree with, please point it out. I'll remove it
      for now, and possibly return to individual points if warranted in
      future reviews.</p>
    <p>Philip</p>
    <p>p.s. Draft text follows, but please make detailed wording
      suggestions on the review.</p>
    <p>Reverts<br>
      -------<br>
      <br>
      As a community, we strongly value having the tip of tree in a good
      state.  As<br>
      such, we tend to make much heaver use of reverts than some other
      open source<br>
      projects, and our norms are a bit different.<br>
      <br>
      When should you revert your own change?<br>
      <br>
      * Any time you learn of a serious problem with a change, you
      should revert it.<br>
        We strongly encourage "revert to green" as opposed to "fixing
      forward".  We<br>
        encourage reverting first, investigating offline, and then
      reapplying the<br>
        fixed patch - possibly after another round of review if
      warranted.<br>
      * If you break a buildbot in a way which can't be quickly fixed,
      please revert.<br>
      * If a test case is reported in the commit thread which
      demonstrates a problem<br>
        please revert, and investigate offline.<br>
      * If you are asked to revert by another contributor, please revert
      and discuss<br>
        the merits of the request offline (unless doing so would further
      destabilize<br>
        trip of tree).<br>
      <br>
      When should you revert someone else's change?<br>
      <br>
      * In general, if the author themselves would revert the change per
      these<br>
        guidelines, we encourage other contributors to do so as a favor
      to the<br>
        author.  This is one of the major cases where our norms differ
      from others;<br>
        we generally consider reverting someones change to be a favor to
      them.  We<br>
        don't expect contributors to be always available, and the
      assurance that a<br>
        problematic patch will be reverted and we can return to it at
      our next<br>
        opportunity enables this.<br>
      * The other case for a third-party revert is for serious norm
      violations.  As a<br>
        general rule, you should never be reverting a patch for this
      unless you've<br>
        already started a discussion highlight the problem on the
      original commit<br>
        thread.  There are exceptions where a rapid revert for a norm
      violation may<br>
        be called for, but if those are relevant for you, you already
      know.<br>
      <br>
      What are the expectations around a revert?<br>
      <br>
      * You should be sure that reverting the change improves the
      stability of tip<br>
        of tree.  Sometimes reverting one change in a series can worsen
      things<br>
        instead of improving them.  We expect reasonable judgment to
      ensure that<br>
        the proper patch or set of patches is being reverted.<br>
      * You should have a publicly reproducible test case ready to
      share.  It is<br>
        not considered reasonable to revert without at least the promise
      to produce<br>
        a public test case in the near term.  We encourage sharing of
      test cases in<br>
        commit threads, or in PRs.  We encourage the reverter to
      minimize the test<br>
        case and to prune dependencies where practical.<br>
      * Reverts should be reasonably timely.  A change submitted two
      hours ago<br>
        can be reverted by a third-party without prior discussion.  A
      change<br>
        submitted two years ago probably shouldn't be.  Where exactly
      the transition<br>
        point is is hard to say, but it's probably in the handful of
      days in tree<br>
        territory.    If you are unsure, we encourage you to reply to
      the commit<br>
        thread, give the author a bit to respond, and then proceed with
      the revert<br>
        if the author doesn't seem to be actively responding.<br>
      <br>
      How should you respond if someone reverted your change?<br>
      <br>
      * In general, the appropriate response is to start by thanking
      them.  If you<br>
        need more information to address the problem, please follow up
      in the<br>
        original commit thread with the reverting patch author.<br>
      * It is normal and healthy to have patches reverted.  Having a
      patch reverted<br>
        does not neccessarily mean you did anything wrong.<br>
      <br>
    </p>
  </body>
</html>