One Hundred Paper Cuts : le flop ?
Vous vous souvenez peut-être de l'annonce dithyrambique faite par Canonical du projet One Hundred Paper Cuts qui devait constituer un des grands axes de développement de Karmic ?
Je dis « peut-être » car il semble que Canonical ait omis de communiquer sur les réalisations du projet et d'en dresser le bilan lors de la sortie de Karmic.
Or l'époque est ainsi faite que, abreuvés que nous sommes d'informations diverse et variées, nous avons la mémoire de plus en plus courte et prêtons de moins en moins attention aux non-dits.
De fait, la blogosphère geek n'a pas manqué de commenter en long, en large et parfois de travers les notes de version d'Ubuntu 9.10 Karmic Koala sans s'arrêter sur les blancs qu'elles comportent, sur ce qu'aurait pu être cette version. Qui s'est demandé ce qu'était devenu le projet One Hundred Paper Cuts, absent des notes de version ?
Pourquoi ce silence de la part de Canonical au moment de dresser le bilan du projet quand l'annonce en avait été faite haut et fort ? Le bilan est-il si catastrophique ? C'est ce que nous allons tenter de voir.
Le projet lancé en juin dernier avait pour objectif de corriger 100 paper cuts d'ici la sortie de Karmic au rythme de 10 par semaine (soit dix « rounds » de prévus).
David Siegel, que j'aurais personnellement préféré ne pas voir recruté par Canonical pour son équipe Design and User Experience, meneur du projet, a posté sur son blogue les rapports des 8 premiers rounds. Son dernier billet sur le sujet date du 28 août dernier puis c'est le silence : plus de « célébration des progrès réalisés » comme préconisé ci-dessus.
Voyons le détail de ces paper cuts :
Dans le premier round, un coup d'œil rapide révèle un score honorable de 8 paper cuts corrigés sur 10.
Dans le détail, que ce sont ces paper cuts ?
Le round 2 promet 8 paper cuts corrigés sur 11 (l'arithmétique n'est plus ce qu'elle était).
Dans le détail :
Le round 3 promet 6 paper cuts corrigés sur 11 (ça baisse). Dans le détail :
Le round 4 promet 6 paper cuts corrigés sur 11. Dans le détail :
Le round 5 promet, comme d'habitude, 6 paper cuts corrigés sur 11 (ça sent la manipulation des paper cuts à travers les rounds pour obtenir des statistiques présentables). Dans le détail :
Le round 6 promet 3 paper cuts corrigés sur 10 (ouille). Rien de spécial à dire ici, je vais pouvoir aller me coucher plus tôt que prévu.
Le round 7 promet 5 paper cuts corrigés sur 12. Rien à signaler à part me féliciter que le bogue signalé par votre serviteur soit résolu (« Downloads should go to ~/Downloads »).
Le round 8 promet 7 paper cuts corrigés sur 11 (presque comme au bon vieux temps des premiers rounds). R.A.S.
Le round 9 promet 2 paper cuts corrigés sur 11 (aïe). Accordés.
Le round 10 promet un bouquet final de 11 paper cuts corrigés sur 19 (attention les yeux). dans le détail :
Je dis « peut-être » car il semble que Canonical ait omis de communiquer sur les réalisations du projet et d'en dresser le bilan lors de la sortie de Karmic.
Or l'époque est ainsi faite que, abreuvés que nous sommes d'informations diverse et variées, nous avons la mémoire de plus en plus courte et prêtons de moins en moins attention aux non-dits.
De fait, la blogosphère geek n'a pas manqué de commenter en long, en large et parfois de travers les notes de version d'Ubuntu 9.10 Karmic Koala sans s'arrêter sur les blancs qu'elles comportent, sur ce qu'aurait pu être cette version. Qui s'est demandé ce qu'était devenu le projet One Hundred Paper Cuts, absent des notes de version ?
Pourquoi ce silence de la part de Canonical au moment de dresser le bilan du projet quand l'annonce en avait été faite haut et fort ? Le bilan est-il si catastrophique ? C'est ce que nous allons tenter de voir.
Le projet lancé en juin dernier avait pour objectif de corriger 100 paper cuts d'ici la sortie de Karmic au rythme de 10 par semaine (soit dix « rounds » de prévus).
A project led by Canonical's Design and User Experience team to improve user experience in Ubuntu by identifying 100 small points of pain for users, or "paper cuts", and healing them!This project aims to improve user experience by:
1. Identifying 100 bugs that appear relatively easy to fix but that negatively impact user experience.
2. Channeling resources to fixing those bugs.
3. Measuring and celebrating progress towards fixing those bugs.
4. Tracking impact of the fixes in upstreams over successive versions.
David Siegel, que j'aurais personnellement préféré ne pas voir recruté par Canonical pour son équipe Design and User Experience, meneur du projet, a posté sur son blogue les rapports des 8 premiers rounds. Son dernier billet sur le sujet date du 28 août dernier puis c'est le silence : plus de « célébration des progrès réalisés » comme préconisé ci-dessus.
Voyons le détail de ces paper cuts :
-1-
Dans le premier round, un coup d'œil rapide révèle un score honorable de 8 paper cuts corrigés sur 10.
Dans le détail, que ce sont ces paper cuts ?
- Ça commence mal : le premier a l'air de figurer dans la liste pour gonfler les statistiques : un bogue mineur sur les nouveau système de notifications comme Mirco Müller en corrige à longueur de journées. Paper cuts ou pas, parions que ce bogue aurait été corrigé exactement de la même façon.
- Apparemment David Siegel sèche sur le bogue visant à remplacer dans le menu contextuel de Nautilus l'entrée « Clean Up by Name » par l'entrée plus adaptée « Arrange by Name » (dernier commentaire posté le 23 juin : « I will try to get more feedback on this ») : dommage ça aurait fait un point facile.
- Le bogue du bouton de recherche qui devrait être à bascule dans la barre d'outils de Nautilus, malgré une intervention efficace de ma part (si, si), a posé des problèmes inattendus qui ont empêché sa correction à temps.
- Passons sur le bogue visant à faire reconnaître le terme Ubuntu par les correcteurs orthographiques du système : je pensais à un poisson d'avril mais le bogue ayant été signalé un 10 avril ça ne colle pas.
-2-
Le round 2 promet 8 paper cuts corrigés sur 11 (l'arithmétique n'est plus ce qu'elle était).
Dans le détail :
- Le bogue du manque de d'informations descriptives sur les programmes listés dans l'entrée « Applications au démarrage » du menu Système->Préférences (« Poor descriptions for some applications in Startup Programs window ») est intéressant mais révèle une relative incohérence du projet qui doit permettre de corriger rapidement des bogues faciles : dès lors pourquoi en noter certains comme non prioritaires (« Importance : low ») alors mêmes qu'ils sont admis au programme curatif de choc ?! Du coup ça traîne à être corrigé et c'est le projet tout entier qui vacille.
- Le bogue « Ambiguous wording in confirmation alert box » est l'exemple d'une mauvaise solution à un réel problème. Computer Janitor vous suggère de supprimer un paquet « pour faire le ménage » (car tout marche bien a priori à ce moment là, mais vous préférez vivre dangereusement) ; vous suivez son conseil et là, en vrai lâche, il vous renvoie à vos responsabilités : « attention à ne pas détraquer le système » ! Mais au lieu de sécuriser l'opération, il est alors proposé de mieux formuler l'avertissement ! De fait, l'on passe de « This may break your system, if you need them. » à « Removing packages that are still needed can cause errors. », notez le progrès substantiel. Pour ma part ça fera un point de moins.
-3-
Le round 3 promet 6 paper cuts corrigés sur 11 (ça baisse). Dans le détail :
- Le bogue visant à créer des icônes spécifiques pour les dossiers XDG Musique, Vidéos... (« Default folders inside Home Folder (e.g. Documents, Music) should have special icons/emblems ») est une autre arnaque puisque GTK+ 2.17.2 a rendu cela possible et le bogue consiste seulement à suivre l'évolution de GTK+ en mettant à jour le thème Ubuntu, ce qui aurait été fait avec ou sans paper cut ! Un point de moins.
-4-
Le round 4 promet 6 paper cuts corrigés sur 11. Dans le détail :
- Faut-il considérer que réduire le nombre de fonds d'écran est un paper cut (« Ship fewer screensavers by default ») ? Je ne pense pas : un bogue, oui, un paper cut, non. - 1.
- La séparateur entre l'applet de notification et l'horloge (« Panel separator between clock and FUSA is not meaningful ») ne semble pas supprimé dans Karmic (sauf erreur de ma part ?) et c'est tant mieux. Pourtant le paper cut est donné pour résolu. -1
- A noter dans les bogues non résolus, un de votre serviteur qui critique que l'export en PDF se fasse par le menu imprimer (« Print to file should say "Export to PDF" instead of "Print to PDF »). Ça n'avance plus pour le moment mais restons patients.
Je concède 4 paper cuts corrigés dans ce quatrième round.
-5-
Le round 5 promet, comme d'habitude, 6 paper cuts corrigés sur 11 (ça sent la manipulation des paper cuts à travers les rounds pour obtenir des statistiques présentables). Dans le détail :
- La correction d'une régression intervenue dans Intrepid tente de se faire passer pour un paper cut (« Annoying beep on shutdown using "System -> Shut down..." ») mais j'ouvre l'œil. -1
-6 à 9-
Le round 6 promet 3 paper cuts corrigés sur 10 (ouille). Rien de spécial à dire ici, je vais pouvoir aller me coucher plus tôt que prévu.
Le round 7 promet 5 paper cuts corrigés sur 12. Rien à signaler à part me féliciter que le bogue signalé par votre serviteur soit résolu (« Downloads should go to ~/Downloads »).
Le round 8 promet 7 paper cuts corrigés sur 11 (presque comme au bon vieux temps des premiers rounds). R.A.S.
Le round 9 promet 2 paper cuts corrigés sur 11 (aïe). Accordés.
-10-
Le round 10 promet un bouquet final de 11 paper cuts corrigés sur 19 (attention les yeux). dans le détail :
- Encore une arnaque : la correction d'une régression intervenue dans les premiers développement de Karmic tente de se faire passer pour un paper cut (« Ethernet icon looks wrong in Default theme ») mais ça ne passe pas. -1
-Bilans-
Au final c'est 54 paper cuts qui ont été résolus selon moi.
Faut-il parler d'échec ?
Tout d'abord je précise que j'ai essayé de jouer le jeu des paper cuts en comptabilisant même les plus minimes corrections (et il y en a des microscopiques) pourvu qu'elles respectaient l'esprit du projet.
Certaines corrections apportent un réel plus et il serait un peu facile d'écrire que le projet One Hundred Paper Cuts n'a servi à rien. Toutefois force est de constater que ce n'est pas la révolution annoncée.
Je pense que l'équipe de Canonical a tout simplement été un peu trop optimiste voire naïve avec ce projet censé résoudre tous les petits problèmes que l'utilisateur rencontre au quotidien. Or il est apparu bien souvent que les corrections requises n'étaient pas simples et demandaient un travail plus important que ce qui était permis par le cahier des charges du projet.
Ceci explique certainement le peu d'auto-congratulation auquel a donné lieu ce projet une fois terminé.
Finalement, au lieu d'un projet temporaire, les paper cuts devraient peut-être être pérénisés pour aider à trier les rapports de bogue et faciliter leur résolution, en incitant d'avantage la communauté à participer sur des bogues « abordables ».
On regrettera le côté un peu prévisible des articles publiés à l'occasion de chaque nouvelle version de la distribution phare (les miens y compris).
Cela donne de beaux articles didactiques et utiles mais qui reprennent tous plus ou moins les notes de version, en les expliquant pour les meilleurs.
Ce mode opératoire rend plus rares les articles un tant soit peu critiques ou originaux, faute d'aller plus loin que les notes de version et de poser les questions simples : qu'apporte la nouvelle version ? les promesses ont elles été tenues ?
-sur le projet One Hundred Paper Cuts-
Au final c'est 54 paper cuts qui ont été résolus selon moi.
Faut-il parler d'échec ?
Tout d'abord je précise que j'ai essayé de jouer le jeu des paper cuts en comptabilisant même les plus minimes corrections (et il y en a des microscopiques) pourvu qu'elles respectaient l'esprit du projet.
Certaines corrections apportent un réel plus et il serait un peu facile d'écrire que le projet One Hundred Paper Cuts n'a servi à rien. Toutefois force est de constater que ce n'est pas la révolution annoncée.
Je pense que l'équipe de Canonical a tout simplement été un peu trop optimiste voire naïve avec ce projet censé résoudre tous les petits problèmes que l'utilisateur rencontre au quotidien. Or il est apparu bien souvent que les corrections requises n'étaient pas simples et demandaient un travail plus important que ce qui était permis par le cahier des charges du projet.
Ceci explique certainement le peu d'auto-congratulation auquel a donné lieu ce projet une fois terminé.
Finalement, au lieu d'un projet temporaire, les paper cuts devraient peut-être être pérénisés pour aider à trier les rapports de bogue et faciliter leur résolution, en incitant d'avantage la communauté à participer sur des bogues « abordables ».
-sur le traitement de l'information par la blogosphère-
On regrettera le côté un peu prévisible des articles publiés à l'occasion de chaque nouvelle version de la distribution phare (les miens y compris).
Cela donne de beaux articles didactiques et utiles mais qui reprennent tous plus ou moins les notes de version, en les expliquant pour les meilleurs.
Ce mode opératoire rend plus rares les articles un tant soit peu critiques ou originaux, faute d'aller plus loin que les notes de version et de poser les questions simples : qu'apporte la nouvelle version ? les promesses ont elles été tenues ?
tags :
