initial commit

2 files changed, 195 insertions, 0 deletions

diff --git a/files/fr/qa/index.html b/files/fr/qa/index.html
new file mode 100644
index 0000000000..a84aeb8874
--- /dev/null
+++ b/files/fr/qa/index.html
@@ -0,0 +1,60 @@
+---
+title: Assurance qualité
+slug: QA
+translation_of: Mozilla/QA
+---
+<div>
+<p>Il y de nombreuses choses que vous pouvez faire pour aider le projet Mozilla dans le département d'Assurance Qualité, sans être un expert en programmation. Certaines ne nécessitent pas non plus de connaissances en HTML ou autres technologies Web. Si nous aider à tester ou pour d'autres activités d'Assurance Qualité vous intéresse, consultez avant tout les pages <a class="external" href="http://www.mozilla.org/quality/">Mozilla Quality Assurance</a> et <a class="external" href="http://www.mozilla.org/quality/help/">Helping with Quality Assurance</a>.</p>
+</div>
+
+<table class="topicpage-table">
+ <tbody>
+  <tr>
+   <td>
+    <h2 class="Documentation" id="Documentation" name="Documentation">Documentation</h2>
+
+    <dl>
+     <dt><a href="/fr/docs/Recommandations_pour_l'écriture_d'un_bug" title="fr/docs/Recommandations_pour_l'écriture_d'un_bug">Recommandations pour l'écriture d'un bug</a></dt>
+     <dd>Plus un bogue signalé sera précis, plus il y aura des chances qu'un développeur le corrige. En suivant ces recommandations, vous serez assuré que votre bogue reste au-dessus de la pile des ingénieurs de Mozilla et soit corrigé. (à traduire de <a href="/en/Bug_writing_guidelines" title="en/Bug_writing_guidelines">en:Bug writing guidelines</a>)</dd>
+     <dt><a class="external" href="http://www.mozilla.org/quality/help/screening-duplicates.html">Comment identifier les rapports de bugs dupliqués</a></dt>
+     <dd>Ce guide vous aidera à identifier un maximum de rapports de nouveaux bugs de manière la plus efficace. Cela suppose que vous soyez habitué à la recherche des doublons dans Bugzilla.</dd>
+     <dt><a class="external" href="http://www.mozilla.org/quality/help/beginning-duplicate-finding.html">Comment détecter si un bug a déjà été rapporté</a></dt>
+     <dd>Vous pouvez faire en sorte que plus de bogues soient corrigés rapidement en vérifiant la base de données Bugzilla avant de poster votre bug, et ne pas en créer un nouveau si celui que vous avez trouvé existe déjà.</dd>
+     <dt><a class="external" href="http://www.mozilla.org/bugs/text-searching.html">Utilisation des expressions rationnelles avec le moteur de recherche de Bugzilla</a></dt>
+     <dd>Ce guide fournit suffisamment de connaissances de base et des exemples concrets pour utiliser les autres types de recherche (particulièrement les expressions rationnelles) — et c'est ainsi que vous ferez votre expérience.</dd>
+    </dl>
+
+    <p><span class="alllinks"><a href="/fr/docs/tag/Assurance_qualité:Articles" title="fr/docs/tag/Assurance_qualité:Articles">Tous les articles…</a></span></p>
+   </td>
+   <td>
+    <h2 class="Community" id="Communaut.C3.A9" name="Communaut.C3.A9">Communauté</h2>
+
+    <ul>
+     <li><a class="external" href="http://quality.mozilla.org/">QMO | quality.mozilla.org</a></li>
+     <li><a class="link-irc" href="irc://irc.mozilla.org/qa">#qa sur irc.mozilla.org</a></li>
+     <li><a class="link-irc" href="irc://irc.mozilla.org/bugs">#bugs sur irc.mozilla.org</a></li>
+     <li><a class="link-irc" href="irc://irc.mozilla.org/smoketest">#smoketest sur irc.mozilla.org</a></li>
+     <li>Forums MozillaZine : <a class="external" href="http://forums.mozillazine.org/viewforum.php?f=23">Firefox Builds</a>, <a class="external" href="http://forums.mozillazine.org/viewforum.php?f=29">Thunderbird Builds</a></li>
+    </ul>
+
+    <h2 class="Tools" id="Outils" name="Outils">Outils</h2>
+
+    <ul>
+     <li><a href="/fr/docs/Bugzilla" title="fr/docs/Bugzilla">Bugzilla</a> — base de données des bugs pour les projets Mozilla</li>
+     <li><a class="external" href="http://litmus.mozilla.org/">Litmus</a></li>
+     <li><a href="/fr/docs/Assurance_qualité/Tests_en_charge" title="fr/docs/Assurance_qualité/Tests_en_charge">Tests en charge</a></li>
+    </ul>
+
+    <p><span class="alllinks"><a href="/fr/docs/tag/Assurance_qualité:Outils" title="fr/docs/tag/Assurance_qualité:Outils">Tous les outils…</a></span></p>
+
+    <h2 class="Related_Topics" id="Sujets_li.C3.A9s" name="Sujets_li.C3.A9s">Sujets liés</h2>
+
+    <ul>
+     <li><a href="/fr/docs/Développement_de_Mozilla" title="fr/docs/Développement_de_Mozilla">Développement de Mozilla</a></li>
+    </ul>
+
+
+   </td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/fr/qa/triaging_bugs_for_firefox/index.html b/files/fr/qa/triaging_bugs_for_firefox/index.html
new file mode 100644
index 0000000000..31510b18c0
--- /dev/null
+++ b/files/fr/qa/triaging_bugs_for_firefox/index.html
@@ -0,0 +1,135 @@
+---
+title: Triaging Bugs for Firefox
+slug: QA/Triaging_Bugs_for_Firefox
+translation_of: Mozilla/QA/Triaging_Bugs_for_Firefox
+---
+<p>Ce document aidera toute personne intéressée par la <a href="http://quality.mozilla.org/">QA chez Mozilla</a> d'apprendre les techniques pour aider avec les bugs tout le long de leur évolution. Il permettra de fixer plus rapidement les bugs importants et d'optimiser l'efficacité de notre communauté Bugzilla. Avant d'entrer dans les détails, il est important de savoir que le Triage  fait ainsi est la raison pour laquelle il est important.</p>
+
+<h3 id="Qu'est_ce_que_le_Triage">Qu'est ce que le Triage?</h3>
+
+<p> Le triage de Bugs est le  processus de déplacement logiques des bugs d'un état à un autre, de sorte qu'ils puissent être résolus d'une manière efficace et facile à comprendre. Chez Mozilla, la QA ne doit pas seulement tester et ensuite déposer leurs propres bugs, mais elle doit aussi aider à exploiter le flux entrant des bugs de la communautés pour trouver des problèmes valides.</p>
+
+<h3 id="Pourquoi_voudriez_vous_aider">Pourquoi voudriez vous aider?</h3>
+
+<p><a href="https://bugzilla.mozilla.org/">Bugzilla</a> est le coeur du projet Mozilla, <span id="result_box" lang="fr"><span class="hps">comme</span> <span class="hps">tous les produits</span>, <span class="hps">Mozilla</span> <span class="hps">suit</span> <span class="hps">ses</span> <span class="hps">défauts logiciels</span> <span class="hps">et les améliorations</span> <span class="hps">dans</span> <span class="hps">BMO</span><span>.</span> <span class="hps">Il n'y a rien</span> <span class="hps">dans le projet</span> <span class="hps">tout aussi</span> <span class="hps">central ou</span> <span class="hps">aussi important que</span> <span class="hps">BMO</span><span>.</span> <span class="hps">Le triage</span> <span class="hps">est nécessaire pour</span> <span class="hps">veiller à ce que</span> <span class="hps">tous les</span> <span class="hps">défauts signalés</span> <span class="hps">sur</span> <span class="hps">Bugzilla</span> <span class="hps">soient</span><span class="hps"> répondu</span><span>.</span> <span class="hps">Un</span> <span class="hps">arriéré de</span> <span class="hps">bugs dans</span> un <span class="hps">Etat quelconque</span><span>, en particulier</span> <span class="hps">l'état</span> <span class="hps">UNCONFIRMED</span><span>,</span> <span class="hps">affecte notre capacité à</span> <span class="hps">réagir à vos</span> <span class="hps">questions importantes</span> <span class="hps">rapidement et efficacement.</span> <span class="hps">Ainsi</span><span>,</span> <span class="hps">nos</span> <span class="hps">déclencheurs</span> <span class="hps">de bugs</span> <span class="hps">sont <strong>incroyablement</strong></span><strong> </strong><span class="hps"><strong>vitales</strong> pour notre</span> <span class="hps">développement de produits</span><span>.</span></span></p>
+
+<h2 id="Préréquis">Préréquis</h2>
+
+<h3 id="Equipez_vous">Equipez vous</h3>
+
+<ul>
+ <li>Télécharger le plus récent <a href="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/">nightly build</a> (recommendé)<a href="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/"> </a></li>
+ <li>Enregistrer un compte avec <a href="http://bugzilla.mozilla.org/">Bugzilla</a></li>
+</ul>
+
+<h3 id="Autorisations_Bugzilla">Autorisations Bugzilla</h3>
+
+<ul>
+ <li><span class="short_text" id="result_box" lang="fr"><span class="hps">Pour modifier</span> <span class="hps">les bugs</span><span>,</span> <span class="hps">vous devez avoir</span> <span class="hps">au moins</span></span>  une autorisation "canconfirm".</li>
+ <li>si vous utilisé Bugzilla depuis un certain temps, vous pouvez déjà avoir ces privilèges. Pour une double vérification, regardez vos <a href="https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions">Préférences Bugzilla</a>. Si votre autorisation affiche  "Can confirm a bug", alors vous l'avez!</li>
+ <li><span id="result_box" lang="fr"><span class="hps">Sinon, vous</span> <span class="hps">aurez besoin de</span> <span class="hps">les obtenir.</span> <span class="hps">Pour trouver un</span> <span class="hps">bon endroit pour</span> <span class="hps">en apprendre davantage sur</span> <span class="hps">comment obtenir</span> <span class="hps">ces autorisations,</span> <span class="hps">s'il vous plaît</span> <span class="hps">lise</span></span>  <a href="https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla">Que faire et ne pas faire sur Bugzilla</a>.</li>
+</ul>
+
+<h3 id="Création_de_requêtes_de_recherche_sur_Bugzilla"><span class="short_text" id="result_box" lang="fr"><span class="hps">Création de</span> <span class="hps">requêtes de recherche</span> <span class="hps">sur</span> <span class="hps">Bugzilla</span></span></h3>
+
+<p>Bugzilla offre deux façons àun utilisateur de trouver des bugs dans sa base de données. Il y a une <a href="https://bugzilla.mozilla.org/query.cgi?format=specific">option de recherche simple</a> et une <a href="https://bugzilla.mozilla.org/query.cgi?format=advanced">option de recherche avancée</a>. <span id="result_box" lang="fr"><span class="hps">Chacun</span>e <span class="hps">offre un moyen</span> <span class="hps">unique de</span> <span class="hps">recherche</span> <span class="hps">qui</span> <span class="hps">permet à l'utilisateur</span> <span class="hps">une certaine souplesse</span> <span class="hps">dans la façon dont</span> <span class="hps">ils veulent</span> <span class="hps">effectuer</span> <span class="hps">leur recherche</span><span>.</span></span> A simple search will only restrict search parameters to any currently not-fixed bug that match the string input by the user. Meanwhile, the advanced search form allows the user the ability to really cut down on any glut found through a simple search. But it can be a bit confusing. So, Bugzilla offers a "Give me Some Help" hyperlink located in the top left portion of the form that reloads the page with hover-enabled tool-tips to guide you through each module. <a href="https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html">This link</a> also give you more information about searching in Bugzilla.</p>
+
+<h3 id="Persistent_Queries_and_how_to_Manage_them">Persistent Queries and how to Manage them</h3>
+
+<ul>
+ <li>After creating a query, you might want to keep that query for future use. If that's the case, it can be transitioned into a <a href="http://www.bugzilla.org/docs/tip/en/html/userpreferences.html#savedsearches">Saved Search</a>, which will appear in the page footer. To save a search, scroll to the bottom of the page, fill out the text field at the bottom of the page and click on the "Remember Search" button.</li>
+ <li>It's very useful if you only plan to go through the bugs every so often, or if you need to track something based on keywords or fields other than product/component, or when you need to look through older bugs.</li>
+</ul>
+
+<h3 id="Tracking_Components">Tracking Components</h3>
+
+<p>If you want something more immediate, you can choose to track a component, such as Disability Access. This is possible via your Bugzilla preferences using the "Component Watching" option. Make sure to track the relevant component in both <a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Core&amp;component=Disability+Access+APIs&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailtype2=exact&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0="> Core-&gt;Disability Access APIs</a> and in the products you care about, such as <a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Firefox&amp;component=Disability+Access&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailtype2=exact&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Firefox (Firefox-&gt;Disability Access)</a> or Thunderbird.</p>
+
+<h2 id="Clean_incoming_Bugs">Clean incoming Bugs</h2>
+
+<h3 id="Why_is_it_Important">Why is it Important?</h3>
+
+<p>Ensuring bugs are properly marked helps make sure they don't get ignored. For example, if a bug that really affects all platforms is marked "Solaris" because the original bug author was on a Solaris machine, most developers will ignore it. Other common issues include major bugs that are marked normal, bugs with a confusing summary, etc. So, ensuring that the bug is properly marked is very helpful in getting the attention it deserves.</p>
+
+<h3 id="What_would_Speed_Up_the_Process">What would Speed Up the Process?</h3>
+
+<p>Each time you submit changes to the bug it creates extra Bugmail, so it's better to do the following steps in batches, if possible.</p>
+
+<ul>
+ <li><u>Find the Inherent Issue:</u> Read very carefully to try and understand what they're talking about. For a guide on how to simplify test cases, go <a href="https://wiki.mozilla.org/QA/Minimal_Test_Cases">here</a>.</li>
+ <li><u>Look for duplicates:</u> A lot of bug reporters mistakenly assume their bug haven't been filed yet. Search for previously filed bugs by searching for keywords in the summary in the bug. For example, if the bug is about the control key, try spelling it ctrl as well. If the user includes a crash report, you can easily clink on the link to see if the crash has already been reported.</li>
+ <li><u>Use the "needinfo" flag to ask for more information from the reporter</u>: If you don't understand the bug or can't reproduce the bug, ask the reporter for more information by selecting "Set Flags" (on the right hand side of the bug entry page) until you have enough information to try it yourself. If they did not provide build information, get that right away, because many bug reports are for older versions that have long been fixed. Some other information you could ask for: - Does the bug occur in <a href="http://kb.mozillazine.org/Safe_mode"> Safe Mode</a>? With a <a href="http://kb.mozillazine.org/Profile_Manager">clean profile</a>? - If it's a crash, ask for Crash Reporter Data found via the "about:crashes" page. - If the reporter still can reproduce but you can't, ask him/her nicely if he/she can test the latest nightly build.</li>
+ <li><u>Ensure appropriate hardware/platform tests</u>: most bug filers will only have tested on one platform. If bug was filed for a particular platform, see if it's a bug on another platform. If it's been reproduced on at least 2 platforms that aren't both Unix/Linux, then go ahead and mark it All/All ((Hardware/OS). If you don't have the capability to test across multiple platforms, going to the #qa channel on irc.mozilla.org is an excellent way to find people that can verify your bug on other platforms.</li>
+ <li><u>Ensure a concise and precise summary</u>: The summary should be 60 characters or less and allow the bug to be reachable via an accurate simple search.</li>
+ <li><u>Ensure Proper Severity</u>: Go to <a href="https://bugzilla.mozilla.org/page.cgi?id=fields.html">this link</a> and scroll down to the "Severity" section for a handy guide. If you feel like the listed severity on the bug report is not accurate, make sure to comment why the bug should be changed and change the state.</li>
+ <li><u>Change Product, Component and owner</u>: Many bugs get marked "Firefox" when they are really bugs in the Core engine. Core shared components used by Firefox and other Mozilla software include :
+  <ul>
+   <li>Handling of Web content</li>
+   <li>Gecko</li>
+   <li>HTML</li>
+   <li>CSS</li>
+   <li>layout</li>
+   <li>DOM</li>
+   <li>scripts</li>
+   <li>images</li>
+   <li>networking</li>
+   <li>Issues with web page layout probably go in Core</li>
+   <li>Firefox user interface issues belong in the <a href="https://bugzilla.mozilla.org/editproducts.cgi?action=edit&amp;product=Firefox">Firefox</a> product.  After you submit a Product change to the bug, Bugzilla will allow you to change the Component as well. When changing Product and/or Component you usually want to select the radio button "Reassign bug to default assignee and QA contact of selected component ".</li>
+  </ul>
+ </li>
+ <li><u>Add Keywords</u>: here are just a few of the important ones (the full list of keywords is located <a href="https://bugzilla.mozilla.org/describekeywords.cgi">here</a>).
+  <ul>
+   <li> "<strong>qawanted</strong>": bugs which need more info, or it needs reproducing, or testcasing, or it's a dupe but you can't find what it's a dupe of. Remove this keyword when the wanted QA work has been completed -</li>
+   <li>"<strong>regressionwindow-wanted</strong>": needs someone to narrow down the time period where it happened, ideally to a specific checkin - "<strong>testcase-wanted</strong>": needs a testcase or its current testcase needs to be simplified in order for the bug to be fixed</li>
+   <li><strong>"access"</strong>: mark accessibility bugs with the keyword "access". This allows accessibility bugs to not be tied to the "Disability Access" or "Keyboard navigation" components, but to the actual component with the problem. For example, the developers for Places should really be responsible for accessibility bugs in Places, but adding the keyword "access" makes sure.</li>
+   <li><strong>"regression"</strong>: mark regressions with "regression". Was this ever not a bug? For example, did it work in Firefox 37? See below for more important information on how to deal with regressions.</li>
+   <li><strong>"crash"</strong>: pretty obvious :)</li>
+   <li><strong>"dataloss"</strong>: this bug will cause users to lose data</li>
+   <li><strong>"hang"</strong>: freezes or locks up the application</li>
+   <li><strong>"testcase"</strong>: indicates that a simplified testcase is included (see below)</li>
+  </ul>
+ </li>
+</ul>
+
+<hr>
+<h3 id="Steps_to_Reproduce"><span style="color: #000000;"><span style="font-size: 1.385em; line-height: 1.538;">Steps to Reproduce</span></span></h3>
+
+<p><span style="line-height: 1.538;">Sometimes, a bug report contains no steps to reproduce or steps that only work for very few people. In that case, it is extremely difficult for a developer to debug and fix the reported issue. Most of the time, these bug reports (and crash reports, where applicable) will contain multiple clues or variations of steps and it is needed for someone to work through them and narrow down reliable steps to reproduce. Here are a few guidelines for narrowing down those steps:</span></p>
+
+<ul>
+ <li>Read everything in the bug report and any other information linked there (crash reports, support entries etc). This information will tell you where to start.</li>
+ <li>Use your instincts. Your experience with using the browser can help you realize where you should be looking.</li>
+ <li>Ask for additional information from the reporter using the needinfo flag if there are no helpful clues in the bug report.</li>
+ <li>Working with the same OS and Firefox version as the issue was reported on will give more chances of reproducing it and finding the right steps.</li>
+ <li>Even if you don't manage to find reliable steps to reproduce, update the bug with the details of your work. This will help anyone else willing to give it a try later.</li>
+</ul>
+
+<h3 id="Minimal_Test_Cases"><span style="color: #000000;"><span style="font-size: 1.385em; line-height: 1.538;">Minimal Test Cases</span> </span></h3>
+
+<p>Reporters usually add to their bug reports the links for the web pages they saw issues on. Some of these pages are very complex, making it quite difficult to realize where or why the bug happens. To help investigate and debug a issue with a complex web page, you first need to reduce it to a minimal test case (i.e. a test case that contains the minimum set of elements that reproduces the issue). Here are some steps for using the process of elimination to create a minimal test case:</p>
+
+<ul>
+ <li>Save the web page on your local hard drive. Make a second copy.</li>
+ <li>From the first copy, cut out big pieces of CSS, JS or HTML -- start with the pieces that are most likely to not have the bug. For example, at first just try to strip out plain paragraphs as these are relatively simple. Try to make as much as possible inline. Try to strip out all images, frames. If any image is required to get the bug, try changing the src to something that isn't likely to expire, such as: <a href="http://www.google.com/images/logo.gif">the Google Logo</a>.</li>
+ <li>If the new version of the file still has the bug, save it as your second copy and repeat step 2.</li>
+ <li>If the new version does not have the bug, then your second copy still contains the bug. In this case, repeat step 2 but avoid cutting out the same piece that you did last time.</li>
+ <li>When you can no longer cut out any HTML without destroying the ability of the file to show the bug, you have a minimal testcase.</li>
+</ul>
+
+<p>Hopefully you'll be left with a file that has only 1-5 HTML elements in it, but still reproduces the bug. At this point you can actually try to start stripping out irrelevant attributes as well You may end up with something like: <code>&lt;label for="myfile"&gt;Enter file name:&lt;/label&gt;&lt;input id="myfile" disabled="disabled" type="file"&gt;</code> ...instead of 50k worth of HTML. When finished, attach the minimal testcase, mark the bug with keyword testcase, and change the bug summary if necessary. For example, "No borders in tables at http://www.sillystatsandstuff.com" can become something much more precise such as "tables with rowspans do not get borders". If it doesn't affect the test - add a title so it can be referred to, e.g &lt;title&gt;Testcase #1 for bug 123456. Also, add the bug number in the filename of the testcase. You have to understand that people from different parts of the world will be reading this, so making concise and direct sentences are much appreciated. For example, if the bug involves line wrapping, then the width of the window and the font size may impact the results. In this case, you can ensure that your reduced testcase will work for everyone by using "font-family: monospace;" and a width specified in "ch" units.</p>
+
+<h3 id="What_do_I_take_away_from_this">What do I take away from this?</h3>
+
+<p>This can all be rather intimidating for people who haven't been playing around with different web technologies such as <a href="http://en.wikipedia.org/wiki/Ajax_%28programming%29">AJAX</a>, <a href="http://en.wikipedia.org/wiki/JavaScript">JS</a>, or <a href="http://en.wikipedia.org/wiki/XML">XML</a> for a long time, but the most important thing to take away from this page is that there's a backend to the bugs you find when interacting with any software, hardware, or general product. Make sure to take that into account when writing your next bug or triaging a host of incoming bugs on Bugzilla! Continue reading all about <a href="https://developer.mozilla.org/en-US/docs/Triaging_crash_bugs#Regression_windows">Finding a Regression Window</a>.</p>
+
+<hr>
+<div class="originaldocinfo">
+<h2 id="Original_document_information">Original document information</h2>
+
+<ul>
+ <li>Author(s): Aakash Desai</li>
+ <li>Date last modified: April 18, 2013 at 7:42 am PST</li>
+</ul>
+</div>
+
+<p> </p>