Jehan a écrit 1673 commentaires

Les étoiles sont une moyenne des notes données par les divers contributeurs ou c'est juste la dernière note donnée par un éditeur?
Je viens d'éditer la notice de GIMP (qui ne s'est pas appelé "The Gimp" depuis longtemps, en fait je l'ai personnellement uniquement connu sous l'acronyme "GIMP" et je viens de vérifier: ça ne s'appelle plus "The Gimp" depuis la 2.4, presque 10 ans!), et j'ai voulu "voter". Bien sûr, biaisé :P, je mets 5 étoiles (c'était à 4). Or je constate maintenant que la notice montre 5 étoiles pour tous. Ai-je juste pesé dans la balance ou bien mon "vote" n'en était pas un et a juste remplacé la note précédente?
Si c'est le cas, ce n'est pas une très bonne fonctionnalité car elle reflète juste l'avis du dernier éditeur. :-/

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Sur le plan de l'architecture, je vois rien dans le C4 en contradiction avec le fait qu'il prend presque tout.

Il faudrait être un peu plus clair: il prend tout et n'importe quoi, même des patchs qui cassent l'architecture actuelle? Ou bien des patchs qui revoient (et donc améliorent) l'architecture?

C'est pas du tout la même chose. En effet, je suis totalement d'accord qu'il faut pas être à cheval sur une architecture, même si c'est soi-même qui l'a conçue, on peut toujours faire mieux (ou évoluer progressivement). Un gars qui propose un changement profond qui remanie entièrement certaines parties architecturales du programme (ces changements doivent avoir du sens bien sûr!) est tout à fait viable et peut même être très bon. À partir de l'inclusion, cela devient donc simplement la nouvelle architecture (donc rien n'est cassé).
Ce genre de contributions arrivent d'ailleurs régulièrement et sont les bienvenues. Ce qui importe, c'est d'avoir un code propre qui respecte les dernières règles fixées.

Par contre, si tu parles vraiment d'accepter des patchs qui cassent les choix architecturaux sans les revoir (donc on se retrouve avec du code hybride où les règles établies ne sont pas suivies), alors je suis absolument pas d'accord.

Note que je n'ai aucune idée si Pieter Hintjens pense ainsi ou pas, et cela ne m'intéresse absolument pas de savoir. Il n'est pas nécessaire de continuer sur la discussion de savoir si on lui rends justice ou pas (pas pour moi en tous cas). Je parle de l'idée générale d'accepter n'importe quel patch qui casse l'architecture, que ce soit ce que cette personne promouvait ou pas.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Hmm… Je ne vois pas du tout par quelle logique tu es passé de mon commentaire au tien.

Si à partir d'une certain taille critique, cela devient trop risqué de le bouger

J'imagine que sur ce point, tu fais référence à ce que j'ai dit y a plusieurs commentaires sur la revue stricte. Mais ce n'était pas le sens. "Revue stricte" ne signifie pas "on ne bouge pas". Non un projet avec revue stricte, quand il bouge, il met un point d'honneur à le faire bien. Bien souvent, "faire bien" veut cependant dire "prendre son temps", pas accepter des patchs à la va-vite parce qu'ils "marchent" et tant pis pour l'archi, les règles de code et pour la réflexion sur une meilleure UI et sur l'expérience utilisateur en général !

Est-ce que ça ne veut pas dire que tout gros projet est destiné à être forké ?

"Destiné", je ne sais pas mais l'histoire montre que c'est courant, oui. GIMP a eu au moins 2 forks qui ont fait parlé d'eux. Ensuite les forks sont-ils souhaitables? Parfois oui bien sûr mais si la raison est essentiellement "ils sont chiants à prendre du temps et à vouloir vérifier mon code", je trouve cela dommage. Des 2 forks de GIMP, l'un (GIMP Painter) a des fonctionnalités qu'on voudrait vraiment avoir, on a manifesté notre intérêt, discuté avec le dèv… le problème ? Alors que la 2.8 était sortie, il développait sur des tarballs de la 2.6. De nos jours, il développe sur la branche 2.8 alors que le core a énormément évolué avec l'intégration de GEGL pour la 2.10. En gros il ne semble pas intéressé par notre processus de développement et fait tout à sa sauce. Personnellement je trouve que c'est très dommage et une raison de forker un peu triste. On veut de ses innovations, mais bien entendu elles ne valent pas un reset de tout notre code depuis 2.8! En fait, je lui ai redemandé récemment s'il ne veut pas travailler sur notre branche master et j'ai l'impression qu'il se fait beaucoup d'idées et qu'il s'imagine nos pensées. Quand il dit par exemple qu'il pense que la core team et lui ont des visions du design d'UI différente… je me demande vraiment d'où il peut tirer cela. Déjà même si on parle souvent de "core team" pour simplifier, il n'y a pas une pensée similaire en notre sein. On est surtout un groupe d'individuels. Parfois on a des idées similaires, parfois non, puis on discute, on argumente, parfois on change d'avis…
En plus je crois pas du tout qu'on bloquerait l'idée d'une toolbar horizontale (au contraire, j'y pense même très régulièrement et j'ai pas eu besoin de connaître GIMP-painter pour y penser), ce qu'il semble dire, etc. Quand il dit qu'avec le "succès" de GIMP painter, ça permettra aux dévs de GIMP de se rendre compte des vrais besoins des utilisateurs et aussi ça nous montrera comment implémenter ces fonctionnalités, je pense que ce développeur se fait beaucoup d'illusions sur son travail. Je pense qu'il est un dév très compétent et avec de bonnes idées, mais comme tant d'autres le sont. Il serait un très bon ajout à notre équipe pour faire évoluer GIMP plus vite et mieux (surtout s'il bénéficie de revue de code! Mais il semble ne pas vouloir subir cela); mais seul de son côté, non il n'est pas notre "modèle" à suivre. Et non on n'a pas le temps de regarder son code, surtout si celui-ci se base sur une branche totalement obsolète (vieille de très nombreuses années)!

Dans ce cas, pourquoi donc appeler au fork ici par exemple? C'est pour moi un exemple typique de gâchis de ressources de qualité. :-/

Ensuite, oui y a eu des cas où le fork a été très bénéficiaire (libreoffice vient à l'esprit immédiatement). Mais le fork est un outil qui a un poids et un prix conséquents. Il faut bien peser le pour et le contre avant de s'y lancer.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

C'est vrai. C'est aussi une possibilité que beaucoup de projets bordéliques aient pu disparaître justement pour cette raison.

Ceci dit, il est toujours possible de réorganiser un projet, surtout quand il est encore petit. Et la qualité du code d'un même développeur va en augmentant avec le temps (d'habitude). On a tous été débutant, et donc on a fait des erreurs en tant que tel, qu'on ne fait plus 10 ans plus tard (on en fait d'autres! :P). Donc y a beaucoup de projets qui peuvent commencer bordéliques et avec une archi mal barrée qui peuvent encore être sauvés avant de devenir in-maintenable. J'imagine qu'un meilleur critère pour la survie est donc de savoir rattraper les erreurs de jeunesse à temps.
Ensuite, qui peut dire? S'il y avait une recette pour faire des gros projets à succès et que tu la trouves, tu es riche! ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je pense que tu as répondu sur le mauvais message, mais c'est pas grave. ;-)

Je me suis un peu renseigné sur la position du dev ZeroMQ sur ce sujet je pense qu'elle est beaucoup plus fine que le "laisser faire" dont tu parles—le journal ne lui rend pas vraiment justice sur ce point.

Ok. Pour ma part, je n'ai pas cherché plus loin et me suis juste basé sur les dires du journal. Ça m'amusait que juste quelques heures après mon message, il y ait justement un journal qui parle du même sujet.

L'idée globalement est que chaque projet devrait décider un ensemble de critères pour les patch proposés, qui puissent être jugés objectivement (par une personne qui connaît bien le code), et ensuite que le travail du mainteneur devrait se limiter à vérifier que les critères ont été appliqués, et si oui inclure le patch.
[…]

The user or Contributor should write the issue by describing the problem they face or observe.
The user or Contributor should seek consensus on the accuracy of their observation, and the value of solving the problem.

Bon bah au final, c'est donc plus une revue stricte de contribution (ça m'a même l'air complètement le contraire de ce que dit le journal, donc tu as bien raison en disant que ça ne rende pas justice!) et ça se rapproche du type de revue que fait un logiciel comme GIMP (ou beaucoup d'autres).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Tu dis "les deux se défendent" comme s'il y avait deux positions discrètes, le tout-va et le toujours-nickel. En pratique il y a un continuum et on peut être "plus souple" ou "plus strict" sans passer d'un extrême à l'autre.

