Rethinking GHC's approach to managing proposals

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=14d66... [5] https://github.com/rust-lang/rfcs [6] https://github.com/ghc-proposals/ghc-proposals

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.
I think the best thing to do is to fork the source code and modify it according to one's own needs. Having some sort of committees to decide about the syntax, etc. is a really bad idea. A.S. -- Apostolos Syropoulos Xanthi, Greece

Apostolos Syropoulos via Glasgow-haskell-users
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.
I think the best thing to do is to fork the source code and modify it according to one's own needs. Having some sort of committees to decide about the syntax, etc. is a really bad idea.
The point here is not to place a committee in charge of designing features. To the contrary, the point of this proposal is to revamp our protocol for handling proposals brought by others. The committee merely serves as a gatekeeper to ensure that GHC's design and implementation remains coherent and maintainable and its semantics well-defined. Cheers, - Ben

Just to be clear:
* We are actively seeking feedback about the proposal [4] below.
It's not a fait-accompli.
* You can join the dialogue by (a) replying to this email,
(b) via the "Conversations" tab of [4], namely
https://github.com/ghc-proposals/ghc-proposals/pull/1
Doubtless via reddit too!
If you don't like something, the more specific and concrete you
can be about a better alternative, the better. E.g. Richard's
comments on the "conversations" tab both ask questions and propose
answers. Bravo!
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 09 July 2016 21:46
| To: GHC developers

Hello,
I think this sounds fairly reasonable, but it is hard to say how well it
will work in practice until we try it.
Some clarifying questions on the intended process:
1. After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment, or just move on to step 2?
2. Is the discussion going to happen on one of the mailing lists, if so
which? Is it the job of the proposing person to involve/notify the
committee about the discussion? If so, how are they to find out who is on
the committee?
3. How does one actually perform step 3, another pull request or simply
an e-mail to someone?
Typo: two separate bullets in the proposal are labelled as 4.
Cheers,
-Iavor
On Mon, Jul 11, 2016 at 2:36 PM, Simon Peyton Jones via
Glasgow-haskell-users
Just to be clear:
* We are actively seeking feedback about the proposal [4] below. It's not a fait-accompli.
* You can join the dialogue by (a) replying to this email, (b) via the "Conversations" tab of [4], namely https://github.com/ghc-proposals/ghc-proposals/pull/1 Doubtless via reddit too!
If you don't like something, the more specific and concrete you can be about a better alternative, the better. E.g. Richard's comments on the "conversations" tab both ask questions and propose answers. Bravo!
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ben | Gamari | Sent: 09 July 2016 21:46 | To: GHC developers
; ghc-users | Subject: Rethinking GHC's approach to managing proposals | | 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red | dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f& | data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608 | d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Hl6GqRWfu7IOQtpE | jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d | [2] | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red | dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f | &data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660 | 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bj2AQqQirX3X%2f | 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d | [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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
participants (5)
-
asyropoulos@aol.com
-
Ben Gamari
-
Ben Gamari
-
Iavor Diatchki
-
Simon Peyton Jones