
"The Phabricator upstream is Phacility, Inc. We maintain total control over the project and roadmap. There is no democratic process, voting, or community-driven decision making. This model is better at some things and worse at others than a more community-focused model would be, but it is
#12240: Common Sense for Type Classes -------------------------------------+------------------------------------- Reporter: Mathnerd314 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:9 Mathnerd314]: the model we operate under."
I am not sure this describes GHC well; wiki:TeamGHC states "GHC's
development as a whole is not led by any particular group, company, or individual." Point well taken. I guess I was specifically referring to this passage from that page: Unjustifiable Costs: We support code in the upstream forever. Support is enormously expensive and takes up a huge amount of our time. The cost to support a change over its lifetime is often 10x or 100x or 1000x greater than the cost to write the first version of it. Many uncoordinated patches we receive are "white elephants", which would cost much more to maintain than the value they provide. As an author, it may look like you're giving us free work and we're rejecting it as too expensive, but this viewpoint doesn't align with the reality of a large project which is actively supported by a small, experienced team. Writing code is cheap; maintaining it is expensive. In an ideal world, the GHC maintenance would be democratized. But that's not quite how it currently is (there's a fairly small group that do the regular maintenance) and so we have to guard the door carefully. Part of the reason that insiders' ideas are seen more favorably is that, once you've demonstrated the time and energy to be a regular contributor, it seems more likely that you will maintain the patch -- at least for a while. This lowers the cost of accepting the patch. Shifting direction a bit, we really do need a more open, inclusive process by which ideas (even ones without proper specifications, yet) can be debated by the community, so that it's clearer what the community reaction is. You're going to get a very self-selected slice of the community by debating here. It sounds (from Simon's blog post linked earlier) that there is such a process in the works, and I'm looking forward to learning more about it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12240#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler