generated from Comenius-Institut/Vorlage-OER-Communities
add-glossar #9
19
vereinbarungen.md
Normal file
19
vereinbarungen.md
Normal file
|
@ -0,0 +1,19 @@
|
|||
# Vereinbarungen zur Zusammenarbeit mit Git
|
||||
|
||||
Hier werden Vereinbarungen und Absprachen für die gemeinsame offene und effektive Zusammenarbeit mit Git festgehalten.
|
||||
|
||||
## Netiquette
|
||||
|
||||
**Du-Ermutigung:** Für die offene Zusammenarbeit braucht es ein respektvolles Miteinander und flache Hierarchien. Daher möchten wir dazu einladen, euch grundsätzlich zu duzen. Teamintern können natürlich auch andere Absprachen getroffen werden.
|
||||
|
||||
**Fehlerkultur:** Wir verstehen uns als lernende Organisation und möchten zum freien Ausprobieren und zum eigenständigen Machen einladen ohne Angst davor, etwas falsch zu machen. Vermeintliche Fehler und Irrtümer gehören dazu und helfen uns dabei, unsere Arbeitsabläufe und -prozesse zu verbessern.An vielen Stellen gibt es kein richtig oder falsch, sondern verschiedene Wege und Lösungen. Lasst uns gemeinsam Fehler machen und beheben und schauen, welche Arbeitsweisen sich für uns als praktikabel erweisen.
|
||||
|
||||
**Datenschutz:** Wir befinden uns im öffentlichen Raum: vertauliche Absprachen und Informationen, Zugangsdaten oder persönliche Daten wie Namen, Adressen, Telefonnr. etc. müssen geschützt werden und dürfen hier nicht veröffentlicht werden!
|
||||
|
||||
**Selbstbestimmung statt Fremdzuweisung:** In Issues können Zuständige festgelegt werden, das empfinden wir ohne vorherige Absprache als übergriffig. Damit nicht eine Person alle möglichen Issues zugewiesen bekommt, aber nicht die Kapazitäten hat, sie alle abzuarbeiten, sollte die betreffende Person zuvor gefragt werden, ob sie das Issue übernehmen kann / möchte und erst dann als zuständige Person für ein bestimmtes Issue festegelgt werden. Zuständigkeiten können auch teamintern besprochen, verteilt und in Issues festgelegt werden. Alternativ kann man auch in Issues über @-Markierungen konkrete Personen, für die das Issue relevant sein könnte oder die unterstützen könnten markieren. Dann können sie selbst entscheiden, ob sie sich dem Issue annehmen oder nicht. Personen können sich auch selbst als Zuständige zuweisen und somit selbst entscheiden, ob sie ein Issue bearbeiten können / wollen oder nicht.
|
||||
|
||||
**Nachvollziehbarkeit:** Durch Git sollen Arbeitsschritte transparent und für andere nachvollziehbar gemacht werden. Dazu ist es wichtig, dass Titel, Beschreibungen oder auch die Bezeichnungen bzw Zuordnungen von Labels etc. so präzise sind, dass auch andere, die nicht direkt involviert sind, verstehen, was gemeint ist. Insbesondere in Issues sollten Aufgaben so formuliert sein, dass deutlich wird, wer was bis wann zu tun hat.
|
||||
|
||||
**Feedbackkultur:** Damit Arbeitsprozesse vorankommen, Inhalte weiterentwickelt oder Fragen beantwortet werden können, braucht es euer Feedback. Bitte beachtet, dass eure Rückmeldungen gerne offen und direkt, aber immer konstruktiv sind.
|
||||
|
||||
**Reviewverfahren:** Mitarbeit ist erlaubt und ausdrücklich erwünscht! Dennoch hat es vermutlich niemand gerne, wenn andere einfach die Inhalte verändern. Aus Respekt möchten wir daher nahelegen, einen eigenen Branch für die Änderungen anzulegen und dann einen Pull Reuqest zu erstellen (siehe Dok zu Branch + PR -> muss noch erstellt werden). Das erscheint zwar umständlich zu sein, ist aber eine Wertschätzung gegenüber der Urheberin / des Urhebers, da sie/er dann entscheiden kann, ob die Änderungen angenommen werden sollen oder nicht und nicht vor vollendete Tatsachen gesetzt wird oder die Änderungen rückgängig machen muss.
|
Loading…
Reference in a new issue