svn commit: r51933 - head/en_US.ISO8859-1/articles/committers-guide

[Eitan Adler]

Author: eadler
Date: Sat Jun 30 05:56:32 2018
New Revision: 51933
URL: https://svnweb.freebsd.org/changeset/doc/51933

Log:
  Committers guide: wordsmith the section on maintainers
  
  - remove an aside about reading the mailing list. This is taken care of
    by the later sentence about reading revision history
  - use a slightly stronger admonition ("important" instead of "note") for
    the comments about not sending mail directly to the maintainer.
  - Refer explicitly to the 'MAINTAINERS' file at the root of the tree
  - Use the language of "asking for a review" instead of "sending the
    change to them" which, again, encourages a more public interaction.
  - Remove the weasel language "it may help" and just encourage people to
    scan the history

Modified:
  head/en_US.ISO8859-1/articles/committers-guide/article.xml

Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml	Sat Jun 30 05:33:32 2018	(r51932)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml	Sat Jun 30 05:56:32 2018	(r51933)
@@ -2674,18 +2674,17 @@ Relnotes:           yes</programlisting>
       probably little need to check with other committers before
       jumping in with a commit.  Working on a bug in an area of the
       system which is clearly orphaned (and there are a few such
-      areas, to our shame), the same applies.  Trying to modify
-      something which is clearly being actively maintained by someone
-      else (and it is only by watching the
-      <literal><replaceable>repository</replaceable>-committers</literal>
-      mailing list that a developer can really get a feel for just
-      what is and is not) then consider sending the change to them
-      instead, just as a developer would have before becoming a
+      areas, to our shame), the same applies.  When modifying
+      parts of the system which are maintained, formally, or
+      informally, consider asking for review just as a developer
+      would have before becoming a
       committer.  For ports, contact the listed
       <varname>MAINTAINER</varname> in the
-      <filename>Makefile</filename>.  For other parts of the
-      repository, if it is not clear who the active maintainer is, it
-      may help to scan the revision history to see who has committed
+      <filename>Makefile</filename>.</para>
+
+    <para>To determine if an area of the tree is maintained, check the
+      MAINTAINERS file at the root of the tree. If nobody is listed,
+      scan the revision history to see who has committed
       changes in the past.  An example script that lists each person
       who has committed to a given file along with the number of
       commits each person has made can be found at on
@@ -2694,11 +2693,11 @@ Relnotes:           yes</programlisting>
       unanswered or the committer otherwise indicates a lack of
       interest in the area affected, go ahead and commit it.</para>
 
-    <note>
+    <important>
       <para>Avoid sending private emails to maintainers.  Other people
 	might be interested in the conversation, not just the final
 	output.</para>
-    </note>
+    </important>
 
     <para>If there is any doubt about a commit for any reason at all,
       have it reviewed before