- MFH

2 files changed, 288 insertions, 0 deletions

diff --git a/de_DE.ISO8859-1/articles/port-mentor-guidelines/Makefile b/de_DE.ISO8859-1/articles/port-mentor-guidelines/Makefile
new file mode 100644
index 0000000000..08088577f8
--- /dev/null
+++ b/de_DE.ISO8859-1/articles/port-mentor-guidelines/Makefile
@@ -0,0 +1,22 @@
+#
+#    The FreeBSD Documentation Project
+#    The FreeBSD German Documentation Project
+#
+#    $FreeBSD$
+#    basiert auf: r39631
+#
+# Article: Port Mentor Guidelines
+#
+
+DOC?= article
+
+FORMATS?= html
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?= gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS=		article.xml
+
+DOC_PREFIX?= ${.CURDIR}/../../..
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml b/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml
new file mode 100644
index 0000000000..275eccc463
--- /dev/null
+++ b/de_DE.ISO8859-1/articles/port-mentor-guidelines/article.xml
@@ -0,0 +1,266 @@
+<?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&uuml;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&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 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 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 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 <ulink url="&url.books.porters-handbook;">Handbuch
+	f&uuml;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&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 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 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 <makevar>PORTVERSION</makevar>, die keine
+	<makevar>plist</makevar>-&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 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 <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&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>