+@node Grand Organization Project (GOP)
+@section Grand Organization Project (GOP)
+
+GOP has two goals:
+
+@itemize
+@item
+Clarify the various development tasks by writing down the policies
+and techniques and/or simplifying the tasks directly.
+
+@item
+Get more people involved in development: specifically, find people
+to do easy tasks to allow advanced developers to concentrate on
+difficult tasks.
+
+@end itemize
+
+@menu
+* Motivation::
+* Ongoing jobs::
+* Policy decisions::
+* Policy decisions (finished)::
+@end menu
+
+@node Motivation
+@subsection Motivation
+
+Most readers are probably familiar with the LilyPond Grand
+Documentation Project, which ran from Aug 2007 to Aug 2008. This
+project involved over 20 people and resulted in an almost complete
+rewrite of the documentation. Most of those contributors were
+normal users who decided to volunteer their time and effort to
+improve lilypond for everybody. By any measure, it was a great
+success.
+
+The Grand Organization Project aims to do the same thing with a
+larger scope -- instead of focusing purely on documentation, the
+project aims to improve all parts of LilyPond and its community.
+Just as with GDP, the main goal is to encourage and train users to
+become more involved.
+
+If you have never contributed to an open-source project before --
+especially if you use Windows or OSX and do not know how to
+program or compile programs -- you may be wondering if there's
+anything you can do. Rest assured that you @emph{can} help.
+
+@subheading "Trickle-up" development
+
+One of the reasons I'm organizing GOP is "trickle-up"
+development. The idea is this: doing easy tasks frees up advanced
+developers to do harder tasks. Don't ask "am I the @emph{best}
+person for this job"; instead, ask "am I @emph{capable} of doing
+this job, so that the current person can do stuff I @emph{can't}
+do?".
+
+For example, consider lilypond's poor handling of grace notes in
+conjunction with clef and tempo changes. Fixing this will require
+a fair amount of code rewriting, and would take an advanced
+developer a few weeks to do. It's clearly beyond the scope of a
+normal user, so we might as well sit back and do nothing, right?
+
+No; we @emph{can} help, indirectly. Suppose that our normal user
+starts answering more emails on lilypond-user. This in turn means
+that documentation writers don't need to answer those emails, so
+they can spend more time improving the docs. I've noticed that all
+doc writers tackle harder and harder subjects, and when they start
+writing docs on scheme programming and advanced tweaks, they start
+contributing bug fixes to lilypond. Having people performing these
+easy-to-moderate bug fixes frees up the advanced developers to
+work on the really hard stuff... like rewriting the grace note
+code.
+
+Having 1 more normal user answering emails on lilypond-user won't
+have a dramatic @q{trickle-up} effect all by itself, of course. But if
+we had 8 users volunteering to answer emails, 6 users starting to
+write documentation, and 2 users editing LSR... well, that would
+free up a lot of current bug-fixing-capable contributors to focus
+on that, and we could start to make a real dent in the number of
+bugs in lilypond. Quite apart from the eased workload, having that
+many new helpers will provide a great moral boost!
+
+@node Ongoing jobs
+@subsection Ongoing jobs
+
+Although GOP is a short-term project, the main goal is to train
+more people to handle ongoing jobs. The more people doing these
+jobs, the lighter the work will be, and the more we can get done
+with lilypond!
+
+Also, it would be nice if we had at least one "replacement" /
+"understudy" for each role -- too many tasks are only being done
+by one person, so if that person goes on vacation or gets very
+busy with other matters, work in that area grinds to a halt.
+
+@subheading Jobs for normal users
+
+@itemize
+@item Consultant:
+LilyPond is sometimes critized for not listening to users, but
+whenever we ask for opinions about specific issues, we never get
+enough feedback. This is somewhat aggravating.
+We need a group of users to make a dedicated effort to test and
+give feedback. If there's new documentation, read it. If there's
+an experimental binary, download it and try compiling a score with
+it. If we're trying to name a new command, think about it and give
+serious suggestions.
+
+@item lilypond-user support:
+I think it would be nice if we had an official team of users
+helping other users.
+
+@item LilyPond Report:
+Keeping a monthly newsletter running is a non-trivial task. A lot
+of work is needed to organize it; it would be great if we could
+split up the work. One person could write the Snippet of the
+Month, another person could do Quotes of the Month, another person
+could do interviews, etc.
+
+@item Documentation:
+Although GDP (the Grand Documentation Project) did great work,
+there's still many tasks remaining.
+
+@item Translations:
+Keeping the documentation translations is a monumental task; we
+need all the help we can get!
+
+@end itemize
+
+@subheading Jobs for advanced users for developers
+
+@itemize
+@item Git help for writers:
+We often receive reports of typos and minor text updates to the
+documentation. It would be great if somebody could create
+properly-formatted patches for these corrections.
+
+Technical requirements: ability to run @ref{LilyDev}.
+
+@item LSR editor:
+LSR contains many useful examples of lilypond, but some snippets
+are out of date and need updating. Other snippets need to be
+advertized, and new snippets need to be sorted. We could use
+another person to handle LSR.
+
+Technical requirements: use of a web browser. LilyPond
+requirements: you should be familiar with most of Notation
+chapters 1 and 2 (or be willing to read the docs to find out).
+
+@item Join the Frogs:
+"Frogs" are a team of bug-fixers (because frogs eat bugs, and you
+often find them in Ponds of Lilies) and new feature implementors.
+
+Technical requirements: development environment (such as
+@ref{LilyDev}), ability to read+write scheme and/or C++ code.
+
+@end itemize
+
+
+@node Policy decisions
+@subsection Policy decisions
+
+There are a number of policy decisions -- some of them fairly
+important -- which we have been postponing for a few years. We
+are now discussing them slowly and thoroughly; agenda and exact
+proposals are online:
+
+@example
+@uref{http://lilypond.org/~graham/gop/index.html}
+@end example
+
+Below is a list of policies which are not @qq{on the agenda} yet.
+
+Note that the presence of an item on this list does @emph{not}
+mean that everybody thinks that something needs to be done.
+Inclusion in this simply means that one developer thinks that we
+should discuss it. We are not going to filter this list; if any
+developer thinks we should discuss something, just add it to the
+bottom of the list. (the list is unsorted)
+
+As GOP progresses, items from this list will be put on the agenda
+and removed from this list. I generally try to have one month's
+discussion planned in advance, but I may shuffle things around to
+respond to any immediate problems in the developer community.
+
+There are some item(s) not displayed here; these are questions
+that were posed to me privately, and I do not feel justified in
+discussing them publicly without the consent of the person(s) that
+brought them up. They will initially be discussed privately on the
+lilypond-hackers mailing list -- but the first question will be
+"do we absolutely need to do this privately", and if not, the
+discussion will take place on lilypond-devel like the other items.
+
+In most policy discussions in lilypond over the past few years,
+the first half (or more) is wasted arguing on the basis of
+incorrect or incomplete data; once all the relevant facts are
+brought to light, the argument is generally resolved fairly
+quickly. In order to keep the GOP discussions focused, each topic
+will be introduced with a collection of relevant facts and/or
+proposals. It is, of course, impossible to predict exactly which
+facts will be relevant to the discussion -- but spending an hour
+or two collecting information could still save hours of
+discussion.
+
+@warning{The estimated time required for "prep work", and the
+following discussion, has been added to each item. At the moment,
+there is an estimated 30 hours of prep work and 140 hours of
+discussion.}
+
+@itemize
+@item @strong{Patch reviewing}:
+At the time of this writing, we have 23 (known) patches waiting
+for review. Some from main developers; some from new developers.
+We desperately need more people helping with lilypond, but
+ignoring patches is the best way to drive potential contributors
+away. This is not good.
+
+(prep: 2 hours. discuss: 10 hours)
+
+@item @strong{Official links to other organizations?}:
+There's something called the "software freedom conservancy", and
+in general, there's a bunch of "umbrella organizations". Joining
+some of these might give us more visibility, possibly leading to
+more users, more developers, maybe even financial grants or use in
+schools, etc.
+
+(prep: 2 hours. discuss: 5 hours)
+
+@item @strong{Issue tracking with google code}:
+We use the google issue tracker, but this means that we are
+relying on a commercial entity for a large part of our
+development. Would it be better (safer in the long run) to use the
+savannah bug tracker?
+
+(prep: 1 hour. discuss: 5 hours)
+
+@item @strong{Patch review tool}:
+Reitveld is inconvenient in some respects: it requires a google
+account, and there's no way to see all patches relating to
+lilypond. Should we switch to something like gerritt?
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1184}
+
+(prep: 5 hours. discuss: 15 hours)
+
+@item @strong{Clarity for sponsorships}:
+We currently do not advertize bounties and sponsorships on the
+webpage. How much advertising do we want, and what type?
+Should we change the "structure" / "framework" for bounties?
+
+(prep: 2 hours. discuss: 10 hours)
+
+@item @strong{code readability}:
+"Our aim when producing source code for Lilypond in whatever
+language is that it should be totally comprehensible to a
+relatively inexperienced developer at the second reading."
+
+Rationale:
+- aids maintainability of code base
+- "second reading" so newer developers can look up unfamiliar
+ stuff
+- will help to keep things simple, even if the code is doing
+ complex stuff discourages "secret squirrel" coding, e.g. "how
+ much functionality can I squeeze into as few characters as
+ possible" "comments are for wimps"
+- will aid not *discouraging* new developers to join the project
+
+(prep: 2 hours. discuss: 10 hours)
+
+@item @strong{C++ vs. scheme}:
+what should be in scheme, what should be in C++, what can/should
+be ported from one to the other, etc. Questions of
+maintainability, speed (especially considering guile 2.0), and the
+amount of current material in either form, are important.
+
+(prep: 5 hours. discuss: 15 hours)
+
+@item @strong{always make an issue number for patches}:
+there is a proposal that we should always have a google code issue
+number for every patch. This proposal is closely tied to our
+choice of patch review tool; if we switch to a different tool (as
+suggested in a different proposal), this proposal may become moot.
+
+(prep: 1 hour. discuss: 5 hours)
+
+@item @strong{initalizer lists}:
+shoudl we use initalizer lists for C++? AFAIK they make no
+difference for built-in types, but there's some weird case where
+it's more efficient for objects, or something.
+
+Probably not worth making this a weekly thing on its own, but we
+can probably wrap it up with some other code-related questions.
+
+(prep: 15 minutes. discuss: 3 hours)
+
+@end itemize
+
+@node Policy decisions (finished)
+@subsection Policy decisions (finished)
+
+Here is a record the final decisions, along with links to the
+discussions.
+
+@menu
+* GOP-PROP 1 - python formatting::
+* GOP-PROP 2 - mentors and frogs::
+* GOP-PROP 3 - C++ formatting::
+* GOP-PROP 4 - lessons from 2.14::
+* GOP-PROP 5 - build system output (not accepted)::
+* GOP-PROP 6 - private mailing lists::
+* GOP-PROP 7 - developers as resources::
+* GOP-PROP 8 - issue priorities::
+* GOP-PROP 9 - behavior of make doc::
+@end menu
+
+@node GOP-PROP 1 - python formatting
+@subsubsection GOP-PROP 1 - python formatting
+
+We will follow the indentation described in PEP-8.
+@uref{http://www.python.org/dev/peps/pep-0008/}
+
+@itemize
+@item
+use 4 spaces per indentation level
+
+@item
+never mix tabs and spaces (for indentation)
+
+@item
+Code indented with a mixture of tabs and spaces should be
+converted to using spaces exclusively
+
+Once this is done, we should add @code{python -tt} to the build
+system to avoid such errors in the future.
+
+@end itemize
+
+There should be absolutely no tab characters for indentation in
+any @code{.py} file in lilypond git. All such files should be
+converted to use spaces only.
+
+@subsubheading Discussions
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00060.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00084.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00310.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00574.html}
+@end smallexample
+
+
+@node GOP-PROP 2 - mentors and frogs
+@subsubsection 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.
+
+@subsubheading Discussions
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00311.html}
+@uref{}
+@uref{}
+@end smallexample
+
+
+@node GOP-PROP 3 - C++ formatting
+@subsubsection GOP-PROP 3 - C++ formatting
+
+Speaking academically, C++ code style is a "solved problem". Let's
+pick one of the existing solutions, and let a computer deal with
+this. Humans should not waste their time, energy, and creativity
+manually adding tabs or spaces to source code.
+
+We have modified @code{fixcc.py} to use astyle, along with extra
+regex tweaks.
+
+@itemize
+@item
+the final script will be run @strong{blindly} on the lilypond
+source code. We will accept whatever formatting the final version
+of this script produces, with no manual tweaking.
+
+@item
+patches which have been run through this tool will not be rejected
+for style reasons. Any code formatting @qq{desires} which are not
+enforced by @code{fixcc.py} will not be considered grounds for
+rejecting a patch.
+
+@item
+for now, this style will not be enforced. It is not cause for
+concern if patches which do not follow the formatting done by
+@code{fixcc.py} are pushed. From time to time, Graham will run
+the formatter on the entire code base, and commit the resulting
+changes.
+
+In a few months, we will tighten up this policy item (with some
+sort of automatic processing), but that is outside the scope of
+this policy item and is a matter for later discussion.
+
+@item
+after the proposal is accepted, we will leave some time for
+existing patches to be accepted and pushed. The script was
+run on the source code on @strong{2011 August 01}.
+
+@end itemize
+
+@subheading GNU code
+
+LilyPond is a GNU project, so it makes sense to follow the GNU
+coding standards. These standards state:
+
+@quotation
+We don’t think of these recommendations as requirements, because
+it causes no problems for users if two different programs have
+different formatting styles.
+
+But whatever style you use, please use it consistently, since a
+mixture of styles within one program tends to look ugly. If you
+are contributing changes to an existing program, please follow the
+style of that program.
+@end quotation
+
+(@uref{http://www.gnu.org/prep/standards/html_node/Formatting.html})
+
+With that in mind, we do not think that we must blindly follow the
+formatting given by the currrent version of Emacs.
+
+@subheading Implementation notes
+
+We can avoid some of the style change pollution in git history by
+ignoring whitespaces changes:
+
+@example
+git diff -w
+@end example
+
+@subsubheading Discussions
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00526.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00796.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00200.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00525.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00751.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00751.html}
+@end smallexample
+
+
+@node GOP-PROP 4 - lessons from 2.14
+@subsubsection GOP-PROP 4 - lessons from 2.14
+
+@subheading History
+
+A brief history of releases:
+
+@multitable @columnfractions .2 .2 .3
+@headitem date (YYYY-MM-DD) @tab version @tab comment
+@item 2008-10-28 @tab 2.11.63 @tab nobody checking regtests
+@item 2008-11-17 @tab 2.11.64
+@item 2008-11-29 @tab 2.11.65
+@item 2008-12-23 @tab 2.12.0
+@item 2009-01-01 @tab @tab somewhere around here, Graham becomes
+officially release manager, but Han-Wen still builds the actual
+releases
+@item 2009-01-01 @tab 2.12.1
+@item 2009-01-25 @tab 2.12.2
+@item 2009-02-28 @tab 2.13.0
+@item 2009-06-01 @tab 2.13.1 @tab note jump in time!
+@item 2009-06-27 @tab 2.13.2 @tab first Graham release?
+@item 2009-07-03 @tab 2.13.3
+@item 2009-09-09 @tab @tab Graham arrives in Glasgow, gets a
+powerful desktop computer, and begins serious work on GUB (sending
+bug reports to Jan). It takes approximately 100 hours until GUB
+is stable enough to make regular releases.
+@item 2009-09-24 @tab 2.13.4
+@item 2009-10-02 @tab 2.13.5
+@item 2009-10-22 @tab 2.13.6
+@item 2009-11-05 @tab 2.13.7
+@item ...
+@item 2010-01-13 @tab 2.12.3
+@item ...
+@item 2010-03-19 @tab 2.13.16 @tab Bug squad starts doing a few
+regtest comparisons, but IIRC the effort dies out after a few
+weeks (BLUE)
+@item ...
+@item 2010-08-04 @tab 2.13.29 @tab Phil starts checking regtests (BLUE)
+@item ...
+@item 2011-01-12 @tab 2.13.46 @tab release candidate 1 (GREEN)
+@item ...
+@item 2011-05-30 @tab 2.13.63 @tab release candidate 7 (GREEN)
+@item 2011-06-06 @tab 2.14.0
+@end multitable
+
+@c A graphical display of bugs:
+@c
+@c @image{bugs-2.13-visualization,png}
+@c @image{zoom-2.13-visualization,png}
+
+@subheading Carl's analysis of the bugs
+
+A @file{csv} spreadsheet is available.
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00852.html}
+@end smallexample
+
+@example
+@uref{lilypond-issues-analysis.csv}
+@uref{lilypond-issues-analysis-trim-duplicates.csv}
+@end example
+
+There 148 issues marked with Priority=Critical in the tracker.
+
+I've done an analysis, and it looks to me like there was initially
+a backlog of critical issues that weren't fixed, and little work
+was being done to eliminate critical issues.
+
+Somewhere about 2010-08-01, critical issues started to disappear,
+but occasional new ones appeared.
+
+There were a couple of major changes that introduced unanticipated
+regressions (new spacing code, beam collision avoidance). These
+produced more than the expected number of regressions.
+
+It appears to me that we didn't really get serious about
+eliminating critical bugs until about 2010-06-15 or so. After
+that point, the number of critical bugs more-or-less steadily
+decreased until we got to a release candidate.
+
+Of particular interest, the first release candidate of 2.14 was
+released on 2011-01-12. Over the next 10 days, about a dozen bugs
+were reported and fixed. Release candidate 2 came out on
+2011-02-09. No surge of bugs occurred with this release.
+Candidate 3 came out on 2011-03-13; we got 2 bugs per week.
+Candidate 4 came out on 2011-03-29; 2 new bugs. Candidate 6 came
+out on 2011-04-07. We got a couple of bugs per week.
+
+@subheading Notes, commentary, and opinions
+
+@example
+Han-Wen: Overall, I think this cycle took too long
+Mike: I agree
+Graham: +1
+@end example
+
+@subsubheading Discussions
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00797.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00364.html}
+@uref{}
+@end smallexample
+
+
+@node GOP-PROP 5 - build system output (not accepted)
+@subsubsection GOP-PROP 5 - build system output (not accepted)
+
+This proposal was too broad; after a month of discussion, Graham
+withdrew the proposal. Portions of it will be introduced in later
+proposals.
+
+@subsubheading Discussions
+
+@smallexample
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00320.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00527.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00753.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01042.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00116.html}
+@uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00310.html}
+@end smallexample
+
+
+@node GOP-PROP 6 - private mailing lists
+@subsubsection GOP-PROP 6 - private mailing list
+
+Potentially sensitive or private matters will be referred to
+Graham. He will then decide who should discuss the matter on an
+ad-hoc basis, and forward or CC them on future emails.
+
+For emphasis, the project administrators are Han-Wen, Jan, and
+Graham; those three will always be CC'd on any important
+discussions.
+
+The lilypond-hackers mailing list will be removed.
+
+@subheading History
+
+There is some unhappy history about this idea in our development
+community:
+
+@example
+@uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00178.html}
+@uref{http://news.lilynet.net/spip.php?article121}
+@uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00076.html}
+@end example
+
+@subheading Other projects
+
+The idea of private mailing lists is hardly uncommon in
+open-source software. For example,
+
+@example
+@uref{http://lwn.net/Articles/394660/} about debian-private
+@uref{http://subversion.apache.org/mailing-lists.html} private@@
+@uref{http://www.freebsd.org/administration.html#t-core}
+@uref{http://foundation.gnome.org/legal/} board members pledge
+to keep certain matters confidential
+
+every security team of every GNU/Linux distribution and OS
+@end example
+
+In fact, Karl Fogel's @qq{Producing Open Source Software}
+explicitly suggests a private mailing list for some circumstances: