- ghc-steering-committee

Redid our documentation
by Joachim Breitner 28 Feb '17

28 Feb '17

[I sent this mail from Monday to the wrong address, second try] Hi, there was a bit confusion about our documentation, so with SPJ’s blessing I went ahead and restructured it a bit. For now, this is only on a branch and not live yet: https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructur ing Note that it starts with a concise timeline of a proposal, and from there has links to section answering specific questions, within the same file. What was three files before (README, process, committee) is now all in here (with the exception of the “detailed instructions” for the Github-novice, which is in a separate file). This should make it easier for everyone involved to know who has to do what when. Our process is, however, flawed: We ask authors to set labels (“Under Discussion” and “Under Committee Review”), but they do not have permissions to do so. So this does not quite work. So I suggest the following change: * What was “Under Discussion” is now simply any PR that does not have any other label. This way, when opening discussion, nothing concrete has to be done. Which is easier. (GitHub allows to list all PRs that have no label, so there is no loss in functionality here.) * When the author wants to submit the PR, he sends a mail to this mailinglist (is this set up to accept mails from non-subscribers?) and it its the task of the shephard to set the label to indicate that that the committee has accepted to review the proposal. (At this point, the shephard could for example set the `Out-of-scope` label instead.) If there are no complains I will adjust the docs-restructuring branch accordingly and then move that to master. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

7 17

Please review: INCOMPLETE_CONTEXTS, Shephard: Roman
by Joachim Breitner 28 Feb '17

