<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
"../../../share/xml/freebsd45.dtd">
<!-- The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
basiert auf: r396332
-->
<article lang="en">
<articleinfo>
<title>Richtlinien für Port-Mentoren</title>
<authorgroup>
<corpauthor>Das &os; Ports-Management Team</corpauthor>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<releaseinfo>$FreeBSD$</releaseinfo>
<copyright>
<year>2011</year>
<holder role="mailto:tabthorpe@FreeBSD.org">Thomas
Abthorpe</holder>
<holder role="mailto:crees@FreeBSD.org">Chris Rees</holder>
</copyright>
</articleinfo>
<sect1 id="port-mentor.guidelines">
<title>Richtlinien für Mentor/Mentee Beziehungen</title>
<para>Dieser Abschnitt soll dazu dienen, den Mythos des
Mentoringprozesses zu entzaubern und gleichzeitig einen offenen
Dialog zu fü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 Qualitätsansprüche an das Produkt,
welches als Portbaum bekannt ist, zu gewährleisten.</para>
<sect2 id="why.mentor">
<title>Warum Mentor sein?</title>
<itemizedlist>
<listitem>
<para>Die meisten von uns kamen durch die Hife eines Mentors
in das Projekt hinein. Also sollte man jemand anderem auch
diesen Gefallen tun.</para>
</listitem>
<listitem>
<para>Sie haben das unwiderstehliche Bedürfnis, anderen
Ihr Wissen mitzuteilen.</para>
</listitem>
<listitem>
<para>Die übliche Bestrafung wird angewendet, da Sie es
mittlerweile Leid sind, die gute Arbeit von anderen Leuten
zu committen.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="mentor.comentor">
<title>Mentor/Mit-Mentor</title>
<para>Gründe für eine Mit-Mentorenschaft:</para>
<itemizedlist>
<listitem>
<para>Signifikanter Zeitzonenunterschied. Verfügbare
Mentoren, mit denen man interaktiv Dinge via Instant
Messenger besprechen kann, sind extrem hilfreich.</para>
</listitem>
<listitem>
<para>Potentielle Sprachbarriere. Ja, &os; ist, wie die
meiste Softwareentwicklung auch, sehr Englisch-orientiert.
Jedoch kann ein Mentor, der die eigene Sprache spricht,
hilfreich sein.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>Ein Mentor-Neuling kann von den Erfahrungen eines
erfahrenen Committers bzw. Mentors profitieren.</para>
</listitem>
<listitem>
<para>Zwei Köpfe sind besser als einer allein.</para>
</listitem>
</itemizedlist>
<para>Gründe für einen Einzelmentor:</para>
<itemizedlist>
<listitem>
<para>Sie arbeiten nicht so gut mit anderen zusammen.</para>
</listitem>
<listitem>
<para>Sie bevorzugen eine 1:1-Beziehung.</para>
</listitem>
<listitem>
<para>Die Gründe für die Mit-Mentorenschaft
treffen auf Sie nicht zu.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="mentor.expectations">
<title>Erwartungen</title>
<para>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.</para>
<para>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.</para>
<para>Wir erwarten, dass Mentoren ihre Mentees die Lektüre
des <ulink url="&url.books.porters-handbook;">Handbuch
für Ports Committer</ulink>, die <ulink
url="&url.articles.pr-guidelines;">PR-Richtlinien</ulink> sowie
den <ulink url="&url.articles.committers-guide;">Committer's
Guide</ulink> 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).</para>
</sect2>
<sect2 id="mentees">
<title>Auswahl eines Mentees</title>
<para>Es existiert keine definierte Regel, die festlegt, dass
ein Kandidat bereit ist. Es kann eine Kombination der Anzahl
von PRs sein, die an <application>GNATS</application>
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. <application>GNOME</application>,
<application>KDE</application>,
<application>Gecko</application> oder andere.</para>
<para>Ein Kandidat sollte fasst keine Auszeiten haben, auf
Anfragen antworten und generell sehr hilfreich in der
Unterstützung seiner Ports sein.</para>
<para>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.</para>
<para>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.</para>
<para>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.</para>
</sect2>
<sect2 id="mentorship.duration">
<title>Dauer der Mentorenschaft</title>
<para>Mit der Zeit wird das Vertrauen in jemanden wachsen und
der Mentee wird <quote>implizite</quote> Commitrechte
erhalten. Dies kann triviale Änderungen für
<filename>Makefile</filename>, <filename>pkg-descr</filename>
und andere Dateien beinhalten. Genauso kann dies
Aktualisierungen der <makevar>PORTVERSION</makevar>, die keine
<makevar>plist</makevar>-Ä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.</para>
<para>Genauso wie wir alle verschiedene Individuen sind, besitzt
jeder Mentee unterschiedliche Lernkurven, Zeitinvestitionen
und andere Einflussfaktoren, die zu der Zeit beitragen, bevor
jemand <quote>allein fliegt</quote>. 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.</para>
</sect2>
<sect2 id="mentor.comentor.debate">
<title>Mentor/Mit-Mentor Debatten</title>
<para>Wenn eine Anfrage an portmgr geht, sieht dies
normalerweise so aus: <quote>I propose 'foo' for a ports
commit bit, I will co-mentor with 'bar'</quote>. Anfrage wurde
erhalten, abgestimmt und die Entscheidung wird
getragen.</para>
<para>Der Mentor ist die primäre Kontaktperson, oder
zumindest der <quote>erste unter gleichgestellten</quote>, der
Co-Mentor dient als Absicherung.</para>
<para>Mancher Schurke, dessen Name hier nicht genannt werden
soll, machte den <ulink
url="http://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html">
ersten aufgezeichneten Mit-Mentoren Commit</ulink>. 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.</para>
</sect2>
<sect2 id="mentee.expectations">
<title>Erwartungen</title>
<para>Wir erwarten von Mentees, dass diese für konstruktive
Kritik aus der Gemeinschaft offen sind. Es gibt immer noch
viel <quote>Wissen</quote>, 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.</para>
<para>Wir warnen Mentees davor, dass manche Kritik, die sie
erhalten werden, weniger <quote>konstruktiv</quote> 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.</para>
</sect2>
</sect1>
</article>