Je pense qu'il faut voir les choses des 2 côtés de manière réaliste:
Oui, te demander de compiler GNOME directement serait idiot et irréaliste (même moi je saurais pas par où commencer pour compiler GNOME). Si quelqu'un t'a demandé cela de manière abrupte et en première réponse à un rapport de bug, alors il n'a pas été très malin.
Cependant les développeurs sont aussi des humains comme les autres, et surtout ils ne sont pas omniscients. Et des fois, sur certains bugs, on est aussi perdu que n'importe qui d'autre (au début en tous cas). Et ce d'autant plus si on n'arrive pas à reproduire le bug, ni à imaginer/comprendre sa raison. Dans ce cas, on peut espérer que si on le reproduit pas, c'est parce qu'il a été corrigé (exprès ou par chance) entre la version du rapporteur et celle du dépôt. Donc, à tout hasard, on peut se retrouver à demander au rapporteur s'il a l'opportunité de pouvoir tester sur la version du dépôt. Il y a diverses façons où cela peut être possible, et pas forcément en compilant. Par exemple certaines distributions ont des paquets de versions de développement (qui ne seront pas forcément le commit du jour, mais au moins une version plus récente). Et puis aussi le logiciel libre est plein de développeurs et quand quelqu'un rapporte un bug, on ne sait pas forcément à qui on a affaire. On peut espérer que le gars en face se trouve justement être un gars capable de compiler le logiciel, peut-être même l'a-t-il déjà fait. Ça ne coûte rien de demander.
En gros, si on t'a demandé cela, cela ne signifie pas forcément que le développeur s'attendait vraiment à ce que tu puisses le faire, mais simplement il était peut-être juste perdu lui-même et il a tenté l'improbable en te demandant, juste au cas où... Peut-être aussi ne l'a-t-il pas fait de manière très diplomate (on n'est pas tous bon diplomate, d'autant plus que beaucoup de dévs emploient aussi l'anglais en seconde langue eux-même; donc pas mal de choses peuvent se perdre dans une double traduction lang1 -> anglais -> lang2).
Ensuite y a le facteur temps: les rapports arrivent plus rapidement qu'ils ne peuvent humainement être corrigés. Donc on espère souvent que le rapporteur peut nous aider. C'est aussi ça une des puissances du logiciel libres, que tout le monde puisse apporter sa pierre. Par exemple pour la reproduction, on pourrait aussi faire l'inverse: le développeur pourrait tester l'ancienne version. Comme tu le notes toi-même, un logiciel a parfois plusieurs versions maintenues et il convient de tester au moins celles-ci. Ainsi pour GIMP, quand on me rapporte un bug sur une 2.8.x (la branche maintenue), je vais toujours d'abord tester master (version de développement), puis si je n'arrive pas à reproduire avec master, la dernière version 2.8.x (si je reproduis, cela indique alors probablement un bug corrigé depuis). Par contre pour raisons temporelles (avec git bisect, on peut tester toutes les versions mais ça prend un temps considérable, surtout pour des projets complexes et compilés, donc c'est rarement le premier choix) ou matérielles (car on n'a pas forcément les sous pour 5 ordis de développement, ou des disques de 10 To pour avoir 20 versions de chaque logiciel), on ne va pas forcément remonter plus loin dans le temps. Donc si je ne reproduis pas un bug dans la dernière version 2.8 (et n'arrive pas à deviner une raison au bug, car bien entendu il est aussi possible qu'un bug puisse exister dans certaines configurations sans pour autant que j'arrive à le reproduire dans la mienne), je conseille à la personne d'essayer de mettre à jour d'abord (seule la dernière 2.8 est maintenue, en l'occurrence la 2.8.22 à ce jour) même si je suis conscient que ce n'est pas forcément possible/aisé (si la personne dépend des paquets de sa distribution qui n'est pas à jour). Ce n'est pas de la mauvaise volonté de ma part, juste un compromis facteur temps/volume de correction, puisque le temps que je ne vais pas passer à essayer de comprendre un bug complexe, dur à reproduire, a priori mineur (surtout s'il arrive à peu de personnes puisqu'il est dur à reproduire), et peut-être même déjà corrigé (ce qui explique qu'on n'arrivait pas à le reproduire, simplement car il n'existait plus), je vais le passer à corriger 10 bugs faciles à reproduire (ce qui veut dire qu'ils arrivent à beaucoup de personnes, voire à tout le monde, donc plus grave du point de vue "volume").
Soyons clair: idéalement on aimerait que nos logiciels soient sans bugs. Sauf cas particulier de personnes vraiment de mauvaise foi et qui ne veulent pas corriger leurs bugs, si on le pouvait, on les corrigerait tous. Mais tout simplement, on est des humains nous aussi. Les développeurs ne sont pas les hackeurs de la télé qui te disent "tiens je vais hacker la NASA", et en 10 secondes, alors que sur leurs écrans on ne voit que des chiffres qui défilent et des dessins 3D qui bougent dans tous les sens, paf! C'est fait! En vrai, chaque bug mineur peut potentiellement prendre un temps fou. Tiens, j'ai posté hier (en anglais), un article sur un correctif de quelques lignes qui m'a pris 3 mois (pas à temps plein, certes! ;p) et beaucoup de prises de tête pour comprendre où se trouvait le problème, surtout que d'autres gens ne reproduisaient pas le problème!
Ensuite il existe aussi des développeurs inbuvables, parfois imbus d'eux-même et surtout désagréables. Cela arrive. De même qu'il y a aussi des cas similaires de certains rapporteurs de bugs. Il ne faut ensuite pas en faire des généralités si possible.
Il y a aussi certains dévs super sympas, mais qui manient parfois l'ironie un peu trop naturellement et cela peut être mal compris malheureusement, surtout à l'écrit. C'est à éviter mais parfois c'est juste le style de la personne. J'en connais qui sont en fait super ouverts aux bugs, vont faire de gros efforts pour tout corriger, mais parfois il arrive que sur certains rapports, ils fassent un commentaire ironique qui peut être mal compris/pris.
Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs
Sur ce point: effectivement les rapports de bug sont l'une des premières méthodes de contribution, mais ça ne veut pas dire que tous les rapports de bug sont utiles. Certains rapports de bug sont vraiment des pertes de temps, par exemple quand la personne en face est elle-même de mauvaise volonté (comme je le disais, ça peut arriver des développeurs comme des rapporteurs). Ça arrive. On peut se demander parfois pourquoi même avoir rapporté le bug si c'est pour ensuite saboter toute tentative de correction, mais je ne suis pas psy.
Parfois certaines personnes ne comprennent juste pas ce qu'on leur demande (même si c'est pas de compiler le logiciel! Un truc plus "simple" mais néanmoins technique, par exemple essayer d'avoir des traces sur un crash). On ne peut pas leur en vouloir, et on aimerait pouvoir les aider, mais au bout d'un moment, on voit bien qu'on ne peut pas. Je suis sûr qu'on en connaît tous des comme-cela. Par exemple mes parents, essayer de leur expliquer des trucs super simples (genre appuyer sur des boutons) en informatique par téléphone, c'est souvent la misère et au final, je me retrouve une ou deux semaines après à devoir montrer devant l'écran (pour qu'ils oublient une semaine plus tard encore). J'ose même pas imaginer si on leur demandait des infos de débug.
Que faire dans ce cas? Essayer indéfiniment de réexpliquer la même chose ou passer ce même temps à corriger 20 bugs majeurs rapportés par des gens qui te donnent directement les bonnes infos?
Encore une fois, ce n'est pas une critique. Comme on dit souvent ici, chacun ses domaines de compétences, et je ne veux pas insinuer que ces gens qui rapportent des bugs peu "utiles" sont "fautifs" de quelque chose. Déjà s'ils ont essayé de rapporter un bug, c'est un premier grand pas en avant et mieux que beaucoup qui ne font que se plaindre. Malheureusement ce premier pas n'est pas toujours suffisant à lui seul, et il peut arriver qu'il soit aussi même cause de beaucoup de perte de temps si la personne n'arrive pas à effectuer les pas supplémentaires. C'est triste mais c'est un fait. Je ne veux pas décourager les gens de rapporter les bugs, bien au contraire: faites ce premier pas. Au fur et à mesure, on peut espérer que même ceux qui ont eu du mal au début deviennent des rapporteurs experts par la suite. Mais il n'est pas exclus que pour en arriver là, ils aient dû faire 3 rapports de bugs inutiles d'abord.
si le projet est organisé pour les traiter.
C'est la grande problématique! Qu'est-ce qu'il faut pour traiter efficacement des bugs?!
Déjà si on pouvait automatiser la récupération de données de debug, ce serait bien. Justement parce que je me suis beaucoup posé ces questions dernièrement (m'étant rendu compte que beaucoup de bugs sont plus compliqué qu'ils ne le seraient si on avait les bonnes infos directement), j'ai récemment implémenté un système de collecte de données de debug (traces d'appels backtrace, informations de versions, etc.) automatique lors de crashs et d'erreurs critiques dans GIMP, qui encourage les gens à rapporter les bugs en quelques clics. Débuggueur GIMP
Ensuite même avec ça, on espère que les gens sauront toujours expliciter ce qu'ils faisaient quand le bug s'est produit, etc. Et comme je l'expliquais, c'est pas toujours donné.
Enfin la dernière chose, encore et toujours: le temps humain. On peut avoir tous les systèmes de débuggage qu'on veut, etc. si y a pas assez de développeurs avec du temps derrière, ben — je le disais — les rapports de bug arriveront plus vite qu'on peut les traiter.
C'est aussi pour cela que j'aimerais professionnaliser mon développement libre à travers le projet ZeMarmot (instant pub, si vous voulez aider, c'est par là! ;p).
Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).
Ben là je ne suis pas d'accord. Comme je viens de le dire, je viens justement d'implémenter une telle fenêtre pour GIMP. Et tu as raison sur le fait qu'on n'a pas forcément les "ressources" pour tout traiter. Je le disais: les rapports de bug arrivent plus vite qu'on ne peut les corriger. Mais pour moi, ce n'est pas une raison pour se masquer les yeux. Un bug est un bug. S'il s'est produit, idéalement on doit le corriger, et on espère donc qu'il sera rapporté. Peut-être ne sera-t-il pas corrigé de manière suffisamment rapide, puisque — je le disais aussi — on fait des compromis en fonction de notre temps disponible. On estime donc des priorités, etc. Et donc ce rapport peut rester dans notre système un temps certain sans obtenir de correction. C'est triste. Mais ce n'est pas une raison suffisante pour ne pas le rapporter. C'est une vision fataliste du développement.
Ma vision est plus optimiste: certes on a pas le temps, mais peut-être l'aura-t-on un jour. Y a un "espoir". Au moins s'il est dans le système, on pourra peut-être le corriger un jour. S'il a jamais été rapporté sous prétexte "qu'on n'a pas les ressources", ben... il sera juste jamais corrigé.
On espère aussi que les rapporteurs de bug comprennent cela également et ne prennent pas ombrage si on ne peut pas corriger de suite. Encore une fois, ce n'est pas forcément de la mauvaise volonté. Et il se trouve que beaucoup de rapporteurs de bugs comprennent cela très bien et sont très compréhensifs.
Le truc, c'est qu'on s'en fout des stats. On n'est pas là pour dire qu'on a peu de bugs juste parce qu'on a peu de rapports. Ça c'est une vision d'entrepreneur qui veut vendre du vent et espère donc avoir le moins de remontée de bugs possible car cela signifie payer plus de gens pour les corriger, et potentiellement une mauvaise image. Nous on s'en fout. On fait un logiciel qu'on veut le meilleur possible et on espère tous les rapports de bug possible. On ne peut pas promettre pouvoir tout corriger, mais on essaiera.
Au passage:
les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes.
En fait ce ne sont pas forcément les rapports qui prennent le plus de temps. Déjà car il existe cette catégorie de contributeur technique non-développeur qui fait pas mal de premier tri de ce type de bugs. On en a plusieurs dans GIMP. Donc ce n'est même pas toujours du temps développeur pris (ou beaucoup moins qu'un nouveau bug réel mais mal rapporté).
Enfin voilà, globalement, malgré mon long message, je suis plutôt d'accord avec pas mal de choses que tu dis. Mais je voulais tout de même rajouter des précisions en me basant sur mon expérience dans ce que tu appelles un "gros projet" (sur la supposition que tu mets GIMP dans cette catégorie, peut-être pas) parce que je ne suis pas non plus d'accord à 100%. En espérant que mon point de vue soit intéressant tout de même. :-)
Enfin voilà. Au final, je pense pas qu'il n'y ait vraiment de point de vue du développeur ni de point de vue de l'utilisateur. Il y a simplement des humains de tous les côtés, avec leurs imperfections, et tout cela (le rapport de bug et sa gestion), c'est avant tout de la relation et communication humaine, qui peut avoir ses petits accrocs parfois, ses incompréhensions, etc. Franchement au final, il faut juste beaucoup d'empathie et ne pas voir le mal là où il n'est pas forcément. C'est pas facile, je le sais bien, parfois moi aussi je fais l'erreur! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Si j'ai bien compris...
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LibreOffice, altération d'images intégrées :( ?. Évalué à 10.
Je pense qu'il faut voir les choses des 2 côtés de manière réaliste:
Oui, te demander de compiler GNOME directement serait idiot et irréaliste (même moi je saurais pas par où commencer pour compiler GNOME). Si quelqu'un t'a demandé cela de manière abrupte et en première réponse à un rapport de bug, alors il n'a pas été très malin.
Cependant les développeurs sont aussi des humains comme les autres, et surtout ils ne sont pas omniscients. Et des fois, sur certains bugs, on est aussi perdu que n'importe qui d'autre (au début en tous cas). Et ce d'autant plus si on n'arrive pas à reproduire le bug, ni à imaginer/comprendre sa raison. Dans ce cas, on peut espérer que si on le reproduit pas, c'est parce qu'il a été corrigé (exprès ou par chance) entre la version du rapporteur et celle du dépôt. Donc, à tout hasard, on peut se retrouver à demander au rapporteur s'il a l'opportunité de pouvoir tester sur la version du dépôt. Il y a diverses façons où cela peut être possible, et pas forcément en compilant. Par exemple certaines distributions ont des paquets de versions de développement (qui ne seront pas forcément le commit du jour, mais au moins une version plus récente). Et puis aussi le logiciel libre est plein de développeurs et quand quelqu'un rapporte un bug, on ne sait pas forcément à qui on a affaire. On peut espérer que le gars en face se trouve justement être un gars capable de compiler le logiciel, peut-être même l'a-t-il déjà fait. Ça ne coûte rien de demander.
En gros, si on t'a demandé cela, cela ne signifie pas forcément que le développeur s'attendait vraiment à ce que tu puisses le faire, mais simplement il était peut-être juste perdu lui-même et il a tenté l'improbable en te demandant, juste au cas où... Peut-être aussi ne l'a-t-il pas fait de manière très diplomate (on n'est pas tous bon diplomate, d'autant plus que beaucoup de dévs emploient aussi l'anglais en seconde langue eux-même; donc pas mal de choses peuvent se perdre dans une double traduction lang1 -> anglais -> lang2).
Ensuite y a le facteur temps: les rapports arrivent plus rapidement qu'ils ne peuvent humainement être corrigés. Donc on espère souvent que le rapporteur peut nous aider. C'est aussi ça une des puissances du logiciel libres, que tout le monde puisse apporter sa pierre. Par exemple pour la reproduction, on pourrait aussi faire l'inverse: le développeur pourrait tester l'ancienne version. Comme tu le notes toi-même, un logiciel a parfois plusieurs versions maintenues et il convient de tester au moins celles-ci. Ainsi pour GIMP, quand on me rapporte un bug sur une 2.8.x (la branche maintenue), je vais toujours d'abord tester master (version de développement), puis si je n'arrive pas à reproduire avec master, la dernière version 2.8.x (si je reproduis, cela indique alors probablement un bug corrigé depuis). Par contre pour raisons temporelles (avec
git bisect, on peut tester toutes les versions mais ça prend un temps considérable, surtout pour des projets complexes et compilés, donc c'est rarement le premier choix) ou matérielles (car on n'a pas forcément les sous pour 5 ordis de développement, ou des disques de 10 To pour avoir 20 versions de chaque logiciel), on ne va pas forcément remonter plus loin dans le temps. Donc si je ne reproduis pas un bug dans la dernière version 2.8 (et n'arrive pas à deviner une raison au bug, car bien entendu il est aussi possible qu'un bug puisse exister dans certaines configurations sans pour autant que j'arrive à le reproduire dans la mienne), je conseille à la personne d'essayer de mettre à jour d'abord (seule la dernière 2.8 est maintenue, en l'occurrence la 2.8.22 à ce jour) même si je suis conscient que ce n'est pas forcément possible/aisé (si la personne dépend des paquets de sa distribution qui n'est pas à jour). Ce n'est pas de la mauvaise volonté de ma part, juste un compromis facteur temps/volume de correction, puisque le temps que je ne vais pas passer à essayer de comprendre un bug complexe, dur à reproduire, a priori mineur (surtout s'il arrive à peu de personnes puisqu'il est dur à reproduire), et peut-être même déjà corrigé (ce qui explique qu'on n'arrivait pas à le reproduire, simplement car il n'existait plus), je vais le passer à corriger 10 bugs faciles à reproduire (ce qui veut dire qu'ils arrivent à beaucoup de personnes, voire à tout le monde, donc plus grave du point de vue "volume").Soyons clair: idéalement on aimerait que nos logiciels soient sans bugs. Sauf cas particulier de personnes vraiment de mauvaise foi et qui ne veulent pas corriger leurs bugs, si on le pouvait, on les corrigerait tous. Mais tout simplement, on est des humains nous aussi. Les développeurs ne sont pas les hackeurs de la télé qui te disent "tiens je vais hacker la NASA", et en 10 secondes, alors que sur leurs écrans on ne voit que des chiffres qui défilent et des dessins 3D qui bougent dans tous les sens, paf! C'est fait! En vrai, chaque bug mineur peut potentiellement prendre un temps fou. Tiens, j'ai posté hier (en anglais), un article sur un correctif de quelques lignes qui m'a pris 3 mois (pas à temps plein, certes! ;p) et beaucoup de prises de tête pour comprendre où se trouvait le problème, surtout que d'autres gens ne reproduisaient pas le problème!
Ensuite il existe aussi des développeurs inbuvables, parfois imbus d'eux-même et surtout désagréables. Cela arrive. De même qu'il y a aussi des cas similaires de certains rapporteurs de bugs. Il ne faut ensuite pas en faire des généralités si possible.
Il y a aussi certains dévs super sympas, mais qui manient parfois l'ironie un peu trop naturellement et cela peut être mal compris malheureusement, surtout à l'écrit. C'est à éviter mais parfois c'est juste le style de la personne. J'en connais qui sont en fait super ouverts aux bugs, vont faire de gros efforts pour tout corriger, mais parfois il arrive que sur certains rapports, ils fassent un commentaire ironique qui peut être mal compris/pris.
Sur ce point: effectivement les rapports de bug sont l'une des premières méthodes de contribution, mais ça ne veut pas dire que tous les rapports de bug sont utiles. Certains rapports de bug sont vraiment des pertes de temps, par exemple quand la personne en face est elle-même de mauvaise volonté (comme je le disais, ça peut arriver des développeurs comme des rapporteurs). Ça arrive. On peut se demander parfois pourquoi même avoir rapporté le bug si c'est pour ensuite saboter toute tentative de correction, mais je ne suis pas psy.
Parfois certaines personnes ne comprennent juste pas ce qu'on leur demande (même si c'est pas de compiler le logiciel! Un truc plus "simple" mais néanmoins technique, par exemple essayer d'avoir des traces sur un crash). On ne peut pas leur en vouloir, et on aimerait pouvoir les aider, mais au bout d'un moment, on voit bien qu'on ne peut pas. Je suis sûr qu'on en connaît tous des comme-cela. Par exemple mes parents, essayer de leur expliquer des trucs super simples (genre appuyer sur des boutons) en informatique par téléphone, c'est souvent la misère et au final, je me retrouve une ou deux semaines après à devoir montrer devant l'écran (pour qu'ils oublient une semaine plus tard encore). J'ose même pas imaginer si on leur demandait des infos de débug.
Que faire dans ce cas? Essayer indéfiniment de réexpliquer la même chose ou passer ce même temps à corriger 20 bugs majeurs rapportés par des gens qui te donnent directement les bonnes infos?
Encore une fois, ce n'est pas une critique. Comme on dit souvent ici, chacun ses domaines de compétences, et je ne veux pas insinuer que ces gens qui rapportent des bugs peu "utiles" sont "fautifs" de quelque chose. Déjà s'ils ont essayé de rapporter un bug, c'est un premier grand pas en avant et mieux que beaucoup qui ne font que se plaindre. Malheureusement ce premier pas n'est pas toujours suffisant à lui seul, et il peut arriver qu'il soit aussi même cause de beaucoup de perte de temps si la personne n'arrive pas à effectuer les pas supplémentaires. C'est triste mais c'est un fait. Je ne veux pas décourager les gens de rapporter les bugs, bien au contraire: faites ce premier pas. Au fur et à mesure, on peut espérer que même ceux qui ont eu du mal au début deviennent des rapporteurs experts par la suite. Mais il n'est pas exclus que pour en arriver là, ils aient dû faire 3 rapports de bugs inutiles d'abord.
C'est la grande problématique! Qu'est-ce qu'il faut pour traiter efficacement des bugs?!
Déjà si on pouvait automatiser la récupération de données de debug, ce serait bien. Justement parce que je me suis beaucoup posé ces questions dernièrement (m'étant rendu compte que beaucoup de bugs sont plus compliqué qu'ils ne le seraient si on avait les bonnes infos directement), j'ai récemment implémenté un système de collecte de données de debug (traces d'appels backtrace, informations de versions, etc.) automatique lors de crashs et d'erreurs critiques dans GIMP, qui encourage les gens à rapporter les bugs en quelques clics.
Débuggueur GIMP
Ensuite même avec ça, on espère que les gens sauront toujours expliciter ce qu'ils faisaient quand le bug s'est produit, etc. Et comme je l'expliquais, c'est pas toujours donné.
Enfin la dernière chose, encore et toujours: le temps humain. On peut avoir tous les systèmes de débuggage qu'on veut, etc. si y a pas assez de développeurs avec du temps derrière, ben — je le disais — les rapports de bug arriveront plus vite qu'on peut les traiter.
C'est aussi pour cela que j'aimerais professionnaliser mon développement libre à travers le projet ZeMarmot (instant pub, si vous voulez aider, c'est par là! ;p).
Ben là je ne suis pas d'accord. Comme je viens de le dire, je viens justement d'implémenter une telle fenêtre pour GIMP. Et tu as raison sur le fait qu'on n'a pas forcément les "ressources" pour tout traiter. Je le disais: les rapports de bug arrivent plus vite qu'on ne peut les corriger. Mais pour moi, ce n'est pas une raison pour se masquer les yeux. Un bug est un bug. S'il s'est produit, idéalement on doit le corriger, et on espère donc qu'il sera rapporté. Peut-être ne sera-t-il pas corrigé de manière suffisamment rapide, puisque — je le disais aussi — on fait des compromis en fonction de notre temps disponible. On estime donc des priorités, etc. Et donc ce rapport peut rester dans notre système un temps certain sans obtenir de correction. C'est triste. Mais ce n'est pas une raison suffisante pour ne pas le rapporter. C'est une vision fataliste du développement.
Ma vision est plus optimiste: certes on a pas le temps, mais peut-être l'aura-t-on un jour. Y a un "espoir". Au moins s'il est dans le système, on pourra peut-être le corriger un jour. S'il a jamais été rapporté sous prétexte "qu'on n'a pas les ressources", ben... il sera juste jamais corrigé.
On espère aussi que les rapporteurs de bug comprennent cela également et ne prennent pas ombrage si on ne peut pas corriger de suite. Encore une fois, ce n'est pas forcément de la mauvaise volonté. Et il se trouve que beaucoup de rapporteurs de bugs comprennent cela très bien et sont très compréhensifs.
Le truc, c'est qu'on s'en fout des stats. On n'est pas là pour dire qu'on a peu de bugs juste parce qu'on a peu de rapports. Ça c'est une vision d'entrepreneur qui veut vendre du vent et espère donc avoir le moins de remontée de bugs possible car cela signifie payer plus de gens pour les corriger, et potentiellement une mauvaise image. Nous on s'en fout. On fait un logiciel qu'on veut le meilleur possible et on espère tous les rapports de bug possible. On ne peut pas promettre pouvoir tout corriger, mais on essaiera.
Au passage:
En fait ce ne sont pas forcément les rapports qui prennent le plus de temps. Déjà car il existe cette catégorie de contributeur technique non-développeur qui fait pas mal de premier tri de ce type de bugs. On en a plusieurs dans GIMP. Donc ce n'est même pas toujours du temps développeur pris (ou beaucoup moins qu'un nouveau bug réel mais mal rapporté).
Enfin voilà, globalement, malgré mon long message, je suis plutôt d'accord avec pas mal de choses que tu dis. Mais je voulais tout de même rajouter des précisions en me basant sur mon expérience dans ce que tu appelles un "gros projet" (sur la supposition que tu mets GIMP dans cette catégorie, peut-être pas) parce que je ne suis pas non plus d'accord à 100%. En espérant que mon point de vue soit intéressant tout de même. :-)
Enfin voilà. Au final, je pense pas qu'il n'y ait vraiment de point de vue du développeur ni de point de vue de l'utilisateur. Il y a simplement des humains de tous les côtés, avec leurs imperfections, et tout cela (le rapport de bug et sa gestion), c'est avant tout de la relation et communication humaine, qui peut avoir ses petits accrocs parfois, ses incompréhensions, etc. Franchement au final, il faut juste beaucoup d'empathie et ne pas voir le mal là où il n'est pas forcément. C'est pas facile, je le sais bien, parfois moi aussi je fais l'erreur! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]