Im Blick auf Probleme in der Vergangenheit, sowie der Umstellung und Änderung der Verwendung und des Sinns der Mailingliste, wird gehofft, dass diese Best Practices eingehalten werden.
Ein Mail-Austausch sollte von allen verfolgt werden können, welche sich bisher beteilig haben oder angeschrieben wurden. Ausnahme bilden der Versand von sensiblen und datenschutzwürdiger Daten.
Eine gute Mail schreiben
Eine "gute" Mail erfüllt die folgende Kriterien.
Bevor eine Mail versendet wird sollte..
Besonderheiten
Für info@ und hilfe@ bremen.freifunk.net sollten folgende Besonderheiten beachtet werden.
Bitte keine E-Mails scheuen. Beispiel nehmen an Hackerspace Bremen Malingliste: viele E-Mails und man sucht sich das raus, was einen interessiert.
Vorbereitung
Bevor ein Konakt hergestellt wird, soll im Ticketsystem nach einem bestehenden Eintrag gesucht werden.
Falls ein Eintrag besteht, sind die bereits vorhanden Informationen zu sichten, bevor man dem Zuständigen Freifunker seine Hilfe anbietet.
Falls kein Eintrag vorhanden ist, soll der entsprechende Standort und man selbst als "zuständig" eingetragen werden.
Dies soll Doppelanfragen, Missverständnisse, sowie dazwischenfunken bei bestehenden Projekten verhindern.
Initialer Kontakt
Um persönlich und greifbar zu wirken, empfiehlt sich für den Erstkontakt ein Telefonat oder ein direktes Gespräch, abhängig von der Art des Standorts.
Bei Firmen oder generell Standorte mit vielen möglichen Ansprechpartnern, sollte vorab der richtige und zuständige Ansprechpartner ermittelt werden. Es bietet sich ein Gespräch mit dem Empfang an. Wenn der Ansprechpartner kurz und knapp gefragt wurde, ob Interesse an Freifunk und WLAN besteht, sollen weiterführende Informationen angeboten werden, über das Medium der Wahl des Ansprechpartners. Das kann ein Treffen zu einem abgemachten Termin, eine Info-Email oder das Fortführen des Telefonates sein.
Kleinen Läden und Standorten, bei welchen der Chef oft vor Ort ist, stattet man am besten direkt einen Besuch ab. So lässt sich auch die Situation vor Ort einschätzen.
Der Angesprochene soll nicht mit Eventualitäten, zukünfitgen Projekten, sowie spezifischen Technik- und Gerätedetails bombardiert werden! Aufdringlichkeit kann einen sonst Interessierten, schnell vergraulen!
In allen Fällen, geht es darum, Interesse an Freifunk zu wecken und den Angesprochenen das Teilnehmen an Freifunk so einfach und zugänglich wie möglich zu machen.
Änderungen kommentieren
Die Seiten dieses Wikis werden in einem Git-Repository gespeichert. Bei jeder Änderung einer Datei in einem Git-Repo wird eine möglichst eindeutige und verständliche Kurzbeschreibung hinzugefügt.
Seiten in diesem Wiki werden bei jedem Speichern mit einer Standard-commit-message versehen, die nur aussagt, dass und wann und welche Datei in welchem Format bearbeitet wurde.
Anstatt mit einem Klick auf das Disketten-Symbol die bearbeitete Seite zu speichern, ist jeder dazu angehalten den Sprechblasen-Button rechts daneben zu verwenden und seiner Bearbeitung einen Kommentar hinzuzufügen.
Am besten lässt man den bereits vorhanden Text stehen und schreibt direkt dahinter was gerade geändert wurde, sowie euren Namen angeführt von einem ^
, falls ihr wollt. So lässt sich im Verlauf einer Seite besser Nachvollziehen, was wann passiert ist. Mit Stehenlassen und Erweitern des bereits vorhanden Kommentars, kann hier direkt nachvollzogen werden, welche Seite bearbeitet wurde.
Oft speichern!
Nicht unbedingt als Richtlinie gedacht, ist es doch eine gute Verhaltensweise um Datenverlust vorzubeugen. Zusätzlich kann bei öfterem Speichern genauer in den Kommentaren festgehalten werden, was geändert wurde.
Namen oder Kontakt zu Infos schreiben
Bei Entwürfen, Tagesordnungen oder anderen Seiten in die Informationen geschrieben werden ist darauf zu achten seinen oder den betreffenden Namen oder Nick anzumerken. Bevorzugt in diesem Format [coolsterTyp]
.
Dies soll Nachfragen ermöglichen, sowie Fragen zuordnenbar zu machen, damit nicht Informationen aus dem Nichts ohne Beleg auftauchen oder Antworten den Fragesteller nicht erreichen._
Failed to render page: conflicting chdir during another chdir block