{% extends "layout.html" %}
{% block title %}Triage a Webcompat Issue{% endblock %}
{% block body %}
<div>
  {% include "nav/nav.html" %}
  <main role="main">
    <section class="grid grid-show-gap">
      <div class="grid-row">
        <aside class="grid-cell x1-fix">
          {% include "contributors/sub-nav.html" %}
        </aside>
        <article class="grid-cell x1">
          <h1 id="triage" class="headline-1 heading">Triage A Webcompat Issue</h1>
          <p>
            Someone has <a href="/contributors/report-bug">reported a bug</a>. The issue is now in the <a href="/issues?page=1&amp;per_page=50&amp;state=open&amp;stage=needstriage&amp;sort=created&amp;direction=desc">needs triage list</a>. You can help!
          </p>

          <p>
            Triaging is an important step in the process. You will be assessing the quality of the issue. You will notice right away that a lot of issues are either invalid or lack the minimum details for <a href="/contributors/diagnose-bug">being able to investigate and create a diagnosis</a>.
          </p>
        </article>
      </div>
    </section>
    <section class="grid">
      <div class="grid-row">
        <div class="grid-cell x3">
          <h2 id="neutral" class="headline-1 heading">Have A Neutral Test Environment</h2>
          <p>
            For having a better understanding of the issue, you will probably need to have a setup which makes it possible to have a fresh profile of the browser you are testing with. For example, on Firefox you can <a href="http://www.otsukare.info/2014/11/12/configure-webcompat-browser" target="_blank">create a profile which resets each time the browser restarts</a>.
          </p>
        </div>
      </div>
    </section>
    <section class="grid">
      <div class="grid-row">
        <div class="grid-cell x3">
          <h2 id="reproducing" class="headline-1 heading">Reproducing The Issue</h2>
          <p>
            Reproducing the issue is sometimes a very tough game. Some issues are happening because of the local settings of the person who created the report. Geographical location, preferences choices, web extensions and add-ons, OS, network constraints, logged on the services, devices and many other parameters are all possibly the source of the breakage as perceived by the reporter.
          </p>

          <p>
            Try your best to understand the report and reproduce the issue. If you have a doubt, reach out <a href="/contributors">someone from the project</a> to help. You may wish to add a screenshot if one was not provided, or if you are seeing different results from the one that was provided. Think of yourself another bug reporter.
          </p>
        </div>
      </div>
    </section>
    <section class="grid">
      <div class="grid-row">
        <div class="grid-cell x3">
          <h2 id="next" class="headline-1 heading">Possible Next Steps</h2>

          <p>
            If you <strong class="bold">can not reproduce the issue</strong>, check if it has been opened by an identified reporter or anonymously. If the issue has an identified reporter, you may want to ask them additional questions (give them a week or two to answer before closing the issue). If the issue was reported anonymously, do not hesitate to close with one of the statuses below. Please do not forget to thank the reporter for opening the issue in the first place.
          </p>

          <p>
            When closing, give information on the rationale for your decision. It doesn't have to be long, but that will help if we decide to reopen or for the reporters to understand the reasoning.
          </p>

          <dl id="statuses">
            <dt id="incomplete" class="bold heading">
              incomplete
            </dt>
            <dd>
              The issue doesn't have enough details to be able to reproduce in a reasonable way. For example, the reporter gives a final screen which is not working, but it is impossible to infer all the steps for reaching this state.
            </dd>

            <dt id="non-compat" class="bold heading">
              non-compat
            </dt>
            <dd id="everywhere">
              The issue is happening on all browsers, perhaps due to the site having a programming error, or a server being unreachable or misconfigured.
            </dd>

            <dt id="worksforme" class="bold heading">
              worksforme
            </dt>
            <dd>
              To the best of your knowledge and your inability to reproduce, the website is working for you.
            </dd>

            <dt class="bold heading">
              invalid
            </dt>
            <dd>
              The report is totally unrelated to the work we do on the webcompat project.
            </dd>
          </dl>

          <p>
            If you <strong class="bold">can reproduce the issue</strong>:
          </p>

          <dl id="statuses">
            <dt class="bold heading">
              duplicate
            </dt>
            <dd>
              A similar issue might exist on the project or there is a known bug on a browser bug tracker to duplicate against. Provide the links to the other webcompat issue or the bug tracker. Leave a comment on the bug tracker to inform that there is a duplicate. On Mozilla bugzilla, you can add the webcompat issue URL to the SeeAlso field.
            </dd>

            <dt class="bold heading">
              needsdiagnosis
            </dt>
            <dd>
              The issue has been successfully reproduced, and it is time to hand it over to the diagnosis crew.
            </dd>
          </dl>
        </article>
      </div>
    </section>
  </main>
</div>
{% endblock %}
{%- block extrascripts -%}
<script type="module" src="{{ url_for('static', filename='dist/contributors.js')|bust_cache }}"></script>
{%- if config.PRODUCTION or config.STAGING -%}
<script nomodule src="{{ url_for('static', filename='dist/contributors.es5.js')|bust_cache }}"></script>
{%- endif %}
{%- endblock %}
