]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/contributor/introduction.itexi
Merge branch 'master' of git://git.savannah.gnu.org/lilypond.git
[lilypond.git] / Documentation / contributor / introduction.itexi
index 480aba641ac8f1c67bb2a3670b2688a98d7098e1..90829b4aaf849b85911716b499232ac6f670aeb3 100644 (file)
@@ -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
@@ -74,9 +74,9 @@ interface is at
 
 Git is a complex and powerful tool, but tends to be confusing at
 first, particularly for users not familiar with the command line
-and/or version control systems.  Contributors who don't want to
-deal with Git directly are encouraged to use the
-@command{lily-git} graphical user interface instead.
+and/or version control systems.  We have created the
+@command{lily-git} graphical user interface to ease this
+difficulty.
 
 @emph{Compiling} (@q{building}) LilyPond allows developers to see
 how changes to the source code affect the program itself.
@@ -96,6 +96,10 @@ email to @email{lilypond-devel@@gnu.org}.  You can subscribe to
 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 our Ubuntu
+LilyPond Developer Remix, as discussed in @ref{Quick start}.}
+
 
 @node Mentors
 @section Mentors
@@ -120,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.
 
@@ -144,7 +154,7 @@ than we think you can handle.
 
 @item
 Respond to questions from your contributor(s) promptly, even if
-the reponse is just @qq{sorry, I don't know} or @qq{sorry, I'm
+the response is just @qq{sorry, I don't know} or @qq{sorry, I'm
 very busy for the next 3 days; I'll get back to you then}.  Make
 sure they feel valued.
 
@@ -154,7 +164,7 @@ emails -- do you work on lilypond every day, or every weekend, or
 what?  Also, if you'll be unavailable for longer than usual (say,
 if you normally reply within 24 hours, but you'll be at a
 conference for a week), let your contributors know.  Again, make
-sure thay feel valued, and that your silence (if they ask a
+sure they feel valued, and that your silence (if they ask a
 question during that period) isn't their fault.
 
 @item
@@ -172,11 +182,34 @@ 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)
 
-@end enumerate
+@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