Pour la première fois cette année nous sommes chez Haiku victime de ce "spam". C'est d'autant plus ridicule que notre dépôt principal n'est pas sur github, c'est le dépôt contenant notre site web qui est visé. Avec des changements du genre rajouter "an amazing project" n'importe où dans le titre d'une page.
Ça partait d'une bonne intention, pourtant, encourager les contributions à l'open source. Mais rien ne va dans la façon dont c'est mis en place:
Il est obligatoire pour participer, d'être sur Github. Le truc qui n'est même pas open source, là.
Tout github est ouvert à la participation, a priori y compris les projets qui n'ont pas une license libre.
Les gens qui ont mis leurs sources sur github reçoivent ces contributions sans savoir de quoi il s'agit. Rien n'indique que c'est pour hacktoberfest dans les pull requests.
Hacktoberfest demande aux mainteneurs de dépôts de fermer les merge requests et de leur appliquer un label pour les exclure de hacktoberfest, si ce n'est pas fait, la pull request est automatiquement validée. Donc il suffit de trouver un dépôt inactif et de faire une pull request dessus, personne ne pourra la fermer.
Les mainteneurs qui participent (contre leur gré, donc) ne sont même pas rémunérés.
Il n'y a aucun encadrement des participants pour leur expliquer comment ça fonctionne. Hacktoberfest part du principe que tout le monde sait déjà comment fonctionne Github, alors même que le but est d'encourager les nouveaux contributeurs à se lancer.
Pourtant, il y avait une solution qui marchait bien. Google, entre 2010 et 2019, organisait le Google Code-In, qui fonctionnait de la façon suivante:
Limité à un petit nombre de projets volontaires (une dizaine au départ, puis cela a augmenté petit à petit)
Des tâches spécifiques et adaptées pour des contributeurs débutants (d'autant plus que seuls les 13-17ans pouvaient participer)
Un site web dédié permettant de ne pas innonder les moyens de communication normaux des projets avec les participants au concours
Une compensation financière pour les projets participants, étant donné la charge de travail que cela représente
Il n'était pas nécessaire d'être sur github, chaque projet participant pouvait donc héberger son code comme il le souhaitait,
Un choix des gagnants, pas seulement en fonction du nombre de pull requests complétées, mais par une revue des tâches par les membres des projets participants, afin de privilégier la qualité du travail.
Voilà, ça semble pourtant pas compliqué de faire les choses correctement. Mais Google a décidé que cela ne les intéressait plus. Probablement parce que la charge de travail pour faire fonctionner tout ça était trop importante et qu'ils ont mieux à faire ailleurs. Dommage.
# Je confirme
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 10.
Pour la première fois cette année nous sommes chez Haiku victime de ce "spam". C'est d'autant plus ridicule que notre dépôt principal n'est pas sur github, c'est le dépôt contenant notre site web qui est visé. Avec des changements du genre rajouter "an amazing project" n'importe où dans le titre d'une page.
Ça partait d'une bonne intention, pourtant, encourager les contributions à l'open source. Mais rien ne va dans la façon dont c'est mis en place:
Pourtant, il y avait une solution qui marchait bien. Google, entre 2010 et 2019, organisait le Google Code-In, qui fonctionnait de la façon suivante:
Voilà, ça semble pourtant pas compliqué de faire les choses correctement. Mais Google a décidé que cela ne les intéressait plus. Probablement parce que la charge de travail pour faire fonctionner tout ça était trop importante et qu'ils ont mieux à faire ailleurs. Dommage.