Merge branch 'master' of git://git.savannah.gnu.org/lilypond.git

[lilypond.git] / Documentation / contributor / introduction.itexi

diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi
index c104cee17551acb2790d8a512c9bb84a1d5e63ec..90829b4aaf849b85911716b499232ac6f670aeb3 100644 (file)
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -29,8 +29,8 @@ help LilyPond.
 @section Overview of work flow
 
 @cartouche
-@strong{Ultra-short summary for Unix developers}: source code is at
-@code{git://git.sv.gnu.org/lilypond.git}.  Documentation is built
+@strong{Short summary for Unix developers}: source code is at
+@uref{git://git.sv.gnu.org/lilypond.git}.  Documentation is built
 with Texinfo, after pre-processing with @code{lilypond-book}.
 Send well-formed patches to @email{lilypond-devel@@gnu.org}.
 @end cartouche
@@ -52,7 +52,7 @@ The @q{official} LilyPond Git repository is hosted by the GNU
 Savannah software forge at @uref{http://git.sv.gnu.org}.
 Although, since Git uses a @emph{distributed} model, technically
 there is no central repository.  Instead, each contributor keeps a
-complete copy of the entire repository (about 116M).
+complete copy of the entire repository (about 116MB).
 
 Changes made within one contributor's copy of the repository can
 be shared with other contributors using @emph{patches}.  A patch
@@ -97,8 +97,8 @@ the developers' mailing list here:
 @uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel}.
 
 @warning{Contributors on Windows or MacOS X wishing to compile
-code or documentation are strongly advised to use lilybuntu, as
-discussed in @ref{Quick start}.}
+code or documentation are strongly advised to use our Ubuntu
+LilyPond Developer Remix, as discussed in @ref{Quick start}.}
 
 
 @node Mentors
@@ -124,6 +124,12 @@ They might not be able to help you with all problems, but we find
 that new contributors often get stuck with something that could be
 solved/explained with 2 or 3 sentences from a mentor.
 
+@item
+If you have been working on a task much longer than was originally
+estimated, stop and ask your mentor.  There may have been a
+miscommunication, or there may be some time-saving tips that could
+vastly simply your task.
+
 @item
 Send patches to your mentor for initial comments.
 
@@ -176,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