Richtlinien für Port-Mentoren

Gründe für eine Mit-Mentorenschaft:

Gründe für einen Einzelmentor:

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).

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.

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.

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.

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.