Considérez le personnel du projet Gutenberg Implémentation d’un bot obsolète pour apprivoiser le référentiel envahi Problèmes File d’attente qui compte actuellement 2 733 problèmes en suspens. Les robots hérités sont généralement utilisés pour fermer automatiquement les problèmes «hérités» et les PR en fonction d’un ensemble prédéfini de paramètres d’inactivité.

«La recommandation actuelle est de fixer notre politique à 180 jours d’inactivité. Donc, s’il n’y a pas de commentaire ou de validation sur un problème ou un PR dans les 180 jours, le bot enverra un commentaire sur le problème pour alerter l’utilisateur. Fermé pour inactivité dans 7 jours », a suggéré Marcus Kazmierczak.

Trouver le bon ton pour le message généré automatiquement est une préoccupation majeure. Si vous utilisez des bots sur un projet open source répandu, ils devraient être plus conviviaux. Un bot cool et indifférent peut involontairement détourner les contributeurs potentiels avec le mauvais type de messages. Kazmierczak a suggéré le message suivant:

Il s’agit d’un message généré automatiquement vous informant que ce problème est inactif depuis 180 jours et que c’est ce que le projet a défini comme obsolète. Cela se fermera automatiquement s’il n’y a pas de nouvelle activité dans les 7 prochains jours. Si le problème est toujours pertinent et actif, vous pouvez simplement « pousser » le commentaire dessus pour le garder ouvert ou ajouter le « ajouter ».[Status] Pas périmé ». Merci de garder notre référentiel sain!

Les participants à la discussion de la proposition ne sont pas d’accord sur la meilleure approche. Daniel Llewellyn, l’un des opposants les plus forts à l’utilisation d’un robot périmé, affirme qu’un problème de fermeture automatique envoie le mauvais message.

«Lorsque nous nous soucions des utilisateurs et qu’ils nous font confiance pour résoudre leur problème, la fermeture automatique de leur problème leur indique que nous ne le sommes pas», a déclaré Llewellyn.

«Si vous ne voulez pas résoudre un problème, il est préférable pour un humain d’expliquer pourquoi le problème ne peut pas être résolu et de le résoudre personnellement. Automatiser cela en supposant que c’est mauvais parce que personne n’a commenté depuis un moment est mauvais! « 

Joy Reynolds était d’accord avec cette évaluation, notant que la résolution des problèmes par tous les moyens peut être décourageante.

« J’ai eu des problèmes que les gens ont fermés parce qu’ils étaient périmés et ce n’est pas mieux », a déclaré Reynolds. «J’ai fermé des problèmes parce que quelqu’un a créé un nouveau problème avec la même chose. Cela perd toute l’histoire et les observateurs.

«J’ai également résolu un problème avec Launchpad car il est obsolète (et le système n’a utilisé que deux semaines comme délai). Cela ne servait à rien du tout. Cela rend les gens frustrés. « 

Kazmierczak a réitéré dans les commentaires que le bot peut être configuré pour ignorer les problèmes marqués comme des erreurs et que les problèmes et les PR peuvent être poussés pour réinitialiser l’horloge de 6 mois.

« L’objectif général de la proposition est d’améliorer le retour d’information et les réponses aux problèmes en garantissant ce qui est pertinent », a déclaré Kazmierczak.

Les questions de fermeture automatique sont la partie la plus controversée du plan. Le consensus général dans les commentaires est d’utiliser le bot pour étiqueter et tester pour fermer manuellement le problème plus tard.

« Je préférerais qu’un robot alerte les gens dans un canal lâche lorsqu’un ticket est déclaré périmé et devient de plus en plus persistant jusqu’à ce qu’un humain réponde », a déclaré Peter Wilson.

Milana Cap a suggéré d’utiliser un bot à l’auteur du ticket comme un compromis entre « être amical et attentionné envers les contributeurs tout en gardant les superviseurs en bonne formation Divi ».

Quelle que soit l’approche sur laquelle les contributeurs atterrissent, exclure les tickets signalés comme bogue est essentiel pour rendre le bot obsolète productif. Sinon, cela devient juste une façon sophistiquée de jeter un coup de pied dans la rue et de retarder l’inévitable.

Dans un article récemment publié intitulé « Github Stale Bots: une mauvaise économieLe développeur de logiciels Ben Winding a expliqué pourquoi les bots obsolètes ne fournissent pas ce que veulent les responsables. Sur la base de son expérience avec le Angulaire Winding, le bot du référentiel, a résumé l’impact de l’ancien bot sur la file d’attente des problèmes:

  1. Réduisez la métrique de Points ouverts dans Github
  2. Les problèmes en double sont devenus beaucoup plus probables
  3. Friction accrue entre les utilisateurs signalant que le problème persiste
  4. En fin de compte, la qualité du logiciel a été diminuée car les problèmes ne reflétaient pas fidèlement la réalité

Si le bot hérité du référentiel Gutenberg peut être configuré pour que les bogues ne soient pas fermés et utilisés pour maximiser l’implication humaine, il est moins susceptible de dissuader les gens de signaler des problèmes. Commentaires sur le suggestion est ouvert jusqu’au 29 janvier 2021. Kazmierczak a demandé des informations sur la mise en œuvre du bot, en particulier son seuil de temps et sa messagerie.



Source link

Recent Posts