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, 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?:

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. Which says only:

"Proposals are ultimately evaluated by the GHC Steering Committee based upon a number of criteria and in light of community feedback."

On Fri, Nov 18, 2016 at 8:56 AM, Richard Eisenberg <rae@cs.brynmawr.edu> wrote:

.....
I propose the following:

- Establish an official 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.