266 lines
10 KiB
XML
266 lines
10 KiB
XML
<?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>
|