                         Richtlinien fu:r Port-Mentoren

  Das FreeBSD Ports-Management Team

   Version: 43184

   Copyright (c) 2011 Thomas Abthorpe, Chris Rees

   2013-11-13 von hrs.
   [ einzelne Abschnitte / komplettes Dokument ]

     ----------------------------------------------------------------------

   Inhaltsverzeichnis

   1. Richtlinien fu:r Mentor/Mentee Beziehungen

1. Richtlinien fu:r Mentor/Mentee Beziehungen

   Dieser Abschnitt soll dazu dienen, den Mythos des Mentoringprozesses zu
   entzaubern und gleichzeitig einen offenen Dialog zu fu:hren, um diese
   Richtlinien anzupassen und zu erweitern. Es gibt bereits sehr viele Regeln
   in unserem Leben und wir sind auch keine Regierungsorganisation, die
   Gesetze aufzwingt. Stattdessen verstehen wir uns als eine Gemeinschaft von
   gleichgesinnten Individuen, die an einem gemeinsamen Ziel arbeiten, um die
   Qualita:tsanspru:che an das Produkt, welches als Portbaum bekannt ist, zu
   gewa:hrleisten.

  1.1. Warum Mentor sein?

     * Die meisten von uns kamen durch die Hife eines Mentors in das Projekt
       hinein. Also sollte man jemand anderem auch diesen Gefallen tun.

     * Sie haben das unwiderstehliche Bedu:rfnis, anderen Ihr Wissen
       mitzuteilen.

     * Die u:bliche Bestrafung wird angewendet, da Sie es mittlerweile Leid
       sind, die gute Arbeit von anderen Leuten zu committen.

  1.2. Mentor/Mit-Mentor

   Gru:nde fu:r eine Mit-Mentorenschaft:

     * Signifikanter Zeitzonenunterschied. Verfu:gbare Mentoren, mit denen
       man interaktiv Dinge via Instant Messenger besprechen kann, sind
       extrem hilfreich.

     * Potentielle Sprachbarriere. Ja, FreeBSD ist, wie die meiste
       Softwareentwicklung auch, sehr Englisch-orientiert. Jedoch kann ein
       Mentor, der die eigene Sprache spricht, hilfreich sein.

     * ENOTIME! Solange es keinen 30-Stunden Tag und eine 8-Tage Woche gibt,
       haben manche von uns nur eine begrenzte Menge Zeit zur Verfu:gung.
       Diese Last mit jemandem zu teilen macht die Sache einfacher.

     * Ein Mentor-Neuling kann von den Erfahrungen eines erfahrenen
       Committers bzw. Mentors profitieren.

     * Zwei Ko:pfe sind besser als einer allein.

   Gru:nde fu:r einen Einzelmentor:

     * Sie arbeiten nicht so gut mit anderen zusammen.

     * Sie bevorzugen eine 1:1-Beziehung.

     * Die Gru:nde fu:r die Mit-Mentorenschaft treffen auf Sie nicht zu.

  1.3. Erwartungen

   Wir erwarten, dass Mentoren alle vorgeschlagenen Patche, zumindest fu:r
   einen Anfangszeitraum, welcher mehr als eine oder zwei Wochen dauert,
   pru:fen und testweise bauen sollten.

   Wir erwarten, dass Mentoren die Verantwortung fu:r die Aktionen Ihres
   Mentees u:bernehmen. Ein Mentor sollte hinter den Commits des Mentees
   stehen, sowohl implizit als auch explizit.

   Wir erwarten, dass Mentoren ihre Mentees die Lektu:re des Handbuch fu:r
   Ports Committer, die PR-Richtlinien sowie den Committer's Guide empfehlen.
   Obwohl es nicht notwendig ist, all diese Details im Geda:chtnis zu
   behalten, sollte jeder Committer einen U:berblick u:ber diese Dinge haben,
   um ein effizienter Teil der Gemeinschaft zu sein (und um Anfa:ngerfehler
   so weit wie mo:glich zu vermeiden).

  1.4. Auswahl eines Mentees

   Es existiert keine definierte Regel, die festlegt, dass ein Kandidat
   bereit ist. Es kann eine Kombination der Anzahl von PRs sein, die an GNATS
   geschickt wurden, die Anzahl an Ports, die von dieser Person gepflegt
   werden, die Ha:figkeit von Ports-Aktualisierungen bzw. die Menge von
   Beteiligungen in einem bestimmten Bereich, z.B. GNOME, KDE, Gecko oder
   andere.

   Ein Kandidat sollte fasst keine Auszeiten haben, auf Anfragen antworten
   und generell sehr hilfreich in der Unterstu:tzung seiner Ports sein.

   Es sollte eine Historie von Einsatzbereitschaft vorliegen, da es
   bekanntermassen Zeit und Aufwand beno:tigt, um einen Committer zu
   trainieren. Falls jemand schon la:ngere Zeit dabei ist und Zeit damit
   verbringt, zu beobachten, wie die Dinge funktionieren, ergibt sich eine
   Erwartungshaltung von angeha:uftem Wissen. Viel zu oft schon haben wir
   beobachten mu:ssen, dass jemand viele PRs schickt, um anschliessend im IRC
   aufzutauchen um zu fragen, wann das Commit-Bit gewa:hrt wird.

   Eine Mailingliste abonniert zu haben und dieser zu folgen ist vorteilhaft.
   Es gibt keine echte Erwartungshaltung, dass durch das schreiben auf einer
   Mailingliste jemand zum Committer wird, doch es zeigt dennoch die
   Bereitschaft. Manche Mails bieten Einsichten in das Wissen eines
   Kandidaten genauso, wie gut jemand mit anderen interagiert. Gleichfalls
   kann durch Teilnahme im IRC jemand ein ho:heres Ansehen erhalten.

   Fragen Sie sechs verschiedene Committer, wieviele PRs jemand vor seiner
   Nominierung einschicken sollte und Sie erhalten sechs verschiedene
   Antworten. Fragen Sie diese Individuen wie lange jemand schon etwas
   beigetragen haben sollte, ergibt sich das gleiche Dilemma. Wieviele Ports
   sollte jemand als Minimum betreuen? Jetzt haben wir wirklich eine
   Diskussion ausgelo:st! Manche Dinge sind einfach schwer als Mengen
   abzubilden, also muss ein Mentor eine Einscha:tzung machen und hoffen,
   dass portmgr zustimmt.

  1.5. Dauer der Mentorenschaft

   Mit der Zeit wird das Vertrauen in jemanden wachsen und der Mentee wird
   "implizite" Commitrechte erhalten. Dies kann triviale A:nderungen fu:r
   Makefile, pkg-descr und andere Dateien beinhalten. Genauso kann dies
   Aktualisierungen der PORTVERSION, die keine plist-A:nderungen sind,
   betreffen. Andere Umsta:nde ko:nnen nach Gutdu:nken des Mentors formuliert
   werden. Allerdings sollten Versionsa:nderungen bei Ports, die andere Ports
   betreffen, vorher von einem Mentor gepru:ft werden.

   Genauso wie wir alle verschiedene Individuen sind, besitzt jeder Mentee
   unterschiedliche Lernkurven, Zeitinvestitionen und andere
   Einflussfaktoren, die zu der Zeit beitragen, bevor jemand "allein fliegt".
   Empirisch sollte ein Mentee fu:r mindestens 3 Monate beobachtet werden.
   90-100 Commits ist ein weiteres Ziel, dass ein Mentor nutzen kann, bevor
   jemand als Mentee entlassen wird. Andere Faktoren, die man vor der
   Freilassung seines Mentees beru:cksichtigen sollte, ist die Anzahl der
   gemachten Fehler, die erhaltenen QATs, usw. Falls immer noch Fehler
   gemacht werden, ist die Betreuung durch einen Mentor weiterhin notwendig.

  1.6. Mentor/Mit-Mentor Debatten

   Wenn eine Anfrage an portmgr geht, sieht dies normalerweise so aus: "I
   propose 'foo' for a ports commit bit, I will co-mentor with 'bar'".
   Anfrage wurde erhalten, abgestimmt und die Entscheidung wird getragen.

   Der Mentor ist die prima:re Kontaktperson, oder zumindest der "erste unter
   gleichgestellten", der Co-Mentor dient als Absicherung.

   Mancher Schurke, dessen Name hier nicht genannt werden soll, machte den
   ersten aufgezeichneten Mit-Mentoren Commit. Es wurden auch schon
   Mit-Mentoren commits im src-Baum beobachtet. Macht dieses Vorgehen die
   Sache richtig? Ist es falsch? Es scheint Teil dessen zu sein, wie die
   Dinge sich entwickeln.

  1.7. Erwartungen

   Wir erwarten von Mentees, dass diese fu:r konstruktive Kritik aus der
   Gemeinschaft offen sind. Es gibt immer noch viel "Wissen", welches nicht
   geschrieben steht. Richtig auf konstruktive Kritik zu antworten ist was
   wir hoffen zu erkennen, wenn wir jemanden anhand seiner Beitra:ge im IRC
   und auf den Mailinglisten auswa:hlen.

   Wir warnen Mentees davor, dass manche Kritik, die sie erhalten werden,
   weniger "konstruktiv" als andere sein wird (egal ob durch
   Versta:ndigungsprobleme, die durch die Sprache bedingt sind oder durch
   Pingeligkeit). Mit dieser Art von Kritik kultiviert umzugehen ist auch
   Teil davon, einer grossen Gemeinschaft anzugeho:ren. Bei spezifischen
   Problemen mit bestimmten Leuten oder falls fragen aufkommen, hoffen wir
   dass diese sich an ein Mitglied von portmgr wenden, entweder via IRC oder
   per eMail.
