Salut les moules,
En mai, au moment où la vaccination fut ouverte à toute la population française et que les centres furent pris d'assaut, j'ai créé doctoshotgun, un programme basé sur woob, qui permet d'automatiser la réservation de créneau de vaccination sur Doctolib.
Partant évidement d'un besoin personnel (lassitude de faire F5 sur Doctolib, pas envie de gruger, et vitemadose s'avérant au final très peu opérant), doctoshotgun a pas mal tourné et j'ai même reçu des contributions rajoutant la gestion de la version allemande de Doctolib, pays où il semble très difficile (en tout cas avant l'été) d'obtenir un rendez-vous de vaccination.
Mais depuis un mois j'ai reçu une quantité astronomique de pull requests (>200) provenant d'étudiants d'une université canadienne, visant… à appliquer des design pattern complètement inappropriés.
Je trouve que c'est une très bonne initiative que les professeurs incitent leurs étudiants à contribuer au libre. D'ailleurs woob en avait bénéficié il y a quelques années, par le biais d'un prof français, plusieurs de ses élèves ayant amélioré la couverture de tests. Le gain pour les étudiants était réel (comprendre le code source d'un logiciel libre, en extraire ce qui peut être intéressant d'automatiser comme tests, participer au processus d'acceptation d'une pull request dans une communauté libriste, etc.) autant que pour le logiciel.
En revanche ici, je m'interroge déjà sur le choix du logiciel, Doctolib n'opérant pas outre-atlantique : les étudiants n'ont aucun usage du logiciel et aucun moyen de tester. Ensuite, sans vouloir pointer de pull request en particulier, on peut voir dans la longue liste qu'ils ne se sont pas embarrassés de trouver du sens à ce qu'ils faisaient, ni ne se sont posés la question de ce que ça peut apporter au logiciel, et la moitié du temps il y a carrément des erreurs de syntaxe.
Il en résulte qu'il s'agit plus d'une perte de temps qu'autre chose pour le mainteneur du logiciel, et que j'ai pris la résolution de ne plus du tout regarder le code et de clore les PR immédiatement. J'ai également pris le parti de contacter la prof pour lui faire part du désagrément, ce à quoi j'ai reçu une réponse un peu lunaire me disant que j'étais le seul à lui avoir fait ce genre de retours… ce qui n'a pas empêché d'avoir une nouvelle vague ces derniers jours.
Ce n'est pas sans rappeler l'histoire de Digital Ocean qui sponsorisait les contributions au FOSS et qui a provoqué un afflux massif de PR inutiles sur github.
Et vous, avez-vous déjà reçu des contributions d'étudiants qui furent pertinentes ? Sur quoi portaient-elles ? De manière générale, comment est-ce que ça peut être organisé pour que ce soit au moins neutre ou au mieux bénéfique pour les projets tout en étant formateur pour les étudiants ?
# Soyons paranos
Posté par boarf . Évalué à 10.
… ou alors, ton projet est intégré à une étude sur la capacité des projets open-source à filtrer les contributions amenant des problèmes de sécurité ?
https://linuxfr.org/users/funix/liens/l-universite-du-minnesota-bannie-du-developpement-du-noyau-linux
Bonne journée :P
# Rien à voir mais ...
Posté par littlebreizhman . Évalué à 10. Dernière modification le 17 août 2021 à 14:04.
Dans le doute j'ai du cherche pour vérifier de woob c'était bien le nouveau nom de l'ancien](https://linuxfr.org/users/nattes/journaux/weboob-renomme-en-woob-et-tambouille-wikipedienne)
Sinon, très bonne idée ton soft.
# Resume-driven development ?
Posté par damaki . Évalué à 10. Dernière modification le 17 août 2021 à 14:25.
Ça pourrait être aussi pour essayer d'embellir leur CV avec "contribution à des projets open source". C'est à la mode chez les recruteurs de regarder vaguement le Github des candidats pour voir s'ils contribuent à des projets, peu importe lesquels. C'est supposé être un moyen d'évaluer la passion des candidats pour le développement logiciel.
[^] # Re: Resume-driven development ?
Posté par Glandos . Évalué à 10.
C'est vrai que sur le profil général GitHub, on ne voit pas bien quelles sont les contributions qui ont réellement été intégrées. C'est toujours tout vert, tout beau.
[^] # Re: Resume-driven development ?
Posté par Lutin . Évalué à 6.
Les pulls request sur la page github du kernel sont assez édifiantes sur le sujet.
[^] # Re: Resume-driven development ?
Posté par farib . Évalué à 7.
en gros, c'est voir si le candidat passe son temps libre a coder en plus de son boulot
je pense que c'est le critère le plus faux à évaluer (mais il doit y avoir un effet mode)
95% des bons devs/admins ne doivent pas avoir de github public…
[^] # Re: Resume-driven development ?
Posté par alkino . Évalué à 3.
Ou alors le bon dév a déniché un job où il produit 80% de code open-source ;)
[^] # Re: Resume-driven development ?
Posté par vv222 (site web personnel) . Évalué à 3.
C’est mon cas, le gros de mon job est sur du développement de code libre. Et pour ne rien arranger, je passe la majorité de mon temps libre à développer d’autre code libre.
Je vous laisse constater la manière dont c’est représenté sur mon profil GitHub ;)
[^] # Re: Resume-driven development ?
Posté par moules . Évalué à 3.
Elle doit être vachement bien ta boîte, c'est quoi ? Elle recrute ? ;)
[^] # Re: Resume-driven development ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 20 août 2021 à 11:53.
Ce que cherchait à montrer vv222, c'est que github n'est pas le centre du monde, et en particulier représente que dalle dans le monde du logiciel libre. La plupart des gros projets n'y sont pas (bien sûr, ils ont souvent des miroirs mais c'est en général juste histoire de rediriger les gens qui croient que tout est forcément sur github justement).
Je passe aussi une majeure partie de mon temps à coder, uniquement du libre, professionnellement comme personnellement, et mon profil github fait peine à voir (si jamais un employeur essayait de m'engager sur ça, je saurais surtout que je ne veux pas travailler pour eux car ça démontrerait qu'ils pigent que dalle à comment tout cela marche). De toutes façons, github est même pas fichu d'associer mes commits à mon compte, même lorsque je les ai poussé sur un projet hébergé sur github avec ma clé à moi (sur ces projets, même lorsque sur certains j'ai les droits en écriture et ai des dizaines de commits, parfois parmi les plus gros contributeurs de l'historique du projet, github ne me met pas dans la liste des contributeurs de l'onglet associé), puis que je les ai contribué au projet par un pull request par l'interface web. Je pense que la plateforme regarde uniquement l'email et comme je lui ai donné un email poubelle (exprès, je ne veux pas donner un email principal à ce type de plateforme)…
Sincèrement github, c'est une broutille dans l'écosystème libre. Énormément des gens y vont et passent leur temps dessus, sans se rendre compte qu'ils font des ronds autour du même arbre sans voir la forêt derrière. C'est triste sincèrement.
P.S.: mais de façon amusante, ces gens agglutinés autour de ce même arbre, quand ils rencontrent quelqu'un qui gambade librement dans la forêt entière vont lui faire la morale: "c'est nul, tu veux pas venir t'agglutiner avec nous plutôt? Moi j'ai pas envie d'aller voir les autres arbres, mais des fois c'est obligé si je veux rencontrer d'autres groupes de gens. Franchement si on était tous autour du même arbre, on aurait pas ce problème!" 🙄
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Resume-driven development ?
Posté par barmic 🦦 . Évalué à -5.
Je… Euh… 🙄
Ensuite c'est tellement une broutille que tout le monde a un compte dessus et tous les projets veulent leur visibilité dessus ? Parce que c'est soit le centre du monde soit une broutille ? Il n'y a aucune forme possible d'entre 2 ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Resume-driven development ?
Posté par vv222 (site web personnel) . Évalué à 7.
Franchement, pour avoir testé, je regrette l’expérience GitHub. J’ai gardé un miroir de la plupart de mes dépôts sur GitHub pendant des années, mais je pense que je n’ai pas eu plus de 1~2 % des contributions qui sont passées par ce biais.
Autant pour le légendaire développeur qui ne voudrait pas créer un compte sur notre forge dédiée mais aurait été prêt à contribuer via GitHub, je n’en ai toujours pas vu l’ombre.
[^] # Re: Resume-driven development ?
Posté par barmic 🦦 . Évalué à 8.
C'est dommage tous ses projets qui s'emmerdent à maintenir leur présence sur github si seulement quelqu'un leur disait qu'ils ne sont pas obligé.
Plus sérieusement, ce n'est pas une question de savoir si github est bien ou pas, mais c'est un phénomène suffisamment important pour que :
Ça pose pleins de problèmes et pour moi qui préfère redmine et mercurial, je suis pas entrain d'encenser github. Juste reconnaitre que si github n'est clairement pas le centre du monde, il est très loin d'être une broutille.
est-ce que le principe des miroirs donne généralement un succès ? est-ce que les miroirs sont bien fait ? etc ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Resume-driven development ?
Posté par gouttegd (site web personnel) . Évalué à 10.
Dommage que le deuxième point annule presque complètement le premier…
La plupart des gens avec qui je travaille aujourd’hui en bioinformatique savent bien utiliser GitHub mais certainement pas git.
Récemment j’ai expliqué à quelqu’un comment on pouvait étudier localement les conséquences d’une pull request en faisant un check out de la branche correspondante dans sa copie de travail. Ça faisait des années que le type utilisait GitHub, il n’avait pas la moindre idée qu’on pouvait faire ça. Pour lui tout ce qu’on pouvait faire avec une pull request c’était étudier les diffs tels qu’affichés sur GitHub, puis cliquer sur le bouton « merge » si on est satisfait.
Autre truc rigolo : globalement, les pull requests ont remplacé les commits comme unité de base du développement. Les commits ne servent plus à rien, ils n’ont plus aucune logique, plus aucune cohérence, et les messages associés sont complètement non-informatifs (« more work on foo.py », « update makefile », « last changes », voire même simplement « WIP » — work in progress). C’est désormais dans les messages associés aux pull requests que les développeurs expliquent ce qu’ils font, c’est là qu’il faut aller chercher si on veut comprendre l’évolution d’un projet.
Entre autres conséquences, ça produit des pull requests de plus en plus difficiles à évaluer, vu qu’on ne peut plus étudier les changements commits par commits, il faut nécessairement étudier le diff sur la pull request complète. Évidemment, c’est beaucoup plus ardu (surtout quand, comme au-dessus, on ne sait pas faire un check out local). Et ça donne lieu à des fils Twitter lunaires comme celui-ci, où certaines réponses me donnent envie de me taper la tête contre le mur en hurlant « mais apprenez à utiliser git bordel ! »
/rant
[^] # Re: Resume-driven development ?
Posté par vv222 (site web personnel) . Évalué à 7.
Ici j’ai essayé de garder le meilleur des deux mondes pour les développements sur lesquels je bosse.
Bien sûr je garde les messages de commit explicites, si besoin détaillés dans le corps du message (les devs qui ne savent pas qu’un message de commit peut faire plus d’une ligne me hérissent le poil). Et pour les discussions éventuelles avec les autres devs, ou les informations concernant l’ensemble de la branche sur laquelle je bosse, j’utilise souvent l’espace de discussion fourni par les forges pour les pull/merge requests.
Une fois la branche prête à être fusionnée, j’utilise le message de commit du commit de fusion pour résumer toutes les discussions et précisions qui ont pu être données dans la page de discussion sur la forge. On peut voir un exemple de ce genre de commit de fusion ici : Library update: New function used to get the context-specific value of a given variable
Au final ce n’est pas tant avec la pull/merge request que je bosse mais avec la branche. D’ailleurs je n’utilise jamais les espaces des forges pour autre chose que de l’information ou de la discussion, toutes les actions sont réalisées depuis mon dépôt local. Dépôt qui n’a aucune notion de pull/merge request.
Je sais qu’écrire du code dans un navigateur Web est à la mode (*tousse*electron*tousse*) mais pour ma part il est hors de question que je me mette à ces pratiques de développement, que je ne réussirai pas à qualifier en restant poli.
[^] # Re: Resume-driven development ?
Posté par barmic 🦦 . Évalué à 2.
Ton reproche ne s'adresse pas au github flow.
Des gens qui écrivent de mauvais messages de commits ça existait déjà avant que git existe, reprocher ça a github me semble très osé.
Tu reproche de ne pas savoir correctement utiliser les outils à disposition pour faire des revues. Le github flow est le seul flow connu est un peu populaire (donc médiatisé, connu, repris, décris, documenté largement,…) qui intègre la notion de revue. Les forges avant github étaient rare à avoir un outil de revue intégré.1
git est un outil mal compris, mais je ne suis absolument pas certain que laisser les gens utiliser git sans leur donner un cadre aurait donné de meilleurs résultats. Est-ce que le github flow est le meilleur cadre ? J'en doute, mais aucun autre n'a pu avoir la même popularité.
Moi tu vois j'y vois un problème2 bien plus vieux que git et qui est une pratique largement répandue même hors github : beaucoup trop de choses dans une branche. Pour moi et dans l'équipe où je suis on préfère merger rapidement, faire ce que l'on appel de l'intégration continue (pas dans le sens utiliser un outil d'intégration continue, mais intégrer de manière continue notre code). Si vous passer votre temps à refactorer des pans important du code et/ou modifier de grandes partie sans pouvoir merger sans backtrack, c'est dommage (amha il faut se poser des questions), mais ce n'est sans doute pas fait pour vous, par contre si vous pouvez le mettre en place ça permet de faire des revues infiniment plus petites tout en simplifiant beaucoup le travail collaboratif.
D'ailleurs tes critiques sont toujours valides sur gitlab qui est l'outil utilisé par ceux qui critique github dans ce thread… ↩
Attention je ne dis pas que c'est un problème en soit et que tout le monde devrait faire d'une façon ou d'une autre, mais il le twitt présente ce qui pour son auteur est un problème. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Resume-driven development ?
Posté par Anonyme . Évalué à 5.
À mon avis (qui vaut ce qu’il vaut) Git flow est bien plus connu que GitHub flow.
Les gens qui utilisent GitHub flow, le font sans le savoir parce que c’est ce que la plateforme les force à faire.
[^] # Re: Resume-driven development ?
Posté par vv222 (site web personnel) . Évalué à 2. Dernière modification le 22 août 2021 à 12:36.
Pour ceux qui comme moi n’ont aucune idée de ce qu’est le GitHub flow : https://githubflow.github.io/
Je ne sais pas non plus ce que désigne le Git flow, mais pour celui-ci je n’ai pas trouvé de présentation "officielle". (bon, je n’ai pas cherché longtemps non plus)
My bad, j’avais loupé la présentation proposée par barmic un peu plus haut.
[^] # Re: Resume-driven development ?
Posté par Jérôme FIX (site web personnel) . Évalué à 1.
Et pour le second je pense qu'on parle de :
https://git-flow.readthedocs.io/fr/latest/presentation.html
[^] # Re: Resume-driven development ?
Posté par vv222 (site web personnel) . Évalué à 5.
Elle recrute, mais de manière vraiment louche : si tu as plusieurs années d’expérience en développement de logiciel libre, ils semblent se moquer royalement de l’absence d’études, de diplôme, et même d’expérience dans le langage utilisé…
En plus ils n’ont même pas l’air de se fier aux profils GitHub des candidats !
[^] # [hs] formation selon poste
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Du coup, je suis allé regardé pour le poste de dev python et dans le blah-blah je lis, pour le descriptif du poste :
Sinon pour celui de devops manager il faut
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Digital Ocean, si c'est pas du spam, c'est des attaques
Posté par GG (site web personnel) . Évalué à 3.
Pendant très longtemps, j'ai banni les ranges d'IP de Digital Ocean pour réduire le bruit des attaques dans les logs de mes serveurs. Et, malheureusement, ils ont plusieurs ranges.
Cela n'a probablement rien à voir, mais ça ne m'étonne pas.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Objectifs d'employés
Posté par Fabimaru (site web personnel) . Évalué à 10.
Selon ces commentaires, dans certaines compagnies (Huawei, Samsung…) les employés sont récompensés si leurs patchs sont acceptés dans le noyau Linux (parce qu'être dans les plus gros contributeurs améliore l'image de l'entreprise), donc ils proposent des modifications triviales.
[^] # Re: Objectifs d'employés
Posté par GG (site web personnel) . Évalué à 10.
Des modifications triviales, pourquoi pas.
Mais lorsque ce sont des modifications qui ne sont pas des améliorations pour le code ou le logiciel, c'est effectivement un problème.
C'est un tournant, participer au code de logiciels libres devient important, il faut s'y adapter.
C'est un peu comme les emails il y a longtemps, le spam n'existait pas, puis plus tard…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Objectifs d'employés
Posté par freem . Évalué à 4.
Donc, pour vivre libres, vivons sans communautés trop faciles d'accès, à défaut de cachées?
De plus en plus, je vois l'amalgame "logiciel libre == communauté qui contribue ensemble sur un projet unique" mais est-ce vraiment la réalité? Et si oui, est-ce que ça doit être le cas de tous les projets libres? Et dans tous les cas, comment filtrer les contributions néfastes, qui sont évidentes dès que ça buzz ou prend de l'ampleur (l'humain est ainsi fait qu'il y aura toujours des ordures prêtes à saccager le travail des autres pour leur profit unique)?
# Prendre le contre pied
Posté par liberforce (site web personnel) . Évalué à 0.
Pourquoi ne pas activer le bugtracker ? Tu pourrais suivre tes propres idées d'amélioration, et avoir d'autres bugs avec un tag spécifique pour les contributions faciles. En son absence, un étudiant peut se dire "tiens, je vais envoyer ça, on verra si ça rentre". Si tu as des listes de contributions possibles, ou acceptes des demandes d'évolution, cela donne une ligne directrice, leur évitant de s'éparpiller. Certes, tu peux te retrouver à fermer des bugs plutôt que des pull requests (voire en plus des pull requests), c'est un risque. Tu peux aussi laisser juste un bug ouvert avec un titre explicite pour dire que le logiciel est complet et n'a pas besoin d'évoluer et n'a pas de bugs (ce qui est à mon avis faux et sonne un peu pédant, mais a le mérite d'être clair).
Le bugtracker c'est le premier réflexe je pense quand tu t'intéresses à l'amélioration d'un logiciel. Il t'aidera à envoyer bouler ce qui sont venus pour la gloire et trouver l'aiguille dans la meule de foin : la personne qui aura un vrai besoin, ou une vraie idée. Tu me diras que tu as déjà ça via les PR, et tu as peut être raison, mais à ta place, je tenterais l'expérience pour voir si cela améliore les choses. Je ne pense pas que les PR ont pour vocation de servir de point d'entrée.
Au pire, ajoute un CONTRIBUTING.md, ou une section de contribution au README.md, mais je ne pense pas que les étudiants en question le liront, j'ai un peu plus d'espoir du côté du bugtracker… Un peu plus de chances avec une table des matières (genre générée avec
md-toc) pour voir en un clin d'œil qu'il y a une section de contribution sans avoir à faire défiler tout le fichier.[^] # Re: Prendre le contre pied
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Pour moi, le suivi de bugs est bien activé sur ce projet.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Prendre le contre pied
Posté par liberforce (site web personnel) . Évalué à 5.
Intéressant. Hier en regardant sur un autre ordinateur j'ai vu autre chose avec des noms d'onglets que je ne connaissais pas. Sinon je n'aurais pas perdu mon temps à écrire de commentaire. Je suis d'autant plsu atterré du comportement des étudiants en question qui envoient des PR qui ne correspondent à aucun besoin réel…
# Il faut prévenir le prof... à chaque fois
Posté par G.bleu (site web personnel) . Évalué à 10.
Si j'en crois cette PR, on a le nom du professeur. De là on obtient très rapidement son adresse mail et son compte Twitter.
À partir de ça perso j'enverrai un mail/tweet à chaque fois qu'une PR abscons est ouverte, si la personne est de bonne fois elle devra bien se rendre à l'évidence que tu subis du harcèlement de la part de ses élèves. Si elle n'est pas de bonne fois, elle te bloquera et là il te reste à faire de même à un responsable de son département (ça se trouve bien sur le site).
Et perso je suis extrêmement curieux de savoir quel exercice a été donnée aux élèves pour en arrivé à un tel résultat, ça vaudrait de poser des questions à ce sujet sur les PRs (si elles ont été réalisées par des comptes d'élèves et non par des comptes de bots ça peut marcher ).
Je parierai sur un exercice consistant à automatiser la création d'une PR:
- ça semble en rapport avec son centre d'intérêt de recherche "mining software repositories for open innovation in two-sided markets."
- la seule activité récente de son github était en rapport avec python et le covid et elle est sans doute francophone (elle était prof y Montréal). Du coup c'est possible qu'elle soit tombé sur ton repo par hasard et l'ai utilisé comme exemple de ce qu'elle attendait de ses élève, et beaucoup l'ont pris au pied de la lettre…
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par moules . Évalué à 10.
Je dois avouer que je ne sais pas ce que veut dire « mining software repositories for open innovation in two-sided markets. ».
Voici ce qu'elle m'avait écrit :
Concernant « good code design » on a pas la même notion.
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par Storm . Évalué à 8.
Puis je ne vois pas l'intérêt de lancer X étudiants sur le même "petit" projet…
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par vv222 (site web personnel) . Évalué à 8.
C’est bien la première fois que je me dis ça, mais je suis prêt à l’admettre quand c’est aussi évident : certaines personnes ne sont vraiment pas faites pour bosser sur du code.
Bon, c’est bien sûr en admettant qu’il s’agit de contributions de bonne foi, ce que j’ai vraiment du mal à croire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par Jehan (site web personnel, Mastodon) . É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 ]
[^] # Re: Il faut prévenir le prof... à chaque fois
Posté par gouttegd (site web personnel) . Évalué à 10.
Cela suppose que son supérieur comprenne mieux le problème qu’elle. On peut toujours essayer mais ça me semble optimiste.
J’imagine le point de vue du responsable de département : « Voyons, d’un côté j’ai un illustre inconnu qui me parle d’un problème avec des “poules requests” sur son “projet libre”, de l’autre j’ai un de mes chercheurs qui vient de décrocher un financement de deux millions de dollars qui me dit qu’elle ne voit pas de problème et que ce doit juste être un chieur de service. Hum, qui croire ? »
# Le temps de mainteneur est la ressource la plus limitée de la plupart des projets
Posté par Xavier Vello (site web personnel) . Évalué à 10.
Tu mentionnes cette sombre connerie de Spamtoberfest dans ton journal, sache que suite à la grogne de nombreux projets, github a implémenté les Temporary interaction limits. Ces réglages permettent de bloquer les contributions (issues, PR, commentaires) d'utilisateurs n'ayant pas déjà contribué au repo (ou n'étant pas membre du repo). Tu pourras l'activer si cela arrive à nouveau au prochain semestre.
Comme PostgreSQL, la plupart des projets sont limités par le temps de reviewer / mainteneur, pas le temps de développeur, donc le sujet des contributeurs inexpérimentés est difficile : leurs contributions peuvent faire perdre plus de temps qu'elles n'en font gagner, sur des sujets pas forcément prioritaires pour le projet.
Pour canaliser les nouveaux contributeurs, les projets KDE publient une liste de junior jobs. Si un nouveau contributeur se manifeste sur un de ces jobs, il peut s'attendre à avoir de l'aide (design, review et merge), car un contributeur existant a déjà manifesté son intérêt pour le sujet. En tant que nouveau contributeur, c'est un tag similaire que je chercherai dans le bug tracker, pour m'acclimater avec la base de code avant de proposer de "gros" changements. C'est aussi ce que j'ai vu dans plusieurs société (des tâches libellées "ramp-up" qu'on donne aux nouveaux employés). Le Summer of Code est un autre bon exemple pour structurer les interactions entre étudiants et projets.
# Ah tout de même…
Posté par Thomas Lecavelier . Évalué à 7.
Faut avoir les nerfs bien accrochés:
https://github.com/rbignon/doctoshotgun/pulls?q=is%3Apr+author%3A3021104750
Le gonze réussi tout de même à ouvrir 5 PR avec… des fichiers vides. Et il n'explique en rien ses intentions.
À ce niveau c'est du vandalisme.
[^] # Re: Ah tout de même…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Le gars est un bot qui va véroler ton projet avec des fichiers invisibles 😅
Je soupçonne un mésusage de
gitassocié à quelque automatisation (genre réécriture de commits ou fusion avec un collège, mais fusion forcée même si pas de changement et poule requête déclenché par l'environnement de développement par exemple ?) En tout cas on est dans le cadre où des gens font mumuse directement en prod parce-que des profs responsables ont donné une mitraillette à des gosses dans la cour de récré…“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ah tout de même…
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 08 septembre 2021 à 20:24.
Qui plus est, ces PRs peuvent faire référence à des ressources tierces qui semblent appartenir à la communauté de ceux qui font ces PRs (et probablement accessible par leur prof) mais probablement pas au développeur, par exemple ici :
Selon la page wikipédia Moodle :
Ça ressemble vachement à un TP qui déborde sur le monde réel. Il semble que le texte du PR soit adressé au prof, comme démonstration, pas au développeur.
ce commentaire est sous licence cc by 4 et précédentes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.