[net] Convert bug triage documents to Markdown.

R=rdsmith
BUG=none

Review URL: https://codereview.chromium.org/1017743002

Cr-Commit-Position: refs/heads/master@{#321574}

net/docs/bug-triage-labels.md

+# Chrome Network Bug Triage : Labels
+
+## Some network label caveats
+
+**Cr-UI-Browser-Downloads**
+: Despite the name, this covers all issues related to downloading a file except
+  saving entire pages (which is **Cr-Blink-SavePage**), not just UI issues.
+  Most downloads bugs will have the word "download" or "save as" in the
+  description.  Issues with the HTTP server for the Chrome binaries are not
+  downloads bugs.
+
+**Cr-UI-Browser-SafeBrowsing**
+: Bugs that have to do with the process by which a URL or file is determined to
+  be dangerous based on our databases, or the resulting interstitials.
+  Determination of danger based purely on content-type or file extension
+  belongs in **Cr-UI-Browser-Downloads**, not SafeBrowsing.
+
+**Cr-Internals-Network-SSL**
+: This includes issues that should be also tagged as **Cr-Security-UX**
+  (certificate error pages or other security interstitials, omnibox indicators
+  that a page is secure), and more general SSL issues.  If you see requests
+  that die in the SSL negotiation phase, in particular, this is often the
+  correct label.
+
+**Cr-Internals-Network-DataProxy**
+: Flywheel / the Data Reduction Proxy.  Issues require "Reduce Data Usage" be
+  turned on.  Proxy url is [https://proxy.googlezip.net:443](), with
+  [http://compress.googlezip.net:80]() as a fallback.  Currently Android and
+  iOS only.
+
+**Cr-Internals-Network-Cache**
+: The cache is the layer that handles most range request logic (Though range
+  requests may also be issued by the PDF plugin, XHRs, or other components).
+
+**Cr-Internals-Network-SPDY**
+: Covers HTTP2 as well.
+
+**Cr-Internals-Network-HTTP**
+: Typically not used.  Unclear what it covers, and there's no specific HTTP
+  owner.
+
+**Cr-Internals-Network-Logging**
+: Covers **about:net-internals**, **about:net-export** as well as the what's
+  sent to the NetLog.
+
+**Cr-Internals-Network-Connectivity**
+: Issues related to switching between networks, ERR_NETWORK_CHANGED, Chrome
+  thinking it's online when it's not / navigator.onLine inaccuracies, etc.
+
+**Cr-Internals-Network-Filters**
+: Covers SDCH and gzip issues.  ERR_CONTENT_DECODING_FAILED indicates a problem
+  at this layer, and bugs here can also cause response body corruption.
+
+## Common non-network labels
+
+Bugs in these areas often receive the **Cr-Internals-Network** label, though
+they fall largely outside the purview of the network stack team:
+
+**Cr-Blink-Forms**
+: Issues submitting forms, forms having weird data, forms sending the wrong
+  method, etc.
+
+**Cr-Blink-Loader**
+: Cross origin issues are sometimes loader related.  Blink also has an
+  in-memory cache, and when it's used, requests don't appear in
+  about:net-internals.  Requests for the same URL are also often merged there
+  as well.  This does *not* cover issues with content/browser/loader/ files.
+
+**Cr-Blink-ServiceWorker**
+
+**Cr-Blink-Storage-AppCache**
+
+**Cr-Blink-WebSockets**
+
+**Cr-Blink-XHR**
+: Generic issues with sync/async XHR requests - missing request or response
+  headers, multiple headers, etc.  These will often run into issues in certain
+  corner cases (Cross origin / CORS, proxy, whatever).  Attach all labels that
+  seem appropriate.
+
+**Cr-Services-Sync**
+: Sharing data/tabs/history/passwords/etc between machines not working.
+
+**Cr-Services-Chromoting**
+
+**Cr-Platform-Extensions**
+: Issues extensions loading / not loading / hanging.
+
+**Cr-Platform-Extensions-API**
+: Issues with network related extension APIs should have this label.
+  chrome.webRequest is the big one, I believe, but there are others.
+
+**Cr-Internals-Plugins-Pepper[-SDK]**
+
+**Cr-UI-Browser-Omnibox**
+: Basically any issue with the omnibox.  URLs being treated as search queries
+  rather than navigations, dropdown results being weird, not handling certain
+  unicode characters, etc.  If the issue is new TLDs not being recognized by
+  the omnibox, that's due to Chrome's TLD list being out of date, and not an
+  omnibox issue.  Such TLD issues should be duped against
+  http://crbug.com/37436.
+
+**Cr-Internals-Media-Network**
+: Issues related to media.  These often run into the 6 requests per hostname
+  issue, and also have fun interactions with the cache, particularly in the
+  range request case.
+
+**Cr-Internals-Plugins-PDF**
+: Issues loading pdf files.  These are often related to range requests, which
+  also have some logic at the Internals-Network-Cache layer.
+
+**Cr-UI-Browser-Navigation**
+
+**Cr-UI-Browser-History**
+: Issues which only appear with forward/back navigation.
+
+**Cr-OS-Systems-Network** / **Cr-OS-Systems-Mobile** / **Cr-OS-Systems-Bluetooth**
+: These should be used for issues with ChromeOS's platform network code, and
+  not net/ issues on ChromeOS.
+
+**Cr-Blink-SecurityFeature**
+: CORS / Cross origin issues.  Main frame cross-origin navigation issues are
+  often actually **Cr-UI-Browser-Navigation** issues.
+
+**Cr-Privacy**
+: Privacy related bug (History, cookies discoverable by an entity that
+  shouldn't be able to do so, incognito state being saved in memory or on disk
+  beyond the lifetime of incognito tabs, etc).  Generally used in conjunction
+  with other labels.
+
+**Type-Bug-Security**
+: Security related bug (Allows for code execution from remote site, allows
+  crossing security boundaries, unchecked array bounds,
+  etc).

net/docs/bug-triage-labels.txt

-Some network label caveats
-* Cr-UI-Browser-Downloads:  Despite the name, this covers all issues related to
-    downloading a file except saving entire pages (Which is Cr-Blink-SavePage),
-    not just UI issues.  Most downloads bugs will have the word "download" or
-    "save as" in the description. Issues with the HTTP server for the Chrome
-    binaries are not downloads bugs.
-* Cr-UI-Browser-SafeBrowsing:  Bugs that have to do with the process by which a
-    URL or file is determined to be dangerous based on our databases, or the
-    resulting interstitials. Determination of danger based purely on
-    content-type or file extension belongs in Cr-UI-Browser-Downloads, not
-    SafeBrowsing.
-* Cr-Internals-Network-SSL:  This includes issues that should be also tagged as
-    Cr-Security-UX (certificate error pages or other security interstitials,
-    omnibox indicators that a page is secure), and more general SSL issues.  If
-    you see requests that die in the SSL negotiation phase, in particular, this
-    is often the correct label.
-* Cr-Internals-Network-DataProxy:  Flywheel / the Data Reduction Proxy.  Issues
-    require "Reduce Data Usage" be turned on.  Proxy url is
-    https://proxy.googlezip.net:443, with compress.googlezip.net:80 as a
-    fallback.  Currently Android and iOS only.
-* Cr-Internals-Network-Cache:  The cache is the layer that handles most range
-    request logic (Though range requests may also be issued by the PDF plugin,
-    XHRs, or other components).
-* Cr-Internals-Network-SPDY:  Covers HTTP2 as well.
-* Cr-Internals-Network-HTTP:  Typically not used.  Unclear what it covers, and
-    there's no specific HTTP owner.
-* Cr-Internals-Network-Logging:  Covers about:net-internals, about:net-export as
-    well as the what's sent to the NetLog.
-* Cr-Internals-Network-Connectivity:  Issues related to switching between
-    networks, ERR_NETWORK_CHANGED, Chrome thinking it's online when it's not /
-    navigator.onLine inaccuracies, etc.
-* Cr-Internals-Network-Filters:  Covers SDCH and gzip issues.
-    ERR_CONTENT_DECODING_FAILED indicates a problem at this layer, and bugs here
-    can also cause response body corruption.
-
-
-Common non-network label reference.  Bugs in these areas often receive the
-Cr-Internals-Network label, though they fall largely outside the purview of the
-network stack team:
-* Cr-Blink-Forms:  Issues submitting forms, forms having weird data, forms
-    sending the wrong method, etc.
-* Cr-Blink-Loader:  Cross origin issues are sometimes loader related.  Blink
-    also has an in-memory cache, and when it's used, requests don't appear in
-    about:net-internals.  Requests for the same URL are also often merged there
-    as well.  This does *not* cover issues with content/browser/loader/ files.
-* Cr-Blink-ServiceWorker
-* Cr-Blink-Storage-AppCache
-* Cr-Blink-WebSockets
-* Cr-Blink-XHR:  Generic issues with sync/async XHR requests - missing request
-    or response headers, multiple headers, etc.  These will often run into
-    issues in certain corner cases (Cross origin / CORS, proxy, whatever).
-    Attach all labels that seem appropriate.
-* Cr-Services-Sync:  Sharing data/tabs/history/passwords/etc between machines
-    not working.
-* Cr-Services-Chromoting
-* Cr-Platform-Extensions:  Issues extensions loading / not loading / hanging.
-* Cr-Platform-Extensions-API:  Issues with network related extension APIs should
-    have this label. chrome.webRequest is the big one, I believe, but there are
-    others.
-* Cr-Internals-Plugins-Pepper[-SDK]
-* Cr-UI-Browser-Omnibox:  Basically any issue with the omnibox.  URLs being
-    treated as search queries rather than navigations, dropdown results being
-    weird, not handling certain unicode characters, etc.  If the issue is new
-    TLDs not being recognized by the omnibox, that's due to Chrome's TLD list
-    being out of date, and not an omnibox issue.  Such TLD issues should be
-    duped against http://crbug.com/37436.
-* Cr-Internals-Media-Network:  Issues related to media.  These often run into
-    the 6 requests per hostname issue, and also have fun interactions with the
-    cache, particularly in the range request case.
-* Cr-Internals-Plugins-PDF:  Issues loading pdf files.  These are often related
-    to range requests, which also have some logic at the Internals-Network-Cache
-    layer.
-* Cr-UI-Browser-Navigation
-* Cr-UI-Browser-History:  Issues which only appear with forward/back navigation.
-* Cr-OS-Systems-Network / Cr-OS-Systems-Mobile / Cr-OS-Systems-Bluetooth:  These
-    should be used for issues with ChromeOS's platform network code, and not
-    net/ issues on ChromeOS.
-* Cr-Blink-SecurityFeature:  CORS / Cross origin issues.  Main frame
-    cross-origin navigation issues are often actually Cr-UI-Browser-Navigation
-    issues.
-* Cr-Privacy:  Privacy related bug (History, cookies discoverable by an entity
-    that shouldn't be able to do so, incognito state being saved in memory or on
-    disk beyond the lifetime of incognito tabs, etc).  Generally used in
-    conjunction with other labels.
-* Type-Bug-Security:  Security related bug (Allows for code execution from
-    remote site, allows crossing security boundaries, unchecked array bounds,
-    etc).

net/docs/bug-triage.txt → net/docs/bug-triage.md

+# Chrome Network Bug Triage
+
 The Chrome network team uses a two day bug triage rotation.  The main goals are
 to identify and label new network bugs, and investigate network bugs when no
 label seems suitable.
 
-Responsibilities
+## Responsibilities
 
-Required:
+### Required:
 * Identify new crashers
 * Identify new network issues.
 * Request data about recent Cr-Internals-Network issue.
 * Investigate each recent Cr-Internals-Network issue.
 * Monitor UMA histograms and gasper alerts.
 
-Best effort:
+### Best effort:
 * Investigate unowned and owned-but-forgotten net/ crashers
 * Investigate old bugs
 * Close obsolete bugs.
 
-All of the above is to be done on each rotation.  These
-responsibilities should be tracked, and anything left undone at the
-end of a rotation should be handed off to the next triager.  The
-downside to passing along bug investigations like this is each new
-triager has to get back up to speed on bugs the previous triager was
-investigating.  The upside is that triagers don't get stuck
-investigating issues after their time after their rotation, and it
-results in a uniform, predictable two day commitment for all triagers.
+All of the above is to be done on each rotation.  These responsibilities should
+be tracked, and anything left undone at the end of a rotation should be handed
+off to the next triager.  The downside to passing along bug investigations like
+this is each new triager has to get back up to speed on bugs the previous
+triager was investigating.  The upside is that triagers don't get stuck
+investigating issues after their time after their rotation, and it results in a
+uniform, predictable two day commitment for all triagers.
+
+## Details
 
-More detail:
+### Required:
 
-Required activities:
 * Identify new crashers that are potentially network related.  You should check
-    the most recent canary, the previous canary (if the most recent less than a
-    day old), and any of dev/beta/stable that were released in the last couple
-    of days, for each platform.  File Cr-Internals-Network bugs on the tracker
-    when new crashers are found.
+  the most recent canary, the previous canary (if the most recent less than a
+  day old), and any of dev/beta/stable that were released in the last couple of
+  days, for each platform.  File Cr-Internals-Network bugs on the tracker when
+  new crashers are found.
+
 * Identify new network bugs, both on the bug tracker and on the crash server.
-    All Unconfirmed issues filed during your triage rotation should be scanned,
-    and, for suspected network bugs, a network label assigned.  A triager is
-    responsible for looking at bugs reported from noon PST / 3:00 pm EST of the
-    last day of the previous triager's rotation until the same time on the last
-    day of their rotation.
-* Investigate each recent (New comment within the past week or so)
+  All Unconfirmed issues filed during your triage rotation should be scanned,
+  and, for suspected network bugs, a network label assigned.  A triager is
+  responsible for looking at bugs reported from noon PST / 3:00 pm EST of the
+  last day of the previous triager's rotation until the same time on the last
+  day of their rotation.
+
+* Investigate each recent (new comment within the past week or so)
   Cr-Internals-Network issue, driving getting information from reporters as
   needed, until you can do one of the following:
-  * Mark it as WontFix (working as intended, obsolete issue) or a duplicate.
-  * Mark it as a feature request.
-  * Remove the Cr-Internals-Network label, replacing it with at least one more
-    specific network label or non-network label.  Promptly adding non-network
-    labels when appropriate is important to get new bugs in front of someone
-    familiar with the relevant code, and to remove them from the next triager's
-    radar.  Because of the way the bug report wizard works, a lot of bugs
-    incorrectly end up with the network label.
-  * The issue is assigned to an appropriate owner.
-  * If there is no more specific label for a bug, it should be investigated
-    until we have a good understanding of the cause of the problem, and some
-    idea how it should be fixed, at which point its status should be set to
-    Available.  Future triagers should ignore bugs with this status, unless
-    investigating stale bugs.
+
+    * Mark it as *WontFix* (working as intended, obsolete issue) or a
+      duplicate.
+
+    * Mark it as a feature request.
+
+    * Remove the Cr-Internals-Network label, replacing it with at least one
+      more specific network label or non-network label.  Promptly adding
+      non-network labels when appropriate is important to get new bugs in front
+      of someone familiar with the relevant code, and to remove them from the
+      next triager's radar.  Because of the way the bug report wizard works, a
+      lot of bugs incorrectly end up with the network label.
+
+    * The issue is assigned to an appropriate owner.
+
+    * If there is no more specific label for a bug, it should be investigated
+      until we have a good understanding of the cause of the problem, and some
+      idea how it should be fixed, at which point its status should be set to
+      Available.  Future triagers should ignore bugs with this status, unless
+      investigating stale bugs.
+
 * Monitor UMA histograms and gasper alerts.
-  * For each Gasper alert that fires, the triager should determine if
-    the alert is real (not due to noise), and file a bug with the
-    appropriate label if so.  Note that if no label more specific than
-    Cr-Internals-Network is appropriate, the responsibility remains
-    with the triager to continue investigating the bug, as above.
 
-Best Effort (As you have time):
+    * For each Gasper alert that fires, the triager should determine if the
+      alert is real (not due to noise), and file a bug with the appropriate
+      label if so.  Note that if no label more specific than
+      Cr-Internals-Network is appropriate, the responsibility remains with the
+      triager to continue investigating the bug, as above.
+
+### Best Effort (As you have time):
+
 * Investigate unowned and owned but forgotten net/ crashers that are still
-    occurring (As indicated by go/chromecrash), prioritizing frequent and long
-    standing crashers.
+  occurring (As indicated by
+  [go/chromecrash](https://goto.google.com/chromecrash)), prioritizing frequent
+  and long standing crashers.
+
 * Investigate old bugs, prioritizing the most recent.
+
 * Close obsolete bugs.
 
 If you've investigated an issue (in code you don't normally work on) to an
@@ -75,5 +91,8 @@ extent that you know how to fix it, and the fix is simple, feel free to take
 ownership of the issue and create a patch while on triage duty, but other tasks
 should take priority.
 
-See bug-triage-suggested-workflow.txt for suggested workflows.
-See bug-triage-labels.txt for labeling tips for network and non-network bugs.
+See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for
+suggested workflows.
+
+See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
+and non-network bugs.