De quoi s'agit t-il?
Proposition visant à améliorer les rapports techniques de bugs en y ajoutant un "rapport humain" dont la définition est apportée. Deux exemples. Conclusion.
L'auteur est utilisateur exclusif d'Ubuntu depuis juin 2006 (huit versions).
Ordinateur, portable Toshiba A80, Pentium M 1,73 Mhz, carte graphique Intel i915, carte son Intel 82801FB/FBM/FR/FW/FRW (ICH6 Family)
1. La marée des bugs
Chaque saison amène inévitablement à Ubuntu sa nouvelle moisson de bugs. La moisson d'automne est aussi riche que celle de printemps. Comme nous le fait savoir le service du marketing, les utilisateurs d'Ubuntu étant sans cesse plus nombreux, le nombre de bugs a cru ces derniers temps de façon exponentielle. C'est la marque d'un progrès qui n'a pu, je pense, échapper à personne de bonne foi. Félicitons-les de bon cœur.
Mais hélas cet accroissement du nombre de bugs n'est pas pallié par un accroissement exponentiel du nombre de développeurs chargé de les résoudre. Les bugs sont jetés en tas, triés, classés, puis certains sont expédiés ailleurs, la plupart sont oubliés, et le cycle recommence. Il me semble que ce système certes perfectionné, a besoin d'être encore amélioré pour lui donner un meilleur sens des priorités. Nous avons peu de moyens, n'est ce pas?
2. Comment s'orienter ?
Il conviendrait de donner à Ubuntu des éléments supplémentaires pour lui permettre de s'orienter dans cette marée qui le submerge pour lui permettre d'identifier les bugs réellement insupportables.
Certes, il existe aujourd'hui une échelle qualitative très pratique, qui culmine avec le bug classé "critique". Mais cette classification est de la responsabilité exclusive des développeurs. A l'expérience, elle n'apparait pas suffisante pour provoquer une amélioration de la situation.
3. Le "rapport humain"
C'est pourquoi il me semble qu'il faudrait compléter les rapports techniques de bugs envoyés par les utilisateurs par ce que j'appelle un "rapport humain". Ce dernier répondrait aux questions suivantes dont les spécialistes de sciences humaines connaissent l'importance et qui pourtant ne figurent pas dans les rapports de bug :
- a t-il une histoire?
Ce bug existe t-il depuis plusieurs versions d'Ubuntu? Un 4V acquerrait ainsi un poids relatif bien plus important qu'un 2V.
Les mono V triviaux, multiples et foisonnants, retombent immédiatement dans le lot commun.
- quel est son poids utilisateur?
Pour attirer l'attention des développeurs, l'utilisateur devrait pouvoir indiquer à son niveau l'importance relative qu'il accorde à ce bug. Je propose de les noter avec les lettres A (atroce) et F (frustrant).
Le rapport lambda serait noté S (schmilblic) puisqu'il est simplement destiné à le faire avancer.
- est-ce un nouveau bug (B) ou une régression (R) ?
Si la distinction ne vous parait pas évidente, c'est que vous ne pratiquez pas Ubuntu depuis suffisamment longtemps. Selon ce que nous disent les spécialistes, la régression survient dans un contexte de progrès significatif et n'est censée concerner qu'une infime minorité (cela veut dire "vous" ) d'utilisateurs. Vous êtes le malchanceux qui paye les pots cassés. Rien que vous. Na!
D'expérience, je sais qu'une régression est beaucoup plus durement ressentie et plus difficilement pardonnée qu'un bug concernant une fonctionnalité nouvelle. Elle mérite donc une coefficient supérieur au bug standard.
4. Comment quantifier un "rapport humain"?
Par le nombre de leurs points utilisateurs (PU), obtenu de la façon suivante:
histoire et nombre de versions: deux points par version
poids subjectif? A= six points, F= deux points, S= zéro point
bug ou régression? B= un point, R= deux points
Je propose qu'au delà de dix points, le bug soit reconnu comme "désastreux", quel qu'en soit le classement donné par ailleurs par un développeur surmené, fatigué, esseulé, irrité.
5. Deux exemples de "rapport humain".
Comme je l'ai indiqué plus haut, ceci viendrait compléter le rapport technique de bug qui n'a pas lieu d'être donné ici.
a)
- deux ans sans micro: Ubuntu peut le faire
Depuis l'introduction de PulseAudio fin avril 2008, je ne peux plus utiliser Skype parce qu'on ne m'entend plus. Cela fonctionnait bien avant PA. A la fin de Jaunty (T= 16 mois), j'ai supprimé PA et, ô merveille, le micro a fonctionné de nouveau. Malheureusement avec Karmic (T=18 mois), la suppression de PA est devenue beaucoup plus compliquée. Les rumeurs de compatibilité de la version 2.1 de Skype (toujours en beta) sont restées des rumeurs.
Selon toute vraisemblance, j'atteindrai la LTS d'avril 2010 sans micro fonctionnel.
Il s'agit d'une regression frustrante et très longue
4V F R soit: 8 +2+2 = 12 pts
b) -
un an de gels: Ubuntu peut le faire.
La sortie de Jaunty en avril 2009 a marqué le début d'une période noire pour les possesseurs de carte Intel comme moi. La regression due aux drivers défectueux n'a pas été corrigée pendant six mois. Il a fallu attendre la sortie de karmic en octobre 2009 et la mise en service de nouveaux drivers (2.9) pour que le phénomène du gel aléatoire disparaisse....presque.
Le bug est sorti par la porte mais rentré par la fenêtre. Aujourd'hui, ma carte graphique est stable en fonctionnement courant. Cependant, la mise en veille (suspend to RAM) crée une instabilité et systématiquement une à deux heures au retour d'une mise en veille, j'ai droit à un gel aussi inopiné qu'atroce.
Selon toute vraisemblance, j'atteindrai la LTS d'avril 2010 en continuant à avoir des gels.
Il s'agit d'une regression longue et atroce.
2V A R soit: 4 + 6 +2= 12 pts
Conclusion.
C'est tout. Je n'ai que deux regressions à vous proposer. Mais elles sont à douze points utilisateur quand même, ce qui devrait suffire à les classer comme "désastreuses" si vous m'avez bien suivi.
A part ça, me direz-vous? Ben, ça va, ça va, on fait aller mais ça a fraîchi. Je vous laisse à vos commentaires. Avant de me brûler sur la place publique, ne prenez quand même pas au pied de la lettre ce que je viens de vous raconter....L'affaire est à prendre au second degré. Mais si le message pouvait passer, j'en serais le premier ravi..
