| 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 | Subject: Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy | unboxed tuples / warn on unbanged strict patterns (#35) | | Simon Peyton Jones 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