-@c -*- coding: us-ascii; mode: texinfo; -*-
+@c -*- coding: utf-8; mode: texinfo; -*-
+
+@include included/helpus.itexi
@node Introduction to contributing
@chapter Introduction to contributing
+This chapter presents a quick overview of ways that people can
+help LilyPond.
@menu
-* Overview of tasks::
-* For unix developers::
-* For other contributors::
+* Help us::
+* Overview of work flow::
* Mentors::
@end menu
-@node Overview of tasks
-@section Overview of tasks
-
-
-FIXME: The intro should contain the "help us" material from web/,
-quite possibly as the very first thing. This requires having a
-macro for it, which depends on issue 939.
+@node Help us
+@section Help us
+@helpusNeed
-@node For unix developers
-@section For unix developers
+@helpusTasks
+@helpusProjects
-To download the LilyPond Git repository:
-
-@example
-git clone git://git.sv.gnu.org/lilypond.git
-@end example
-Documentation is built using Texinfo. Subscribe to the
-developers' mailing list at
-@uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel} and
-send well-formed Git patches to
-@uref{mailto:lilypond-devel@@gnu.org} for discussion.
-
-
-@node For other contributors
-@section For other contributors
+@node Overview of work flow
+@section Overview of work flow
+@cartouche
+@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
Git is a @emph{version control system} that tracks the history of
a program's source code. The LilyPond source code is maintained
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
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.
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
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.
@item
Inform your mentor if you're willing to do more work -- we always
-have way more work than we have helpers available.
+have way more work than we have helpers available. We try to
+avoid overwhelming new contributors, so you'll be given less work
+than we think you can handle.
@end enumerate
@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.
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
-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
+