Bien sûr. Mais comme c'est une histoire de philosophie de maintenance, on rencontre souvent les extrêmes.
C'est marrant (et j'imagine, le hasard) car justement le journal qui te suit parle de cela, mais de l'autre point de vue.

Pieter Hintjens est un développeur récemment décédé et ce serait sa pensée qu'il explique dans des articles:

En partant de ces postulats, il considère qu'une architecture parfaite est secondaire. D'autant plus qu'elle repose déjà sur un grand bazar (pas une de vos dépendances n'est codée pareil). Par conséquent, lorsqu'on réalise un projet communautaire, toute contribution est bonne à prendre. Il nous invite à donc à être laxiste sur les conditions d'acceptation d'un patch. Ainsi, on permet une plus grande participation. Une intelligence collective se met en œuvre. Le groupe peut proposer des solutions plus pertinentes et adaptées. L'ensemble des intervenants est plus motivé. Ce qui attire plus de monde et diversifie la communauté. Elle passe ainsi dans un état propice à la résolution pertinente de problèmes.

C'est vraiment à l'inverse de ce qu'on fait dans un logiciel qui va contrôler plus sérieusement les patchs. Même s'il y a aussi un entre-deux possible, ici on voit plus des philosophies opposées. C'est pour ça que je fais ce genre de séparation (même si tu as raison). Ensuite je comprends bien ce point de vue laxiste aussi et je pense qu'il marche mieux pour les plus petits projets (petit notamment en nombre de lignes/fichiers). Pourquoi? Parce qu'un peu de bordel est acceptable dans ce cas. Ça reste lisible. Pour lancer un projet, c'est sûrement idéal même d'être très laxiste sur la revue de patch. Je n'étais pas là à l'époque, mais je suis sûr que ça a dû être le cas au début de GIMP aussi.
De nos jours, GIMP est un projet gigantesque en terme de fichiers, lignes de code, et fonctionnalité. Et pourtant il est globalement extrêmement bien organisé. L'architecture sépare bien les diverses parties du code (le "core" fonctionnel, les actions, la peinture, la gestion de fichier, les opérations graphiques, le GUI… et bien plus de sous-séparations encore). Le style de code est plutôt bien respecté partout (rendant le code très lisible). Etc.
Si on se mettait à accepter un patch qui casse nos diverses règles juste parce qu'il "marche", je pense que ce serait le début de la fin et qu'au bout d'un an, le code ne serait plus aussi maintenable.
C'est pas parfait mais c'est une base de code étonnamment bonne pour un projet de 21 ans. En fait je me rends compte que pas mal de gros projets sur lesquels j'ai contribué ont des bases globalement saines, alors que beaucoup de petits projets sont des bordels sans nom. Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.

Tu ne parles que des "bons cas" dans les deux scénarios. […] ne dit rien, et le patch stagne. Dans les conflits dont on entend parler où un mainteneur bloque un projet, c'est souvent ce genre de problèmes à la base, où les gens s'accrochent à une notion de qualité qui a l'effet de geler le projet. C'est très facile de tomber dans ce travers là, ça m'est arrivé à moi aussi, et je pense que que c'est important d'en être conscient.

C'est vrai, ça arrive très souvent, surtout quand y a peu de développeurs. Et là aussi GIMP est un parfait exemple car nous sommes trop peu. Je ne crois pas qu'il y ait de vraie solution, et en particulier, je doute que transiger sur la qualité soit vraiment la solution. Comme je le disais, ce serait le meilleur moyen de bousiller le projet en rendant son code non-maintenable à moyen terme. On en accepte 1, puis 2, puis 10, puis 100. Et voilà, la base de code est flinguée.

Le second problème est les problématiques de design d'UI. Beaucoup de patchs bloquent sur les choix UI car les utilisateurs et contributeurs ont tous ce "petit quelque chose qui va rendre GIMP 1000 fois mieux!", disent-ils. Bien sûr, ils ne voient que leur utilisation, et parfois même pas forcément une utilisation habituelle. Genre ils basent leur patch sur leur expérience d'un projet où ils ont dû faire une tâche assez répétitive et ils se sont alors dit que si y avait tel bouton là pour faire ça, ça aurait vachement simplifié leur tâche donc ils font un patch et le défendent corps et âme. Mais je suis même pas sûr qu'une fois ce projet terminé, ils aient jamais besoin d'utiliser ce bouton encore. Et quand bien même, y a des millions d'autres utilisateurs de GIMP.
Le truc, c'est que si on devait accepter tous les patchs pour ajouter des boutons, à ce jour y aurait 1000 boutons dans chaque dock. En fait je trouve qu'y en a déjà trop. Je parle même pas de l'ordre des boutons ou fonctions. C'est simple, on a dû avoir des demandes pour toutes les combinaisons possibles. Si on acceptait chaque fois un patch pour changer l'ordre, GIMP serait totalement schizophrène et changerait l'ordre de ses boutons constamment.

Ce qu'il nous fait, c'est une GUI plus personnalisable, mais forcément ce patch n'est pas aussi simple si on veut le faire bien (c'est d'ailleurs dans mes cartons). ;-)

