Proposal: Change to library proposal process

[Simon Peyton-Jones]

Some short thoughts on this thread

* Duncan makes a critical distinction between 
	API changes	
 	Implementation changes

  Both changes presumably offer some benefit.  Implementation
  changes may impose some costs, but only on other
  implementers (outright bugs aside).  These costs are of the
  form "how the devil does this new code work".

  API changes impose costs on every user of that library, to
  adapt his or her code to work with the new API.  That's a
  much larger population.

  Gregory advocates a "by default apply patch" policy.  That's
  fine for implementation changes, but I think it is arguably
  right for API changes to have to suffer a significantly higher bar.

  (In fairness to Gregory, I believe that his proposals were
  largely directed at implementation changes.  When people offer
  patches for GHC itself, we certainly use the "by default apply"
  rule, because they are internal -- they fall under the
  "implementation change" heading.  Even then, if the patch
  is big it sometimes take me a while to review because I am
  aware that I'll be maintaining this code in 5 years time, when
  the author is perhaps long gone.)

  I think it'd be good if the library-change prcess acknowledged
  the above distinction explicitly, and treated the two differently,
  as Duncan suggests.

* I fully subscribe to Johan's view that each core library needs
  a named, individual maintainer (or a small group of such).  The
  libraries@ mechanism does work, but I think it'd work better if
  each lib had a named maintainer.

* Gregory writes "The fact of the matter is, I would definitely
  like to contribute but I'm not going near our current process
  with a 20-foot barge pole. And I'm unequivocally not the only
  potential contributor who feels this way. From an interested
  observer's perspective, it seems like libraries@ is where good
  code goes to die, and I don't have the time, energy, or
  patience to endure it."

  Others may agree or disagree with this view, but it is a *fact*
  that G feels this way, and that he believes that others do too.
  That's alarming to me, and I think we need to take it
  seriously, since G has done us the courtesy of explaining his
  position (thank you Gregory).  Quite what we might do to
  address these concerns isn't so clear to me.  I'm agnostic
  about technology, my gut feel is that the core issues are not
  technological ones (eg github vs darcs).

Simon