                     Richtlinien fu:r Port-Mentoren

  Das FreeBSD Ports-Management Team

   $FreeBSD:
   release/8.4.0/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml
   40614 2013-01-13 17:04:52Z bcr $

   Copyright (c) 2011 Thomas Abthorpe, Chris Rees

   $FreeBSD:
   release/8.4.0/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml
   40614 2013-01-13 17:04:52Z bcr $

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

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.

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

     Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
                   <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail
                an <de-bsd-translators@de.FreeBSD.org>.
