Ich habe heute beschämt mit @Tobias Kontakt aufgenommen, da ich trotz Zusage im letzten Sommer quasi „nix“ zur Doku beigetragen habe. Daher habe ich mir heute erstmal die Issues für linuxmuster-docs/main angeschaut und war komplett überfordert. In Absprache mit @Tobias habe ich jetzt ein klein wenig aufgeräumt und kommentiert. Ich habe allerdings erstmal kein Issue geschlossen, da ich noch das Gefühl dafür bekommen möchte ob das von allen Beteiligten so gewollt ist. Aus meiner Sicht können wir aber direkt die ersten sechs Issues schließen (die explizit für die LMN6) gedacht waren. Die habe ich jetzt mit einem Label „Closing Request“ versehen. Wenn es keine Einsprüche gibt, schließe ich die. Dann nochmal ein paar Punkte bzw. Fragen zur Orga:
Vereinbart war Issues, Commits, Milestones, Labels, etc. in Englisch zu erstellen, oder?
Ist ein eigener Branch pro Bearbeitung (Issue) der dann mit einem Pull-Request geschlossen wird als Verfahren für Euch OK … oder anders gedacht. Das ist auch ein Thema in #168.
Den Milestone für Version 6.x würde ich auch entfernen.
Muss ich sonst noch was beachten, bevor ich aktiv werde?
Hallo Tobi,
schön, dass Du wieder an Board bist.
Ich fände es wichtig, wenn Du die issues prüfen und entspr. schließen würdest.
Insgesamt sind die issues zu überarbeiten, damit sie handhabbar sind. Dann können sie auch mit dem beschriebenen Verfahren - neuer Branch, fixed, wieder schließen - bearbeitet werden.
Wir haben viele Kapitel neu geschrieben für die v7, in dem Zuge die issues etwas vernachlässigt. Es wäre super, wenn Du Dich derer annehmen könntest.
VG
Chris
Ich habe jetzt ein wenig sortiert, den Milestone 6.x entfernt und u. a. einen neuen Milestone „V7 - Summer 2020“ angelegt. Darunter sind jetzt 10 Issues derer ich mich jetzt in den nächsten Wochen annehmen werde/will. Wenn ich Euch ein neues Issue zuweise … habe ich meist eine Frage … wie in in #380
hatten wir das 01- , 02- usw schema nur diskutiert oder uns festlegen wollen. Jedenfalls ist davon nichts in den Leitlinien zu Dokumenation gelandet?
[/del]
Also wenn ich den Knopf oben nutzen und direkt in Github ändere dann fließt das sofort in den Master ein. Was ich auch nicht schlimm finde, da es die Kontaktschwelle zu git senkt. Aber halt nicht mit dem Zitat bzgl. neuer Branch zusammen passt.
Eventueller habe ich auch etwas nicht richtig verstanden. Daher meine Frage.
… ah … jetzt habe ich es verstanden. Mir ist der Button vorab überhaupt nicht aufgefallen. (Was man so alles ausblendet).
Ich habe heute für meine Mini-Änderungen nicht auf einem eigenen Branch gearbeitet. Aber wenn ich mir jetzt ein Thema vornehme an dem ich evtl. mehrere Tage werkel … dann würde ich auf einem eigens dafür erstellten Branch arbeiten und definitiv nicht diesen Button benutzen (Github-Flow)
Ob damit die Kontakschwelle zu git/github sinkt weiß ich nicht, da meines Wissens nur die Leute Änderungen einpflegen können, die ein Schreibrecht im Repo haben. Forken und einen Pull-Request stellen kann aber jeder … oder liege ich da falsch?
Ich sehe es gerade. Ich aktualisiere den Beitrag mit der führenden 0. Die 0er hatte ich schon letztes Jahr vergessen
Hätte ich schon gesagt! Ihr habt Euch da ein sauberes Konzept überlegt. Das hatte ich auch irgendwie noch in Erinnerung. Für mich sind jetzt erstmal alle Fragen geklärt.
Hallo zusammen,
wenn Änderungen direkt über GitHub vorgenommen werden und der schicke Button gedrückt wird, dann ist ein Branch hinfällig.
Wenn ich lokal via GitHub Änderungen erstelle, dann führe ich diese lokal in einem neu erstellten Branch aus, schließe diesen wieder über den pull request. Mein lokaler Clone folgt in diesem Fall dem main branch (remote).
Wenn ich einen fork anlege, der dem main branch der Doku folgt, dann führe ich lokal mit Git die Änderungen durch, führe den commit aus, schiebe diesen in den remote fork und konsolidieren das Ganze mit einem pull request.
Uuih, hoffe, das ist halbwegs nachvollziehbar.
VG
Chris
Nee, absolut nicht! Sonder das ist ganz und gar nachvollziehbar.
Recht herzlichen Dank für die erklärende Zusammenfassung.
Dafür von mir ein
Und wenn ich @toheine eines verleihen könnte, würdest du von mir eins bekommen, dafür das du neuen Wind in die Doku bringst und sie damit wieder fahrt aufnimmt.
Danke an alle die sich beteiligen und Aufruf an andere es auch zu tun.
ich darf noch ergänzen: als Außenstehender wird bei dem schicken Button doch ein PR erzeugt, also intern wird ein branch erzeugt, der dann gemergt wird.
Wenn wir als maintainer das machen, dass könnenw ir gleich commiten oder einen PR erstellen.
Wobei ich mich frage, wie der direkte „Auf Github bearbeiten“-Knopf in der Doku da reinpasst?
… wie in in 
