path: root/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
        "../../../share/xml/freebsd50.dtd">
<!-- The FreeBSD Documentation Project
     The FreeBSD German Documentation Project

     $FreeBSD$
     basiert auf: r396332
-->
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="de">
  <info><title>Richtlinien f&uuml;r Port-Mentoren</title>
    

    <authorgroup>
      <author><orgname>Das &os; Ports-Management Team</orgname></author>
    </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>
  </info>

  <sect1 xml:id="port-mentor.guidelines">
    <title>Richtlinien f&uuml;r Mentor/Mentee Beziehungen</title>

    <para>Dieser Abschnitt soll dazu dienen, den Mythos des
      Mentoringprozesses zu entzaubern und gleichzeitig einen offenen
      Dialog zu f&uuml;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&auml;tsanspr&uuml;che an das Produkt,
      welches als Portbaum bekannt ist, zu gew&auml;hrleisten.</para>

    <sect2 xml: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&uuml;rfnis, anderen
	    Ihr Wissen mitzuteilen.</para>
	</listitem>

	<listitem>
	  <para>Die &uuml;bliche Bestrafung wird angewendet, da Sie es
	    mittlerweile Leid sind, die gute Arbeit von anderen Leuten
	    zu committen.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2 xml:id="mentor.comentor">
      <title>Mentor/Mit-Mentor</title>

      <para>Gr&uuml;nde f&uuml;r eine Mit-Mentorenschaft:</para>

      <itemizedlist>
        <listitem>
	  <para>Signifikanter Zeitzonenunterschied. Verf&uuml;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&uuml;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&ouml;pfe sind besser als einer allein.</para>
	</listitem>
      </itemizedlist>

      <para>Gr&uuml;nde f&uuml;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&uuml;nde f&uuml;r die Mit-Mentorenschaft
	    treffen auf Sie nicht zu.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2 xml:id="mentor.expectations">
      <title>Erwartungen</title>

      <para>Wir erwarten, dass Mentoren alle vorgeschlagenen Patche,
	zumindest f&uuml;r einen Anfangszeitraum, welcher mehr als
	eine oder zwei Wochen dauert, pr&uuml;fen und testweise bauen
	sollten.</para>

      <para>Wir erwarten, dass Mentoren die Verantwortung f&uuml;r die
	Aktionen Ihres Mentees &uuml;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&uuml;re
	des <link xlink:href="&url.books.porters-handbook;">Handbuch
	f&uuml;r Ports Committer</link>, die <link xlink:href="&url.articles.pr-guidelines;">PR-Richtlinien</link> sowie
	den <link xlink:href="&url.articles.committers-guide;">Committer's
	Guide</link> empfehlen. Obwohl es nicht notwendig ist, all
	diese Details im Ged&auml;chtnis zu behalten, sollte jeder
	Committer einen &Uuml;berblick &uuml;ber diese Dinge haben, um
	ein effizienter Teil der Gemeinschaft zu sein (und um
	Anf&auml;ngerfehler so weit wie m&ouml;glich zu vermeiden).</para>
    </sect2>

    <sect2 xml: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&auml;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&uuml;tzung seiner Ports sein.</para>

      <para>Es sollte eine Historie von Einsatzbereitschaft vorliegen,
	da es bekanntermassen Zeit und Aufwand ben&ouml;tigt, um einen
	Committer zu trainieren.  Falls jemand schon l&auml;ngere Zeit
	dabei ist und Zeit damit verbringt, zu beobachten, wie die
	Dinge funktionieren, ergibt sich eine Erwartungshaltung von
	angeh&auml;uftem Wissen. Viel zu oft schon haben wir
	beobachten m&uuml;ssen, dass jemand viele PRs schickt, um
	anschliessend im IRC aufzutauchen um zu fragen, wann das
	Commit-Bit gew&auml;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&ouml;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&ouml;st! Manche Dinge sind einfach schwer als
	Mengen abzubilden, also muss ein Mentor eine Einsch&auml;tzung
	machen und hoffen, dass portmgr zustimmt.</para>

    </sect2>
    <sect2 xml: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 &Auml;nderungen f&uuml;r
	<filename>Makefile</filename>, <filename>pkg-descr</filename>
	und andere Dateien beinhalten. Genauso kann dies
	Aktualisierungen der <varname>PORTVERSION</varname>, die keine
	<varname>plist</varname>-&Auml;nderungen sind, betreffen.
	Andere Umst&auml;nde k&ouml;nnen nach Gutd&uuml;nken des
	Mentors formuliert werden. Allerdings sollten
	Versions&auml;nderungen bei Ports, die andere Ports betreffen,
	vorher von einem Mentor gepr&uuml;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&uuml;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&uuml;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 xml: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&auml;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 <link xlink:href="http://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html">
	ersten aufgezeichneten Mit-Mentoren Commit</link>. 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 xml:id="mentee.expectations">
      <title>Erwartungen</title>

      <para>Wir erwarten von Mentees, dass diese f&uuml;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&auml;ge im IRC und auf den Mailinglisten
	ausw&auml;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&auml;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&ouml;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>