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