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

[Simon Peyton Jones]

|  * 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