svn commit: r44933 - head/en_US.ISO8859-1/articles/port-mentor-guidelines
Benedict Reuschling
bcr at FreeBSD.org
Sat May 24 15:05:42 UTC 2014
Author: bcr
Date: Sat May 24 15:05:41 2014
New Revision: 44933
URL: http://svnweb.freebsd.org/changeset/doc/44933
Log:
Whitespace fixes only. Translators can ignore.
Modified:
head/en_US.ISO8859-1/articles/port-mentor-guidelines/article.xml
Modified: head/en_US.ISO8859-1/articles/port-mentor-guidelines/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/port-mentor-guidelines/article.xml Sat May 24 12:22:13 2014 (r44932)
+++ head/en_US.ISO8859-1/articles/port-mentor-guidelines/article.xml Sat May 24 15:05:41 2014 (r44933)
@@ -1,12 +1,16 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
-<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
- <info><title>Port Mentor Guidelines</title>
-
+<article xmlns="http://docbook.org/ns/docbook"
+ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
+ xml:lang="en">
+ <info>
+ <title>Port Mentor Guidelines</title>
<authorgroup>
- <author><orgname>The &os; Ports Management Team</orgname></author>
+ <author>
+ <orgname>The &os; Ports Management Team</orgname>
+ </author>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
@@ -15,7 +19,8 @@
<copyright>
<year>2011</year>
- <holder role="mailto:tabthorpe at FreeBSD.org">Thomas Abthorpe</holder>
+ <holder role="mailto:tabthorpe at FreeBSD.org">Thomas
+ Abthorpe</holder>
<holder role="mailto:crees at FreeBSD.org">Chris Rees</holder>
</copyright>
</info>
@@ -43,13 +48,13 @@
</listitem>
<listitem>
- <para>You have an irresistible urge to inflict knowledge
- on others.</para>
+ <para>You have an irresistible urge to inflict knowledge on
+ others.</para>
</listitem>
<listitem>
<para>The usual punishment applies because you are sick and
- tired of committing somebody else's good work!</para>
+ tired of committing somebody else's good work!</para>
</listitem>
</itemizedlist>
</sect2>
@@ -60,10 +65,10 @@
<para>Reasons for a co-mentorship:</para>
<itemizedlist>
- <listitem>
- <para>Significant timezone differential.
- Accessible, interactive mentor(s) available via
- IM is extremely helpful!</para>
+ <listitem>
+ <para>Significant timezone differential. Accessible,
+ interactive mentor(s) available via IM is extremely
+ helpful!</para>
</listitem>
<listitem>
@@ -71,7 +76,7 @@
English oriented, as is most software development,
however, having a mentor who can speak a native language
can be very useful.</para>
- </listitem>
+ </listitem>
<listitem>
<para>ENOTIME! Until there is a 30 hour day, and an 8 day
@@ -112,19 +117,20 @@
<title>Expectations</title>
<para>We expect mentors to review and test-build all proposed
- patches, at least for an initial period lasting more than a
+ patches, at least for an initial period lasting more than a
week or two.</para>
- <para>We expect that mentors should take responsibility for
- the actions of their mentee. A mentor should follow up with
- all commits the mentee makes, both approved
- and implicit.</para>
+ <para>We expect that mentors should take responsibility for the
+ actions of their mentee. A mentor should follow up with all
+ commits the mentee makes, both approved and implicit.</para>
<para>We expect mentors to make sure their mentees read the
<link xlink:href="&url.books.porters-handbook;">Porter's
- Handbook</link>, the <link xlink:href="&url.articles.pr-guidelines;">PR handling guide</link>, and
- the <link xlink:href="&url.articles.committers-guide;">Committer's
- Guide</link>. While it's not necessary to memorize all the
+ Handbook</link>, the <link
+ xlink:href="&url.articles.pr-guidelines;">PR handling
+ guide</link>, and the <link
+ xlink:href="&url.articles.committers-guide;">Committer's
+ Guide</link>. While it's not necessary to memorize all the
details, every committer needs to have an overview of these
things to be an effective part of the community (and avoid as
many rookie mistakes as possible).</para>
@@ -133,101 +139,108 @@
<sect2 xml:id="mentees">
<title>Selecting a mentee</title>
- <para>There is no defined rule for what makes a candidate ready; it
- can be a combination of number of PRs they have submitted to
- <application>GNATS</application>, the number of ports maintained,
- frequency of ports updates and/or level of participation in a
- particular area of interest, e.g. <application>GNOME</application>,
- <application>KDE</application>, <application>Gecko</application>
- or others.</para>
-
- <para>A candidate should have almost no timeouts, be responsive to
- requests, and generally helpful in supporting their ports.</para>
+ <para>There is no defined rule for what makes a candidate ready;
+ it can be a combination of number of PRs they have submitted
+ to <application>GNATS</application>, the number of ports
+ maintained, frequency of ports updates and/or level of
+ participation in a particular area of interest, e.g.
+ <application>GNOME</application>,
+ <application>KDE</application>,
+ <application>Gecko</application> or others.</para>
+
+ <para>A candidate should have almost no timeouts, be responsive
+ to requests, and generally helpful in supporting their
+ ports.</para>
<para>There must be a history of commitment, as it is widely
- understood that training a committer requires time and effort. If
- somebody has been around longer, and spent the time observing how
- things are done, there is some anticipation of accumulated
- knowledge. All too often we have seen a maintainer submit a few
- PRs, show up in IRC and ask when they will be given a commit
- bit.</para>
-
- <para>Being subscribed to, and following the mailing lists is very
- beneficial. There is no real expectation that submitting posts on
- the lists will make somebody a committer, but it demonstrates a
- commitment. Some mails offer insights into the knowledge of a
- candidate as well how they interact with others.
- Similarly participating in IRC can give somebody a
+ understood that training a committer requires time and effort.
+ If somebody has been around longer, and spent the time
+ observing how things are done, there is some anticipation of
+ accumulated knowledge. All too often we have seen a
+ maintainer submit a few PRs, show up in IRC and ask when they
+ will be given a commit bit.</para>
+
+ <para>Being subscribed to, and following the mailing lists is
+ very beneficial. There is no real expectation that submitting
+ posts on the lists will make somebody a committer, but it
+ demonstrates a commitment. Some mails offer insights into the
+ knowledge of a candidate as well how they interact with
+ others. Similarly participating in IRC can give somebody a
higher profile.</para>
- <para>Ask six different committers how many PRs a maintainer should
- submit prior to being nominated, and you will get six different
- answers. Ask those same individuals how long somebody should have
- been participating, same dilemma. How many ports should they have
- at a minimum? Now we have a bikeshed! Some things are just hard
- to quantify, a mentor will just have to use their best judgement,
- and hope that portmgr agrees.</para>
+ <para>Ask six different committers how many PRs a maintainer
+ should submit prior to being nominated, and you will get six
+ different answers. Ask those same individuals how long
+ somebody should have been participating, same dilemma. How
+ many ports should they have at a minimum? Now we have a
+ bikeshed! Some things are just hard to quantify, a mentor
+ will just have to use their best judgement, and hope that
+ portmgr agrees.</para>
</sect2>
<sect2 xml:id="mentorship.duration">
<title>Mentorship duration</title>
<para>As the trust level develops and grows, the mentee may be
- granted <quote>implicit</quote> commit rights. This can include
- trivial changes to a <filename>Makefile</filename>,
+ granted <quote>implicit</quote> commit rights. This can
+ include trivial changes to a <filename>Makefile</filename>,
<filename>pkg-descr</filename> etc. Similarly, it may include
<varname>PORTVERSION</varname> updates that do not include
<varname>plist</varname> changes. Other circumstances may be
- formulated at the discretion of the Mentor. However, during the
- period of mentorship, a port version bump that affects dependent
- ports should be checked by a mentor.</para>
+ formulated at the discretion of the Mentor. However, during
+ the period of mentorship, a port version bump that affects
+ dependent ports should be checked by a mentor.</para>
<para>Just as we are all varied individuals, each mentee has
- different learning curves, time commitments, and other influencing
- factors that will contribute to the time required before they can
- <quote>fly solo</quote>. Empirically, a mentee should be observed
- for at least 3 months. 90-100 commits is another target that a
- mentor could use before releasing a mentee. Other factors to
- consider prior releasing a mentee are the number of mistakes they
- may have made, QATs received etc. If they are still making rookie
- mistakes, they still require mentor guidance.</para>
+ different learning curves, time commitments, and other
+ influencing factors that will contribute to the time required
+ before they can <quote>fly solo</quote>. Empirically, a
+ mentee should be observed for at least 3 months. 90-100
+ commits is another target that a mentor could use before
+ releasing a mentee. Other factors to consider prior releasing
+ a mentee are the number of mistakes they may have made, QATs
+ received etc. If they are still making rookie mistakes, they
+ still require mentor guidance.</para>
</sect2>
<sect2 xml:id="mentor.comentor.debate">
<title>Mentor/Co-Mentor debate</title>
<para>When a request gets to portmgr, it usually reads as,
- <quote>I propose 'foo' for a ports commit bit, I will co-mentor
- with 'bar'</quote>. Proposal received, voted, and carried.</para>
+ <quote>I propose 'foo' for a ports commit bit, I will
+ co-mentor with 'bar'</quote>. Proposal received, voted, and
+ carried.</para>
<para>The mentor is the primary point of contact or the
- <quote>first among equals</quote>, the co-mentor is the backup.</para>
+ <quote>first among equals</quote>, the co-mentor is the
+ backup.</para>
<para>Some reprobate, whose name shall be withheld, made the
- <link xlink:href="http://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html">
- first recorded co-mentor commit</link>. Similar co-mentor commits
- have also been spotted in the src tree. Does this make it right?
- Does this make it wrong? It seems to be part of the evolution of
- how things are done.</para>
+ <link
+ xlink:href="http://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html">
+ first recorded co-mentor commit</link>. Similar co-mentor
+ commits have also been spotted in the src tree. Does this
+ make it right? Does this make it wrong? It seems to be part
+ of the evolution of how things are done.</para>
</sect2>
<sect2 xml:id="mentee.expectations">
<title>Expectations</title>
- <para>We expect mentees to be prepared for constructive criticism
- from the community. There's still a lot of <quote>lore</quote>
- that isn't written down. Responding well to constructive criticism
- is what we hope we are selecting for by first reviewing their
- existing contributions on IRC and mailing lists.</para>
-
- <para>We warn mentees that some of the criticism they receive may be
- less <quote>constructive</quote> than others, (whether through
- language communication problems, or excessive nit-picking), and
- that dealing with this gracefully is just part of being in a large
- community. In case of specific problems with specific people, or
- any questions, we hope that they will approach a portmgr member on
- IRC or by email.</para>
-
+ <para>We expect mentees to be prepared for constructive
+ criticism from the community. There's still a lot of
+ <quote>lore</quote> that isn't written down. Responding well
+ to constructive criticism is what we hope we are selecting for
+ by first reviewing their existing contributions on IRC and
+ mailing lists.</para>
+
+ <para>We warn mentees that some of the criticism they receive
+ may be less <quote>constructive</quote> than others, (whether
+ through language communication problems, or excessive
+ nit-picking), and that dealing with this gracefully is just
+ part of being in a large community. In case of specific
+ problems with specific people, or any questions, we hope that
+ they will approach a portmgr member on IRC or by email.</para>
</sect2>
</sect1>
</article>
More information about the svn-doc-all
mailing list