----- Mail original -----
De: "Sophie" <gautier.sop...@gmail.com>
À: qa@fr.libreoffice.org
Envoyé: Vendredi 18 Août 2017 12:37:30
Objet: Re: [fr-qa] LibO 5.3.5.2 pb localisation ?

Bonjour Pierre,
Le 18/08/2017 à 12:05, Pierre Choffardet a écrit :
> 
> 
> ----- Mail original -----
> De: "Sophie" <gautier.sop...@gmail.com>
> À: qa@fr.libreoffice.org
> Envoyé: Vendredi 18 Août 2017 11:16:43
> Objet: Re: [fr-qa] LibO 5.3.5.2 pb localisation ?
> 
> Bonjour à tous,
> 
> Le 18/08/2017 à 10:46, Ysabeau a écrit :
>> Le 18/08/2017 à 10:28, Luc Novales a écrit :
>>> Bonjour,
>>>
>>>
>>> Le 17/08/2017 à 23:06, Jean-Baptiste Faure a écrit :
>>>> Il faut plus de gens qui compilent et testent en continu sous Windows
>>>> et mac Os, même en juillet-août. Et prennent la peine d'alerter en
>>>> urgence sur irc et les ML dev et QA quand un tel pépin arrive.
>>>
> Elle a au moins servi à ce que la 5.3.6 soit dispo rapidement. 
> 
> Et qu'une version pourrie soit en circulation
> 
> Le débat sera sans fin tant qu'il y aura si peu d'utilisateurs concernés par 
> les
> contributions au projet, je parle de personnes morales type ENAC, MIMO,
> etc. En France, à part Nantes et l'agglo de Nantes, en termes de
> contribution notoire (amélioration de fonctionnalités, participation aux
> réunions UX, diffusion des enquêtes utilisateurs, conférence…), je
> vois pas grand monde, je me trompe ?
> 
> Et si la qualité de la suite décroit, si on donne des arguments aux 
> détracteurs de la suite… On va dans le m…

Mais quelles sont tes mesures, quel delta entre
l'apport/corrections/régressions as-tu pour évaluer le décroit de la suite ?

- 800 régressions remontées, confirmées, en constante augmentation (x6 en  5 
ans)
- 6 000 bugs ouverts (x15 en 5 ans)

Mon utilisation personnelle de la suite (deux petites exemples) :
- Impossible d'utiliser l'EDI des macros sur mon portable, alors que ça 
fonctionne bien avec AOO
- Impossible d'utiliser les transitions de diapos sans perdre des animations 
lors d'un retour en arrière pendant le diaporama

Cela ne retire rien au travail de fond fait, mais la qualité de la suite se 
dégrade dans son utilisation au quotidien


> 
> 
>>
>> Mais comme toi, Pierre et d'autres je suis d'accord. Et je vois les
>> effets néfastes sur l'image de "qualité" de la suite. Par ailleurs le
>> nombre de bugs corrigés, quand on voit l'info très vite ça donne surtout
>> à penser que c'était bien pourri, bref en termes de communication je ne
>> suis pas sure que ça soit le meilleur critère.
> 
> Ben en effet LibreOffice est toujours aussi pourri, mais heureusement,
> il y a des utilisateurs que cela concerne et qui chaque jour œuvre à le
> rendre meilleur. Et cela offre entre autre à des personnes de s'exprimer
> et travailler dans leur langue pour un coût très réduit par rapport à
> une offre inexistante ou inabordable.
> Mais il vaut mieux continuer à pointer les dysfonctionnements sans
> s'intéresser à ce qui est mis en place pour leur amélioration (et
> accessoirement y contribuer) et geindre sur cette pauvre bande
> d'incapables qui nuit au produit en ne sachant pas gérer son
> développement parce que je ne doute pas que ce dernier soit le cœur de
> votre métier.
> 
> 
> C'était le ton de mon intervention ? Désolé, ce n'est pas ce que j'ai voulu 
> dire. Mais peut-être est il possible d’envisager qu'une stratégie choisie 
> n'est pas la bonne, ou pas la meilleure, ou qu'elle doive évoluer. Cela sans 
> remettre en cause les compétences des uns et des autres, 
> leurs investissements personnel, gratuit… est-ce pour autant un parapluie à 
> la critique ?

Non, et effectivement, il y a des réunions avec les ingénieurs toutes
les semaines et avec les (grands) utilisateurs tous les 3 mois pour cela.
> 
> Ici, je pointe seulement le fait qu'il faut plus de temps entre la 
> publication d'une version et son annonce. En particulier en aout, lorsque les 
> volontaires sont peu nombreux. C'est compliqué ? il est ou le problème ?

Le problème de ne pas respecter un calendrier est d'impacter l'ensemble
des distributeurs de LibreOffice et donc de mettre en danger son
écosystème. Mais je suis d'accord avec toi sur le délai de test.
> 
> Je suis peut-être un gars un peu spécial, mais dans mon quotidien quand un 
> problème me pète à la figure, je passe du temps à essayer qu'il ne se 
> reproduise pas. Et ce sans prendre en compte le fait que les gars 
> responsables du problème soient bons ou pas, qu'ils s'investissent beaucoup 
> ou pas. Juste éviter que le problème ne se reproduise. Là, j'ai l'impression 
> que ça passe aux pertes et profits…

