Proposal process status

Niklas Larsson metaniklas at
Wed Jul 20 19:39:22 UTC 2016

> 20 juli 2016 kl. 19:38 skrev amindfv at
>> El 20 jul 2016, a las 12:45, Ben Gamari <ben at> escribió:
>> Iavor Diatchki <iavor.diatchki at> writes:
>>> Hello Ben,
>>> I posted this when you originally asked for feed-back, but perhaps it
>>> got buried among the rest of the e-mails.
>> Indeed it seems that way. Sorry about that!
>>> I think the proposal sounds fairly reasonable, but it is hard to say how
>>> well it will work in practice until we try it, and we should be ready to
>>> change it if needs be.
>> Right. I fully expect that we will have to iterate on 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?
>> The discussion phase can happen asynchronously from any action by the
>> Committee. Of course, the Committee should engauge in discussion early,
>> but I don't think any sort of acknowledgement is needed. An open pull
>> request should be taken to mean "let's discuss this idea."
>>> 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?
>> The proposed process places the discussion in a pull request. The idea
>> here is to use well-understood and widely-used code review tools to
>> faciliate the conversation.
> This part runs strongly against the grain of what I'd prefer: email is lightweight, decentralized, standard, and has many clients. We can read discussion of Haskell proposals any way we like. Github on the other hand only allows us to read issues by going to Github, and using whatever interface Github has given us (which personally I find very annoying, esp. on mobile). In addition, reading proposals offline becomes very difficult. Many of us read discussion when commuting, where, e.g. in NYC, there isn't cell service.
> For reviewing code that implements a proposal, I'm a lot more flexible (although again I'm not a fan of Github)
> For the people who like having history tracked with git: gitit is a possibility, and is written in Haskell.
> Tom

It's possible both follow and contribute to issues in a github repo via email. I do it all the time for Idris.

// Niklas

>> The Committee members will be notified of the open pull request by the
>> usual event notification mechanism (e.g. in GitHub one can subscribe to
>> a repository).
>>> 3. How does one actually perform step 3, another pull request or simply
>>> an e-mail to someone?
>> The opening of the pull request would mark the beginning of the
>> discussion period. When the author feels that the discussion has come to
>> something of a conclusion, they will request that the GHC Committee
>> consider the proposal for acceptable by leaving a comment on the pull
>> request.
>>> Typo: two separate bullets in the proposal are labelled as 4.
>> I believe this should be fixed now. Thanks!
>> Cheers,
>> - Ben
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the ghc-devs mailing list