Mitmachen bei Open-Source-Projekten ...

Geschrieben von Dirk Deimeke am Donnerstag, 1. Dezember 2016

Nur auf der OpenRheinRuhr habe ich den Vortrag "Mitmachen bei und lernen von Open-Source-Projekten" gehalten. Mir ist es wichtig, dass verstanden wird, dass Open-Source-Projekte nicht nur aus Code bestehen, sondern Mithilfe jeder Art gebrauchen können.

Unter diesem Link kann man das PDF herunterladen, bei eingeschaltetem JavaScript sieht man auch hier den eingebetteten Vortrag:

Trackbacks

Trackback-URL für diesen Eintrag

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Fryboyter am Donnerstag, 1. Dezember 2016:

Kann ich so unterschreiben. Bin auch einer derjenigen, die nichts beitragen können, wenn es um das Programmieren geht. Dafür melde ich Fehler möglichst ausführlich. An die eine oder andere Übersetzung bzw. Verbesserung einer bestehenden habe ich mich auch schon gewagt.

Bei vielen Projekten ist es aber für Außenstehende meiner Meinung nach schwierig überhaupt herauszufinden welche Hilfe gebraucht wird. Und wie man vorgehen soll. Ich nutze zum Beispiel recht gerne den Double Commander. Hier war die deutsche Sprachdatei vor einigen Monaten noch sehr unvollständig. Es gibt bei dem Projekt zwar eine Seite die sich mit den Übersetzungen beschäftigt, dort wird aber im Grunde nur erklärt wie wie man die po-Datei ändern muss. Wohin man die Datei dann senden muss, geht aus der Seite nicht hervor.

Was habe ich also gemacht? Ich habe mehrere Stunden mit der Übersetzung verbracht, was ziemliche Nerven gekostet hat, da manche Strings nur eine bestimmte Länge haben durften. Da ich mich ehrlich gesagt nicht auch noch in SVN einarbeiten wollte, habe ich den Weg des geringsten Widerstands gewählt und die Datei im offiziellen Forum veröffentlicht (wurde von anderen auch schon so gemacht und die Dateien wurden eingepflegt). Und was ist passiert? Ein paar Tage später hat ein anderer die deutsche Sprachdatei fertig übersetzt und hat sie direkt in SVN gepackt. Ratet mal, welche der beiden Dateien nun Bestandteil des Programms ist?

Ich kenne einige Leute die zum Beispiel Programme in diverse Sprachen übersetzen könnten (und auch dazu bereit sind). Aber in Git würden sich diese zum Beispiel nie im Leben einarbeiten. Für solche Fälle wäre es meiner Meinung nach durchaus sinnvoll, wenn es eine leichtere Art geben würde, die Daten einzureichen.

tuxflo am Donnerstag, 1. Dezember 2016:

Ich kennte mich (als Inforamatik-Student) zwar selbst recht gut mit so Sachen wie git und Co aus, kann aber dein beschriebenes Phänomen gut nachvollziehen. Meiner Meinung nach sollte sich in Sachen Contrubution und Projektmanagement in der Open Source Welt noch einiges tun. Auch wenn es um den Code geht, sollten die Hauptentwickler eher bereit sein auch mal Neulinge ran zu lassen. Ich könnte mir beispielsweise ein Bug-Label a la "Easy-to-fix" vorstellen, was von Einsteigern bearbeitet werden könnte um überhaupt mal das Arbeiten an Softwareprojekten zu lernen. Auch das Schreiben einer Doku könnte man meiner Meinung nach zu Teilen "auslagern" und so vielleicht auch besser vorhandene Ressourcen verteilen.

Vielleicht sollte man auch hier mehr "Gamification" einsetzen und die potentiellen Helfer mit Badges und Punkten belohnen...

Dirk Deimeke am Donnerstag, 1. Dezember 2016:

Da bin ich zwiegespalten.

Zum Einen kann ich Deinen Standpunkt verstehen, dass es möglichst einfach sein soll, beitragen zu können. Da ist in vielen Projekten noch einiges an Arbeit nötig.

Auf der anderen Seite möchtest Du sicher auch nicht, dass die, die in einem Projekt mitarbeiten zu reinen Verwaltern werden. Wenn es einen erheblichen Aufwand bedeutet, Beiträge "projektkompatibel" zu machen, werden wenige Teammitglieder diese "Last" auf sich nehmen.

Das grosse Problem ist, dass es so viele Menschen wie bevorzugte Wege gibt. Kein Projekt kann es allen recht machen.

Das Basiswissen für Git ist nicht schwer, es gibt kostenlose Online-Kurse, die es allen leicht machen, sich das Wissen anzueignen. Warum also nicht etwas neues lernen.

