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 Bedürfnis, anderen Ihr Wissen mitzuteilen.

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

1.2 Mentor/Mit-Mentor

Gründe für eine Mit-Mentorenschaft:

• Signifikanter Zeitzonenunterschied. Verfü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 Verfü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 Köpfe sind besser als einer allein.

Gründe für einen Einzelmentor:

• Sie arbeiten nicht so gut mit anderen zusammen.

• Sie bevorzugen eine 1:1-Beziehung.

• Die Gründe für die Mit-Mentorenschaft treffen auf Sie nicht zu.

1.3 Erwartungen

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

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

Wir erwarten, dass Mentoren ihre Mentees die Lektüre des Handbuch für Ports Committer, die PR-Richtlinien sowie den Committer's Guide empfehlen. Obwohl es nicht notwendig ist, all diese Details im Gedächtnis zu behalten, sollte jeder Committer einen Überblick über diese Dinge haben, um ein effizienter Teil der Gemeinschaft zu sein (und um Anfängerfehler so weit wie mö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 Hä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 Unterstützung seiner Ports sein.

Es sollte eine Historie von Einsatzbereitschaft vorliegen, da es bekanntermassen Zeit und Aufwand benötigt, um einen Committer zu trainieren. Falls jemand schon längere Zeit dabei ist und Zeit damit verbringt, zu beobachten, wie die Dinge funktionieren, ergibt sich eine Erwartungshaltung von angehäuftem Wissen. Viel zu oft schon haben wir beobachten müssen, dass jemand viele PRs schickt, um anschliessend im IRC aufzutauchen um zu fragen, wann das Commit-Bit gewä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 hö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 ausgelöst! Manche Dinge sind einfach schwer als Mengen abzubilden, also muss ein Mentor eine Einschä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 Änderungen für Makefile, pkg-descr und andere Dateien beinhalten. Genauso kann dies Aktualisierungen der PORTVERSION, die keine plist-Änderungen sind, betreffen. Andere Umstände können nach Gutdünken des Mentors formuliert werden. Allerdings sollten Versionsänderungen bei Ports, die andere Ports betreffen, vorher von einem Mentor geprü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 fü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 berü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 primä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 fü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 Beiträge im IRC und auf den Mailinglisten auswählen.

Wir warnen Mentees davor, dass manche Kritik, die sie erhalten werden, weniger “konstruktiv” als andere sein wird (egal ob durch Verständigungsprobleme, die durch die Sprache bedingt sind oder durch Pingeligkeit). Mit dieser Art von Kritik kultiviert umzugehen ist auch Teil davon, einer grossen Gemeinschaft anzugehö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.