Wann Code auf Github veröffentlichen

[Yagharek]

Hallo
...

Das Problem an der Sache ist, dass dies ein Hobby ist, welches gewachsen ist und deshalb kaum Struktur enthält. So habe ich selber das Problem, dass ich Programmteile nicht richtig verstehe, die ich vor 1 oder 2 Jahren geschrieben habe. Deshalb bin ich dabei, nach und nach Struktur und Übersichtlichkeit in mein Code zu bringen. Ich überlege mir nur gerade meine nächsten Schritte.

Macht es entweder mehr Sinn, jetzt Arbeit in den Code zu stecken, dass ich die unstrukturierten Teile so aufarbeite, dass ich und andere diese lesen können.
Oder sollte ich jetzt ein bisschen Arbeit in eine allgemeine Erklärung des Codes stecken und Beispiele erstellen, wie man den Code starten kann, damit Arbeitsblätter erzeugt werden und andere diese Code, wenn sie möchten, sofort nutzen können?

Warum ich mir darüber Gedanken mache: Da es ein Hobby ist, welches ich nur verfolge, wenn ich Zeit dafür habe, wird es noch mindestens ein Jahr dauern, bis der Code so übersichtlich ist, dass er veröffentlicht werden kann. Einen Einstieg in den Code werde ich wohl in ein bis zwei Monaten hinbekommen.
.

 

[netzgestaltung]

Vor einer Veröffentlichung auf Github mußt du jedenfalls prüfen ob sich Passwörter, Keys oder sonstige Credentials irgendwo befinden.

Ich persönlich würde gleich verölffentlichen und dann mit dem Git repo weiter arbeiten. Meistens bist du auf GitHub eh unbeobachtet von einer "Öffentlichkeit" und man sieht den Verlauf und hat alle anderen Vorteile von Git. Mein Code ist aber auch immer mit GPLv2 oder höher Lizenziert da ist das weniger ein Thema.

Ich kenne aber auch andere Meinungen die dahin gehen, das erst veröffentlicht wird wenn es eine "Version 1" gibt. Auch eine Herangehensweise.

 

[djerunX]

Das Github Repo kann man ja auch erstmal auf privat stellen und später veröffentlichen. So oder so würde ich so früh es geht mit einer Versionsverwaltung anfangen, schaden tut das nie.

 

[kachiri]

Liegt ganz an dir. Natürlich sollten im Code keine "persönlichen" Informationen versteckt sein. Das würde ich, wie bereits angesprochen, vorher checken.
Ansonsten: Git anlegen und am besten dort weiter arbeiten. Ob du das ganze "Öffentlich" oder "Privat" setzt, kannst du ja selbst entscheiden. Auch wer das "Main Repo" bearbeiten darf. Das heißt du kannst es "Öffentlich" zur Verfügung stellen, andere dürfen forken und selbst damit arbeiten, aber eben nicht dein eigenes Repo anfassen

Allein die Versionsverwaltung ist ja eine Genugtuung und das man jede Änderung nachvollziehen kann g

 

[Yagharek]

Danke für eure Rückmeldungen. Die Antworten gehen da doch in eine eindeutige Richtung.

Das mit Privat und Öffentlich wusste ich noch gar nicht. Ich werde also mein Code da hoch laden, auf Privat stellen und mich an Beispielen und Erklärungen machen. Etwas was auch für mich wichtig ist. Danach wirds öffentlich.

Als Lizenz wollte ich die MIT Lizenz nehmen. Soweit ich verstanden habe, reicht es einfach die Textdatei LIZENZ zu erstellen. Ich muss mich nirgendwo anmelden?

 

[Dalek]

Ein git repository anlegen und das ganze auf Github pushen ist immer das erste was ich mache, das ist auf jeden Fall eine gute Idee. Wie schon gesagt kannst du das Repository auch zuerst auf privat setzen.

MIT Lizenz ist für Quellcode gedacht, sowas wie Arbeitsblätter wären evtl. mit einer Creative Commons Lizenz besser. Egal welche Lizenz, du solltest dir halt überlegen welche Rechte du anderen geben willst. MIT bedeutet das andere so ziemlich alles was sie wollen damit machen können. Lizenzdatei ins Repository kopieren reicht, Github hat da auch Tools um bekannte Lizenzen direkt reinzusetzen.

 

[Yagharek]

Ich lade eine Code hoch. Die Arbeitsblätter sind nur das Ergebnis, wenn man den Code ausführt. Darum auch nicht Creative Commons Lizenz.

MIT bedeutet das andere so ziemlich alles was sie wollen damit machen können.

Darum dachte ich auch an die MIT Lizenz. Da ich eh nicht überprüfen, verfolgen kann, was andere mit meinem Code machen, können die ruhig alles machen. Mir ist nur wichtig, dass man mir nichts ankreiden kann, wenn ich meinen Code hochlade. Sei es, dass meine Skripte irgendwas kaputt machen (ich nutze einen lösch Befehl) oder jemand meint, meinen Code zu kopieren, unter einer anderen Lizenz zu veröffentlichen und mich dann abzumahnen.

 

[Bl4ckeagle]

@djerunX

Kann man bei github, ohne Premium Account, auf privat stellen?
Ich nutze sonnst gitlab, selbe in grün.

@Yagharek

Wie schon erwähnt, check ob passwörter, keys, oder daten im code enthalten sind, die nicht hingehören.
Danach direkt auf ein privates Git repo hochladen.
Wie gut oder schlecht dein Code ist, ist mal am anfang egal. kannst ja immer noch einlesen, wenn du lust hast.

 

[KitKat::new()]

@djerunX

Kann man bei github, ohne Premium Account, auf privat stellen?