Tout ça pour dire que même si ce que tu dis est vrai, je ne suis pas sûr que ce soit une mauvaise chose de "s'accrocher à une notion de qualité" et s'y tenir. Mais encore une fois, un projet comme GIMP (ou gcc, et probablement même LLVM, ainsi que tout gros projet avec beaucoup de code et une base d'utilisateur énorme) doit être géré différemment. On ne doit pas s'empêcher d'expérimenter (et on le fait vraiment beaucoup; si t'as l'occasion d'essayer la version de dév, essaie!), mais on ne peut pas non plus faire tout et n'importe quoi.
Encore une fois, je pense donc que ce que tu dis s'appliquera bien mieux à un petit projet qui a tout intérêt à avoir des contributeurs et qui peut se permettre de changer plein de petits trucs très régulièrement.

À ma surprise à l'époque, les contributeurs m'ont demandé d'arrêter: ils n'aiment pas qu'on modifie leurs patchs "derrière eux" parce qu'ils ont vraiment envie d'apprendre comment faire le patch parfait et ils préfèrent donc que je leur explique les changements à faire. Maintenant je ne le fais que très très rarement.

Ah ça m'est jamais arrivé. Mais bon dans mon cas, je ne le fais que soit parce que le contributeur ne répond pas (mais que son patch est suffisamment intéressant pour être intégré moyennant quelques corrections), soit après déjà 3 ou 4 patchs corrigés (mais le contributeur n'a pas compris ou vu tous les problèmes qu'on lui soumettait); donc je pense qu'à ce moment le contributeur est soulagé de ne pas avoir à faire un autre aller-retour revue-patch.
Dans mon cas, j'essaie aussi de le faire aussi rarement que possible.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

C'est intéressant ce que tu dis. Mais ne préférerais-tu pas et ne serais-tu pas encore plus fier d'avoir une revue de code juste mais stricte, qui te demande de revenir sur ton code, d'intégrer les changements demandés par le réviseur (est-ce la bonne trad pour "reviewer"?), puis que ton patch final soit intégré dans le logiciel sous ton nom à toi (et pas juste une vague citation)?

Personnellement je fais tout mon possible pour que le nom du contributeur reste l'auteur du commit. Bien sûr, si le contributeur ne répond plus, et que je suis obligé de réécrire totalement son patch (car il ne correspond pas à nos critères de qualité) qui à la fin n'a plus rien à voir, je suis bien obligé de me mettre en auteur. Mais j'essaie d'éviter d'arriver à cela. S'il le faut, je laisse du temps passer et attend quelques mois (parce que tout le monde a une vie et je comprends bien qu'ils ne peuvent pas forcément réagir immédiatement à une revue de code) en re-demandant 1 ou 2 fois où ça en est avant d'éventuellement me décider à committer quelque chose moi-même.

Personne ne s'arrachera les cheveux sur ton code et aucun système critique ne mourra par ta faute car ce sera alors du bon code. Ou du moins si problème il y a, ce sera tout autant (voire plus) la faute du réviseur de code (Si on doit absolument chercher un fautif — en reprenant tes termes — mais ce n'est absolument pas la logique habituelle, du moins dans les projets auxquels je participe où on fait du travail collaboratif et tout le monde a le droit à l'erreur; j'ai moi-même de temps en temps des commits qui doivent être annulés, ça arrive, c'est pas la fin du monde et personne ne lance la pierre). Et en plus ton nom sera dans les auteurs. J'aime donner ce petit bout de fierté aux contributeurs et je pense que c'est important de les faire se sentir part au logiciel auquel il contribue.
C'est pour moi l'une des meilleures fonctionnalités des systèmes de versionnement décentralisés. À l'époque de SVN, un contributeur occasionnel n'était qu'une bref citation dans le commit du message au nom d'un autre, même si le commit était 100% de vous (seuls les développeurs "core", c'est à dire ceux avec accès écriture sur le dépôt pouvaient être dans le champs "auteur", et donc un patch d'un contributeur revenait à celui qui le poussait). De nos jours, avec git, mercurial et co., on est capable de donner la véritable paternité d'un code et c'est réjouissant.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je sais que c'est dans l'air du temps de discuter des "mainteneurs grincheux", alors je vais prendre un peu le contre-pieds, en étant régulièrement justement du côté "mainteneur" (ou "reviewer" de code, ce qui peut souvent être vu similairement pas un contributeur) de la barrière.

La partie du message à laquelle — j'imagine — tu fais référence en parlant de mainteneur grincheux qui introduit de la friction dans le développement, est:

L'autre inconvénient c'est que souvent ces personnes se retrouvent à dire "non, on ne va pas faire comme ça, il faut plutôt faire comme ça", et ça ne plaît à personne quand la personne en face essaie juste de faire intégrer un changement qu'on lui a demandé de faire.
<original>The other downside is that it often involves saying "no, let's not do that, let's do this instead" a lot, and that makes people feel bad when they know someone else is just trying to achieve a task someone assigned them.</original>

Moi quand j'ai lu cette phrase, je n'ai pas du tout interprété ça comme toi, mais plutôt qu'y a beaucoup de contributeurs qui ne veulent pas se faire chier, ni même forcément faire du bon code, et surtout pas interagir avec l'équipe et collaborer. Donc de leur point de vue, tout se passe bien si on leur dit "c'est génial, on intègre", mais dès qu'y a un peu de revue détaillée et qu'on leur demande de changer leur code pour intégration, y a plus personne au bout de la ligne (ou du mécontentement).

Daniel Berlin parle des gens à qui on a assigné une tâche (donc typiquement des gens qui contribuent essentiellement parce qu'ils sont payés pour le faire; notons que ça ne signifie pas toujours qu'ils aiment l'idée du Libre, ou de l'OpenSource, plus que ça). Mais il y a d'autres cas. On voit souvent des gens qui font vraiment du lâchage de patch, mais dès qu'on répond avec une revue de code (pas méchante, polie et amicale, mais on leur demande de changer des trucs), on n'a pas de réponse. Bien sûr, ça peut aussi être des problèmes de manque de temps (ça m'arrive moi-même régulièrement de laisser passer des mois avant de revenir sur un patch car j'avais d'autres priorités). Des fois aussi, les jeunes, étudiants ou développeurs moins expérimentés ont beaucoup de mal à corriger leur patch en suivant les indications donnés, etc. Y a plein de raisons possibles.

Pourquoi leur demande-t-on de corriger leur patch? Certains (beaucoup même, j'ai l'impression) projets ont cette tendance à intégrer tout et n'importe quoi. Parfois ils corrigeront après coup, dans un nouveau commit, parfois même pas, alors que le patch de base a clairement des manques, ne suit pas le style du projet, etc. Je pense que l'envie d'avoir de nouveaux contributeurs pour certains mainteneurs surpasse l'envie d'avoir du code de haute qualité. Surtout pour les plus petits projets.
Dans GIMP, on a tendance à demander un haut niveau de qualité pour un patch. Déjà qualité du code même, mais aussi le respect de l'architecture du logiciel (on ne peut pas inclure des headers de n'importe quelle partie du code vers n'importe quel autre partie. Par exemple le core de GIMP n'a aucune notion de GUI, etc.), ou même le style de code. C'est la base: si je contribue sur un projet tiers, je regarde toujours quel est leur style (tabulations, espaces, accolades en début ou fin de ligne?…). On s'en fiche quel style j'aime personnellement quand je contribue. J'impose mon style seulement sur mes projets persos.
Alors bien sûr, c'est un choix et les 2 se défendent: vaut-il mieux tout intégrer et faire plaisir aux contributeurs (quitte à prendre beaucoup de temps après coup pour tout nettoyer derrière) ou demander un haut niveau d'entrée et risquer de perdre des contributeurs (en se faisant appeler "grincheux")? Ce que j'ai tendance à penser sur le sujet:

• beaucoup de petits patchs seraient bien plus vite et bien mieux écrits si on les faisaient nous-même que si on en fait la revue et le commentaire. Alors pourquoi le fait-on? Parce qu'avoir des contributeurs est important et qu'on "utilise" du temps maintenant mais pour potentiellement en gagner beaucoup plus tard si certains contributeurs décident de rester dans le coin, et pourquoi pas devenir des contributeurs majeurs. C'est donc un investissement de temps sur le long terme.
  Alors d'un certain point de vue, vaut-il mieux faire plaisir à un max de ces petits contributeur au cas où on a notre futur contributeur majeur dans le lot? D'un autre côté, si on ne l'a pas habitué à faire de la qualité dès le début, à quoi s'attend-t-on pour la suite? Veut-on vraiment de quelqu'un qui n'est pas capable de suivre un style donné, de revenir sur son code, d'écouter des critiques constructives, de lire et comprendre des revues de code et réorganiser le sien? Peut-être que cela est bien plus rentable sur le long terme. Après tout, comme je le disais, intégrer les petits patchs peut vraiment prendre un temps fou, donc autant que ce temps soit utilisé à bon escient pour le futur du programme. Parfois même, le patch en soi est moins important que la relation qui peut se construire avec le contributeur.

