Rejected GitHub Profile Achievements - Sammlung abgelehnter GitHub-Profil-Auszeichnungen

 (github.com/Flet)
1 Punkte von GN⁺ 2023-07-06 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Sammlung abgelehnter Auszeichnungen, die bei der Entwicklung der Funktion GitHub Profile Achievements entstanden sind
  • Jeder Eintrag ist eine Liste aus Auszeichnungstitel, Badge-Prototyp und Freischaltbedingung
  • Beispiel-Auszeichnungen umfassen Bedingungen wie mehr als 100 Issue-Kommentare, die nur aus +1 oder einem Daumen-hoch-Emoji bestehen, das versehentliche Committen eines geheimen API-Schlüssels in ein public repository oder das direkte Committen auf den main branch, wodurch der Build-Prozess kaputtgeht
  • Weitere Beispiele sind mehr als 1.000 offene Issues in einem eigenen public repository, das Beibehalten von über 150 Branches, die gemergt, aber nicht gelöscht wurden, oder das Reviewen und Genehmigen eines Pull Requests mit mehr als 10.000 Zeilen innerhalb von 15 Sekunden
  • Es wird ausdrücklich als Scherzprojekt mit dem Hinweis „This is a joke“ bezeichnet, und es steht dort, dass Pull Requests willkommen sind
  • Es heißt, das Projekt sei von Schweinepriester/github-profile-achievements inspiriert, und die Badges basierten auf Artworks von OpenMoji

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-06
Hacker-News-Kommentare

  • Vorschlag: „The Artist“ für Leute, die Terminal-Screenshots hochladen, statt Text zu kopieren und einzufügen, und „The Filmmaker“ für Leute, die GIFs von Terminal-Sitzungen hochladen, statt aufzuschreiben, was sie gemacht haben
    Maintainer lieben Künstler und Filmemacher wirklich sehr!

    • „The Novelist“: Leute, die in einem Issue oder Thread nur „doesn't work“ hinterlassen, völlig ohne zu schreiben, was sie versucht haben, warum sie denken, dass es nicht funktioniert, oder welche Fehlermeldung kam
      „Captain Obvious“: Leute, die ein sehr aggressives Issue eröffnen, weil sich ein Projekt nicht installieren lässt, und dann verschwinden und nie wieder antworten, nachdem der Maintainer gebeten hat zu prüfen, ob nicht wichtige Hinweise in der Dokumentation übersehen wurden
    • Beim Debugging sind Videos und GIFs wirklich gut
      Oft erfassen sie kleine Details viel besser als die Beschreibung einer Person. Ein Bug kann davon abhängen, dass etwas auf eine von mehreren Arten gemacht wurde, oder Teil des Problems ist vielleicht eine Aktion direkt vor dem Auftreten des Bugs, ohne dass der Nutzer das selbst bemerkt. Es kann auch nur unter Bedingungen wie einer bestimmten Bildschirmgröße, Terminal-Farben oder der Nutzung eines Touchscreens auftreten
      Mit einem Video fällt so etwas viel leichter auf. Es ist nicht perfekt, und am besten ist ein Video zusammen mit einer ausführlichen Beschreibung; noch besser ist es, wenn Fehler oder wichtiger Text zusätzlich eingefügt werden, damit man sie kopieren kann. Wenn ich aber eines von beidem wählen müsste, bevorzuge ich oft ein Video statt Text
      Daher mag ich in diesem Kontext „Filmmaker“ wirklich. Schickt bitte Screenshots und auch Videos
    • „Wikipedian“: macht innerhalb von 10 Minuten nach einem Push auf main einen Commit rückgängig
      „Social distancer“: reicht einen Commit ein, der nur Leerzeichen hinzufügt
      „Edgycat“: trägt ein Badge für dieses Repository bei oder schlägt eines vor. Ich arbeite gerade daran, genau dieses Badge zu bekommen
      „Duct tape“: schickt drei Commits hintereinander mit dem Text fix tests
    • Bitte schickt Terminal-Text nicht als Screenshot statt ihn zu kopieren und einzufügen
      Seltsamerweise bekomme ich von Leuten in technischen Berufen oft Screenshots von Text. Logdateien, Fehlermeldungen, alles wird als Bild geschickt. Es wirkt fast so, als würden sie Slack für ein Tool halten, mit dem man nur Bilder und Emojis senden kann
      Ich werde sicher nicht anfangen, Stichwörter aus drei Seiten Java-Exceptions abzutippen oder eine kodierte AWS-Authentifizierungsnachricht per Hand zu übertragen
    • „not helping“: hinterlässt einen Low-Effort-Kommentar, der überhaupt nicht hilft
      „Internet famous“: im Repository ist ein so gravierender Bug, dass sogar ein Artikel darüber erscheint
      Beides fiel mir ein mit Blick auf https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

  • „Unpopular opinion“: ein einzelner Kommentar in einem Issue bekommt mehr als 100 Downvotes
    „I will raise with the team“: ein Issue oder Pull Request mit mehr als 100 Upvotes bleibt über ein Jahr lang offen
    „For legal reasons“: ein Pull Request zur Behebung eines Issues wird eingereicht, aber automatisch geschlossen, weil kein CYA unterschrieben wurde
    „Business Model Blues“: Mehr als 50 % des Texts in der Datei LICENSE werden geändert
    „Back from the dead“: kommentiert ein Issue oder einen Pull Request, der seit über einem Jahr offen ist

  • Bei mehr als 1.000 offenen Issues in einem öffentlichen Repository braucht man wirklich ein Badge namens „This is fine“
    Im Vergleich zu vor zehn Jahren gibt es viel zu viele Open-Source-Projekte, und gerade im JavaScript-Bereich gibt es unglaublich viele Projekte mit unfassbar vielen offenen Bugs
    Das Problem ist, dass die Qualität dieser Bugs größtenteils niedrig wirkt. Dadurch wird selbst ein Bug, den ein erfahrener Entwickler mit viel Beitragserfahrung meldet, leicht einfach ignoriert
    Ich warte gerade bei next.js auf einen Bug, bei dem ein 404 kein 404 zurückgibt, und er ist seit Monaten offen (https://github.com/vercel/next.js/issues/51021). Ich habe keine Zeit, selbst einen Pull Request zu schreiben, aber ich habe im Lauf der Zeit unzählige Pull Requests und Bugreports verfasst und an mehreren Open-Source-Projekten mitgewirkt, also finde ich, dass ich meinen Teil getan habe
    Es ist elitär, aber es wäre gut, wenn Maintainer Bugs nach der Reputation des Meldenden sortieren könnten. Dann könnten Projekte Issues mit hoher Qualität priorisieren

    • Ich wünschte, es gäbe eine Möglichkeit, Werte auszutauschen. Zum Beispiel bezahlte Lizenzen, Support-Stufen und Dinge, die die alten Römer „ein Geschäft betreiben“ nannten. /s
      Aber nein, alles muss kostenlos sein, und dann stapeln sich überraschenderweise die offenen Issues und niemand will sich darum kümmern
    • Gemeint ist nicht „1.000 offene Issues, die ich in öffentlichen Repositories erstellt habe“, sondern 1.000 offene Issues in öffentlichen Repositories, die mir gehören
      Beides ist interessant

  • „The thief“: geht mit Open Source so um, dass Pull Requests geschlossen und die Änderungen manuell unter eigenem Namen gemergt werden
    Das passiert ziemlich oft in Projekten großer Unternehmen, und es wird wohl Compliance-Gründe geben, aber von außen wirkt es ziemlich verdächtig

    • Das ist ziemlich übel; könntest du ein bekanntes Projekt nennen, das so etwas macht?

  • Schade, dass mein persönlicher Favorit fehlt: mehr als 50 Feature-Request-Issues eröffnen, aber sonst nichts beitragen

    • Als Name für das Achievement fände ich „I'm more of an idea person“ oder „chop-chop“ passend
    • Wie wäre es mit einem Achievement wie „10 Beiträge geleistet, aber über ein Jahr lang ungeprüft liegen gelassen“?
    • „Architecture Astronaut“
    • Für normale Nutzer ist das die einzige Möglichkeit, mit dem Autor Kontakt aufzunehmen
    • „Idea guy“

  • Ich habe „patient skeleton“ zweimal bekommen
    Das wirklich Erstaunliche ist, dass einer davon nach zwei Jahren gemergt wurde. Zu diesem Pull Request gab es keinerlei Gespräche, und weil das Projekt wenig Aktivität hatte, wurde er einfach übersehen. Ich hatte schon aufgegeben und requirements.txt so angepasst, dass es auf meinen Fork zeigte
    Jemand anderes eröffnete dann ein Issue wegen genau desselben Problems, das mein alter Pull Request behebt, und als ich in diesem Issue darauf hinwies, dass der Pull Request das Problem löst, wurde er dank dieser Aktivität endlich entdeckt
    Der andere wartet immer noch

    • Der nicht realisierte Wert, der in Fork-Projekten gebunden ist, die nicht in den Mainstream gemergt wurden und nur eine wichtige Änderung enthalten, dürfte leicht in die Milliarden gehen

  • Ich schlage „YOLO“ vor: Dependabot-Warnungen länger als drei Monate ignorieren
    Man kann wohl sagen, dass auf diesem Award mein Name steht

  • Zur Klarstellung: Das sind keine von GitHub abgelehnten Achievements, sondern einfach Humor-Ideen des GitHub-unabhängigen Entwicklers „flet“

    • Glückwunsch zum Freischalten des Achievements Captain Obvious!

  • Vorschlag: Wer seinem eigenen Repository einen Stern gibt, sollte das Achievement „Copium“ bekommen

    • Ich bin mir nicht sicher, aber ich glaube, GitHub hat früher beim Erstellen eines Repositories automatisch einen Stern vergeben
    • „Narcissist“ wäre vielleicht noch passender

  • „Type O Contributor“: wenn der einzige Beitrag nur aus kleinen Rechtschreib- und Grammatikkorrekturen besteht

    • Das kann kein Achievement sein. Es könnte wieder aberkannt werden
    • Ich habe so etwas selbst auch manchmal gemacht; sind solche Beiträge also nicht willkommen?
    • „Typo-O donor“ gefällt mir