Assigner des bogues à des paquets aide à diriger les rapports de bogues vers les développeurs les plus potentiellement capables d'aider. En s'assurant de la pertinence de cette information, vous augmentez les chances de voir le bogue résolu rapidement. Il n'est souvent pas aisé de décider du paquet contenant le bogue, et il est alors adapté de reporter le bogue pour Ubuntu. Si un bogue est assigné à un paquet qui n'est clairement pas le bon, mais connaissez pas le bon paquet, changez-le pour Ubuntu.
Le paquet correct pour les bogues dans le noyau Linux est linux, quel que soit le paquet réellement utilisé (il y a beaucoup de paquets qui contiennent des noyaux Linux).
Si un bogue est marqué « Non confirmé » (Unconfirmed), il est utile que vous essayiez de reproduire le problème et que vous enregistriez les résultats dans Malone. Si vous êtes capable de reproduire le problème, vous devriez changer l'état (Status) pour « Confirmé » (Confirmed). Si vous ne parvenez pas à confirmer le problème, c'est aussi une information utile qui devrait être enregistrée dans un commentaire.
Forwarding bugs upstream
Vous pouvez transmettre les bogues aux auteurs du logiciel (upstream), si
vous vous êtes assuré que le bogue ne se produit pas à cause des changements dûs à Ubuntu.
le changement est trop difficile à appliquer par vous-même ou quelqu'un de l'équipe
Si vous faites ça, soyez certain d'inclure les informations nécessaires, telles que
comment reproduire le bogue
which version is used (which version of dependent libraries, if the bug indicates problems there)
la personne qui l'a rapporté
l'endroit où la conversation complète peut être trouvée
Assurez-vous de créer un rapport de bogue dans Malone pour ce bogue.
Si vous pensez que le bogue reporté est une demande de fonctionnalité déguisée en rapport de bogue, présentez aimablement au rapporteur vers notre Processus de Spécification (Specification Process). Soyez certain de mentionner les ressources pour la spécification suivantes : FeatureSpecifications, SpecSpec, SpecTemplate, et http://launchpad.net/specs.
Si vous pensez que le bogue rapporté est une demande de support déguisée en rapport de bogue, présentez aimablement au rapporteur notre outil de suivi de support (Support Tracker). Soyez certain de mentionner http://launchpad.net/support.
Si vous pensez que le bogue rapporté est une suggestion pour changer le comportement par défaut déguisée en rapport de bogue, dirigez aimablement la discussion vers une liste de discussion (mailing liste) ou un forum de discussion adaptés. Si ce changement a déjà été discuté et rejeté, expliquez-en les raisons à l'utilisateur et dirigez-le vers la discussion en question pour d'autres suggestions/commentaires.
Trouver les doublons de bogues est une contribution de grande valeur à la communauté des bogues. Les utilisateurs ne savent parfois pas comment vérifier si le même bogue a déjà été rapporté et parfois ils ne s'y intéressent pas. Éviter les messages tels que « MOI AUSSI » et rassembler l'information sont cruciaux pour le processus de correction de bogues.
Il y a quelques mesures que vous pouvez prendre pour aider de ce point de vue. La première est de chercher les bogues reportés pour le même composant. Essayez de reformuler votre recherche et vous concentrer sur les actions et mots qui décrivent les éléments impliqués pour la reproduction du bogue.
Exemples :
Simples : DAAP support est un doublon de please enable daap.
Plus compliqués : plug:spdif on emu10k1 gone after breezy upgrade est un doublon de Muted sound after dist-upgrade from Hoary to Breezy.
Si vous ne pouvez pas le trouver dans la liste des bogues ouverts, vous pourriez essayer de le trouver dans la listes des rapports de bogues fermés. Ne vous sentez pas découragés si vous ne trouvez pas les doublons rapidement au début. Après un certain temps, vous reconnaîtrez facilement les suspects habituels et vous serez capable de les identifier plus facilement.
Si vous trouvez un bogue qui a un titre terrible/incompréhensible, reformulez-le afin que les gens le retrouvent plus facilement.
Notez que le Code de Conduite s'applique également aux conversations dans les rapports de bogues. Si vous observez que certaines personnes se comportent de manière irrespectueuse, dirigez-les vers le Code de Conduite Ubuntu.
En tant que rapporteur, vous ne devrez habituellement pas vous occuper de l'état. En tant que trieur de bogues ou que développeur, c'est un outil important pour catégoriser les bogues et avoir une bonne vue d'ensemble de l'état des paquets et des logiciels.
Voici une brève liste et explication des différents états :
Unconfirmed: Bugs start with this status. Bugs marked Unconfirmed sometimes lack information, are not ready, or are not confirmed yet. Most of them have not yet been triaged.
Needs Info: If you have to ask the reporter questions, please set this bug to "Needs Info". A regular task for Needs Info bugs is to ask back. If there are no answers after a reasonable period, close them saying "If you have more information on this bug, please reopen."
Rejected: Bugs marked as Rejected are closed. Be sure to triple-check a bug before you reject it.
Confirmed: Confirmed bugs require somebody else to confirm. Please don't confirm your own bugs.
In Progress: If you start working on a bug, set it to In Progress so people know someone is working on the bug.
Fix Committed: For upstream projects this means the fix is in CVS/SVN/bzr or committed somewhere. For package maintainers it means that the changes are pending and to be uploaded soon (it is what PENDINGUPLOAD is in Bugzilla)
Fix Released: (Correctif publié). Pour les projets gérés sur le Launchpad (upstream), cela signifie qu'une version a été annoncée et est publiquement disponible. Pour les mainteneurs de paquets, ceci signifie qu'un correctif a été téléversé. N'hésitez pas à ajouter un journal des changements (changelog) en commentaire, afin que les gens connaissent les changements affectant leur(s) bogue(s).
Ubuntu utilise la politique suivante afin de juger de la sévérité des bogues :
Wishlist (Souhait) : une requête pour ajouter une nouvelle fonctionnalité à une des programmes dans Ubuntu. Utilisez ceci pour des bogues qui n'en sont pas vraiment mais qui sont plutôt des idées pour des nouvelles fonctionnalités encore inexistantes.
Minor (Mineur) : bogues qui affectent la fonctionnalité, mais dans une moindre mesure que la majorité des bogues
Normal(e) : un bug de fonctionnalité de type standard. La majorité des bogues sont de sévérité « Normale ».
Major (Majeur) un bogue ayant un impact sévère sur une petite part (estimée) d'utilisateurs de Ubuntu ou a un impact modéré sur une large part (estimée) d'utilisateurs de Ubuntu.
Critical (Critique) : un bug ayant un impact sévère sur une large part d'utilisateurs de Ubuntu.
Ne modifiez pas ce champ sans y avoir préalablement invité spécifiquement par un développeur. En particuler, ne PAS utiliser ce champ pour rappeler la version d'Ubuntu dans laquelle le bogue a été observé : ce n'est pas son rôle ! Ce champ est utilisé par l'équipe de version (release team) lorsqu'il y a une raison pour adresser un bogue sur une version cible spécifique.