• on essaie d'avoir un code toujours stable sur master, même s'il est expérimental. Il ne faut pas intégrer un commit qui ne compile pas, ou va faire crasher le programme, ou autre mauvais "comportement". Intégrer un patch qu'on sait ne pas être parfait est donc une mauvaise idée. Évidemment on peut rétorquer que si on fait immédiatement un commit de correction derrière le patch du contributeur et on pushe les 2 en même temps, alors on a un changement atomique (quelqu'un qui fetche le dépôt aura les 2 commits d'un coup), mais cela reste non-idéal.
  Une autre possibilité peut être de corriger direct le commit du contributeur (--amend). On le fait souvent d'ailleurs, surtout quand les seuls changements sont des problèmes de style de code. Parfois aussi pour des changements plus importants, voire parfois on fait du gros élagage. Mais on laisse le nom du contributeur en tant qu'auteur du commit. Y a la question alors: jusqu'à quel niveau de changement peut-on toujours considérer ce contributeur comme auteur du commit? C'est pour ça que je rechigne à faire trop souvent cela personnellement, hormis pour des changements vraiment mineurs, et fait plutôt des commits juste après. Mais idéalement on préférerait que les contributeurs nous fassent un patch parfait qu'on n'aura pas à corriger. Et pour cela, ils doivent simplement suivre nos indications de revue de code.

Ensuite il y a les choix de design de l'application. On ne peut pas accepter tout et n'importe quoi. Et beaucoup de contributeurs semblent penser que changer un "petit" (d'après eux) truc n'a pas besoin d'être discuté. Déjà beaucoup de choses ne sont pas si "petites" même si un contributeur va essayer de vous en convaincre (or s'il est si attaché à voir ce patch intégré, c'est justement que le changement n'est pas si petit à ses yeux). Ensuite chaque fonctionnalité a son fan-club. Même si on se rend compte qu'une fonctionnalité est fondamentalement mauvaise, il y aura toujours quelqu'un pour l'apprécier. Et ça veut dire qu'une fois acceptée, elle sera très dure à retirer plus tard sans se prendre des plaintes et des menaces. En gros quoiqu'on fasse (garder, retirer, changer…), y a toujours quelqu'un pour ne pas être content et le faire savoir, souvent de façon virulente.

XKCD 1172 par Randall Munroe — CC BY-NC.

Ça signifie donc qu'il vaut bien mieux bien réfléchir sur chaque changement de fonctionnalité et chaque nouvel ajout, avant de l'accepter. Pas se dire "on pourra toujours revenir sur la décision plus tard". Car ce n'est pas similaire. Dans un cas, il ne se passe rien; dans l'autre on se prend des coups quoiqu'on fasse. Il est donc tout naturel de calmer les ardeurs et de réfléchir posément les nouvelles fonctionnalités, non seulement sur leur qualité intrinsèque, mais aussi sur le choix d'implémentation. Et donc oui, des fois, ça en revient à dire "non on va pas faire ça, on va faire ça à la place" (ce qui n'est pas un refus, mais une alternative ou différente implémentation — souvent pour des raisons qualitatives du code, donc maintenabilité — pour un comportement final similaire). Et oui, des fois, ça plaît pas forcément.

Mais ça veut pas forcément dire qu'on est grincheux. :P
Perso j'essaie d'être toujours le plus agréable et ouvert possible aux nouvelles idées. Mais ça veut pas dire que je dois laisser mon esprit critique au vestiaire et me passer de prendre des décisions finales quand il le faut. C'est pas facile tous les jours, d'ailleurs. Ensuite, soyons clair: globalement cela se passe bien et la plupart des contributeurs le prennent bien. Mais il arrive des couacs par moment.

En tous cas c'est assez marrant de voir que selon les personnes et leur niveau d'implication dans des projets, à quel point on a un niveau de lecture différent de la même phrase. ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Pour info, l'opérateur --> veut dire "aller jusqu'à"

hmm… Je n'ai jamais vu cet opérateur. Bon ensuite je ne peux prétendre connaître les moindres subtilités du C. Par contre il serait en effet indistinguible de '--' suivi de '>' (puisque l'espace n'est pas obligatoire). Donc je doute vraiment qu'un tel op puisse exister.

Dans l'exemple donné, chaque test a simplement l'effet de bord de décrémenter la variable apres coup. Ça ne marche donc que pour un décompte. Un compte croissant devra utiliser '++ >'.

Ensuite je veux bien avoir tort et apprendre quelque chose aujourd'hui. Mais ça me paraîtrait vraiment étonnant que cet op existe. :p

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

J'appellerai pas ça un problème de mésententes, c'est surtout un problème classique de point de vue développeur vs packageur.

Bien sûr. Mais justement cela aurait pu être fait dans la joie et la bonne humeur. ;-)
Par exemple, puisque le packager Debian patchait Owncloud pour justement permettre de sauter des versions lors des mises à jour, peut-être ces patchs auraient-ils pu être repris upstream (et éventuellement corrigés/améliorés/nettoyés selon les standards du projet)? Le fait est que maintenant Nextcloud (et probablement Owncloud) souhaite avoir cette fonctionnalité de toutes façons, les forces auraient pu être jointes plutôt que les ponts rompus.

C'est là où il y a eu mésentente. Avec de simples discussions aimables, bien sûr cela ne résoud pas forcément le problème technique. Peut-être le travail en cours de Debian n'était pas acceptable d'un point qualitatif par Owncloud, mais c'est aussi exprimable de manière constructive sans braquer l'autre côté. Et peut-être que cela aurait abouti à de nouvelles propositions de patchs qui se seraient rapprochées d'un truc livrable. Ou pas. Mais dans tous les cas, ce serait une meilleure situation que maintenant.

C'est le principe d'une revue de code. Quand je lis un patch, j'essaie de passer mes commentaires pour demander au contributeur d'améliorer son patch de manière agréable. Ça marche pas toujours. Certains faisaient juste un lâchage de patch et reviennent de toutes façons jamais. Certains peuvent le prendre mal malgré tous les efforts diplomatiques que l'on puisse faire pour dire que ça n'est pas suffisamment dans nos standards de qualité. Mais bon, faut essayer quand même.
Et dans le cas d'un packager Debian, qui maintient plein de patchs et depuis longtemps, je pense qu'il aurait pu prendre mieux une proposition d'inclure son travail moyennant des changements. Mais pour cela, il aurait fallu discuter (en lisant les commentaires des 2 côtés, j'ai l'impression qu'Owncloud se focalise sur un commit et ne s'est pas rendu compte que c'était une partie d'un travail en cours pour une mise à jour en sautant des versions).

