Ich bin da wirklich zwiegespalten. Einerseits finde ich es großartig. Wer hat nicht schon einmal ein Backlog-Refinement-Meeting erlebt, bei dem man sich von oben nach unten durch die Liste kratzt, obwohl man weiß, dass man nie bis zum Ende kommt? Dieses Gefühl ist eindeutig elend.
Andererseits sind die Issues ja nicht verschwunden, sie haben nur ein anderes Label bekommen. Und wenn es am Ende nur um Tags und Ordnung geht, könnte man es dann nicht einfach laufen lassen, statt dieses Pseudo-Ideal einer perfekt leeren Issue-Liste kontrollieren zu wollen? Es gibt schließlich sicher auch Vorteile, solche Notizen sichtbar liegen zu lassen. Es fühlt sich ein bisschen an wie beim großen Aufräumen: Man hat entschieden, etwas wegzuwerfen, aber das Unterbewusstsein sagt, man solle es behalten, weil man es später vielleicht noch brauchen könnte.
Insgesamt bin ich trotzdem eher dafür. Zumindest dürfte es ein Gefühl der Befreiung geben und neue Energie für neue Issues.
Um noch etwas Kontext zu ergänzen: Der Autor arbeitet an einer kompletten Neufassung.
Es wäre vermutlich sauberer gewesen, erst die neu geschriebene Version zu veröffentlichen und dann die bestehenden Issues als deprecated zu schließen. Issues im Rewrite-Branch hätte man per Versions-Tag trennen können. Wenn man sie schließt, bevor die neue Version fertig ist, könnten Beitragende neue Issues zur bestehenden Version öffnen, ohne zu wissen, dass diese nicht mehr unterstützt wird.
Trotzdem ist es nicht so, dass die Issues ignoriert und Probleme in der Codebasis liegen gelassen werden; das gesamte Projekt wird gerade neu aufgesetzt. https://twitter.com/jdalton/status/1571863497969119238
Aus Nutzersicht ist so ein „Aufräumen“ problematisch, wenn es bedeutet, Issues zu schließen. Wenn ein Problem im Produkt weiterhin existiert, sollte es schon aus Dokumentationsgründen offen bleiben – und damit andere Nutzer mit demselben Problem es leicht finden und ergänzen können.
Ich finde es ehrlicher, wenn ein Projekt die Existenz der Issues anerkennt und sie offen lässt. Wenn Entwickler die Anzahl der Issues stört, wäre ein Filter besser, der alte, unwichtige Issues ausblendet.
Ich bin auch zwiegespalten. Einerseits greife ich jedes Mal wieder zu lodash, wenn ich zu JavaScript-Arbeit zurückkehre. Andererseits denke ich, dass etwas weniger als die Hälfte dieser Bibliothek bitte in der Standardbibliothek enthalten sein sollte.
Ist so etwas nicht genau die Art Aufgabe, in der große Sprachmodelle gut sein sollten? Ich meine Ticket-Zusammenfassungen.
Deshalb pflegt Basecamp kein Backlog. Was wichtig ist, kommt wieder hoch.
jwz hat dazu gesagt:
Ich glaube, das ist die häufigste Art, wie Bugs geschlossen werden, die ich bei Open-Source-Softwareprojekten gemeldet habe. Man meldet einen Bug, dann wird er ein Jahr lang, manchmal zwei Jahre lang, nicht gelesen, und eines Tages wird das Modul von Grund auf neu geschrieben. Und der neue Maintainer hat keine Lust zu prüfen, ob die neue Version die bekannten Probleme der alten Version tatsächlich behebt.
Bei Projekten mit wenigen Maintainern oder bei Ein-Personen-Projekten erscheint es mir sinnvoller, wenn die Bug-Reporter jeweils 10 bis 15 Minuten investieren, um zu prüfen, ob das Problem noch besteht, statt dass ein einzelner Maintainer Tage bis Wochen mit der Verifikation verbringt.
Besonders bei schwer reproduzierbaren oder komplexen Bugs ist es von vornherein unklar, ob der Maintainer sie in seiner eigenen Umgebung überhaupt reproduzieren kann; der Reporter ist wahrscheinlich eher daran gewöhnt, diesen Bug zu beobachten.
Wenn es ein größeres Team gibt oder es sich um ein Begleitprojekt zu einem kommerziellen Dienst handelt, kann sich dieses Gleichgewicht etwas verschieben.
Was man bei vielen freien/Open-Source-Projekten sieht: Es gibt sehr wenige Leute, die selbst mit anpacken wollen, aber gleichzeitig investieren sie viel Zeit darin, mitzuteilen, wie unverzichtbar das Projekt für sie ist, Forderungen zu stellen und viele Vorschläge zu machen.
Die meisten erstellen neue Issues, um Wunschlisten kundzutun, oder hinterlassen sehr vage Bug Reports. Einige davon liefern zwar ordentliche Bug Reports, aber die Bereitschaft zur Mitarbeit endet meist dort.
Persönlich bin ich nicht der Typ für Projekt-Maintenance, weil ich nicht die Bereitschaft habe, die meisten der häufig zu sehenden Kommentare diplomatisch zu behandeln.
Trotzdem versuche ich bei Issues, die ich melde, immer meinen Teil beizutragen: die Ursache nachverfolgen und, wenn möglich, einen PR mit einem Fix einreichen.
Davon gibt es auch eine Variante: Für eine Major-Version wird ein Issue gemeldet, dann erscheint eine neue Major-Version, und obwohl es keine Neufassung, sondern nur eine schrittweise Änderung ist, werden alle Issues zu früheren Releases geschlossen, weil das Problem ja möglicherweise nicht mehr besteht.
Man kann einen PR erstellen, der Tests enthält, die bestehen sollten, derzeit aber als übersprungen markiert sind. Dann gibt es beim Neuaufbau einen einfachen Weg, den Fortschritt zu prüfen und zu sehen, ob es Verbesserungen gibt.
Wenn einem ein Problem wirklich wichtig ist, sollte man einen Test hinzufügen.
Auch Sicherheitsfunde werden manchmal so behandelt.
Bei Closed-Source-Softwareprojekten ist meine Erfahrung dieselbe.
John-David Dalton, der Autor von lodash, hat [letztes Jahr Folgendes][1] geschrieben:
Beim lodash-Rewrite erkläre ich den technischen Schuldenbankrott. Neustart von Grund auf mit TypeScript und Rollup. Keine FP-Wrapper. Diese Mode ist vorbei. Mein Beileid an die Kollegen der Person, die diesen Schmerz in die Codebasis gebracht hat. Absolut nicht team- oder menschenfreundlich.
Ich weiß nicht, ob es zu 100 % genau so läuft, aber es sieht ziemlich nah dran aus.
[1]: https://twitter.com/jdalton/status/1571863497969119238
„Diese Mode ist vorbei. Mein Beileid an die Kollegen der Person, die diesen Schmerz in die Codebasis gebracht hat. Absolut nicht team- oder menschenfreundlich“ – war der ursprüngliche Autor nicht er selbst?
Es klingt, als hätte jemand anderes die Komplexität hinzugefügt, die er kritisiert. Wenn er sie selbst eingeführt hat, klingt es weniger nach Rückblick oder Lernerfahrung, sondern eher danach, dass man das Projekt einem Trend folgend entwickelt hat und jetzt, da der Trend vorbei ist, zum nächsten Ding weiterzieht.
Was war dieser FP-Wrapper, und was für ein Trend war das?
Ich kenne mich mit den JavaScript-Themen nicht gut aus: Was ist in diesem Kontext das Problem mit funktionaler Programmierung?
Gut gemacht.
Schon bei ein paar PRs ganz vorne in der Liste sieht man solche Dinge:
ein einzelnes Wort in einem Kommentar ergänzen, eine Konfigurationsdatei zur Bewerbung eines Entwicklerdienstes hinzufügen, var durch let ersetzen, das gut etablierte Verhalten einer Kernfunktion ändern, Semikolons entfernen usw.
Die meisten wurden wohl mit der guten Absicht eröffnet, die Library zu verbessern, aber irgendwann wird das für Maintainer einfach zu Spam – oder schlimmer noch: zu einer Last, die umso mehr Schuldgefühle erzeugt, je weniger man sich darum kümmern kann.
So wie Prominente Bodyguards engagieren und First Class oder Privatjet fliegen, um der ständigen Aufmerksamkeit zu entgehen und ihre psychische Gesundheit zu schützen, frage ich mich, welche Maßnahmen für bekannte Open-Source-Projekte möglich wären.
Persönlich mag ich als Open-Source-Maintainer PRs zu Tippfehlern, Formulierungen und automatisierten Refactorings am liebsten. Sie kosten kaum Review-Aufwand, daher merge ich sie fast immer sehr schnell.
Am längsten dauern PRs, die riesige Features implementieren. Weil sie viel Review und Diskussion brauchen, schiebe ich es auf, sie mir genauer anzusehen.
Eine Zeit lang gab es den Trend, bei bekannten Projekten triviale PRs zu eröffnen. Ich sehe das als Versuch, den Lebenslauf zu füllen.
Es gab einen bestimmten GitHub-Nutzer, der wiederholt PRs in mehreren JavaScript-Projekten eingereicht hat, die nur var durch let ersetzt haben.
Fühlte sich an wie das Auffüllen des GitHub-Profils.
Wow.
Ich hatte angefangen, mich dafür zu interessieren, meine Pakete auf Bun umzustellen, habe aber gezögert, weil ich mir Sorgen um die Kompatibilität machte und ob Bun wirklich langfristig überlebt. An „Modern Yarn“ hatte ich mir auch schon leicht die Finger verbrannt. Aber wenn ich sehe, dass lodash wechselt, möchte ich das jetzt ernsthafter prüfen.
Das ist tatsächlich eine große Nachricht. Besonders wenn man bedenkt, dass es trotz des jüngsten v1.0-Releases unter Windows Performance-Probleme gibt.
Ich versuche zu vermeiden, Open-Source-Entwicklern vorzuschreiben, wie sie ihre Projekte führen sollen. Ich bin selbst Open-Source-Entwickler, und es nervt mich, wenn andere das bei mir tun.
Aber wenn ich ein Nutzer gewesen wäre, der einiges an Zeit investiert hat, um Issues zu schreiben und bei der Problemlösung zu helfen, oder jemand, der an einem Fix oder einem neuen Feature gearbeitet und einen PR eingereicht hat, wäre ich jetzt ziemlich demotiviert.
Die meisten Nutzer investieren aber nur sehr wenig Zeit in das Schreiben von Issues. Die meisten Bugreports sind miserabel.
Die Issues wurden geschlossen, nicht gelöscht. Wenn sie noch relevant sind, kann man sie später vermutlich erneut anfragen.
Issue-Bankrott ist real. Aus persönlicher Erfahrung gesagt: Irgendwann wird Open-Source-Maintenance schwer mit dem Leben in der realen Welt vereinbar.
Die Arbeit ist unbezahlt und oft undankbar. Natürlich nicht immer. Das Problem ist komplex und konkurriert mit realen Verpflichtungen wie Arbeit, Familie und Erholung. Menschen sind schnell gereizt und wollen regelmäßig streiten oder verlangen, dass man für sie die Dokumentation liest. Wenn Open Source bekannt ist, kommt auch enorme Verantwortung dazu.
Ich rechne damit, dass es im Open-Source-Ökosystem zu einem großen Zusammenbruch kommen wird, wenn die Leute, die Projekte leiten, „reicht“ sagen und sich wichtigeren Dingen zuwenden.
Das verstehe ich. Inzwischen denke ich sogar, dass nichttriviale persönliche Projekte eher Sucht oder Selbstverletzung sind als echte Projekte.
Allerdings ist das Open-Source-Ökosystem wahnsinnig ineffizient. Es gibt lodash, underscore und unzählige andere Libraries, aber sie müssen nicht alle existieren. Es gibt auch viele Libraries, die nur eine einzige Sache tun, und meistens sind sie eine Teilmenge solcher Libraries.
Die meisten dieser Dinge werden zusammen mit Minifiern und Tree Shaking verwendet, und ungenutzte Funktionen werden entfernt. Selbst schwere Libraries lassen sich leicht optimieren und bestehen größtenteils aus getrennten Teilen, sodass man nicht unbedingt leichte Libraries braucht, und der Entwicklungsaufwand steigt im Großen und Ganzen linear.
Wenn Programmierer Eleganz und Einfachheit nicht über alles lieben und nicht ständig alles neu schreiben wollten, um es noch ein bisschen besser zu machen, gäbe es meiner Meinung nach genug Arbeitskraft für Open Source, selbst wenn alle nur ein Viertel der heutigen Zeit investieren würden.
Lodash ist eine hervorragende Library. In fast jedem Projekt, an dem ich arbeite, verwende ich es zumindest ein wenig.
Aber je besser JavaScript wird, desto weniger Lodash nutze ich. Jedes Mal, wenn ich es verwenden will, prüfe ich, ob es für das, was ich vorhabe, eine eingebaute Funktion gibt. Es kommt auch ziemlich oft vor, dass ich in PRs mit einem Link kommentiere: „Dafür braucht man kein Lodash.“
Trotzdem hoffe ich, dass das kein Signal dafür ist, dass sich das Projekt zurückzieht.
Es ist definitiv praktisch, aber wenn es darauf ankommt, würde ich für Utilities wohl eher eine selbst gebaute Version bevorzugen.
Ich habe seit acht Jahren weder lodash noch underscore.js verwendet. Ich weiß nicht genau, was sich nicht einfach mit map, filter, find usw. erledigen ließe.
Ein Issue-Tracker überlagert zwei Verwendungszwecke. Der eine ist eine Möglichkeit für Maintainer, nachzuverfolgen, was sie zu tun haben; der andere ist eine Möglichkeit für die breitere Community und die Nutzer, Defekte in der Software nachzuverfolgen.
Eine Erklärung von „Issue-Bankrott“ ergibt für den ersten Zweck Sinn, löscht beim zweiten aber wertvolle Informationen über Issues, die in der aktuellen Version existieren.
1 Kommentare
Meinungen auf Hacker News
Ich bin da wirklich zwiegespalten. Einerseits finde ich es großartig. Wer hat nicht schon einmal ein Backlog-Refinement-Meeting erlebt, bei dem man sich von oben nach unten durch die Liste kratzt, obwohl man weiß, dass man nie bis zum Ende kommt? Dieses Gefühl ist eindeutig elend.
Andererseits sind die Issues ja nicht verschwunden, sie haben nur ein anderes Label bekommen. Und wenn es am Ende nur um Tags und Ordnung geht, könnte man es dann nicht einfach laufen lassen, statt dieses Pseudo-Ideal einer perfekt leeren Issue-Liste kontrollieren zu wollen? Es gibt schließlich sicher auch Vorteile, solche Notizen sichtbar liegen zu lassen. Es fühlt sich ein bisschen an wie beim großen Aufräumen: Man hat entschieden, etwas wegzuwerfen, aber das Unterbewusstsein sagt, man solle es behalten, weil man es später vielleicht noch brauchen könnte.
Insgesamt bin ich trotzdem eher dafür. Zumindest dürfte es ein Gefühl der Befreiung geben und neue Energie für neue Issues.
Es wäre vermutlich sauberer gewesen, erst die neu geschriebene Version zu veröffentlichen und dann die bestehenden Issues als deprecated zu schließen. Issues im Rewrite-Branch hätte man per Versions-Tag trennen können. Wenn man sie schließt, bevor die neue Version fertig ist, könnten Beitragende neue Issues zur bestehenden Version öffnen, ohne zu wissen, dass diese nicht mehr unterstützt wird.
Trotzdem ist es nicht so, dass die Issues ignoriert und Probleme in der Codebasis liegen gelassen werden; das gesamte Projekt wird gerade neu aufgesetzt.
https://twitter.com/jdalton/status/1571863497969119238
Ich finde es ehrlicher, wenn ein Projekt die Existenz der Issues anerkennt und sie offen lässt. Wenn Entwickler die Anzahl der Issues stört, wäre ein Filter besser, der alte, unwichtige Issues ausblendet.
jwz hat dazu gesagt:
Besonders bei schwer reproduzierbaren oder komplexen Bugs ist es von vornherein unklar, ob der Maintainer sie in seiner eigenen Umgebung überhaupt reproduzieren kann; der Reporter ist wahrscheinlich eher daran gewöhnt, diesen Bug zu beobachten.
Wenn es ein größeres Team gibt oder es sich um ein Begleitprojekt zu einem kommerziellen Dienst handelt, kann sich dieses Gleichgewicht etwas verschieben.
Was man bei vielen freien/Open-Source-Projekten sieht: Es gibt sehr wenige Leute, die selbst mit anpacken wollen, aber gleichzeitig investieren sie viel Zeit darin, mitzuteilen, wie unverzichtbar das Projekt für sie ist, Forderungen zu stellen und viele Vorschläge zu machen.
Die meisten erstellen neue Issues, um Wunschlisten kundzutun, oder hinterlassen sehr vage Bug Reports. Einige davon liefern zwar ordentliche Bug Reports, aber die Bereitschaft zur Mitarbeit endet meist dort.
Persönlich bin ich nicht der Typ für Projekt-Maintenance, weil ich nicht die Bereitschaft habe, die meisten der häufig zu sehenden Kommentare diplomatisch zu behandeln.
Trotzdem versuche ich bei Issues, die ich melde, immer meinen Teil beizutragen: die Ursache nachverfolgen und, wenn möglich, einen PR mit einem Fix einreichen.
Wenn einem ein Problem wirklich wichtig ist, sollte man einen Test hinzufügen.
John-David Dalton, der Autor von lodash, hat [letztes Jahr Folgendes][1] geschrieben:
Es klingt, als hätte jemand anderes die Komplexität hinzugefügt, die er kritisiert. Wenn er sie selbst eingeführt hat, klingt es weniger nach Rückblick oder Lernerfahrung, sondern eher danach, dass man das Projekt einem Trend folgend entwickelt hat und jetzt, da der Trend vorbei ist, zum nächsten Ding weiterzieht.
Gut gemacht.
Schon bei ein paar PRs ganz vorne in der Liste sieht man solche Dinge:
ein einzelnes Wort in einem Kommentar ergänzen, eine Konfigurationsdatei zur Bewerbung eines Entwicklerdienstes hinzufügen,
vardurchletersetzen, das gut etablierte Verhalten einer Kernfunktion ändern, Semikolons entfernen usw.Die meisten wurden wohl mit der guten Absicht eröffnet, die Library zu verbessern, aber irgendwann wird das für Maintainer einfach zu Spam – oder schlimmer noch: zu einer Last, die umso mehr Schuldgefühle erzeugt, je weniger man sich darum kümmern kann.
So wie Prominente Bodyguards engagieren und First Class oder Privatjet fliegen, um der ständigen Aufmerksamkeit zu entgehen und ihre psychische Gesundheit zu schützen, frage ich mich, welche Maßnahmen für bekannte Open-Source-Projekte möglich wären.
Am längsten dauern PRs, die riesige Features implementieren. Weil sie viel Review und Diskussion brauchen, schiebe ich es auf, sie mir genauer anzusehen.
vardurchletersetzt haben.Fühlte sich an wie das Auffüllen des GitHub-Profils.
Die größere Nachricht ist, dass Lodash von Node.js zu Bun wechselt: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Ich hatte angefangen, mich dafür zu interessieren, meine Pakete auf Bun umzustellen, habe aber gezögert, weil ich mir Sorgen um die Kompatibilität machte und ob Bun wirklich langfristig überlebt. An „Modern Yarn“ hatte ich mir auch schon leicht die Finger verbrannt. Aber wenn ich sehe, dass lodash wechselt, möchte ich das jetzt ernsthafter prüfen.
Ich versuche zu vermeiden, Open-Source-Entwicklern vorzuschreiben, wie sie ihre Projekte führen sollen. Ich bin selbst Open-Source-Entwickler, und es nervt mich, wenn andere das bei mir tun.
Aber wenn ich ein Nutzer gewesen wäre, der einiges an Zeit investiert hat, um Issues zu schreiben und bei der Problemlösung zu helfen, oder jemand, der an einem Fix oder einem neuen Feature gearbeitet und einen PR eingereicht hat, wäre ich jetzt ziemlich demotiviert.
Es wurden 363 Issues mit dem Tag
issue bankruptcyversehen und geschlossen: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...Bei PRs sind es auf die gleiche Weise 325: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
Issue-Bankrott ist real. Aus persönlicher Erfahrung gesagt: Irgendwann wird Open-Source-Maintenance schwer mit dem Leben in der realen Welt vereinbar.
Die Arbeit ist unbezahlt und oft undankbar. Natürlich nicht immer. Das Problem ist komplex und konkurriert mit realen Verpflichtungen wie Arbeit, Familie und Erholung. Menschen sind schnell gereizt und wollen regelmäßig streiten oder verlangen, dass man für sie die Dokumentation liest. Wenn Open Source bekannt ist, kommt auch enorme Verantwortung dazu.
Ich rechne damit, dass es im Open-Source-Ökosystem zu einem großen Zusammenbruch kommen wird, wenn die Leute, die Projekte leiten, „reicht“ sagen und sich wichtigeren Dingen zuwenden.
Allerdings ist das Open-Source-Ökosystem wahnsinnig ineffizient. Es gibt lodash, underscore und unzählige andere Libraries, aber sie müssen nicht alle existieren. Es gibt auch viele Libraries, die nur eine einzige Sache tun, und meistens sind sie eine Teilmenge solcher Libraries.
Die meisten dieser Dinge werden zusammen mit Minifiern und Tree Shaking verwendet, und ungenutzte Funktionen werden entfernt. Selbst schwere Libraries lassen sich leicht optimieren und bestehen größtenteils aus getrennten Teilen, sodass man nicht unbedingt leichte Libraries braucht, und der Entwicklungsaufwand steigt im Großen und Ganzen linear.
Wenn Programmierer Eleganz und Einfachheit nicht über alles lieben und nicht ständig alles neu schreiben wollten, um es noch ein bisschen besser zu machen, gäbe es meiner Meinung nach genug Arbeitskraft für Open Source, selbst wenn alle nur ein Viertel der heutigen Zeit investieren würden.
Lodash ist eine hervorragende Library. In fast jedem Projekt, an dem ich arbeite, verwende ich es zumindest ein wenig.
Aber je besser JavaScript wird, desto weniger Lodash nutze ich. Jedes Mal, wenn ich es verwenden will, prüfe ich, ob es für das, was ich vorhabe, eine eingebaute Funktion gibt. Es kommt auch ziemlich oft vor, dass ich in PRs mit einem Link kommentiere: „Dafür braucht man kein Lodash.“
Trotzdem hoffe ich, dass das kein Signal dafür ist, dass sich das Projekt zurückzieht.
..., hatte enorme Auswirkungen. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Iterator-Helper sollen ebenfalls bald ausgeliefert werden und werden sehr hilfreich sein. Async-Iterator-Helper werden sich wohl noch eine Weile verzögern. https://github.com/tc39/proposal-iterator-helpersFrüher hatte ich das Gefühl, in Codebases, an denen ich arbeitete, mehrmals pro Woche
.apply()benutzen zu müssen, um Funktionen auf kreative Weise aufzurufen. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Das ist inzwischen alles verschwunden, und selbst wenn 50 % der Teammitglieder.callund.applykennen, wäre das wohl schon ein Münzwurf.In Chrome 117 kommt
Object.groupBy()hinzu, und das wird sehr dabei helfen, viele der letzten Gründe zu beseitigen, Lodash einzusetzen. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,findusw. erledigen ließe.Ein Issue-Tracker überlagert zwei Verwendungszwecke. Der eine ist eine Möglichkeit für Maintainer, nachzuverfolgen, was sie zu tun haben; der andere ist eine Möglichkeit für die breitere Community und die Nutzer, Defekte in der Software nachzuverfolgen.
Eine Erklärung von „Issue-Bankrott“ ergibt für den ersten Zweck Sinn, löscht beim zweiten aber wertvolle Informationen über Issues, die in der aktuellen Version existieren.