+Note that whenever there is one snippet from @file{input/new} and the
+other from LSR with the same file name, the one from @file{input/new}
+will be copied by @command{makelsr.py}.
+
+
+@node Fixing snippets in LilyPond sources
+@section Fixing snippets in LilyPond sources
+
+In case some snippet from @file{input/lsr} cause the documentation
+compilation to fail, the following steps should be followed to fix it
+reliably.
+
+@enumerate
+
+@item
+Look up the snippet filename @file{@var{foo}.ly} in the error output
+or log, then fix the file @file{input/lsr/@var{foo}.ly} to make the
+documentation build succesfully.
+
+@item
+Determine where it comes from by looking at its first line, e.g. run
+
+@example
+head -1 input/lsr/@var{foo}.ly
+@end example
+
+@item
+@strong{In case the snippet comes from LSR}, apply the fix to the
+snippet in LSR and send a notification email to a LSR editor with CC
+to the development list -- see @ref{Adding and editing snippets}. The
+failure may sometimes not be caused by the snippet in LSR but by the
+syntax conversion made by @command{convert-ly}; in this case, try to
+fix @command{convert-ly} or report the problem on the development
+list, then run @command{makelsr.py} again, see @ref{LSR to Git}. In
+some cases, when some features has been introduced or vastly changed
+so it requires (or takes significant advantage of) important changes
+in the snippet, it is simpler and recommended to write a new version
+of the snippet in @file{input/new}, then run @command{makelsr.py}.
+
+@item
+@strong{In case the snippet comes from} @file{input/new}, apply in
+@file{input/new/@var{foo}.ly} the same fix you did in
+@file{input/lsr/@var{foo}.ly}. In case the build failure was caused
+by a translation string, you may have to fix
+@file{input/texidocs/@var{foo}.texidoc} instead.
+
+@item
+In any case, commit all changes to Git.
+
+@end enumerate