- ghc-steering-committee

Status
by Joachim Breitner 14 Sep '19

14 Sep '19

Dear committee, nothing creative to say here this month, while I am sitting at Richard’s breakfast table due to my intra-european jet lag (train lag?). Since the last status, we * had a partial committee meeting at ICFP, with some suggested changes. None of those not there have vetoed (or even commented) them, so I guess we should start implementing those that we haven't yet. * were asked to review these proposals: #160: NoToplevelFieldSelectors (Shepherd: Eric) #259: No kind signatures on associated types (Shepherd: Simon PJ) * have a recommendation form the shepherd about: #259: No kind signatures on associated types (rec: accept) * decided about the following proposals #231: #233: Higher-order roles (needs revision) #231: Record with syntax (needs revision) #160: NoFieldSelectors (accept) #229: Simplified parsing of (~) and (!) (accept) We currently have to act on the following 3 proposals, 3 down since last time. Good job committee! No kind signatures on associated types Shepherd: Simon PJ Status: acceptance recommended, consensus seems to emerge https://github.com/ghc-proposals/ghc-proposals/pull/259 Qualified Imports Shepherd: Simon M. Status: Waiting for Simon to officially make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/220 Updated partial type signatures Shepherd: Vitaly Status: Waiting for Vitaly to make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/194 Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Early feedback wanted on #243: TH overhaul to make it Cross-compile-friendly
by Joachim Breitner 14 Sep '19

14 Sep '19

Dear committee, there is a rather large proposal sitting in #243. Its goal is to address our somewhat embarrassing story around Template Haskell and cross compilation, and as such deserves attention. But it is also a very big, wide reaching change, even removing some existing features until we figured out how to do them properly. In his comment at https://github.com/ghc-proposals/ghc-proposals/pull/243#issuecomment-531394… the author (John Ericson) wondered if he could get preliminary feedback on the proposal: Is this going into a direction that has a chance of acceptance? Who in the committee knows enough about TH and (maybe) also cross compilation to give the proposal in its current form a good read and give a first assessment? Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #233: Higher-order roles, Shepherd: Simon PJ
by Joachim Breitner 05 Sep '19

05 Sep '19

Dear Committee, this is your secretary speaking: Higher-order Roles has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/233 https://github.com/goldfirere/ghc-proposals/blob/higher-roles/proposals/000… I propose Simon PJ as the shepherd, as he already has had a discussion with Richard on this. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Proposals under review
by Simon Peyton Jones 05 Sep '19

05 Sep '19

Joachim On our home page https://github.com/ghc-proposals/ghc-proposals there is a list of "proposals under committee review": https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… But alas the latter shows zero proposals -- but I know there are proposals under review. What's up? Simon

3 2

Please review #258: TopLevelKindSignatures -> StandaloneKindSignatures , Shepherd: Chris
by Joachim Breitner 05 Sep '19

05 Sep '19

Dear Committee, this is your secretary speaking: TopLevelKindSignatures -> StandaloneKindSignatures has been proposed by Krzysztof Gogolewski https://github.com/ghc-proposals/ghc-proposals/pull/258 I propose Chris as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Results of committee meeting at ICFP
by Joachim Breitner 24 Aug '19

24 Aug '19

Hi Committee, some of us (2×Simon, Iavor, Richard, Eric, me) met over lunch at ICFP and discussed tweaks to the process, and came up with the following changes. Of course we want to give the other members a chance to comment and speak if up if something is a bad idea, so we won’t be implementing the immediately (but preferably soon). * Proposals that are in “Pending committee decision” phase will have a [committee] tag appended to the title, so that we can filter emails by that status. * We drop the restrictions for non-authors to comment in that phase. It doesn't work and sometimes we do want the insights of the others. * We will update wording in the README to tell authors that it is ok and not impolite to nudge the shepherd if the process seems stalled. * We will update wording in the README to tell authors that turning a proposal back with “needs review” is not a bad thing. * If we have later proposals that are not stand-alone proposals, but rather changes to existing ones, and those get accepted, then the updated proposal should link back to the changing PR, just like it links to the original PR (e.g “This proposal was discussed at … and amended by ….”). * We will stop renumbering proposals sequentially, but instead simply use the PR number, so that we no longer have this two-number confusion. (We should have done that from the start :-() * We will actually re-number the already accepted proposals, but leave the old files there to point to the new location, so that existig links stay valid. (Either as symlinks or simply as very short files, I will see how GitHub presents either of these options). * We considered making it a requirement that authors find a number of “endorsers” for their proposal, but were not sure if that is useful. But we would like to experiment with that concept, so we would add a section to the template that will contain a list of endorsers, and endorsers could indicate to the author that they endorse the proposal on the GitHub comment thread, and the authors then adds them. The expectation for an endorser is that “they support the proposal as if they were an authors, and they would happily have submitted it themselves, had they had the idea and time.” Endorsers have no hard role in the process, but hopefully ensure that proposals are seen and read and checked by more people before submission, and we get a bit more signal by seeing how many people and who also wants this. * Although most people were at least mildly in favor, we kicked the question of fixed terms down the road. But I will send out the brief “how do you feel about your work in the committee” questionaire that we had a few months ago around once in a while, with the explicit purpose to nudge members to maybe get more involved again, or plan to rotate out. What do you think? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 5

