Rejected GitHub Profile Achievements - collection de succès de profil GitHub rejetés

 (github.com/Flet)
1 points par GN⁺ 2023-07-06 | 1 commentaires | Partager sur WhatsApp
  • Une collection qui rassemble et énumère les succès rejetés lors de la création de la fonctionnalité GitHub Profile Achievements
  • Chaque élément est une liste composée du titre du succès, d’un prototype de badge et des conditions d’obtention
  • Parmi les exemples de succès : plus de 100 commentaires d’issue composés uniquement de +1 ou d’un emoji pouce levé, commit accidentel d’une clé API secrète dans un dépôt public, ou commit direct sur la branche main qui casse le processus de build
  • D’autres exemples incluent : plus de 1 000 issues ouvertes sur un dépôt public possédé, maintien de plus de 150 branches fusionnées mais non supprimées, ou revue et approbation d’une pull request de plus de 10 000 lignes en 15 secondes
  • Il est précisé qu’il s’agit d’un projet humoristique indiqué comme « This is a joke », et qu’il accepte les PR
  • Il est indiqué que le projet s’inspire de Schweinepriester/github-profile-achievements et que les badges ont été créés à partir des illustrations d’OpenMoji

À lire aussi

1 commentaires

 
GN⁺ 2023-07-06
Avis sur Hacker News

  • Proposition : « The Artist » pour les gens qui publient des captures d’écran du terminal au lieu de copier-coller le texte, « The Filmmaker » pour ceux qui mettent un GIF de session terminal au lieu d’écrire ce qu’ils ont fait
    Les mainteneurs adorent vraiment les artistes et les cinéastes !

    • « The Novelist » : la personne qui laisse seulement « doesn't work » dans une issue ou un fil, sans dire ce qu’elle a essayé, pourquoi elle pense que ça ne marche pas, ni quel est le message d’erreur
      « Captain Obvious » : la personne qui ouvre une issue très agressive pour dire que le projet ne s’installe pas, puis disparaît sans jamais répondre quand le mainteneur lui demande de vérifier si elle n’a pas raté une consigne importante pourtant bien indiquée dans la documentation
    • Pour le débogage, les vidéos et les GIF sont vraiment utiles
      Ils capturent souvent bien mieux les petits détails qu’une explication écrite. Il arrive qu’un bug dépende d’une seule façon parmi plusieurs d’effectuer une action, ou que l’utilisateur ne se rende même pas compte qu’un geste juste avant le bug fait partie du problème. Ça peut aussi n’arriver que dans certaines conditions, comme une taille d’écran précise, des couleurs de terminal particulières ou l’usage d’un écran tactile
      Avec une vidéo, c’est beaucoup plus facile à remarquer. Ce n’est pas parfait, et l’idéal reste une vidéo accompagnée d’une description détaillée, avec en plus les erreurs ou le texte important collés en clair pour pouvoir les copier. Mais s’il faut choisir, je préfère souvent une vidéo à du texte
      Donc dans ce contexte, j’aime sincèrement « Filmmaker ». Envoyez des captures d’écran, et envoyez aussi des vidéos
    • « Wikipedian » : annule un commit moins de 10 minutes après son push sur main
      « Social distancer » : soumet un commit qui n’ajoute que des espaces
      « Edgycat » : contribue ou propose un badge pour ce dépôt. Je suis justement en train d’obtenir celui-là
      « Duct tape » : envoie trois commits d’affilée contenant le texte fix tests
    • Pitié, n’envoyez pas de captures d’écran au lieu de copier-coller le texte du terminal
      Étrangement, je reçois souvent des captures d’écran de texte de la part de gens dans des métiers techniques. Fichiers de logs, messages d’erreur, tout arrive sous forme d’image. On dirait qu’ils pensent que Slack est un outil fait uniquement pour envoyer des images et des emojis
      Je n’ai aucune intention de retaper à la main des mots-clés perdus dans trois pages d’exception Java, ni un message d’authentification AWS encodé
    • « not helping » : laisse un commentaire bâclé qui n’aide en rien
      « Internet famous » : le dépôt a un bug tellement grave qu’il finit par avoir droit à un article
      Les deux m’ont fait penser à https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

  • « Unpopular opinion » : un commentaire posté sur une issue reçoit plus de 100 votes négatifs
    « I will raise with the team » : une issue ou une pull request avec plus de 100 votes positifs reste ouverte pendant plus d’un an
    « For legal reasons » : une pull request corrigeant une issue est soumise mais fermée automatiquement faute d’avoir signé le CYA
    « Business Model Blues » : plus de 50 % du texte du fichier LICENSE est modifié
    « Back from the dead » : laisse un commentaire sur une issue ou une pull request ouverte depuis plus d’un an

  • S’il y a plus de 1 000 issues ouvertes sur un dépôt public, il faut vraiment un badge « This is fine »
    Il y a bien plus de projets open source qu’il y a 10 ans, et surtout côté JavaScript, beaucoup de projets accumulent un nombre hallucinant de bugs ouverts
    Le problème, c’est que la plupart de ces bugs semblent de mauvaise qualité. Résultat, même quand un développeur expérimenté avec un bon historique de contributions ouvre un bug pour aider, il risque simplement d’être ignoré
    En ce moment, j’attends toujours qu’un bug de next.js où une 404 ne renvoie pas une 404 soit traité, et il est ouvert depuis des mois (https://github.com/vercel/next.js/issues/51021). Je n’ai pas le temps d’écrire une pull request, mais j’en ai déjà rédigé beaucoup, ainsi que quantité de rapports de bugs, et j’ai contribué à plusieurs projets open source, donc j’estime avoir fait ma part
    C’est élitiste, mais j’aimerais bien que les mainteneurs aient un moyen de trier les bugs selon la réputation du rapporteur. Les projets pourraient ainsi prioriser les issues de meilleure qualité

    • J’aimerais qu’il existe un moyen d’échanger de la valeur. Par exemple des licences payantes, des niveaux de support, ce genre de choses que les Romains de l’Antiquité appelaient « gérer une activité ». /s
      Mais non, tout doit être gratuit, et ensuite, surprise, les issues s’accumulent et plus personne ne veut les traiter
    • Ici, ça ne veut pas dire « 1 000 issues ouvertes que j’ai créées dans des dépôts publics », mais 1 000 issues ouvertes dans un dépôt public dont je suis propriétaire
      Les deux seraient intéressants

  • « The thief » : quand la façon d’aborder l’open source consiste à fermer des pull requests puis à fusionner manuellement les différences sous son propre nom
    Ça arrive assez souvent dans des projets pilotés par de grandes entreprises ; il y a sans doute des raisons de conformité, mais vu de l’extérieur, ça paraît quand même assez louche

    • C’est assez grave ; tu pourrais citer des projets connus qui font ça ?

  • Je suis déçu qu’il n’y ait pas mon préféré : ouvrir plus de 50 issues de demande de fonctionnalité sans aucune autre contribution

    • Comme nom d’achievement, « I'm more of an idea person » ou « chop-chop » irait bien
    • Que diriez-vous d’un achievement du type « 10 contributions laissées sans revue pendant plus d’un an » ?
    • « Architecture Astronaut »
    • Pour l’utilisateur ordinaire, c’est parfois le seul moyen de contacter l’auteur
    • « Idea guy »

  • J’ai obtenu « patient skeleton » deux fois
    Le plus incroyable, c’est que l’une d’elles a fini par être fusionnée après plus de 2 ans. Il n’y avait eu aucune discussion autour de cette pull request, et comme le projet était peu actif, elle était simplement passée inaperçue. J’avais abandonné et laissé mon requirements.txt pointer vers mon fork
    Quelqu’un d’autre a ensuite ouvert une issue pour le même problème que corrigeait mon ancienne pull request, et j’ai répondu dans cette issue qu’elle le résolvait ; cette activité l’a finalement remise en lumière
    L’autre est toujours en attente

    • La valeur non récupérée enfermée dans des forks de projet qui contiennent un seul changement important sans être fusionnés dans la branche principale doit facilement se chiffrer en dizaines de milliards de dollars

  • Je propose « YOLO » pour le cas où on ignore des alertes Dependabot pendant plus de 3 mois
    On peut considérer que ce prix porte mon nom

  • Pour être précis, ce ne sont pas des achievements refusés par GitHub, mais simplement des idées humoristiques créées par « flet », un développeur sans lien avec GitHub

    • Félicitations pour avoir obtenu l’achievement Captain Obvious !

  • Il a été proposé d’accorder l’achievement « Copium » quand on met une étoile à son propre dépôt

    • Je n’en suis pas certain, mais il me semble qu’autrefois GitHub mettait automatiquement une étoile quand on créait un dépôt
    • « Narcissist » serait peut-être plus approprié

  • « Type O Contributor » : quand l’unique contribution consiste en de petites corrections d’orthographe et de grammaire

    • Ça ne peut pas être un achievement, puisqu’on pourrait vous le retirer après annulation
    • J’en fais parfois moi-même ; ce genre de contribution n’est pas bienvenu ?
    • « Typo-O donor » serait bien