Très bon (ou mauvais) code qui sera juger... par des développeurs (dont c'est le métier)
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Ça me va si celui qui me dit ça est à même de l'évaluer
...
(vous par un développeur, nous par un designer)
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
ça peut être des devs s'ils savent
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'...), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)... Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin... j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
Je pense que tu accepterais moins ces "refus de patches" et de contributions si elles étaient repoussées par des non devs sur des prétextes fallacieux. "Tenez j'ai codé un système pour améliorer la sécu" "lol non on en veut pas et on aime pas ton indentation".
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mon commentaire sur le blog...
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'...), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)... Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin... j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]