Please review #160: NoToplevelFieldSelectors, Shepherd: Eric
by Joachim Breitner 23 Aug '19

23 Aug '19

Dear Committee, this is your secretary speaking: NoToplevelFieldSelectors have been proposed by Simon Hafner https://github.com/ghc-proposals/ghc-proposals/pull/160 https://github.com/reactormonk/ghc-proposals/blob/master/proposals/0000-no-… I propose Eric as the Shepherd, because I know what you did last summer (namely look at that propsoal). Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Steering committee thoughts
by Simon Peyton Jones 21 Aug '19

21 Aug '19

(Resend because I stupidly sent it to the wrong address. Joachim's summary really post-dates this email.) Friends Here are a collection of suggestions that we might discuss at our meeting today, about managing expectations in the GHC proposals process. Factors at work: * Proposal authors are sometimes quite invested in their work, and expect prompt feedback. * Yet committee members are volunteers with day-jobs, and reviewing proposals is a kind of blank cheque on their time, and they are doing the community a great service by being willing to do that reviewing. * Finally, to an author the benefits of acceptance are sharply-focused and immediate; but the costs are blurry and deferred. (I'm thinking of costs like: consistency of design, complexity of the language, implementation burden over time..) Balancing these is hard. I've seen discussion that boils down to a mis-match of expectations. Here are some concrete suggestions for things that might contribute to making expectations clearer and more explicit. All of the numbers (four years, two weeks) are just straw-men... the first thing is to decide if we want any of these thing s in principle. * Make service on the GHC Steering Committee a fixed 4-yr term, with staggered dates so two people retire each year. Renomination is allowed; but the expectation is that fresh blood is preferred unless there is a clear reason to the contrary. As I've said in earlier email, I think this is just basic good practice for any committee. Current membership is here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. I'd quite like not to have the reviewing load, but I think that Simon and I should probably be exceptions to this rule * Write down the constituencies we'd like to see represented on the steering committee; invite members to self-designate which constituencies they feel well equipped to represent; and then add that as a column to the table you have helpfully made. This will help to show gaps when we are seeking nominations. * For shepherding, make it clear what the expectations are: no shepherded thread should be dormant for more than two weeks without the shepherd making a proposal for the next step. And even if actively discussed, the shepherd should guide the committee to a conclusion (accept, push back to author) within two months. Big proposals may need longer, so the shepherd should be free to (explicitly) propose a different timescale. * For committee membership, write down expectations about their participation. Something like * Participate actively in at least some proposals in the discuss-and-refine phase. * Review every proposal that is submitted to the committee, within three weeks, and offer a view - even if that view is "I have read the proposal completely but I do not have enough expertise in this area to express a well-informed opinion" * Act as the shepherd for a small number of proposals (see expectations of shepherds). Thanks Simon

1 0

lunch in "Wolverine"
by Richard Eisenberg 21 Aug '19

21 Aug '19

Hi all, The lunch today at ICFP will take place in the Wolverine room. Pass between the elevators and turn left to find the room. Please bring your lunch to the room. If you beat me there and the room is locked, Annabel knows we're there and will unlock the room if you say the magic words "GHC Steering Committee". See you soon, Richard

1 0

ICFP Meetup?
by Eric Seidel 18 Aug '19

18 Aug '19

Hi Committee! How many of us will be at ICFP next week? Shall we meet up again at some point? There are a couple things that I think might be worthwhile for us to reflect on and discuss: 1. The GitHub vs ML question. Richard argued a few weeks back that the pure GitHub strategy wasn't working very well, and a few of us agreed with him but the discussion didn't go any further. 2. The ExtraCommas proposal left quite a few valued members of the community dissatisfied, in ways that I think we could have prevented (e.g. the excessively long deliberation period and the confusion around the vote). I'll be around all week. Eric

7 9