[ghc-steering-committee] Results of committee meeting at ICFP

[Simon Peyton Jones]

|  * We will update wording in the README to tell authors that turning
|    a proposal back with “needs review” is not a bad thing.

I think we could be more precise.  Specifically, if significant new technical questions arise during committee discussion, then I think it should be positively encouraged to go back to discussion phase, so that the author can update the proposal to address the technical questions, and (when the discussion dies down and the author is satisfied), resbumit.

In this way proposals should languish in "committee review" status for less long.

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 21 August 2019 12:58
| To: ghc-steering-committee <ghc-steering-committee at haskell.org>
| Subject: [ghc-steering-committee] Results of committee meeting at ICFP
| 
| 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 at joachim-breitner.de
|   http://www.joachim-breitner.de/
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee