CG: update GOP list, add url to agenda.

diff --git a/Documentation/contributor/administration.itexi b/Documentation/contributor/administration.itexi
index fc6c15ce276f95b0e8e1111a82953e54534ca0fe..aef67b3beaa6b2dbe202f6d2e0d529d8500298c0 100644 (file)
--- a/Documentation/contributor/administration.itexi
+++ b/Documentation/contributor/administration.itexi
@@ -303,14 +303,15 @@ Technical requirements: development environment (such as
 @subsection Policy decisions
 
 There are a number of policy decisions -- some of them fairly
 @subsection Policy decisions
 
 There are a number of policy decisions -- some of them fairly

-important -- which we have been postponing for a few years.  When
-GOP begins, we will start discussing them.
+important -- which we have been postponing for a few years.  We
+are now discussing them slowly and thoroughly; agenda and exact
+proposals are online:

 
 

-@warning{The fact that we are not arguing about them right now is
-not, I repeat @strong{not}, an indication that we do not feel that
-these issues are not important.  It is simply that if we began
-talking about them now, it would postpone the 2.14 release for a
-few months.}
+@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.
 
 Note that the presence of an item on this list does @emph{not}
 mean that everybody thinks that something needs to be done.


@@ -319,12 +320,10 @@ 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)
 
 developer thinks we should discuss something, just add it to the
 bottom of the list.  (the list is unsorted)
 

-Once GOP starts, the list will be sorted into a rough agenda.  We
-will probably introduce one topic each week -- yes, it will
-therefore take months to get through everything, but we must
-balance productive work vs. policy administration.  If we find
-that we settle questions faster (or slower) than predicted, we
-will of course change the speed of new topic introductions.
+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
 
 There are some item(s) not displayed here; these are questions
 that were posed to me privately, and I do not feel justified in


@@ -360,10 +359,9 @@ away.  This is not good.
 
 (prep: 2 hours.  discuss: 10 hours)
 
 
 (prep: 2 hours.  discuss: 10 hours)
 

-@item @strong{Lessons from the 2.14 release; future release policy}:
-What went well; what went badly? (how) should we change any
-policies pertaining to releases? Should an undocumented new
-feature count as release-blocking?
+@item @strong{Future release policy}:
+(how) should we change any policies pertaining to releases? Should
+an undocumented new feature count as release-blocking?

 
 (prep: 1 hour.  discuss: 15 hours)
 
 
 (prep: 1 hour.  discuss: 15 hours)
 


@@ -376,22 +374,6 @@ so, who should be on it?
 @item @strong{Hackers B}:
 
 
 @item @strong{Hackers B}:
 
 

-@item @strong{Code style}:
-New contributors sometimes struggle to follow our indentation and
-code style -- this is especially difficult when parts of our
-existing source code doesn't have a consistent style. This is
-problematic... we want new contributors to be struggling with the
-lilypond architecture, not playing games in their text editors!
-(ok, we don't actually want them to be struggling with lilypond
-internals... but given the current state of the CG, it's
-understandable, and at any rate it's still better than struggling
-with code style)
-Speaking academically, C++ code style is a "solved problem". Let's
-pick one of the existing solutions (probably either astyle,
-uncrustify, or emacs), and let a computer deal with this.
-
-(prep: 5 hours.  discuss: 15 hours)
-

 @item @strong{Git repository(s)}:
 We currently have a web/ branch in our main repo; this seems
 misleading to new developers. More generally, should we have
 @item @strong{Git repository(s)}:
 We currently have a web/ branch in our main repo; this seems
 misleading to new developers. More generally, should we have


@@ -485,16 +467,6 @@ required merging and stuff.
 
 (prep: 2 hours.  discuss: 10 hours)
 
 
 (prep: 2 hours.  discuss: 10 hours)
 

-@item @strong{Precise definition of Critical issues}:
-at the moment, a stable release is entirely dependent on the
-number of Critical issues, but there's some questions about
-precisely what a "Critical issue" should be.  We should clarify
-this, in conjunction with a general discussion about how often we
-want to have stable releases, how permissive we want to be about
-patches, etc etc.
-
-(prep: 1 hour.  discuss: 5 hours)
-

 @item @strong{When do we add regtests?}:
 There is a discrepancy between our stated policy on adding
 regtests, and our actual practice in handling bugs and patches.
 @item @strong{When do we add regtests?}:
 There is a discrepancy between our stated policy on adding
 regtests, and our actual practice in handling bugs and patches.