28 Feb '17

Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/34 was brought before the committee. I propose Roman as the Shephard. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process (or refuse to shepherd and maybe propose someone else – I hand this job out based on who has already commented I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim PS: I could not assign this PR to you on Github. Ben, can you add Roman to the team on Github, remove Atze, and update the list of committee members in the README (and maybe make me, as the secretary, an owner of the GitHub organisation)? -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Review requested: Hex floats, Shephard: Iavor
by Joachim Breitner 28 Feb '17

28 Feb '17

Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/37 was brought before the committee. I propose Iavor as the Shephard. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Backpack, complete spec
by Christopher Allen 26 Feb '17

26 Feb '17

https://github.com/ghc-proposals/ghc-proposals/pull/5#issuecomment-280942000 Could I get a quick up/down on this? I'd rather not start making exceptions to the process we laid out. If a proposal is so complicated at the proposer cannot gather a complete specification of the proposal, it should under no circumstances be checked into source control. -- Chris Allen

1 0

Prioritizing proposals for processing? Viewing dates/deadlines?
by Ryan Newton 20 Feb '17

20 Feb '17

Dear steering committee, How do we see what the deadline is for a given proposal discussion? I know we've discussed process a fair bit, but I seem to quickly forget these things if they're not super simple. I can go here <https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+is%3Aopen+so…>, and see proposals, oldest first. (The PR numbers effectively date them as well.) The labels are super useful too (Under discussion). Richard's original proposal is attached below. SPJ later suggested "2 weeks"->"4 weeks" for the consideration period. I think that corresponds to the "Pending Committee review" label. But right now, *no proposals have that label*. For example, how to judge the stage of PR number 36 <https://github.com/ghc-proposals/ghc-proposals/pull/36>?: - has the "Under discussion" label - was posted Jan 15 (1 month old) - has been commented on by some committee members - doesn't have a corresponding email thread on "ghc-steering-committee" - doesn't have a shepherd, which I *think *would appear as an "Assignee" on the PR/issue, right? For better or worse I live a very deadline driven life ;-). So it would be nice to see which proposals have a decision deadline and act there first. As a small technical point, how do we record the DATE when the "Pending committee review" label is assigned, which is what starts the clock ticking right? Thanks, -Ryan P.S. It seems like the decisions about timing and process haven't filtered through to the front-page / top level README <https://github.com/ghc-proposals/ghc-proposals>. Which says only: * "Proposals are ultimately evaluated by the GHC Steering Committee <https://github.com/ghc-proposals/ghc-proposals/blob/master/steering-committ…> based upon a number of criteria and in light of community feedback."* On Fri, Nov 18, 2016 at 8:56 AM, Richard Eisenberg <rae(a)cs.brynmawr.edu> wrote: > ..... > I propose the following: > > - Establish an official ghc-committee(a)haskell.org mailing list that > reaches just us. It will not be open to the public to join, though I have > no problem making archives public. > - When the author of a proposal (or anyone else, really, if the author > wanders off) deems the proposal ready for a decision, that author emails > the list telling us so. > - We use an organic process to decide on one individual in the committee > who will oversee the discussion on the proposal. If organic doesn’t work, > our chair(s) assign the proposal to a member. It is expected that > membership on the committee means that we will volunteer to handle > proposals as appropriate. The committee member running this discussion > process is hereby titled the Shepherd of the proposal. (NB: This is > slightly different than my understanding of a Shepherd in Rust, who is > assigned earlier in the process.) > - Neither the shepherd nor the committee is *not* responsible for reading > GitHub (or other) commentary. The proposal will be considered on its own. > If the author wishes the committee to consider any commentary, that > commentary should be incorporated into the proposal. > - Once a decision is requested, the shepherd has two weeks (in holiday > times or near the ICFP deadline, 3) to generate consensus. If consensus is > elusive, then we vote, with the Simons retaining veto power. > - If we say no: the shepherd updates the proposal (not just the > commentary) with the reasons for rejection. The proposer is welcome to > revise and try again, but the document should retain this original > rejection information. > - If we say yes: A Trac ticket is created, referring back to the proposal > and commentary. (The shepherd is responsible for making sure this happens.) > At this point, the proposal process is technically complete. I believe it > is outside of our purview to implement, oversee implementation, attract > implementors, etc. Naturally, we will want to do this as individuals, but I > believe it’s not in our remit. > >

3 2

Defaulting rules
by Simon Peyton Jones 10 Feb '17

10 Feb '17

Dear GHC steering committee Advice needed. * Some time ago amindfv submitted https://ghc.haskell.org/trac/ghc/ticket/12923. He offered a patch 8 weeks ago. * There wasn't much discussion about the proposed change, nor did anyone ask him to undertake the GHC proposals process * It's a small change, but it is a user-facing one * The design isn't obvious to me; see comment:12. * We could change it now and change it again later; it's a corner case * It matters to him and his customers. So, should we let it in? It's about the defaulting mechanism. With an unsolved constraint (C alpha) where alpha is otherwise unconstrained, GHC will try a series of types to fill in alpha. We extended the rules with ExtendedDefaultRules<https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#t…>. He wants a further extension. I hate slipping things in late, actually after the deadline; but the fault is partly ours for not proactively warning people with open patches. Opinions? Simon

1 1

Re: [ghc-steering-committee] Defaulting rules
by Simon Peyton Jones 09 Feb '17

09 Feb '17

Well not easy for /me/ to fix. But perhaps easy for the ghc-steering-committee mail forwarding agent to fix? S From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: 09 February 2017 11:14 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [ghc-steering-committee] Defaulting rules That was fine. Oh well, I guess it's not an easy thing to fix then. On 9 February 2017 at 10:50, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Direct to you! From: Simon Marlow [mailto:marlowsd@gmail.com<mailto:marlowsd@gmail.com>] Sent: 09 February 2017 08:59 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: [ghc-steering-committee] Defaulting rules Hi Simon, email from you is being marked as spam by gmail. I only just discovered this, and I have several of your messages in my spam folder. Gmail shows the following diagnostic: [cid:image001.png@01D282C6.19AF2590] Which suggests that perhaps it's a problem at your end, maybe you could get someone to look into it? Cheers Simon On 3 February 2017 at 17:38, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Dear GHC steering committee Advice needed. • Some time ago amindfv submitted https://ghc.haskell.org/trac/ghc/ticket/12923. He offered a patch 8 weeks ago. • There wasn’t much discussion about the proposed change, nor did anyone ask him to undertake the GHC proposals process • It’s a small change, but it is a user-facing one • The design isn’t obvious to me; see comment:12. • We could change it now and change it again later; it’s a corner case • It matters to him and his customers. So, should we let it in? It’s about the defaulting mechanism. With an unsolved constraint (C alpha) where alpha is otherwise unconstrained, GHC will try a series of types to fill in alpha. We extended the rules with ExtendedDefaultRules. He wants a further extension. I hate slipping things in late, actually after the deadline; but the fault is partly ours for not proactively warning people with open patches. Opinions? Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org…> https://mail.haskell.org/cgi-<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske…>bin/mailman/listinfo/ghc-steering-committee

1 0

Re: [ghc-steering-committee] Defaulting rules
by Simon Peyton Jones 09 Feb '17

09 Feb '17

This usually happens with mail from me via a mailing list, where the mailing list server has failed to do the right thing. So I think it’s the ghc-steering-committee mail forwarder. I’ll send an email direct to you, and you can see if it’s flagged the same way. Simon From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: 09 February 2017 08:59 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [ghc-steering-committee] Defaulting rules Hi Simon, email from you is being marked as spam by gmail. I only just discovered this, and I have several of your messages in my spam folder. Gmail shows the following diagnostic: [cid:image001.png@01D282C2.52B92F60] Which suggests that perhaps it's a problem at your end, maybe you could get someone to look into it? Cheers Simon On 3 February 2017 at 17:38, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Dear GHC steering committee Advice needed. • Some time ago amindfv submitted https://ghc.haskell.org/trac/ghc/ticket/12923. He offered a patch 8 weeks ago. • There wasn’t much discussion about the proposed change, nor did anyone ask him to undertake the GHC proposals process • It’s a small change, but it is a user-facing one • The design isn’t obvious to me; see comment:12. • We could change it now and change it again later; it’s a corner case • It matters to him and his customers. So, should we let it in? It’s about the defaulting mechanism. With an unsolved constraint (C alpha) where alpha is otherwise unconstrained, GHC will try a series of types to fill in alpha. We extended the rules with ExtendedDefaultRules. He wants a further extension. I hate slipping things in late, actually after the deadline; but the fault is partly ours for not proactively warning people with open patches. Opinions? Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org…> https://mail.haskell.org/cgi-<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske…>bin/mailman/listinfo/ghc-steering-committee

1 0

Mutable constructor fields
by Iavor Diatchki 07 Feb '17

07 Feb '17

Hello, I am not sure what's the process for this, but I am really keen on Simon M's "Mutable constructor fields" proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/8) so I'd like to propose that we adopt it. I'd be happy to volunteer time to work on the implementation too, if there's need for that. -Iavor