ja

 

[Revan1710]

Nach meinen Erfahrungen mit git repos Dritter ist meine Meinung klar, dass eine vernünftige Dokumentation mit Beispielen wichtiger ist als ein aufgeräumter oder schicker Code (funktional sollte es natürlich sein).

Wenn ich etwas gefunden habe, dass mir weiterhelft, ich mir aber im Code erst mühsam zusammensuchen muss wie ich es verwende, dann kehrt man dem ganzen schnell wieder den Rücken zu. Auf dein Tool wird man ja erstmal durch seinen Nutzen aufmerksam und erst aus regelmäßigem Nutzen wird ein Mitwirken (wenn überhaupt).

 

[andy_m4]

Genau. Dokumentation und Erklärungen ist das A und O.
Ohne dem ist selbst der beste Quelltext nix wert.
Also nicht nur für andere, sondern auch für Dich. Denn noch hat man die Sachen im Kopf präsent. Aber guckt man in ein paar Monaten oder Jahren noch mal drüber, erschließt sich einem das nicht mehr sofort.

Oder sollte ich jetzt ein bisschen Arbeit in eine allgemeine Erklärung des Codes stecken und Beispiele erstellen, wie man den Code starten kann, damit Arbeitsblätter erzeugt werden und andere diese Code, wenn sie möchten, sofort nutzen können?

Unbedingt. Du solltest auch als erstes klar machen, worum es überhaupt geht.
So die typischen Punkte sind:

Was macht es?
Wie sieht es aus (ggf. mit Screenshots)?
Wie wird es installiert?
Wie benutze ich es?
Wie deinstalliere ich es?

Wenn Du Code dokumentierst, dann sag dort nicht was Du machst (hier kommt jetzt eine Schleife oder so). Weil das ergibt sich aus dem Code. Sag lieber warum Du bestimmte Dinge machst.
Verwende im Code vernünftige Bezeichner die auch sagen, wofür die Variable oder Funktion da sind (also ruhig lange beschreibende Namen verwenden).
Was Du hier an Tipparbeit sparst musst Du später an Zeit investieren um rauszukriegen, was da eigentlich passiert.
Statt
var int ed
lieber
var int expire_date

Sowas wie
var int ed // Expire Date
ist übrigens (obwohl kommentiert!) eher schlecht. Weil Erfahrungsgemäß ändert sich Code und dann werden die Kommentare gerne nicht immer mitgezogen. Außerdem bringen die modernen IDEs Hilfsmittel zur Variablenumbenennung mit, so das alles wo die Variable (oder Funktion) vorkommt automatisch ersetzt wird. Kommentare bleiben bei dieser Funktionalität außen vor. Auch deshalb ist es besser das so wie oben dargestellt zu machen.

 

[.courson]

Moin,
ich kann den Vorrednern eigentlich nur zustimmen.

Bzgl. deinen Fragen kann ich dir noch folgende Links empfehlen:

OpenSource/Lizenzen

• https://opensource.guide (allgemeines; hier nicht so relevant, aber kann man ja mal durchlesen)
• https://opensource.guide/legal/ (nochmal was zu Lizenzen)
• https://choosealicense.com/ (welche Lizenz passt zu meinem Anspruch)

Readme-Gestaltung

• https://bulldogjob.com/news/449-how-to-write-a-good-readme-for-your-github-project (eher ein Teaser für z.B. Markdown)
• https://github.com/noffle/art-of-readme#readme (allgemeines zum Aufbau einer Readme)
• https://github.com/matiassingers/awesome-readme (Beispiele)

Vielleicht ist ja was interessantes für dich dabei.

 

[Oma Erna]

Aus meiner Sicht überschätzt du da die Öffentlichkeitswirksamkeit.
Für 99% aller öffentlichen Repos interessiert sich wirklich niemand.

 

[Yagharek]

@courson
Danke für die Readme links. Die helfen mir sehr weiter. Deine links zu den Lizenzen haben mich glücklicher weise bestätigt.

@andy_m4
Danke für die ausführliche Antwort. Ich arbeite jetzt an der Dokumentation.

@Oma Erna
Wenn es keiner nutzt, ist es auch nicht schlimm. Denn dann habe ich halt Arbeit darein gesteckt, dass ich mein Projekt in ein paar Jahren immer noch gut nutzen kann.

 

[djerunX]

Und ich meine wenn du es mal einem Kollegen zeigen oder weitergeben möchtest der sich dafür interessiert, freut der sich sicher auch mehr (;

 

[cmi777]

Ich glaube es ging auch ein bisschen darum, dass du dir nicht zuviel Sorgen vor dem "veröffentlichen" machen sollst. Das muss keine Version 1.0 sein, dass kann (quasi) eine Version 0.1 sein, das Repo kann wachsen. Das schöne bei GitHub/GitLab ist ja, dass du Feedback bekommen kannst. Leute können theoretisch mitarbeiten, Fragen stellen etc. - d.h. du entwickelst dadurch nicht unbedingt im luftleeren Raum wo du nicht mal weißt, was die Leute eigentlich interessiert oder welche Fragen sie stellen oder welche Probleme sie haben.

Was enthalten sein sollte ist meines erachtens erstmal "nur" eine README.md, die beschreibt für was Projekt gedacht ist, was benötigt wird und wie man es (grob) benutzt.

Der Rest kann (imho) erstmal unstruktuiert sein, daran kannst du auch arbeiten, wenn das Projekt "öffentlich" ist. "Öffentlich" heißt ja nicht, dass die halbe Welt sich daraufstürzt Durch die README weiß aber jeder potentielle Besucher erstmal für was das ist bzw. in welche Richtung es gehen soll.