ich finden OpenEMS sehr spannend und betreibe aktuell das Energiemanagment in meinem Haus damit. Um so weit zu kommen habe ich Anfang 2025 begonnen, mich mit dem System zu beschäftigen und bis zum April Code zur Anbindung meines PV-Inverters, eines Energiezähler und einer Ladestation entwickelt. Als Nebenprodukt sind einige Patches entstanden, die ich als PR in Github angeboten habe.
Nun hat mich Github davor gewarnt, dass ein PR aufgrund von Inaktivität geschlossen werden sollen. Ich habe dies durch Einmergen des aktuellen Release-Branches verhindert, aber würde dies auch gerne zum Anlass nehmen, um die Frage zu stellen:
Besteht überhaupt Interesse an Beiträgen von Dritten?
Da OpenEMS das erste OpenSource Projekt ist, an dem ich mich aktiv beteilige, fehlt mir möglicherweise die Erfahrung oder ich bin vielleicht etwas zu ungeduldig? Wenn allerdings PRs fast ein halbes Jahr ohne einen einzigen Kommentar bleiben und von Github einfach geschlossen werden sollen, fördert das nicht gerade die Motivation sich weiter zu beteiligen.
Ich verstehe, dass vermutlich die meisten hier ihre Freitzeit einbringen und nicht alles die höchste Priorität hat. Ich könnte es auch verstehen, wenn mir jemand schreibt, dass mein Code von schlechter Qualität ist (auch wenn ich da anderer Meinung bin ) oder dass man die Änderung einfach nicht braucht/will oder ins Konzept passt.
Ich hoffen, dass meine Offenheit nicht negativ sondern konstruktiv verstanden wird und würde mich sehr über Feedback freuen: Mache ich etwas falsch? Bin ich zu ungeduldig? Lohnt es sich, weiter Zeit in die Erstellung und Pflege von PRs zu investieren?
Mir geht es auch so. Zwei meiner PRs wurden schon geschlossen und der Nächste ist kurz davor.
Lieber wäre mir schon, wenn mir wenigstens ein menschlich verfasster Kommentar mitteilt, dass fachlich kein Interesse besteht, als wenn bei Github ein Timer abläuft.
Das ist defakto nicht der Fall - da geht es eher darum, dass es in der Vergangenheit PRs gab, die nicht gemaintaint wurden und dementsprechend geschlossen werden sollen. Zudem soll denke ich damit gewährleistet werden, dass die PRs so aktuell wie möglich sind. Dies erleichtert eben auch die Arbeit zu unterscheiden, ob PRs aktuell sind oder nicht. Als Ersteller eines PRs muss man sich folgende Fragen stellen:
Habe ich die Coding Guidelines beachtet?
Laufen die Tests durch?
Habe ich Tests für meinen Code/Codeänderung geschrieben?
Gibt es starke “Fehler” in meinem Code?
Macht der PR wirklich sinn für das Gesamtprojekt, oder ist es eine persönliche, kleine Sache, die man anders irgendwo unterbauen kann?
Mir fallen da noch viel mehr Sachen ein. Ein OpenSource Projekt zu maintainen erfordert SEHR viel Zeit, um zu Gewährleisten, dass das Projekt auch “am Leben” bleibt. Das macht @stefan.feilmeier meiner Meinung nach SEHR gut und besser als manch andere Maintainer. Das benötigt halt Zeit.
ich kann eueren Frust gut nachvollziehen. Nichts ist demotivierender, als wenn ein PR lange unbeachtet bleibt. Ich möchte euch versichern, dass ganz klar Interesse an Beiträgen von Dritten besteht.
Die GitHub-Action zum automatischen Markieren/Schließen von inaktiven PRs habe ich eingeführt, um wieder etwas Struktur ins Repository zu bringen. Ziel war vor allem, wie @Sn0w3y richtig erwähnt hat, sehr alte, nicht mehr gepflegte PRs aufzuräumen. Damit sollen in erster Linie PRs geschlossen werden, bei denen vom Ersteller kein Interesse mehr vorhanden ist.
Wenn ein PR also mal als „Stale“ markiert wird, ist das updaten also genau das richtige.
Uns ist bewusst, das dem Repo oft das Momentum fehlt und dadurch leider auch gute PRs und Vorschläge liegen bleiben. Ich bin deshalb auch mit @stefan.feilmeier im austausch, wie wir das künftig verbessern können.
Das automatische Schließen ist also nur ein erster Schritt, um die Situation langfristig zu verbessern.
Klinke mich mal ein, da ich auch noch auf ein Merge warte.
Letztendlich ist es IMHO nötig das reviewn und auch mergen auf mehrere Schultern zu verteilen (Busfaktor = 1 ist nie gut ). Vielleicht ein Thema für die MV/Konferenz sich darüber auszutauschen, welche Kompetenzen und Qualitäten ein solches Amt braucht und bspw. mittels der soziokratischen Personenwahl zu schauen wer passend wäre. Evtl. hilft ja auch ein Peer-Coaching/Training um eine Person zu befähigen. Wenn das soweit Konsens ist, lässt sich vielleicht gemeinsam ein nächster Schritt definieren.
BTW sorry for stating the obvious.
Ich möchte die Arbeit von @stefan.feilmeier gar nicht beurteilen, da ich das nicht kann. Wie ich eingangs schrieb, finde ich OpenEMS sehr spannend und damit steckt da aus meiner Sicht viel gute Arbeit drin - daran hat @stefan.feilmeier sicher auch seinen Anteil.
Mir ging es vor allem darum, zu verstehen, ob sich das Erstellen/Nachverfolgen/Aktuallisieren von Patches/PR lohnt, da diese Tätigkeiten auch für mich einen Aufwand bedeutet. Und natürlich möchte ich gerne dazu lernen, falls ich etwas grundlegends falsch mache.
Daher danke ich für das Feedback (@da-Kai@Sn0w3y) und werde meine PRs entsprechend weiter auf dem Laufenden halten und abwarten.
) oder dass man die Änderung einfach nicht braucht/will oder ins Konzept passt.