Ensuite je ne connais pas le détail et surtout le passif de discussion. Je ne saurais dire qui est le plus en faute dans l’interaction sociale (et franchement ça m'intéresse pas de savoir). Je constate juste le résultat et trouve cela un peu triste.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui tout à fait. Ceci dit, de nos jours, on trouve facilement (et pour quasi rien) des clés USB de 8GB ou plus (de la mémoire à 8GB aussi ceci dit, mais pas du tout au même tarif!) donc c'est tout de même une différence.

Mais bon, je chipote (ou j'extrapole, car on a pas les détails de toutes façons!). ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suite à de nombreuses incompréhensions entre les programmeurs d'Owncloud et le mainteneur du paquet Debian, ce dernier a choisi de supprimer tous les paquets Owncloud des dépôts Debian (Source)

Quand on suit un peu les liens, je comprends les problématiques techniques des 2 côtés: Debian veut pouvoir fournir un logiciel stable (sans faire de mise-à-jour majeure forcée si on veut juste profiter des corrections de bug) alors qu'Owncloud veut pousser les gens à mettre à jour le plus possible (et j'imagine qu'en tant que petite boîte, ils n'ont pas forcément les moyens humains pour maintenir trop longtemps de vieilles versions). Le problème était donc que les packagers Debian patchaient Owncloud pour créer leur propre système de mise à jour leur permettant de sauter des versions majeures (le but étant — j'imagine — de pouvoir mettre à jour Owncloud tous les X années, à chaque sortie de Debian, durée pendant laquelle il y aurait eu plusieurs versions majeures d'Owncloud, en ne proposant que les corrections de bugs dans l'intermède).

Perso, je comprends les deux raisons. Le problème semble réellement essentiellement humain, notamment le développeur Owncloud qui dit sur les mailing lists que le mainteneur Debian est un irresponsable. C'est sûr que ce n'est pas forcément très diplomatique. :-/

Il n'y a aucun paquet nextcloud dans Debian à l'heure actuelle […]
ça ressemble à une occasion manquée

Quand on lit ton lien, on se rend compte que les packagers Debian sont surtout vraiment pas chauds et considèrent la relation avec Nextcloud tout aussi problématique que celle avec Owncloud. En fait pire, le dév hostile fait justement partie des gens qui sont partis d'Owncloud vers Nextcloud! Donc en un sens, même si c'était sous le nom "Owncloud" (car à l'époque Nextcloud n'existait pas encore), on pourrait dire que c'est tout autant voire plus la relation avec Nextcloud qui fut rompue.

Ceci dit, le dernier message (à ce jour) de ce rapport de bug dit aussi que Nextcloud a annoncé la possibilité de mettre à jour en sautant des versions, ce qui est exactement ce qui posait problème à Debian et qu'ils espèrent que Debian aura un paquet. Ce n'est donc pas entièrement fermé, semblerait-il. Il faut juste voir comment se passera le côté relationnel car ça semble avoir vraiment été très mal vécu du côté Debian.

En tous cas, c'est toujours triste de lire ce type de mésententes. ;-(

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

La plupart des distrib Live n'ont pas de persistence. En d'autres termes, je pense même pas que ça installe sur la clé mais juste en mémoire. Ensuite je connais pas Mythbuntu ni comment ils ont construit leur clé live. Peut-être est-ce spécialisé pour la persistence des données et non juste pour le test de la distrib?
Si ce n'est pas le cas, c'est en effet très vraisemblablement la cause du problème.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je veux bien que certaines options puissent améliorer la donne, mais rendre un filtre anti-spam inutile, sûrement pas! S'il suffisait juste de quelques options pour avoir une boîte email sans spam et surtout sans faux-positifs (c'est le plus important: on ne veut surtout pas rejeter un email valide, c'est bien pire que de laisser passer quelques spams), alors le spam sur internet ne serait pas un tel problème.

vérification du domaine de l'expéditeur

Ça veut dire quoi ça? Tu acceptes que certains domaines? Genre si t'es pas Gmail ou Yahoo, ça va pas, email refusé?

Ou alors tu veux vérifier si l'email est transmis avec un HELO qualifié avec un nom de domaine? Si c'est le cas, c'est une mauvaise méthode et tu peux te retrouver à bloquer des serveurs tout à fait OK. Tiens une petite recherche vite faite sur le web, qui donne des conseils avec lesquels je suis d'accord.

Ou bien tu parles du SPF? SPF part d'une bonne idée, mais là aussi je me suis rendu compte que dans la réalité, des mails peuvent se perdre. Voici une histoire vraie qui m'est arrivée:

• Quelqu'un de @redhat.com m'a envoyé un email sur mon adresse @gimp.org. Comme j'en ai marre d'avoir 100 adresses, je préfère les alias. Mon adresse @gimp.org est donc un alias sur mon adresse principale.
• Puisque c'est un alias, l'email est passé par les serveur de gnome.org (bien qu'il soit parti de redhat.com).
• Mon serveur a donc reçu un email disant provenir de redhat.com mais en apparence venant de gnome.org. Puisque RedHat a un enregistrement SPF strict et que j'avais configuré mon serveur pour obéir strictement aux règles SPF, ce dernier a rejeté cet email pourtant tout à fait valide (et même possiblement important). Je ne l'aurais jamais su si cette personne de RedHat ne m'avait pas ensuite contacté par une autre adresse pour me prévenir du problème. Et pourtant dans cette exemple tout le monde a fait parfaitement comme on lui demande: RedHat a un enregistrement strict, l'employé envoyait bien depuis les serveurs RedHat, mon serveur avait une politique stricte… SPF ne prend tout simplement pas la possibilité d'alias email en compte.

Depuis j'ai appris ma leçon et je ne configure plus mon serveur email pour appliquer une politique SPF stricte en attendant de trouver une alternative (mais j'ai pas l'impression que ça existe).
SPF a aussi des problèmes dans l'autre sens (envoi d'emails qui sont refusés), similaire aux alias, alors qu'on suit toutes les règles de bonne conduite, mais bon je vais pas détailler chaque cas possible qui peut mal tourner.

blocage des adresses dynamiques

Certains font de l'auto-hébergement et arrivent à associer des IPs dynamiques à un nom de domaine de manière transparente. C'est prise de tête, et je le ferais pas, perso, mais c'est quand même internet et je vais pas les refuser. Les personnes avec IPs dynamiques ne sont pas des sous-citoyens. Internet n'est pas que les gros serveurs des GAFAM.

vérification des listes noires

Les listes noires, ça bloque tout et n'importe quoi. Et pour se faire retirer de certaines, c'est la croix et la bannière. Pour le coup, ça bloque bien plus que des IPs dynamiques, mais aussi souvent des IPs fixes de fournisseurs d'accès (donc on considère qu'un particulier a pas le droit d'héberger un serveur?), et aussi des IPs d'hébergeurs sous prétexte que quelqu'un dans le bloc a loué une fois un serveur pour spammer.
En gros, là c'est Internet == GAFAM++.

Ensuite c'est une discussion qui revient souvent sur linuxfr et je ne vais pas revenir dessus. Je donne cependant mon avis: les listes noires, c'est mauvais.

greylisting

Je pense que c'est la seule bonne idée de la liste.

Forcément si tu configures Postfix pour refuser tout et n'importe quoi, t'as plus de problème de spam, mais en même temps tu limites ton réseau à une micro portion de l'internet. Mon internet à moi, il est quand même un peu plus grand et va au delà de Google et Co.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Photoshop: oui. Tout le monde connait photoshop, c'est même passé dans le langage courant: 'oh cette image a été photoshoppee.'

La semaine dernière, j'étais à un festival d'animation sur Paris ("Carrefour du Cinéma d'Animation" au Forum des Images), un endroit avec des pros (des gens qui se font payer pour dessiner ou faire de la 3D, des films, etc.) et des jeunes en école (dont le but est de devenir pro). Lors d'une table ronde, je remarque que la souris a laissé en surbrillance un programme sur l'écran de l'animateur principal: GIMP.

Pendant ce temps, à l'extérieur, les étudiants d'école de cinéma d'animation faisaient des démos (en fait ils préparaient un cadavre exquis animé à présenter pour la fermeture du festival). Au milieu des Maya/Photoshop/After Effects, je repère direct plusieurs Blender (Blender est aussi cochable dans les listes de compétences Pôle Emploi, et de plus en plus de studios l'utilisent).

Ensuite je ne vais pas t'affirmer que Photoshop n'a plus sa place de choix dans les milieux pro. Je pense que si cet animateur avait GIMP sur son ordi, ce n'était probablement pas pour animer, mais par contre ça signifie probablement que lorsqu'il veut modifier une image, GIMP lui convient parfaitement. Ceci dit, des gens comme nous animons avec GIMP — donc c'est pas impossible, note bien — mais parce que nous avons aussi nos outils internes en cours de développement (utilisés au quotidien, pas encore sorti, mais ce sera libre, et d'ailleurs sûrement livré dans GIMP même).

