Vos rapports de bugs peuvent nous aider à améliorer rapidement K-Meleon. Pour que ceci devienne une réalité, et vous le souhaitez autant que nous, vous devrez prendre un peu de temps pour la rédaction des rapports.
Mieux le rapport est écrit, mieux celui-ci peut-être utilisé pour la résolution rapide des problèmes. Ceci ne vous prendra probablement pas plus d'une minute ou deux pour un rapport, ce qui n'est donc pas si long que ça. Suivez le guide suivant, lorsque vous rapportez un bug:
Etape 1: Choisissez le bon endroit pour écrire votre rapport:
a) Les bugs trouvés dans une version beta sont généralement pas mis dans le BTS (les composants développés sont cassés et réparés sur de courts échange...) Merci de communiquer avec la Liste des Développeurs avant de remplir tout rapport de bug pour les versions non stables. Vois l'étape 4 sur le contenu des informations à envoyer. Mais, assurez-vous qu'un rapport n'a pas été déjà saisi si le problèmee n'est pas fixé rapidement.
b) Bugs that have been reported before should not be reported anew.
Always check the Bug Tracking System to see if anyone else has
reported a similar bug as what you have found. If there is a bug,
please add any extra information you have that can help identify and
fix that bug. (Too many of the current bug reports are very vague
and hard to understand.) See step 4 on what information to add.
c) Newly found bugs in official releases should be filed as new
bugs. Select Report a Bug to open a new bug report. If you have
encountered more than one bug at the same time, please file separate
reports for each bug to make the bug tracking easier.
Step 2: Select component, severity and owner.
You will usually not have to bother about the bug report dropdown
fields, but if you are able to identify the faulting component this
might help us to quickly set the right person in charge of the bug.
Please don't try to push "your" bug by setting an extra high
severity, it doesn't work that way. Best way to have a bug fixed
quickly is by providing outstanding information under step 4 below.
Step 3: Write a short, one-line, "summary".
It is _very_ important that you write a summary that provides a good
description of your bug. This will often be the only text read when
searching, grouping and judging the relations of different bugs
later. Take your time and think carefully! If the bug involves a
specific plugin or component, it can be wise to include the name of
that in the summary.
Step 4: Write a detailed description of your bug.
Tell us, short and to the point, but yet detailed:
-
- What you were doing when the bug happened.
- What you expected to happen and what actually happened.
- The steps that we need to follow to recreate your bug.
- If the bug just happened once or happens over and over again.
- The URL for the web site if the bug happens at a specific web site.
- Whether other Mozilla browsers are affected too.
Try find out if the bug depends on whether one or the other plugin
is loaded or not, whether changing some preferences give different
results, or anything else you can think of that can be of
importance. But don't make guesses in your report! This point is
worth spending some time on. You want help with having the bug
fixed. We want help with figuring out what goes wrong.
If a bug involves rendering, networking, javascript, or third party
plugins chances are that it is not a bug in the K-Meleon source.
Please see if other Gecko-based browsers are effected too (such as
Netscape, Mozilla, MfcEmbed) and try find a relevant bugzilla entry
to add to your report in that case.
Always use your best English when writing a bug report; aim for
proper language, grammar, punctuation and so on. Standard
compliance is the best way to guarantee that what you write is
interpret the way you intend. ;-)
Step 5: Click on Submit to file your bug!
We will follow-up on your report as soon as we can. The more
information you provide us, the more likely that we can identify and
fix the bug you have found. With your help, we will clean up our
K-Meleon bugs as fast as possible!