Rethinking GHC's approach to managing proposals

[Ben Gamari]

Hello everyone,

Recently there has been a fair bit of discussion[1,2] around the
mechanisms by which proposed changes to GHC are evaluated. While we have
something of a formal proposal protocol [3], it is not clearly
documented, inconsistently applied, and may be failing to serve a
significant fraction of GHC's potential contributor pool.

Over the last few weeks, I have been doing a fair amount of reading,
thinking, and discussing to try to piece together a proposal scheme
which better serves our community.

The resulting proposal [4] is strongly inspired by the RFC process in
place in the Rust community [5], the leaders of which have thought quite
hard about fostering community growth and participation. While no
process is perfect, I feel like the Rust process is a good starting
point for discussion, offering enough structure to guide new
contributors through the process while requiring only a modest
investment of developer time.

To get a sense for how well this will work in our community, I propose
that we attempt to self-host the proposed process. To this end I have
setup a ghc-proposals repository [6] and opened a pull request for
discussion of the process proposal [4].
           
Let's see how this goes.

Cheers,

- Ben


[1] https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/
[2] https://www.reddit.com/r/haskell/comments/4isua9/ghc_development_outsidein/
[3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
[4] https://github.com/ghc-proposals/ghc-proposals/pull/1/files?short_path=14d66cd#diff-14d66cda32248456a5f223b6333c6132
[5] https://github.com/rust-lang/rfcs
[6] https://github.com/ghc-proposals/ghc-proposals
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160709/2b3c1f10/attachment.sig>