En restant dans le propriétaire, l'un des programmes phare cette année pour le film d'animation 2D est le (relativement) récent TVPaint. Pourquoi phare? Probablement déjà parce qu'il a été utilisé pour La Tortue Rouge dont le réalisateur était l'invité d'honneur cette année, premier film non réalisé par un japonais produit par les studios Ghibli, et qui a gagné plusieurs prix. Donc TVPaint a eu droit à sa conf d'1h30, etc. TVPaint fait un peu parler de lui ces dernières années, on pourrait croire que c'est parce qu'il est développé en France, mais Aryeom (la réalisatrice de "ZeMarmot") connaît des animateurs amis coréens qui ont aussi travaillé avec (en Corée donc). Ce programme a le vent en poupe depuis quelques années. Or — c'est là où je veux en venir — bien que propriétaire, il se trouve qu'il est aussi disponible pour GNU/Linux!
À un moment, quelques années auparavant, on avait presque hésité à l'essayer pour notre projet pour cette raison, mais le fait de travailler avec du propriétaire nous a finalement arrêté car l'un des buts de notre projet est aussi d'améliorer le logiciel libre.

Tiens Pixar eux-même régulièrement montre des démos avec un Desktop sous GNOME (donc Linux), par exemple à SIGGRAPH 2016 (le plus gros salon business de l'animation) lorsqu'ils ont libéré USD, ou encore cette vidéo (où on voit encore le même logiciel tourner sous Linux. Dans la vidéo, ils expliquent clairement qu'ils développent leurs propres outils dès le début, bien que ce documentaire en particulier est orienté vers la collaboration avec Autodesk, donc on voit aussi des ordis sous Windows dans certaines parties). C'est le "backend" qui fut libéré et non le logiciel d'animation que l'on voit à l'écran, lequel doit donc être leur outil interne… notons tout de même que cette GUI tourne sous Linux et donc que les animateurs peuvent produire leur film animé entièrement depuis un bureau Linux!

La conclusion est donc que non, Windows (ou OSX) ne sont absolument pas des obligations dans le monde pro du graphisme (ou de l'animation dans mes exemples. Forcément… je connais cet angle là plus particulièrement…). Je dirais même qu'il a déjà beaucoup perdu de sa superbe par rapport à des années auparavant. Photoshop est probablement ce qui s'utilise le plus encore — forcément il avait un quasi-monopole pendant si longtemps — mais justement par les gens qui ne connaissent pas grand chose (ou ne s'intéressent pas à la technique) et vont donc au plus connu. Mais tous ceux qui étudient vraiment les alternatives voire ont leur propres développeurs vont voir ailleurs. Et après tout, c'est ceux qui entraînent le marché et annoncent donc un futur potentiel pour le grand public également.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

C'est un peu violent ta méthode. En fait tu ré-entraines tous les jours avec l'ensemble de tes emails au lieu de seulement les erreurs? Je me demande même si ça peut pas être mauvais pour la qualité du filtre.

Comment fais-tu pour que le déplacement génère le réapprentissage ? ça serait pas mal en effet.

Franchement j'ai tout réglé y a des années et j'essaie d'y toucher le moins possible (en général, seulement lors de mises à jour si besoin).
Mais j'ai jeté un œil et je crois que c'est grâce au plugin antispam de Dovecot. Si tu fais tourner dspam en daemon, tu peux alors communiquer avec dspam --client et lui envoyer des signatures d'email à réapprendre (en spam ou ham selon le type d'erreur). Sur le web, tu trouves divers tutoriaux qui donne des exemples de configuration, par exemple:
https://kuther.net/howtos/integrate-dspam-postfix-dovecot-any-mail-client (tout en bas de page)

Je ne saurais te donner plus de détails car — comme je disais — c'est super vieux pour moi et j'ai vraiment pas envie de me plonger sur le sujet si je peux éviter (la mise en place d'un serveur email fonctionnel est un vrai calvaire). J'espère que ces infos te donneront les pistes nécessaires.

Bien sûr, je te donne la version dspam mais je suis persuadé que spamassassin ou rspamd ont une méthode de réapprentissage équivalente.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

J'ai une conf postfix/spamassassin, avec un peu de scripting perso qui récupère les IP des SMTP qui m'ont envoyé du spam, et les balance dans fail2ban. Un peu de bayes le soir pour apprendre des spams en plus.

En sus d'essayer de "remonter le chemin du spam" (tu feras quoi si tu trouves la source d'ailleurs?), tu peux essayer d'améliorer ta config.

Déjà, peut-être que spamassassin n'est pas le meilleur choix? Perso j'utilise dspam qui marche plutôt bien, mais il paraît que son développement est au point mort et que certaines distribs commencent à le retirer. Récemment quelqu'un sur linuxfr faisait un peu de pub pour rspamd, plus récent et qui paraîtrait-il marche bien mieux. Notamment il donnait le lien vers un test de performance (fait par le dév de rspamd). D'après ces tests, rspamd fonctionne mieux que dspam et spamassassin (ce dernier utilise apparemment les mêmes filtres bayésiens que Bogofilter et par conséquent faut regarder "Bogofilter" pour comparer dans ton cas).

J'ai pas encore eu le courage de tester rspamd (parce que mon dspam, bien que non parfait, marche quand même relativement bien et que configurer mon serveur email, ça prend du temps et ne me met pas en joie…), mais ça peut valoir le coup si tu as le temps et si tu es trop mécontent de ton installation.

Deuxième amélioration possible: le réapprentissage. Tu dis que tu le fais le soir. Quelle est ta procédure exactement? Pourquoi ne fais-tu pas du réapprentissage constant et temps réel?
Perso, j'ai mis en place une boîte au lettre "spam" et si un spam n'est pas correctement détecté (il arrive dans Inbox, cad "Ham False Positive"), le déplacer dans le répertoire spam lance un réapprentissage sur ce spam. Au contraire, si je repère un email valide dans ma boîte spam ("Spam False Positive"), le déplacer hors du répertoire lance aussi un réapprentissage inverse.
Je trouve cette façon de faire bien plus simple car en gros, c'est naturel: au moment où je suis dans mon lecteur de courriers, le simple fait de déplacer les messages dans un autre répertoire (ce qui est assez naturel de base) va lancer des réapprentissages.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Est ce que seul google fait ca? je ne crois pas, étant donné qu'il me semble que c'est dans la norme du formatage des adresse email. (que je n'arrive pas à retrouver…)