4 3

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy unboxed tuples / warn on unbanged strict patterns (#35)
by Simon Peyton Jones 27 Jan '17

27 Jan '17

| The limited discussion period was a suggestion that entered the process | only rather late as a suggestion from Richard (or least my interpretation | thereof). The hope is that it makes things a bit more manageable by | keeping the number of proposals at the focus of the communities attention | small. Authors are of course able to continue working with collaborators | to hone their proposals outside of the discussion phase, but we want to | avoid having idle proposals accumulate over time. OK. I propose that we change this. Remove the four-week language. Instead: * At any time the author of a proposal can transition from "Discussion" to "Decision", by changing the status of the proposal [link to explain how], and by sending email to the committee to signal the change. The author should do this only when there has been adequate opportunity for the community to respond to the proposal. It would be unusual to consider adequate any period less than four weeks from the last substantial change to the proposal. But this is not a hard and fast rule. It's the intent that matters. * Any proposal in "Discussion" that has had no input for more than four weeks may be moved "Dormant" status (by anyone). The goal here is simply to keep manageable the list of proposals that are being actively worked on. The author is free to resurrect it to "Discussion" status. Simon | -----Original Message----- | From: Ben Gamari [mailto:ben@well-typed.com] | Sent: 26 January 2017 16:25 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy | unboxed tuples / warn on unbanged strict patterns (#35) | | Simon Peyton Jones <simonpj(a)microsoft.com> writes: | | > Colleagues | > | > I didn’t think we had any 4-week discussion period. I thought that it | > was up to the author to press the button, saying “I think the proposal | > is in its final form, and the community has had enough time to | > respond”. At that point it moves from “Discussion” to “Committee | > decision” phase. | > | The limited discussion period was a suggestion that entered the process | only rather late as a suggestion from Richard (or least my interpretation | thereof). The hope is that it makes things a bit more manageable by | keeping the number of proposals at the focus of the communities attention | small. Authors are of course able to continue working with collaborators | to hone their proposals outside of the discussion phase, but we want to | avoid having idle proposals accumulate over time. | > | > I guess there could be a minimum period: the author can’t press the | > button until the community really has had time. But if they don’t want | > to push the button, fine. | > | > I’m trying put the author in control as much as possible. | > | > In decision mode we need a shepherd from the committee to push the | > discussion forward. Ben, as our current secretary, should suggest who. | > | Sure. | | | > Incidentally the “proposals process” link in the opening sentence | > https://github.com/ghc-proposals/ghc-proposals leads back to the same | > page, which is unhelpful. It should lead to | > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-su | > bmission.rst (which is about the whole process, not just about | > submission despite the URL). | > | I'll have a look at this. | | Cheers, | | - Ben

4 3