xoxys/geeklabor_legacy
Archived
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fix typos
All checks were successful
the build was successful
Details

Browse Source
This commit is contained in:
Robert Kaussow 2019-01-05 23:35:52 +01:00
parent f4a2634240
commit 247ed44702
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
content/post/better-when-open.md
View File

@ -3,7 +3,7 @@ title: "Better when open"
date: 2019-01-05T23:30:00+02:00 date: 2019-01-05T23:30:00+02:00
draft: false draft: false
author: robert-kaussow author: robert-kaussow
description: "Open Source ist keine Einbahnstraße. Doch die Mitarbeit an Projekten gleicht manchmal einem Minenfeld wieder, welches gar nicht so leicht zu durchqueren ist." description: "Open Source ist keine Einbahnstraße. Doch die Mitarbeit an Projekten gleicht manchmal einem Minenfeld, welches gar nicht so leicht zu durchqueren ist."
keywords: keywords:
- open - open
- source - source
@ -25,7 +25,7 @@ Wenn die Rede von Open Source ist denken die meisten von euch sicher in erster L
Das Internet ist voll von kleinen und großen Open Source Projekten die fast alle ein wenig wie ein Staat funktionieren. Es gibt einen oder mehrere Oberhäupter, die entweder selbstbestimmt sind oder gewählt wurden. Diese müssen Änderungen absegnen bevor sie übernommen werden und sie legen auch die Spielregeln für die Mitarbeit an der freien Software fest. Fast immer gibt es Issue Templates, einen Code of Conduct, der definiert wie was gemacht wird, wie miteinander umgegangen wird und seit 2018 endlich auch [politisch total korrekte](https://www.theregister.co.uk/2018/09/11/python_purges_master_and_slave_in_political_pogrom/) Begriffe, die man benutzen soll um einen technischen Zusammenhang herzustellen. Wenn man Glück hat, ist das alles noch an ein CICD-System gekoppelt, welches alle Regeln gnadenlos prüft und jeden Fehler mit einem großen roten Kreuz hinter dem Commit abstraft. Das Internet ist voll von kleinen und großen Open Source Projekten die fast alle ein wenig wie ein Staat funktionieren. Es gibt einen oder mehrere Oberhäupter, die entweder selbstbestimmt sind oder gewählt wurden. Diese müssen Änderungen absegnen bevor sie übernommen werden und sie legen auch die Spielregeln für die Mitarbeit an der freien Software fest. Fast immer gibt es Issue Templates, einen Code of Conduct, der definiert wie was gemacht wird, wie miteinander umgegangen wird und seit 2018 endlich auch [politisch total korrekte](https://www.theregister.co.uk/2018/09/11/python_purges_master_and_slave_in_political_pogrom/) Begriffe, die man benutzen soll um einen technischen Zusammenhang herzustellen. Wenn man Glück hat, ist das alles noch an ein CICD-System gekoppelt, welches alle Regeln gnadenlos prüft und jeden Fehler mit einem großen roten Kreuz hinter dem Commit abstraft.
So sieht die Entwicklung von Open Source heute aus. An dieser Stelle sei eines ganz klar gesagt. Ich finde es richtig und wichtig, dass es solche Strukturen gibt! Sie sorgen dafür, dass Verantwortlichkeiten geklärt sind und eine gewisse Qualität des Endproduktes sichergestellt werden kann. Doch was passiert, wenn jetzt ein Nutzer einen Fehler findet oder nach einem Feature fragt oder einfach gerne mitarbeiten möchte das aber noch nie gemacht hat? Nun, das kommt immer etwas auf das Projekt an, aber im Grunde gibt es erfahrungsgemäß drei Möglichkeiten: So sieht die Entwicklung von Open Source Software heute aus. An dieser Stelle sei eines ganz klar gesagt. Ich finde es richtig und wichtig, dass es solche Strukturen gibt! Sie sorgen dafür, dass Verantwortlichkeiten geklärt sind und eine gewisse Qualität des Endproduktes sichergestellt werden kann. Doch was passiert, wenn jetzt ein Nutzer einen Fehler findet oder nach einem Feature fragt oder einfach gerne mitarbeiten möchte das aber noch nie gemacht hat? Nun, das kommt immer etwas auf das Projekt an, aber im Grunde gibt es erfahrungsgemäß drei Möglichkeiten:
- Die Anfrage wird freundlich entgegengenommen, eventuell werden ein paar fehlende Informationen eingefordert, ein Entwickler kann den Fehler reproduzieren und taktet den Fix für ein kommendes Release ein oder der Nutzer wird bei seinem ersten Pull Request unterstützt und ein wenig geführt. - Die Anfrage wird freundlich entgegengenommen, eventuell werden ein paar fehlende Informationen eingefordert, ein Entwickler kann den Fehler reproduzieren und taktet den Fix für ein kommendes Release ein oder der Nutzer wird bei seinem ersten Pull Request unterstützt und ein wenig geführt.
- Man wird angeblafft, warum nicht alle Felder des Issue Templates ausgefüllt wurden, das man nicht beabsichtigt irgendwas in die Richtung zu tun und das man ja auch selber eine Pull Request erstellen kann, wenn man die Änderung jetzt unbedingt braucht. Eine Minute später ist der Issue dann bereits geschlossen. - Man wird angeblafft, warum nicht alle Felder des Issue Templates ausgefüllt wurden, das man nicht beabsichtigt irgendwas in die Richtung zu tun und das man ja auch selber eine Pull Request erstellen kann, wenn man die Änderung jetzt unbedingt braucht. Eine Minute später ist der Issue dann bereits geschlossen.
@ -35,12 +35,10 @@ Fall 3 passiert mir persönlich recht selten, bereits bei der Evaluierung einer
Der zweite Fall ist mir leider schon öfter begegnet und widerspricht für mich den Grundlagen von Open Source. Oft wird in diesen Fällen damit argumentiert, dass es nur begrenzte Entwicklungsressourcen gibt und man Prioritäten setzen muss und nicht alles umgesetzt werden kann. Auch dem stimme ich grundlegend zu, man darf aber nicht vergessen das nicht jeder der Anwender auch ein Hacker oder Entwickler ist, der das Problem schon im Vorfeld durch debugged und analysiert hat und gleich mit einem fertigen Pull Request um die Ecke kommt. Viele Nutzer sind eben nur Nutzer, denen ein Fehler aufgefallen ist und die eventuell noch das Error-Log kopieren können. Selbst wenn man nicht der absolute Programmieranfänger ist und den Fehler auf eigene Faust beheben konnte und einen Pull Request erstellt hat, erntet man dafür nicht immer nette Worte. Manche werden kommentarlos abgelehnt oder erst gar nicht beachtet. Der zweite Fall ist mir leider schon öfter begegnet und widerspricht für mich den Grundlagen von Open Source. Oft wird in diesen Fällen damit argumentiert, dass es nur begrenzte Entwicklungsressourcen gibt und man Prioritäten setzen muss und nicht alles umgesetzt werden kann. Auch dem stimme ich grundlegend zu, man darf aber nicht vergessen das nicht jeder der Anwender auch ein Hacker oder Entwickler ist, der das Problem schon im Vorfeld durch debugged und analysiert hat und gleich mit einem fertigen Pull Request um die Ecke kommt. Viele Nutzer sind eben nur Nutzer, denen ein Fehler aufgefallen ist und die eventuell noch das Error-Log kopieren können. Selbst wenn man nicht der absolute Programmieranfänger ist und den Fehler auf eigene Faust beheben konnte und einen Pull Request erstellt hat, erntet man dafür nicht immer nette Worte. Manche werden kommentarlos abgelehnt oder erst gar nicht beachtet.
Letztendlich ist Open Source natürlich keine Einbahnstraße, man kann sich auch als Nutzer nicht immer mit
> Ich bin ja kein Entwickler > Ich bin ja kein Entwickler
herausreden, denn viele Projekte brauchen nicht nur Programmierer, sondern auch Leute die Dokumentationen schreiben, Artwork bereitstellen, Webauftritte betreuen und und und. So gut wie jeder kann in irgend einer Art und Weise mitarbeiten, wenn er das denn wirklich will. Auf der anderen Seite brauchen sich manche Projekte aber auch nicht über mangelnde Beteiligung beschweren, wenn jedem gleich an den Karren gefahren wird, der sich mal kritisch äußert oder vielleicht noch nicht so richtig weiß wie er was machen sollte, wenn er an dem Projekt mitarbeiten möchte. Ich denke das es beiden Seiten ab und an ganz guttun würde sich etwas verständnisvoller gegenüberzutreten und sich auf die Werte der Open Source Kultur zu besinnen. Letztendlich ist Open Source natürlich keine Einbahnstraße, man kann sich auch als Nutzer nicht immer herausreden, denn viele Projekte brauchen nicht nur Programmierer, sondern auch Leute die Dokumentationen schreiben, Artwork bereitstellen, Webauftritte betreuen und und und. So gut wie jeder kann in irgend einer Art und Weise mitarbeiten, wenn er das denn wirklich will. Auf der anderen Seite brauchen sich manche Projekte aber auch nicht über mangelnde Beteiligung beschweren, wenn jedem gleich an den Karren gefahren wird, der sich mal kritisch äußert oder vielleicht noch nicht so richtig weiß wie er was machen sollte, wenn er an dem Projekt mitarbeiten möchte. Ich denke das es beiden Seiten ab und an ganz guttun würde sich etwas verständnisvoller gegenüberzutreten und sich auf die Werte der Open Source Kultur zu besinnen.
Zum Abschluss noch ein schönes Zitat [eines Github Users](https://github.com/appleboy), an dem auch ich versuchen werde mich in Zukunft mehr zu orientieren: Zum Abschluss noch ein schönes Zitat [eines GitHub Users](https://github.com/appleboy), an dem auch ich versuchen werde mich in Zukunft mehr zu orientieren:
> I really believe committing every day on an open source project is the best practice. > I really believe committing every day on an open source project is the best practice.