Ce n'est pas une norme si je ne m'abuse, seulement une pratique commune. Et donc oui la plupart des serveurs mails permettent cela (par défaut sûrement même). Mon serveur Postfix+Dovecot permet cela aussi (je me souviens plus si j'ai dû activer une option ou si c'est par défaut).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui tu as raison, et c'est ce que j'ai écrit puisque je parle de consonnes et voyelles (donc un alphabet). Simplement du point de vue "stockage" des textes, donc des codages de caractères, c'est un système tout à fait syllabique. 안 est un unique caractère, même s'il est en effet assemblé de ㅇ, ㅏ et ㄴ (ceux-ci existent aussi en tant que caractères informatiques mais ne sont quasi jamais utilisé dans un texte final). Du point de vue informatique, c'est donc un système d'écriture complètement syllabique, même s'il passe par des phases alphabétiques lors de l'entrée des caractères.

En outre, la base même de l'orthographe coréenne est que chaque mot doit être composé de syllabes complètes uniquement (au minimum 1 consonne et 1 voyelle). Et de ce point de vue là, le système d'écriture coréen est complètement syllabique (cette fois d'un point non-informatique, mais par leurs règles orthographiques).

Donc oui, tu as raison, ils ont un alphabet, et pas un syllabaire. Mais cela n'empêche pas leur système d'écriture d'être profondément syllabique sous de très nombreux aspects.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ça aurait été avec grand plaisir mais ça reste un peu compliqué en semaine quand on habite en grande couronne :/

J'habite Cergy depuis quelques mois, ce qui est dans la grande couronne aussi, me semble-t-il. ;-)
Trêve de plaisanterie, je comprends bien. Je suis souvent aussi dans le cas où j'ai la flemme d'aller à un évènement sur Paris, surtout en soirée.

Par contre, si y'a un espace en ligne où les créations sont/seront stockés et où on pourrait participer je suis preneur :)

Y a déjà un dépôt git, mais il est assez vide. On a aussi une liste de discussion, qui est pour l'instant très peu causante. Tu es le bienvenu pour amener un peu de vie. Les 2 ateliers passés n'ont pas vraiment fait beaucoup de vagues, mais on espère que cela va changer.
Dans tous les cas, je ferai un compte-rendu après l'atelier de jeudi, et je redonnerai les divers moyens de participer à distance.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ce n'est pas ce qui a été choisi par MS-Office aussi ? Ainsi que la plupart des traitement de texte ?

Je ne peux pas dire avec certitude car je n'ai pas ce programme (ni de système d'exploitation où il pourrait tourner), mais j'imaginerais bien que oui. Il n'y a pas encore si longtemps, je pense que quasi tout document fait avec un traitement de texte était fait pour l'impression. Déjà parce que pas tout le monde n'avait internet, ou bien pas forcément un internet rapide, et puis c'était la force de l'habitude.
De nos jours, on considère presque Internet partout comme une évidence (dans les pays occidentaux, même si pourtant on n'a pas encore une couverture 100% du territoire en haut débit ironiquement). la plupart des administrations poussent à faire toutes les démarches en dématérialisées, toutes les grosses sociétés qui envoient des factures mensuelles proposent d'envoyer une version PDF seulement (parfois avec petite réduc sur la facture quand on fait ce choix), etc.

Mais oui, les traitements de texte sont nées dans un monde où presque tout document texte était destiné au support papier. Donc cela ne m'étonnerait absolument pas si la plupart des (voire tous les) traitements de texte font encore la supposition que le document est fait pour l'impression.

Aujourd'hui, lorsque pour un système donné, je dois produire un rapport en pdf, pour la forme je demande toujours au client si le but est de l'imprimer ou de le visualiser à l'écran. Quelque soit la réponse, je préfère un rendu pour l'écran (j'utilise Latex); Je sais que le rapport sera lu sur écran et qu'on me reprocherait son rendu tout moche, alors qu'une fois imprimé, plus personne ne le lira.

C'est probablement le bon choix par rapport à ce que tu dis. Typiquement le vrai but (dans ton cas) est la visualisation sur écran, même si le client te dit que c'est une visualisation papier. Ce n'est pas la première ni ne sera la dernière fois qu'un client donne le critère inverse de la réalité. Note que ce n'est pas forcément la faute du client. En l'occurrence il va sûrement vraiment l'imprimer donc il dit vrai. C'est aussi à toi de savoir lire entre les lignes et de faire le bon choix (et a priori, d'après ce que tu dis, tu le fais), pas juste le choix "je-réfléchis-pas-c-est-la-règle-qui-le-dis". Cela illustre bien ce que je disais précédemment sur les règles qui n'en sont pas vraiment et sont faites pour être brisées.
D'ailleurs qu'en est-il des documents qui sont autant fait pour le papier que l'écran? Y en a aussi!

Sans compter que beaucoup de designers font aussi des choix esthétiques avant l'utilitaire et cela peut être tout à fait valide aussi en fonction des cas (bon typiquement probablement pas dans le cas d'un rapport).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Le corps de texte en serif et les titres en sans serif ! C'est fait exprès pour faire moche?

C'est une combinaison typographique classique pour l'impression. Cherche dans un moteur de recherche, tu auras des dizaines d'articles sur le sujet. Je crois que la raison principale est d'avoir un contraste immédiat entre "titres" et "corps de texte".

Note que pour des documents destinés à visualisation sur écran principalement, ce sera en général un choix inverse (mais LibreOffice fait donc le choix de supposer que les documents créés le sont dans le but de les imprimer. Ça se discute bien sûr puisque de plus en plus on fait des documents pour en faire des PDFs à s'échanger par email, mais historiquement c'est assez réaliste). En effet, les choix typographiques de base sont en général que le Serif, c'est bon pour l'impression, et que le Sans-Serif meilleur pour l'écran. Donc il va de soi que le gros d'un texte (donc le corps du texte) devra utiliser ce qui est jugé le plus "lisible" (serif sur papier, sans-serif sur écran d'après le choix habituel), alors que le titre utilisera l'autre pour le contraste.
Par exemple, sur Wikipédia, tu peux constater que les titres sont en serif et le corps du texte en sans-serif.

Note que je ne donne pas d'avis car je n'en ai pas vraiment. Je te donne seulement les sortes de "règles populaires" qui expliquent que LibreOffice fait probablement un choix par défaut tout à fait à propos. Ensuite clairement ces règles ne sont nullement en dur (ce ne sont pas vraiment des "règles" quoi, disons plutôt une sorte de connaissance populaire quand on veut pas s'embêter). Chacun est libre de faire d'autres choix et les designers ne s'en privent pas. Donc toute combinaison serif/sans se trouve dans la nature.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Il y a quand même une limite à ça à mon avis. Si les gens apprennent que Google vend des informations nominatives (ie: « Monsieur Michu a écrit "Duschmol puducul" le 21/04/13 à 11h00 dans un mail adressé à Monsieur Duschmol » ou encore : « Voici le récapitulatif des remboursement de soins de Madame Périclès ») ils risquent de se tourner vers un autre fournisseur qui respecte le savoir être le plus élémentaire…

Je regardais le premier épisode d'une série l'autre jour ("Mad Men") qui se passe dans les années 60, avec de nouvelles études qui commencent à peine à dire que le tabac est dangereux pour la santé et peut même provoquer des maladies mortelles. Les personnages principaux (des publicitaires dans une grosse boîte de comm') ont une entreprise de tabac en clients et se demandent alors comment ils sera possible de continuer à vendre du tabac; tout le monde semble persuader que c'est la fin de ce business, et que tout le monde va bientôt arrêter de fumer, en connaissance de cause.
~ 50 ans plus tard, ce ne sont plus de vagues nouvelles recherches. On sait pertinemment à travers le monde que le tabac tue. On a presque tous vu (soit sur internet, soit dans divers reportages/documentaires) ces photos horribles de poumons ou autres organes de gros fumeurs totalement noircis par le tabac. Dans énormément de pays, le tabac est désormais vendu avec des phrases chocs sur le paquet du type "Le Tabac Tue". Pourtant beaucoup de gens fument encore.

Bien sûr, je pense que le marché du tabac dans les pays occidentaux est moins bon qu'il y a 50 ans (notamment grâce à tout ce que j'ai noté plus haut), mais force est de constater que c'est loin d'être un marché mort. Les entreprises de tabac ne sont pas moribondes, loin de là et continuent tranquillement leur business.
Alors quand j'ai vu cet épisode où ces personnages des années 60 voyaient déjà la fin de tout un marché basé sur ce que le grand public sait maintenant depuis plus de 50 ans, cela fait se poser des questions. Non je n'ai pas vraiment l'impression que ce savoir du public des horreurs derrière certains business soit si puissant. En tous cas, pas suffisamment pour mettre à mal définitivement les-dits business.
Peut-être sur le très long terme. Qui sait, avec 50 autres années, le business du tabac sera alors anecdotique? Il aura alors fallu 1 siècle? Et encore, j'en doute…

Je pense que ces "savoirs" peuvent réellement être un problème aux entreprises de taille moyenne. Mais passé un seuil, c'est rien de plus qu'une petite tâche ennuyeuse qui pourra être nettoyée par les services de communication des plus grosses entreprises.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Si on arrive à finir dans notre deadline, ce sera le résultat qu'on devrait pouvoir présenter. Note que cela dépendra entièrement de si on a des contributeurs intéressés et qui souhaitent y mettre du leur car je met un point d'honneur à ne faire aucun choix primordial et à seulement aiguiller les gens vers ce qu'ils veulent faire du projet. Bien sûr, on pourrait plier ça en 2 semaines (voire moins) si on voulait faire ça nous-même, mais c'est absolument pas le but du projet. Ça nous intéresse vraiment dans un contexte de faire découvrir les logiciels libres de création (ainsi que les problématiques de licences libres).

On pourra toujours faire un atelier aux RMLLs, mais dans ce cas soit pour commencer un nouveau projet, soit juste un atelier "dans le vent" qui n'a pas pour but d'aboutir à quelque chose (puisque l'album sera théoriquement fini). Ça peut aussi être intéressant si l'atelier pouvait être dirigé par nos contributeurs, ou si on pouvait faire une petite conf par des contributeurs (pas nous).

Enfin bon, tout cela reste encore totalement théorique. J'attends encore de voir nos libristes intéressés. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Elle est cool ta liste. Je vois que tu parles de quelques claviers et surtout dispositions japonaises en plein milieu, mais sans vraiment élaborer. Et à te lire, on a presque l'impression que tu dis que cette disposition "thumb-shift" est encore la plus utilisée. Juste au cas où, je voulais préciser que c'est pas du tout le cas. Je la connaissais même pas en tous cas (ensuite je ne prétends pas non plus être expert de l'écriture japonaise, très loin de là :P).

Mon impression est que la méthode kana-kanji est le plus utilisé car c'est ce que je vois par défaut sous Linux, et aussi sous Windows (de ma faible expérience sur des Windows d'autrui, mais soyons clair: vraiment petite expérience, car j'ai pas pour habitude d'utiliser beaucoup de machines tierces). Cette méthode a aussi l'avantage de pouvoir être utilisée avec n'importe quel clavier, même sans connaître par cœur les touches).
Ensuite il est vrai que le système JIS (qui utilise lui des kana directement sur les touches, similairement à Thumb-shift, bien qu'avec une disposition qui n'a rien à voir) doit aussi être courant puisque tous les claviers sur le marché japonais sont vendus avec cette disposition imprimée (notamment mon clavier de portable car je l'ai acheté au Japon). Donc j'imagine bien que ça doit avoir un nombre d'utilisateurs importants.

J'ai essayé de chercher des stats pour savoir quoi de kana-kanji et de JIS est le plus utilisé, mais je n'ai pas pu trouver. En tous les cas, je ne doute pas que Thumb-Shift soit encore utilisé, notamment dans les milieux de l'écriture, et en lisant Wikipédia, j'ai l'impression que c'est un peu la version "ergonomique" pour taper le Japonais (au même titre que bépo pour le français ou dvorak pour l'anglais?). Mais je ne crois pas que ce soit super répandu non plus, en tous cas dans le grand public.

Quant au coréen, ils ont une disposition super intéressante aussi. Leur méthode d'entrée est très similaire au kana-kanji japonais, ce qui veut dire que c'est pas forcément efficace au niveau nombre de touches à taper (comme on lit sur Wikipédia pour expliquer l'attrait de Thumb-Shift notamment), par contre ils ont choisi de ne pas utiliser la disposition qwerty comme base, et ça change tout. Le clavier est en gros séparé des "consonnes" à gauche et des "voyelles" à droite. Comme leur système d'écriture est syllabique (comme le japonais), mais surtout qu'il est basé sur l'association de ces consonnes et voyelles (en gros alors que le japonais a des kanas syllabiques totalement différent "visuellement" les uns des autres, même lorsque les sons consonantique/voyelle sont les même, chaque caractère coréen est lui-même formé de 2 sous-caractères visuels — consonnes et voyelles — au moins. Notons qu'ils ont aussi la consonne sans son: 'ㅇ'), on se retrouve à taper quasiment systématiquement main gauche-droite-gauche-droite… C'est pas du 100% mais ça reste très bon.
C'est tout de même l'un des principes derrière dvorak/bépo (utiliser alternativement les 2 mains au possible) donc je trouve ça assez cool de voir un pays dont le clavier officiel suit cette logique (plutôt que tenter de s'accrocher au qwerty ou un dérivé proche).
Par contre je ne sais pas si statistiquement les lettres sont parfaitement bien placés pour utiliser principalement les doigts forts et bouger le moins possible les mains, et s'il y a eu des études pour ce faire, mais j'en ai bien l'impression. Clairement (enfin… basé sur mon impression, pas sur des statistiques réelles) on retrouve les caractères les plus courants sur la ligne centrale et sous les doigts. Et ils ont aussi regroupés des caractères par types. Par exemple certaines consonnes et voyelles sont formées à partir d'un autre en rajoutant une barre. Ainsi hjk sont mappés sur: ㅗ(o)ㅓ(eo)ㅏ(a), et juste au dessus, yui est mappé: ㅛ(yo)ㅕ(yeo)ㅑ(ya). On voit tout de suite une logique rendant la disposition évidente et surtout simple.
Alors soyons clair, je ne saurais affirmer que la disposition coréenne est parfaite, mais clairement c'est un très bon élève quand on voit les aberrations qu'on se traîne depuis des dizaines d'années dans nos pays.

Bien sûr, c'est peut-être légèrement hors sujet car je ne parle pas de clavier "physique" ergonomique. Mais les méthodes d'entrée m'intéressent beaucoup et ça fait aussi partie de l'ergonomie, n'est-ce pas? :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]