La problématique pour un auteur de voir son texte édité comme s'il s'agissait d'un logiciel.
Il n'y a absolument aucune différence avec un logiciel. Je peux t'assurer (vous assurer? J'ai tendance à tutoyer sur linuxfr! Préférez-vous le vouvoiement?) que si on me fait des remarques mal placées sur mon code, cela finit pareil. Ce n'est pas le fait de faire une remarque, mais comment elle est faite et sûrement aussi sur quoi elle porte.
Par exemple, si tu t'évertues à dépenser du temps et de l'énergie à faire une super fonctionnalité mais t'as quelqu'un qui vient et marche sur les plates-bandes sans rien comprendre et dit "mais ça sert à rien, hop poubelle" sans explication adéquate, tu seras pas content. J'ai une telle expérience notamment avec un gars qui nous aidait au design de GIMP (il était là avant que je contribue) mais il voulait tout contrôler et disait qu'aucune nouvelle fonctionnalité d'UI ne pouvait rentrer sans passer par lui d'abord (alors qu'il était devenu très peu actif depuis des années, donc clairement ce fut une période très sèche en nouvelles fonctionnalités excitantes, comme on l'imagine). À l'époque, j'étais encore un petit jeunot dans le projet, donc je disais rien. Un jour, quelqu'un a contribué une superbe fonctionnalité. Il représentait un groupe d'étudiants (en Inde, si je me souviens), et ils avaient implémenté la recherche d'action (une barre de recherche où on peut taper des mots clés pour retrouver des filtres, des outils, des actions, un peu tout, sans avoir à passer par les menus). C'est vraiment une fonctionnalité géniale et depuis son inclusion dans GIMP 2.10, je lis régulièrement cette fonctionnalité dans le top-10 des nouvelles fonctionnalités préférées des gens tellement c'est pratique (j'utilise ça tout le temps moi-même). Bien sûr, ce n'était pas passé par notre designer, mais c'est ça aussi le logiciel libre, parfois on reçoit des patchs inattendus et géniaux. Et puis c'était tellement utile que je ne pensais pas que ça ferait le moindre problème (tout le monde était d'accord). Bon bien sûr, le code n'était pas extra-ordinaire, c'était des étudiants, c'est normal. Au début on échangeait un peu avec l'étudiant à qui on faisait des revues de code et qui faisait quelques changements. Au bout d'un moment, je me suis lancé moi-même dans une large revue-correction, j'ai nettoyé le code, ai restructuré énormément toute la logique, l'ai améliorée, ai changé des comportements et ajouté des fonctionnalités. J'y ai passé des jours. À la fin c'était plus juste une bonne idée à l'état de prototype, mais une superbe fonctionnalité, stable et bien implémentée.
On se dit qu'il faut quand même passer par le designer. Dans mon esprit, je me dis qu'il va faire des remarques, des propositions, peut-être même ne pas aimer certaines choses et proposer des changements, et notamment faire une spécification écrite. C'est le jeu et ça me va bien, je changerai ce qu'il faut. Après plusieurs relances et des jours d'attente, il commence finalement à répondre en disant des trucs peu appropriés, genre que ça le rendait malade, puis il pose des questions sur la cible et d'autres trucs auxquels on essaie de répondre. Il dit beaucoup de choses qui me paraissent totalement inappropriés. Il y a dû y avoir une dizaine de personnes qui a intervenu dans la discussion et personne ne comprenait son problème avec cette nouvelle fonctionnalité (moi je soupçonne que c'est juste qu'on n'est pas passé par lui d'abord, ce qui était impossible par concept — code drop inhérent au système du logiciel libre, je le rappelle — et qu'il bloquait par égo).
Au final, le mainteneur a dû intervenir et a dit que ça rentrait dans GIMP, et puis c'est tout.
En tous les cas, ce fut une expérience particulièrement peu plaisante (pour cette personne aussi puisque ce fut son dernier échange technique avec nous, puis il a annoncé son départ quelques mois plus tard; j'en étais heureux!).
Dans mes années de code, j'en ai d'autres des histoires de commentaires déplaisants. Ça fait tout aussi désagréable que ce soit du code ou du texte. Ce n'est pas à propos de la revue ou de l'action d'autres personnes sur son œuvre. C'est comment c'est fait, pour quelles raisons, etc.
Parce qu'en parallèle, des gens qui ont touché mon code (ou mes textes), parfois très en profondeurs, y en a aussi plein des histoires et j'en suis très content. De grosses fonctionnalités ont été très largement réorganisée en un code de meilleure qualité et plus efficaces par d'autres, et quand j'ai vu le résultat, je me suis dit "waw c'est génial". C'est ça de bosser à plusieurs, on se complète, on améliore les idées et implémentations des autres. On peut aussi faire des commentaires ou être en désaccord. J'ai plein de code qui est sorti très différemment de ma proposition d'origine après revue de code. J'ai même des cas de changements qui au final furent refusés, et je comprenais la raison et l'ai accepté (même si j'étais un peu triste, c'était fait de manière tout à fait saine).
En parallèle, j'ai beaucoup apprécié l'écriture collaborative sur linuxfr. Y a des gens qui ont repéré les erreurs de français (orthographe, grammaire...), ceux qui ont francisé des choses (supporter → prendre en charge !), ceux qui ont rajouté des nouvelles idées intéressantes auxquelles je n'avais pas initialement pensées et avaient toute leur place dans l'article, ceux qui faisaient des commentaires constructifs ou qui proposaient de changer certaines tournures ou paragraphes, ceux qui aident à écrire, ceux aident à la traduction. Il y avait même ceux qui proposaient de supprimer des parties en donnant un argumentaire compréhensible et sur lequel on pouvait discuter.
Par contre, il y a aussi eu les mauvaises expériences (j'en ai eu quelques unes dernièrement sur linuxfr), de ceux qui mettent ça sur le plan personnel et commencent à t'accuser de trucs, ou qui veulent complètement changer l'esprit de ton article sans raison valable.
Le texte aussi a ses revues d'ailleurs dans le milieu professionnel. C'est notamment le rôle de l'éditeur pour un texte publié. Et s'il fait bien son boulot, ce dernier peut faire des remarques, parfois même de fond, mais de façon totalement approprié, compréhensible et qui peut être une base de discussion (puis finir ou non en changements).
Donc non, il faut arrêter de vouloir voir des différences entre le texte et le code. J'écris des choses auxquelles je tiens dans les 2 cas, j'ai mon nom attaché à ce que j'ai écrit dans les 2 cas. Et dans les 2 cas, j'apprécie (et même souhaite!) des remarques et de l'aide constructives... et les remarques/aide destructives me font souffrir dans les 2 cas. Aucune différence.
Je sais que certains voient les choses techniques comme un truc froid et détaché, mais dans la vraie vie, ceux qui font ça avec passion du moins, ils aiment leurs œuvres techniques aussi et y sont très attachés.
En conclusion:
Votre propos illustre encore la problématique. Si textes et logiciels partagent des points communs, les confondre et vouloir les traiter sans discrimination reste bien problématique.
Ce n'est pas du tout le problème. Le problème est de savoir travailler en groupe ou non. Clairement certains ne savent pas.
Une collaboration toxique n'est pas saine. Une remarque doit être constructive. Un changement majeur du travail d'autrui ne peut pas être fait à la légère. Et il ne faut pas mélanger les sentiments personnels avec une collaboration technique (le texte aussi est technique, même pour un roman), car à ce moment là, on touche aussi les autres personnellement et c'est là que ça fait mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Commentaire additionnel
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à 10.
Il n'y a absolument aucune différence avec un logiciel. Je peux t'assurer (vous assurer? J'ai tendance à tutoyer sur linuxfr! Préférez-vous le vouvoiement?) que si on me fait des remarques mal placées sur mon code, cela finit pareil. Ce n'est pas le fait de faire une remarque, mais comment elle est faite et sûrement aussi sur quoi elle porte.
Par exemple, si tu t'évertues à dépenser du temps et de l'énergie à faire une super fonctionnalité mais t'as quelqu'un qui vient et marche sur les plates-bandes sans rien comprendre et dit "mais ça sert à rien, hop poubelle" sans explication adéquate, tu seras pas content. J'ai une telle expérience notamment avec un gars qui nous aidait au design de GIMP (il était là avant que je contribue) mais il voulait tout contrôler et disait qu'aucune nouvelle fonctionnalité d'UI ne pouvait rentrer sans passer par lui d'abord (alors qu'il était devenu très peu actif depuis des années, donc clairement ce fut une période très sèche en nouvelles fonctionnalités excitantes, comme on l'imagine). À l'époque, j'étais encore un petit jeunot dans le projet, donc je disais rien. Un jour, quelqu'un a contribué une superbe fonctionnalité. Il représentait un groupe d'étudiants (en Inde, si je me souviens), et ils avaient implémenté la recherche d'action (une barre de recherche où on peut taper des mots clés pour retrouver des filtres, des outils, des actions, un peu tout, sans avoir à passer par les menus). C'est vraiment une fonctionnalité géniale et depuis son inclusion dans GIMP 2.10, je lis régulièrement cette fonctionnalité dans le top-10 des nouvelles fonctionnalités préférées des gens tellement c'est pratique (j'utilise ça tout le temps moi-même). Bien sûr, ce n'était pas passé par notre designer, mais c'est ça aussi le logiciel libre, parfois on reçoit des patchs inattendus et géniaux. Et puis c'était tellement utile que je ne pensais pas que ça ferait le moindre problème (tout le monde était d'accord). Bon bien sûr, le code n'était pas extra-ordinaire, c'était des étudiants, c'est normal. Au début on échangeait un peu avec l'étudiant à qui on faisait des revues de code et qui faisait quelques changements. Au bout d'un moment, je me suis lancé moi-même dans une large revue-correction, j'ai nettoyé le code, ai restructuré énormément toute la logique, l'ai améliorée, ai changé des comportements et ajouté des fonctionnalités. J'y ai passé des jours. À la fin c'était plus juste une bonne idée à l'état de prototype, mais une superbe fonctionnalité, stable et bien implémentée.
On se dit qu'il faut quand même passer par le designer. Dans mon esprit, je me dis qu'il va faire des remarques, des propositions, peut-être même ne pas aimer certaines choses et proposer des changements, et notamment faire une spécification écrite. C'est le jeu et ça me va bien, je changerai ce qu'il faut. Après plusieurs relances et des jours d'attente, il commence finalement à répondre en disant des trucs peu appropriés, genre que ça le rendait malade, puis il pose des questions sur la cible et d'autres trucs auxquels on essaie de répondre. Il dit beaucoup de choses qui me paraissent totalement inappropriés. Il y a dû y avoir une dizaine de personnes qui a intervenu dans la discussion et personne ne comprenait son problème avec cette nouvelle fonctionnalité (moi je soupçonne que c'est juste qu'on n'est pas passé par lui d'abord, ce qui était impossible par concept — code drop inhérent au système du logiciel libre, je le rappelle — et qu'il bloquait par égo).
Au final, le mainteneur a dû intervenir et a dit que ça rentrait dans GIMP, et puis c'est tout.
En tous les cas, ce fut une expérience particulièrement peu plaisante (pour cette personne aussi puisque ce fut son dernier échange technique avec nous, puis il a annoncé son départ quelques mois plus tard; j'en étais heureux!).
Dans mes années de code, j'en ai d'autres des histoires de commentaires déplaisants. Ça fait tout aussi désagréable que ce soit du code ou du texte. Ce n'est pas à propos de la revue ou de l'action d'autres personnes sur son œuvre. C'est comment c'est fait, pour quelles raisons, etc.
Parce qu'en parallèle, des gens qui ont touché mon code (ou mes textes), parfois très en profondeurs, y en a aussi plein des histoires et j'en suis très content. De grosses fonctionnalités ont été très largement réorganisée en un code de meilleure qualité et plus efficaces par d'autres, et quand j'ai vu le résultat, je me suis dit "waw c'est génial". C'est ça de bosser à plusieurs, on se complète, on améliore les idées et implémentations des autres. On peut aussi faire des commentaires ou être en désaccord. J'ai plein de code qui est sorti très différemment de ma proposition d'origine après revue de code. J'ai même des cas de changements qui au final furent refusés, et je comprenais la raison et l'ai accepté (même si j'étais un peu triste, c'était fait de manière tout à fait saine).
En parallèle, j'ai beaucoup apprécié l'écriture collaborative sur linuxfr. Y a des gens qui ont repéré les erreurs de français (orthographe, grammaire...), ceux qui ont francisé des choses (supporter → prendre en charge !), ceux qui ont rajouté des nouvelles idées intéressantes auxquelles je n'avais pas initialement pensées et avaient toute leur place dans l'article, ceux qui faisaient des commentaires constructifs ou qui proposaient de changer certaines tournures ou paragraphes, ceux qui aident à écrire, ceux aident à la traduction. Il y avait même ceux qui proposaient de supprimer des parties en donnant un argumentaire compréhensible et sur lequel on pouvait discuter.
Par contre, il y a aussi eu les mauvaises expériences (j'en ai eu quelques unes dernièrement sur linuxfr), de ceux qui mettent ça sur le plan personnel et commencent à t'accuser de trucs, ou qui veulent complètement changer l'esprit de ton article sans raison valable.
Le texte aussi a ses revues d'ailleurs dans le milieu professionnel. C'est notamment le rôle de l'éditeur pour un texte publié. Et s'il fait bien son boulot, ce dernier peut faire des remarques, parfois même de fond, mais de façon totalement approprié, compréhensible et qui peut être une base de discussion (puis finir ou non en changements).
Donc non, il faut arrêter de vouloir voir des différences entre le texte et le code. J'écris des choses auxquelles je tiens dans les 2 cas, j'ai mon nom attaché à ce que j'ai écrit dans les 2 cas. Et dans les 2 cas, j'apprécie (et même souhaite!) des remarques et de l'aide constructives... et les remarques/aide destructives me font souffrir dans les 2 cas. Aucune différence.
Je sais que certains voient les choses techniques comme un truc froid et détaché, mais dans la vraie vie, ceux qui font ça avec passion du moins, ils aiment leurs œuvres techniques aussi et y sont très attachés.
En conclusion:
Ce n'est pas du tout le problème. Le problème est de savoir travailler en groupe ou non. Clairement certains ne savent pas.
Une collaboration toxique n'est pas saine. Une remarque doit être constructive. Un changement majeur du travail d'autrui ne peut pas être fait à la légère. Et il ne faut pas mélanger les sentiments personnels avec une collaboration technique (le texte aussi est technique, même pour un roman), car à ce moment là, on touche aussi les autres personnellement et c'est là que ça fait mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]