I rather agree with Ryan. I think we are doing quite well on generating thoughtful debate; but rather badly on bringing those debates to a conclusion. I’d like to suggest: · The author of the proposal is responsible for moving a proposal into “committee review” status. We should make it blindingly clear that it’s the author’s responsibility; and how they should actually make that change. · We need a committee Secretary who o Assigns a “shepherd” for each proposal that is in “committee review”. (I don’t think we need a shepherd before then.) The shepherd is responsible for bringing the committee to consensus within four weeks. o Chivvies the shepherd if s/he doesn’t appear to be making progress. o Perhaps sends regular (fortnightly?) summaries of what proposals are in what state – thought that should be a web link, shouldn’t it? Yes: we should display the date of when it moved into committee review. o Makes sure that the proposals repo is in good shape. For example the submission pagehttps://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submissi... does not specify that the author changes status, etc. It looks like a previous version… So the Secretary chivvies the shepherd; and the shepherd chivvies the committee; and we should get decisions actually taken. Now, to date I think Ben has been de-factor Secretary; but he has rather a lot of balls to juggle, and I wonder if you would be interested/willing Joachim? Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Ryan Newton Sent: 19 February 2017 15:26 To: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] Prioritizing proposals for processing? Viewing dates/deadlines? 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 herehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpulls%3Fq%3Dis%253Apr%2Bis%253Aopen%2Bsort%253Acreated-asc&data=02%7C01%7Csimonpj%40microsoft.com%7C580eab8a619c4dbdb28e08d458dc8c99%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636231151665537766&sdata=kw4dXYfavJM7w%2BiOBiK3T0E2WyMXchLlXMXKn%2BlsvUI%3D&reserved=0, 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 36https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F36&data=02%7C01%7Csimonpj%40microsoft.com%7C580eab8a619c4dbdb28e08d458dc8c99%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636231151665537766&sdata=y1bGEzyCEnHDH0TDSw07kUw1bOPZ4jcZEqm1lVZOcho%3D&reserved=0?: * 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 READMEhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7C580eab8a619c4dbdb28e08d458dc8c99%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636231151665537766&sdata=%2FCFVE%2B6C9%2Fld%2FXB5i9XrL08H5M5ziqUoP5vG5%2FTCzBs%3D&reserved=0. Which says only: "Proposals are ultimately evaluated by the GHC Steering Committeehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fsteering-committee.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C580eab8a619c4dbdb28e08d458dc8c99%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636231151665537766&sdata=N1mTjcucqKfQtdgM3r0%2Faw6lC85pAHQ8d0m8L0CW4AI%3D&reserved=0 based upon a number of criteria and in light of community feedback." On Fri, Nov 18, 2016 at 8:56 AM, Richard Eisenberg mailto:rae@cs.brynmawr.edu> wrote: ..... I propose the following: - Establish an official ghc-committee@haskell.orgmailto:ghc-committee@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.