Pour moi, si y a vraiment plus de 200 merge requests contre-productifs, ça s'apparente tout de même à du sabotage institutionnel. En fait je comparerais même cela à ce qui est arrivé avec l'université du Minnesota dans le développement du noyau Linux. C'est très comparable: des universitaires qui n'y comprennent rien au principe bienveillant du développement communautaire et font un truc finalement complètement néfaste à la place (possiblement sans même s'en rendre compte ni se remettre en question).
Je parle pas d'avoir des petits patchs mineurs de temps en temps par des étudiants isolés qui contribuent dans le cadre de leurs études. Genre j'ai eu y a pas si longtemps des patchs mineurs qui corrigeaient des warnings de compilation (des vrais warnings, donc une vraie correction tout de même), avec quelques erreurs par ci par là, et finalement beaucoup de revue de code sur des trucs basiques tels que le style (indentation, noms qui ne suivent pas nos conventions, etc.). Dans ces cas là, on pourrait se dire que ça nous prendrait moins de temps à juste refaire le patch nous-même plutôt que jouer le jeu des aller-retours de revue de code. Mais en même temps, c'est normal, on a tous été débutants, il faut bien commencer quelque part et c'est mieux d'être bienveillants envers ces débutants qui pourraient être les développeurs de demain, de leur montrer un peu les trucs du métier, ce que l'école ne leur apprend pas, etc. (même sur des patchs mineurs) Ces patchs là ne me dérangent pas trop. Ceci dit, je voudrais pas en recevoir par poignée en continu. Mais une fois de temps en temps, ça me fait plaisir d'aider ces étudiants.
Mais des patchs complètement inutiles, qui ne font que réimplémenter des schémas débiles d'école juste histoire de (si je comprends bien l'idée), sans rien apporter, voire carrêment des patchs qui ne corrigent rien ou rajoute du code inutile (comme dans tes exemples), c'est juste nul. Et si en plus, tous les élèves proposent sur le même dépôt (même si c'était un dépôt important avec plein de dévs; genre je doute qu'ils apprécieraient de recevoir des dizaines de tels patchs inutiles, type "exercice d'école", sur des gros projets tels que le noyau Linux par exemple), là c'est carrêment du sabotage actif de projets libres.
Franchement je suis pas pour le public shaming mais je conseillerais de la contacter d'abord (ce que tu as fait), et si elle ne comprends pas (apparemment c'est le cas), de contacter son supérieur (comme conseillé par G.bleu) pour lui demander de raisonner un peu ce prof. Pas de la virer, rien de déshonorant, mais lui faire comprendre qu'elle est censé avoir une éthique en tant qu'universitaire pour ses futurs cours/recherches. Attention d'ailleurs, l'idée n'est pas qu'elle se dise "ah bah ce mainteneur est chiant, la prochaine fois, je dirigerai mes élèves sur un autre projet" mais bien "non on ne fait pas ça, sur ce projet comme sur un autre". Tu peux d'ailleurs te permettre de citer le cas récent de l'université du Minnesota et de Linux, pour lui rappeler que si ça s'était passé sur un tel projet, ça ne serait pas juste une tape sur la main, mais que ça pourrait se terminer mal pour l'université entière.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Doctoshotgun pris d'assaut par le variant étudiant. Évalué à 10.
Pour moi, si y a vraiment plus de 200 merge requests contre-productifs, ça s'apparente tout de même à du sabotage institutionnel. En fait je comparerais même cela à ce qui est arrivé avec l'université du Minnesota dans le développement du noyau Linux. C'est très comparable: des universitaires qui n'y comprennent rien au principe bienveillant du développement communautaire et font un truc finalement complètement néfaste à la place (possiblement sans même s'en rendre compte ni se remettre en question).
Je parle pas d'avoir des petits patchs mineurs de temps en temps par des étudiants isolés qui contribuent dans le cadre de leurs études. Genre j'ai eu y a pas si longtemps des patchs mineurs qui corrigeaient des warnings de compilation (des vrais warnings, donc une vraie correction tout de même), avec quelques erreurs par ci par là, et finalement beaucoup de revue de code sur des trucs basiques tels que le style (indentation, noms qui ne suivent pas nos conventions, etc.). Dans ces cas là, on pourrait se dire que ça nous prendrait moins de temps à juste refaire le patch nous-même plutôt que jouer le jeu des aller-retours de revue de code. Mais en même temps, c'est normal, on a tous été débutants, il faut bien commencer quelque part et c'est mieux d'être bienveillants envers ces débutants qui pourraient être les développeurs de demain, de leur montrer un peu les trucs du métier, ce que l'école ne leur apprend pas, etc. (même sur des patchs mineurs) Ces patchs là ne me dérangent pas trop. Ceci dit, je voudrais pas en recevoir par poignée en continu. Mais une fois de temps en temps, ça me fait plaisir d'aider ces étudiants.
Mais des patchs complètement inutiles, qui ne font que réimplémenter des schémas débiles d'école juste histoire de (si je comprends bien l'idée), sans rien apporter, voire carrêment des patchs qui ne corrigent rien ou rajoute du code inutile (comme dans tes exemples), c'est juste nul. Et si en plus, tous les élèves proposent sur le même dépôt (même si c'était un dépôt important avec plein de dévs; genre je doute qu'ils apprécieraient de recevoir des dizaines de tels patchs inutiles, type "exercice d'école", sur des gros projets tels que le noyau Linux par exemple), là c'est carrêment du sabotage actif de projets libres.
Franchement je suis pas pour le public shaming mais je conseillerais de la contacter d'abord (ce que tu as fait), et si elle ne comprends pas (apparemment c'est le cas), de contacter son supérieur (comme conseillé par G.bleu) pour lui demander de raisonner un peu ce prof. Pas de la virer, rien de déshonorant, mais lui faire comprendre qu'elle est censé avoir une éthique en tant qu'universitaire pour ses futurs cours/recherches. Attention d'ailleurs, l'idée n'est pas qu'elle se dise "ah bah ce mainteneur est chiant, la prochaine fois, je dirigerai mes élèves sur un autre projet" mais bien "non on ne fait pas ça, sur ce projet comme sur un autre". Tu peux d'ailleurs te permettre de citer le cas récent de l'université du Minnesota et de Linux, pour lui rappeler que si ça s'était passé sur un tel projet, ça ne serait pas juste une tape sur la main, mais que ça pourrait se terminer mal pour l'université entière.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]