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

[Joachim Breitner]

You are adding some points, but all sensible and good.

Am 21. August 2019 14:49:29 MESZ schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>|  * 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 ….”).
>
>I don't find this very clear.  I think what you mean is:
>
>* To amend an accepted proposal #N (where #N is actually the # of the
>  original PR, no longer renumbered), you submit a PR (perhaps #K)
>  that is a diff to the accepted proposal.
>
>* That amendment might be minor (add clarification, examples) in which
>  case the Secretary may accept it directly.  Result: a modified
>  accepted proposal #N.
>
>* Alternatively, it might be substantive, and should be debated by
>  the community and committee.  In that case it goes through the
>  same process as any other proposal.  But once accepted, the result
>  is, once again, a modified accepted proposal #N.
>
>* In the latter case it is helpful if the PR is explicit that it's an
>  edit for an existing accepted propsal (not a fresh proposal), and
>  gives pointers a rendered version the original accepted proposal,
>  the diff, and the proposed final outcome after applying the diff.
>
>Have I understood correctly?
>
>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