CG: add final GOP-PROP 2: contrib. and mentors

diff --git a/Documentation/contributor/administration.itexi b/Documentation/contributor/administration.itexi
index da8f48276caf3ac59043957dff16cbf60ec176b4..415a30feb88dea10397013d48b3bc121c4422bdc 100644 (file)
--- a/Documentation/contributor/administration.itexi
+++ b/Documentation/contributor/administration.itexi
@@ -554,6 +554,19 @@ any @code{.py} file in lilypond git.  All such files should be
 converted to use spaces only.
 
 
+@subheading GOP-PROP 2: mentors and frogs
+
+Nothing much was decided.  The list of responsibilities was
+slightly altered; see the new one in @ref{Mentors}.  We should
+encourage more use of the Frogs mailing list.  There's a list of
+contributor-mentor pairs in:
+
+@smallexample
+@uref{https://github.com/gperciva/lilypond-extra/blob/master/people/mentors.txt}
+@end smallexample
+
+That's pretty much it.
+
 
 @node Grand LilyPond Input Syntax Standardization (GLISS)
 @section Grand LilyPond Input Syntax Standardization (GLISS)

diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi
index 525792b3b19ff7b2aaf3de8bb45020236722defb..90829b4aaf849b85911716b499232ac6f670aeb3 100644 (file)
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -182,9 +182,33 @@ for docs and translations; code patches should almost always go to
 -devel before being pushed).
 
 @item
-Keep track of patches from your contributor.  If you've sent a
-patch to -devel, it's your responsibility to pester people to get
-comments for it, or at very least add it to the google tracker.
+Keep track of patches from your contributor.  Either upload them
+to Rietveld yourself, or help+encourage them to upload the patches
+themselves.  When a patch is on Rietveld, it's your responbility
+to get comments for it, and to add a link to the patch to the
+google tracker.  (tag it @qq{patch-new}, or @qq{patch-review} if
+you feel very confident in it)
+
+@item
+Encourage your contributor to review patches, particularly your
+own!  It doesn't matter if they're not familiar with C++ / scheme
+/ build system / doc stuff -- simply going through the process is
+valuable.  Besides, anybody can find a typo!
+
+@item
+Contact your contributor at least once a week.  The goal is just
+to get a conversation started -- there's nothing wrong with simply
+copy&pasting this into an email:
+
+@example
+Hey there,
+
+How are things going?  If you sent a patch and got a review, do
+you know what you need to fix?  If you sent a patch but have no
+reviews yet, do you know when you will get reviews?  If you are
+working on a patch, what step(s) are you working on?
+@end example
+
 
 @end enumerate