Dirk Deimeke am Donnerstag, 1. Dezember 2016:

"Gamification" bieten wir nicht, aber das andere, was Du vorschlägst, wollen wir bei Taskwarrior umsetzen.

Es wird Bugs geben, die mit dem Marker "easyfix" (oder so) versehen werden.

Dokumentation ist bei uns statisches HTML, was auch in einem Repository liegt, zu dem man beitragen kann.

Vieles ist leider nur möglich, wenn das Projekt eine bestimmte Grösse erreicht hat, zum Beispiel Neulingen Mentoren an die Hand geben.

Dirk Deimeke am Donnerstag, 1. Dezember 2016:

Nachtrag: Für Taskwarrior habe ich auf der FrOSCon einen Vortrag über "Contribute to Taskwarrior" gehalten, in dem auch Stellenbeschreibungen zu finden sind. Diese Positionen würden wir gerne besetzen.

Zum Beispiel suchen wir auch jemanden, der sich um die Webseite kümmert

Matthias Gutjahr am Donnerstag, 1. Dezember 2016:

In der Vorweihnachtszeit gibt es ein nettes Projekt namens 24PullRequests, welches die Contributions zu Open Source-Projekten fördern will. Dort werden insbesondere Projekte vorgestellt, die offene Issues auf GitHub haben, die mit Tags wie Help Wanted, Documentation oder Beginner versehen sind. Häufig sind diese Verbesserungen gut für Einsteiger geeignet. Wer also gerade kein Projekt zur Hand hat, bei dem er/sie mithelfen könnte, kann dort fündig werden

Dirk Deimeke am Donnerstag, 1. Dezember 2016:

Die Idee ist grossartig.

Vielen Dank für den Link!

Fryboyter am Montag, 5. Dezember 2016:

Recht machen müsste man es doch eigentlich "nur" zwei Gruppen. Denjenigen die mit Git und Co. umgehen können und dem Rest.

Was spräche zum Beispiel dagegen wenn Projekt X auch Beiträge (die beispielsweise nichts mit programmieren zu tun haben) über eine bestimmte E-Mail-Adresse annehmen würde und dann einer aus dem Team das dann per Git / SVN oder was auch immer einpflegt?

Das mit dem Wissen aneignen ist halt auch so eine Sache. Git würde ich vermutlich 2 bis 3 mal im Jahr, immer für unterschiedliche Projekte, nutzen. Da hätten wir das gleiche Problem wie mit vim. Vim mag unterm Strich besser sein als andere Editoren. Aber wenn man ihn nicht regelmäßig nutzt, vergisst man halt die Bedienung ganz schnell. Daher nutze ich auch für mich "einfacherer" Lösungen. Und das obwohl ich mich sehr viel mit Computer und Co. beschäftige.

Dann ist da noch der Zwang, dass man sich beispielsweise auf Github anmelden muss, damit man an Projekt X etwas beitragen kann. Für viele ist das scheinbar wirklich eine Hürde (eher weniger technischer Natur sondern bezüglich des Wollens). So war es bei einem Projekt bei dem ich inzwischen ausgestiegen bin geplant, dass für die Nutzer Neuerungen eingeführt werden. Da bisherige Diskussionen / Planungen in einem Forum geführt und dort in der Regel versandet sind (unter anderem weil es zu unübersichtlich war), wurde von einem Teammitglied die Idee gebracht ein Kanban Board einzuführen. Installiert war es schnell, lief aber unter einer anderen Adresse und man musste sich registrieren. Was war das Ende vom Lied? Es wurde im Forum ein neuer Bereich erstellt, der optisch so umgebaut wurde, dass er der Ansicht eines Kanban Board entsprach aber nicht den Funktionsumfang geboten hat.

Dirk Deimeke am Montag, 5. Dezember 2016:

Die meisten Projekte, mit denen ich zu tun habe, machen das so, wie Du es beschreibst. Du kannst Änderungen via E-Mail einreichen und diese werden eingepflegt.

Es ist trotzdem eine Frage der Projektgrösse und der Anzahl an Einreichungen über diesen "Nicht-Standard-Weg".

Für "ein Mal im Jahr etwas beitragen" lohnt sich sicherlich nicht der Aufwand, ein völlig unbekanntes Programm zu lernen. Wenn man aber dauerhaft beitragen möchte und das auch in verschiedenen Projekten tun will, dann relativiert sich der Aufwand doch sehr schnell.

Eine Anmeldung finde ich nicht falsch und das hat auch einen Grund, die Menge an Spam oder "hingerotzten" Beiträgen reduziert sich auf ein absolutes Minimum, wenn diese sehr kleine Hürde eingebaut wird.