Silke Meyer

Ein kleines Protokoll zu Dokumentationszwecken!

Wir befinden uns heute im Bereich Softwareentwicklung, genauer in der Entwicklung freier Software, so ein typischer Versuchsaufbau, bei dem die beteiligten Personen über das Internet zusammenarbeiten. Hier bin ich total neu. Bis vor wenigen Tagen habe ich von mir gesagt, dass ich nicht programmieren kann. Um die Sache zu tun, die ich vorhatte (mit Puppet eine Art Metakonfiguration schreiben, mit der man dann viele Server ganz schnell konfigurieren kann), musste ich mich aber sowohl mit der Programmiersprache Ruby befassen als auch mit git, einer Software für Versionskontrolle. Das kann man sich so vorstellen: Alles Geschriebene kommt zwischendurch und ganz am Ende in git und wird in der jeweiligen Version gespeichert. Falls was kaputt geht, ist es möglich, zu irgendeinem gespeicherten Stand zurückzugehen. Und das Ganze gibt es auch noch an verschiedenen Orten, auf dem eigenen Rechner und auf einem Server irgendwo in diesem Internet.Git hat außerdem eine Art Feedbackfunktion, um die es hier geht (git review). So weit, so gut.

Nach vielleicht zwei Wochen Arbeit mit Puppet und git, was es soweit, dass ich mein Ergebnis in einen größeren Kontext einspeisen wollte, um a) Feedback zu bekommen und b) anderen das Erarbeitete zur Verfügung zu stellen. Damit alle das neu Programmierte nun auch benutzen können, muss es – so die Absprache – von zwei Leuten angesehen und für gut befunden werden. Dann wird es in den „allgemeinen Fundus“ aufgenommen. Dazu sieht die benutzte Feedback-Software ein kleines Benotungssystem vor. Erst mit 2x „+1“ geht es weiter.

Ihr ahnt jetzt sicher schon, worauf ich hinauswill. Nach etwas Hin und Her mit git hat es schließlich geklappt: Die Feedback-Software hat meinen Input angenommen und nun liegt er da. Die Personen, die sich auskennen, hatten mir vorher sehr viel geholfen und waren/sind nun gefragt, sich dazu zu äußern. Haben sie auch. (Das Folgende sind Paraphrasen, keine wortwörtlichen Zitate.)

An der einen Stelle ist ein überflüssiges Leerzeichen am Zeilenende!

Ich so: Oh, okay, okay, ich mach das schnell weg. Ändern, neu hochladen. Warten.

Hier, da hast Du plötzlich Tabs benutzt, die sind aber davor nicht in der Datei gewesen, die Du geändert hast.

Ich so: Ohne Worte. (Don’t feed the…)

Du kopierst zu viel schon Bestehendes.

Ich dann so: Ja, aus dem und dem Grund. Antwort: Ah, okay, verstehe. Ich hab da eine Idee. Es vergehen ein paar Tage, eine Person baut ein paar Dateien um, damit ich einfacher meine Abwandlung unterbringen kann. Da saß ich natürlich erstmal davor und fragte mich, was ich damit jetzt soll, also wie ich das eigentlich benutze. Als ich das einmal verstanden hatte, war das auch sehr sinnvoll. Es dauerte also insgesamt nochmal ein paar Tage, dann war meine nächste Version hochgeladen. Nun mit Leerzeichen statt Tabs, wie es in der Puppet-Doku auch drinsteht. Reaktionen?

Ja, so hatte ich mir das gedacht. Hab noch’n paar Kommentare über Formatierung reingeschrieben und diese drei anderen Dateien da, die sind ja dann jetzt überflüssig.

Ich dachte mir so: Na, toll, immer noch keine „Note“… Noch jemand kommentiert. Ich gucke mir die Kommentare an.

Da, wo die Tabs waren, sind jetzt ja überall Leerzeichen drin. Wenn du die Tabs jetzt alle durch Leerzeichen ersetzt, dann werden zwischen deinen Versionen ganz viele bedeutungslose Unterschiede angezeigt.

Die Puppet-Doku spricht von 2 Leerzeichen. 4 sind also der schlechste Weg von allen.

Ich *schreib*: Ey hallo, ich kann das von mir aus noch ein letztes Mal ändern, wenn Ihr mal ne Ansage macht, wie jetzt eigentlich. Dann könnten wir nämlich mal zum inhaltlichen Feedback übergehen!

Ok, Ansage: Wenn du eine schon bestehende Datei änderst, dann mach es so wie die Person vor dir. Wenn das nicht eindeutig ist, dann mach es so wie andere in dem Projekt, vorausgesetzt, da gibt es einen Konsens, was hier glaub ich der Fall ist. Wenn das nicht so ist, dann gibt es hier (*schick Link*) einen Styleguide von unserem Projekt, da steht Puppet zwar nicht mit drin, aber wir nehmen Tabs.

Ich: *schweig*

Neue Person: Noch was Anderes: Wenn Du in git eine commit-Message schreibst, dann geh da drin nicht so genau auf die Entwicklung/Veränderungen ein. Das versteht später niemand mehr, so ohne Zusammenhang. Die Leute sehen dann deine ersten Einreichungen ja nicht. Um zu erklären, was du geändert hast, kannst du doch einen Bewertung ohne Note hinzufügen und dann dort einen Kommentare reinschreiben.

Tag des ersten Hochladens: 29.10., Tag des letzten Kommentars: 10.11., Tage der Fassungslosigkeit: 16.