Je serais intéressée de savoir/comprendre pourquoi tu as cette
impression. Lorsque le problème de localisation a été rapporté, j'ai
immédiatement alerté Christian sur notre canal irc staff TDF. Ce qui lui
a permis de trouver la cause du problème (sans actuellement avoir eu le
temps de comprendre effectivement) et de prendre la décision de fournir
une version supplémentaire. Il n'empêche que Christian va chercher la
cause de ce tag sur une mauvaise branche (il en va aussi de
l'extensibilité de son temps de travail) afin que cela ne se reproduise
pas.


Parce que l'on ne parle pas de la même chose. Toi, tu parles de la correction 
de ce bug, de sa gestion, sa correction, de la façon d'éviter que CE bug 
réapparaisse. Moi je parle d'un bug, qui arrive, un bug qui pourrie la suite. 
Il en arrivera toujours, l'erreur est humaine, et plus on travaille sur la 
suite, plus il y en aura. Il me semble donc très difficile des les éliminer à 
la source.

Trois jours pour valider une suite, et la qualifier, c'est juste trop court. On 
peut imaginer que ce soit bon dans les premières versions, mais quand on dit 
que la version est bonne pour le déploiement en entreprise, alors, il faut se 
donner plus de temps (surtout au mois d'aout).
Je rappelle que c'est arrivé aussi sur la branche 5.2. Il faudrait un process 
de qualification plus conséquent lorsqu'on dit que la suite est mature pour un 
déploiement en entreprise.

Ensuite, je dis qu'il faut aussi réagir et fermer le robinet, lorsque c'est du 
poison qui en sort, dès qu'un bug qui aurait été un bloqueur est remonté, il 
faut couper la source des téléchargements, ou à minima, annoncer le problème 
sur la page de téléchargement. pOur éviter que le poison ne se répande.

Aujourd’hui, et pour quelques jours encore, peut-être même une semaine, on peut 
toujours télécharger cette version, que des gars garderont pendant des mois, et 
un jour, ils essayeront de programmer une macro, et ça ne marchera pas, alors 
ils iront ailleurs en pestant sur la suite.

> 
> 
> Ensuite, je critique le critère qualité de la suite : Le nombre de bugs 
> corrigés. (par ce que c'est un peu cocasse tout de même de sortir une version 
> annoncée comme mature pour un déploiement en entreprise pourrie et 
> s'enorgueillir de l’énorme travail de qualité produit). Jamais TDF ou les 
> devs, ne communiquent sur le nombre de régressions ou de bugs ouverts. 
> Pourquoi ? Cela donne l'impression qu'ils s’en foutent.

Je communique tous les trois mois un extrait de la présentation que je
fais pour la réunion de l'Advisory Board sur la liste des membres TDF,
ces diapos contiennent les statistiques de régressions, évolution, etc.
D'autre part, nous mettons à disposition un dashboard qui permet
d'interroger les statistiques en filtrant pas mal des choses :
https://dashboard.documentfoundation.org/
Nous avons mis à disposition (plutôt pour les développeurs, c'est vrai)
une vue de tous les outils:
http://devcentral.libreoffice.org/
Xisco publie un rapport tous les lundis sur la liste QA:
http://nabble.documentfoundation.org/Libreoffice-qa-Weekly-QA-Report-W32-2017-td4220519.html
itou sur les minutes de l'ESC (celles de hier ne sont pas encore dispo)
http://nabble.documentfoundation.org/Libreoffice-qa-Minutes-of-ESC-call-2017-08-10-td4220294.html
voir crash reporting, crash reporter et tout en bas QA stats
> 
> Je ne vois pas pourquoi on ne devrait pas pointer les dysfonctionnements au 
> prétexte qu'il y a par ailleurs du bon travaille de fait.

Pointer les dysfonctionnements n'est pas le problème, ç'est l'assertion
que rien n'est fait pour y remédier qui est plus dérangeante dans la
mesure où elle met en cause le travail et le fonctionnement de
l'ensemble du projet.
> 
> Quelque part, est-ce qu'il n'est pas vraiment dommage que ce travail soit 
> masqué par une précipitation dans la publication d'une version ? d’où vient 
> le problème, du messager ou du contenu du message ? J'ai l’impression que 
> l'on veut faire taire le messager, en le culpabilisant.

Je pense qu'il manque au messager une partie de l'information et que son
réflexe n'est pas de chercher l'information, mais de juger et de
condamner une démarche alors qu'il n'en voit qu'une partie.

À bientôt
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
GSM: +33683901545
IRC: sophi
Release coordinator
The Document Foundation

-- 
Envoyez un mail à qa+unsubscr...@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à 
http://listarchives.libreoffice.org/fr/qa/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne 
pourront pas être supprimés

-- 
Envoyez un mail à qa+unsubscr...@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à 
http://listarchives.libreoffice.org/fr/qa/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne 
pourront pas être supprimés

Répondre à