<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/22/2014 01:20 PM, Pranith Kumar
      Karampuri wrote:<br>
    </div>
    <blockquote cite="mid:53F6F64A.3070807@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <br>
      <div class="moz-cite-prefix">On 08/22/2014 11:46 AM, Joe Julian
        wrote:<br>
      </div>
      <blockquote cite="mid:53F6E023.1050609@joejulian.name" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        adding the "correct" gluster-devel to this.<br>
        <br>
        <div class="moz-cite-prefix">On 8/21/2014 10:55 PM, Joe Julian
          wrote:<br>
        </div>
        <blockquote cite="mid:53F6DB62.1090006@joejulian.name"
          type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          There have been times that I, as a user and a front-line
          supporter, have marked a bug with the urgency that I think it
          deserves - based on my own knowledge as well as feedback from
          other users - only to have that urgency lowered to normal
          because a developer who doesn't experience the urgency we do
          as users, deemed it so.<br>
        </blockquote>
      </blockquote>
      Actually developers/assignees are not allowed to change severity,
      never (Something that I learnt an year back. May be some
      developers don't even know about it :-( ). Only priority is
      something that can be lowered by the assignee. In my experience
      this happens for severe bugs as well when the steps to re-create
      the bug are not there or logs are not enough to find the root
      cause etc.<br>
      <blockquote cite="mid:53F6E023.1050609@joejulian.name" type="cite">
        <blockquote cite="mid:53F6DB62.1090006@joejulian.name"
          type="cite"> <br>
          Granted, there have also been many occasions where I didn't
          set the urgency and my bug has been treated as if it was a
          message from beyond the natural realm, for which I am truly
          grateful.<br>
        </blockquote>
      </blockquote>
      Because the message _is_ from beyond natural realm ;-)<br>
      <blockquote cite="mid:53F6E023.1050609@joejulian.name" type="cite">
        <blockquote cite="mid:53F6DB62.1090006@joejulian.name"
          type="cite"> <br>
          When I set the urgency, I try to consider more than just my
          own current needs (though often they're truly quite urgent)
          and look at potential for data loss, likelihood to encounter
          the bug during normal operations, and feedback from other
          users who have (usually) encountered the same bug. To have all
          that forethought discarded is disheartening. For that reason,
          I never set the urgency of any of my bugs any more.<br>
        </blockquote>
      </blockquote>
      I guess it would be better if you could raise it in devel mailing
      list rather that not setting the urgency anymore :-(.<br>
      <blockquote cite="mid:53F6E023.1050609@joejulian.name" type="cite">
        <blockquote cite="mid:53F6DB62.1090006@joejulian.name"
          type="cite"> <br>
          I would be willing to participate in triage, but I would
          expect the same rigidness in changing an urgency as there is
          in getting a change accepted. The developer who wants to
          change the urgency should be expected to argue his case, not
          simply change it.<br>
        </blockquote>
      </blockquote>
      +1<br>
      <br>
      Pranith<br>
    </blockquote>
    <br>
    It would good if we can update the triage wiki page [1] to have
    right criteria/information about changing Severity and Priority. We
    should treat the wiki page as our policy document.<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://www.gluster.org/community/documentation/index.php/Bug_triage">http://www.gluster.org/community/documentation/index.php/Bug_triage</a><br>
    <br>
    -Lala<br>
    <blockquote cite="mid:53F6F64A.3070807@redhat.com" type="cite">
      <blockquote cite="mid:53F6E023.1050609@joejulian.name" type="cite">
        <blockquote cite="mid:53F6DB62.1090006@joejulian.name"
          type="cite"> <br>
          <div class="moz-cite-prefix">On 8/21/2014 12:12 AM, Lalatendu
            Mohanty wrote:<br>
          </div>
          <blockquote cite="mid:53F59BD7.30108@redhat.com" type="cite">
            <meta http-equiv="content-type" content="text/html;
              charset=ISO-8859-1">
            I hope the subject line have increased your curiosity to go
            through the email :). <br>
            <br>
            As a community, we are looking for contributors for
            GlusterFS bug triage and hopefully this mail will give you
            enough motivation for it. <br>
            <br>
            As mentioned in the subject , bug triage will help to get
            bugs fixed quicker, and features implemented sooner. If you
            are not sure what bug triage means, please refer the gluster
            wiki page [1] for bug triage.<br>
            <br>
            Here are few questions and answers to help you if this is
            something you should do.<br>
            <br>
            <ul>
              <li>Q: Why we need to do bug triage?</li>
              <li>A: It reduces the time between reporting a bug and the
                availability of a fix enormously.</li>
              <ul>
                <li>Because many developers have bad response times for
                  new bugs that are not pointed out to them. When well
                  triaged bugs get assigned to right developers, the
                  response time improves. <br>
                </li>
                <li>Also developers work mainly on writing bug fixes and
                  implementing new features. Which in turn results in to
                  spending (too little) time on bug triaging. <br>
                </li>
              </ul>
            </ul>
            <p><br>
            </p>
            <ul>
              <li>Q: I am just a GlusterFS user. Why bug triage will
                help me? <br>
              </li>
              <li>A: It will increase your understanding of GlusterFS,&nbsp;
                current issues in GlusterFS, increase the interaction
                between developers, community and triager. It will also
                help filing better bugs too. The better the bug report,
                the easier it is for a developer to write a fix. </li>
            </ul>
            <p><br>
            </p>
            <ul>
              <li>Q: Do you run GlusterFS in production?</li>
              <li>A: If your answer is yes, then bug triage is the right
                platform for you to raise the importance of bugs. Bug
                triage will also help you know existing issues in the
                version of GlusterFS you are using, help you to know
                existing issues in a new feature. So you will be in a
                better position to decide if a feature is production
                ready or not.</li>
            </ul>
            <p><br>
            </p>
            <ul>
              <li>Q: I want to contribute to GlusterFS. Will bug triage
                help?</li>
              <li>A: Yes, it is an awesome place to start. You will get
                to know about all the components in GlusterFS along with
                issues in each of them. This knowledge will help you to
                do better testing, development (bug fixing) etc. Also
                you will interact with developers while triaging bugs.
                You can use these interactions to ask more detailed
                questions. </li>
            </ul>
            <p><br>
            </p>
            <ul>
              <li>Q: How can I triage bugs of GlusterFS?</li>
              <li>A: The wiki page [1] is the right place start. We are
                starting up a bi-weekly/weekly triage meeting in
                #gluster-meeting on Freenode. There would be another
                mail with details about the meeting. You can join the
                meeting and interact with other triagers.</li>
            </ul>
            Please don't hesitate to hit the reply button if you have
            any question on this. We would love to hear your
            suggestions/feed back :).<br>
            <br>
            [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.gluster.org/community/documentation/index.php/Bug_triage">http://www.gluster.org/community/documentation/index.php/Bug_triage</a><br>
            <br>
            Thanks,<br>
            On behalf of the bug triage team<br>
            #gluster-dev, #gluster on Freenode<br>
            <br>
            <fieldset class="mimeAttachmentHeader"></fieldset>
            <br>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>