[ghc-steering-committee] Unhappy proposers

[Simon Peyton Jones]

Thanks Joachim - and thank you Matthew for taking the trouble to write.

Some brief responses

* I don't see any reason to conduct a conversation on the steering
  committee email list, rather than on the Github converation.  In
  fact doing it by email is *less* good because the discussion is in
  two places.  The only reason to do so would be to have a private
  conversation -- but the email list is by design public.  So yes
  to Github; and let's explicitly invite the author to participate
  in the conversation if they wish.

* Delay.  This is a challenge because everyone is a volunteer and
  everyone is busy.  Should I spend the next 30 mins reviewing a
  GHC proposal or a patch that fixes a bug?  That delay is hard on 
  the author, but I see no way to fully solve that tension.

* Cost and benefit.  The biggest tension I feel is that every incremental
  change to the language makes it more complicated, makes the compiler
  more complicated, and imposes a new maintenance burden on the
  implementors, forever.  There are many features I value (e.g. partial
  type signatures, or pattern synonyms) whose authors have long since
  moved on, and I am the de-facto maintainer.

  It's not wrong to move on. It's a huge service for someone to propose,
  design, and implement something.  But is genuinely difficult to balance
  the immediate benefits (esp to the author) against the long-term costs.

* Audience.  Sometimes the population that genuinely wants a feature is
  pretty small.  That does not make it a bad proposal -- sometimes people
  don't know they want something till it's there.  But it does make it
  harder to generate the time and energy to dig into the technical details.

It may be that we could articulate some of these tensions on our wiki pages.
Doing so won't solve them but might help people to feel less badly treated.
And THAT is a very important goal.

Matthew: you are a major contributor to GHC -- thank you!

Simon
 

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 17 April 2019 11:30
|  To: ghc-steering-committee at haskell.org
|  Cc: Matthew Pickering <matthewtpickering at gmail.com>
|  Subject: [ghc-steering-committee] Unhappy proposers
|  
|  Dear Committee,
|  
|  I have received an email from one of our most productive proposal writers,
|  Matthew, who we have left quite unhappy with the process, and I hope we
|  can take the time to see what went wrong, and what we can do differently
|  to not be wasteful with the motivation of the Matthews out there.
|  
|  Matthew asked me to paraphrase his complaints, just to get this started on
|  a productive tone. So I’ll play annoyance tone firewall.
|  
|  The PR in question is #207 (Fix the treatment of type variables in
|  quotations), and he has three main reasons why he is unsatsified:
|  
|  
|  1. Delay
|  ========
|  
|  There was a long delay between consensus on the mailing list (March 7) and
|  the official announcement on GitHub.
|  
|  
|  This is clearly true, and is purely on me, and I am sorry for that.
|  
|  I try to do a monthly sweep of the committee activities, including closing
|  or accepting proposals where I did not do it directly, but well, the last
|  month turned out to be 90 days or so … I will try to be better here, but
|  also appreciate nudges.
|  
|  Also, shepherds, if you detect consensus, feel encouraged to respond to
|  the list with “Looks like we can accept/reject this, Joachim, can you do
|  it?” Then I am likely to do the bureaucratic acts directly.
|  
|  
|  2. Lack of understanding
|  ========================
|  
|  Matthew has the impression that the itch he was trying to scratch, the
|  overall needs of Typed Template Haskell (a still rarely used feature, but
|  dear to his hard) and his solutions are not well understood.
|  
|  
|  I am not in a position (and this is maybe not the right thread) to judge
|  who is wrong and who is right. And maybe that is partly the
|  point: Not the whole committee is in a position to understand the
|  implications of a change to, say, Typed Template Haskell. Do we need to
|  adjust our process to that somehow? How do we deal with that?
|  
|  Also, I think we can recognize that we should not underestimate the
|  motivation and the actual needs of the people who sit down and write
|  proposals, and assume good faith. Matthew says that the bug he tries to
|  fix here does affect his actual work, and in particular that our solution
|  (forbid type variables in splices) does not actually solve his problem.
|  
|  
|  3. Lack of communication
|  ========================
|  
|  Finally, Matthew points out that some of the reasons that led to the
|  rejection were not properly discussed with him as the author first.
|  
|  
|  I agree that this is a problematic pattern, and one that I have observed a
|  few times too: A proposal gets proposed, the shepherd recommends rejection
|  (or the discussion veers in that direction), we discuss the pros and cons,
|  and then just reject it. I understand how a proposer might feel helpless
|  in that situation.
|  
|  Worse, they see that proposals by committee members have an easier time,
|  because then the committee member happens to be on the list and can defend
|  and explain their proposal better. (This point was not raised by Matthew,
|  but added by me).
|  
|  
|  Luckily, I think this problem can be solved in a procedural way.
|  
|     Procedural proposal A:
|  
|     When a shepherd intents to proposal rejecting a proposal, he first
|     writes his rationale on the Github discussion thread and waits for
|     the author’s rebuttal. This can (and is encouraged) to lead to a
|     discussion between shepherd and authors (and any further interesting
|     party or committee member) with one of these outcomes:
|      * the shepherd is swayed and proposes acceptance,
|      * the proposal is improved and the shepherd can propose to accept
|        it,
|      * the authors withdraw the proposal,
|      * no agreement can be reached, and the discussion comes to an end.
|        Now the shepherd may propose rejecting to the committee.
|  
|  
|  I think this process would give the authors a bigger say and role, more
|  insight and warning into a possible rejection, and thus hopefully better
|  satisfaction in the end.
|  
|  
|  A simpler variant of that with a similar result would be something we have
|  discussed earlier:
|  
|     Procedural proposal B:
|  
|     The committee discusses proposals on Github; the mailing list is
|     only used for announcement (new proposal and shepherd assignment,
|     shepherd’s recommendation, decision, status messages,
|     metadiscussions like this one.)
|  
|  
|  What are you opinions here?
|  
|  Matthew, would any of these procedures have given you a better experience
|  and/or outcome?
|  
|  
|  I hope we can turn Matthew’s bad experience into something with a
|  productive outcome!
|  
|  (Note that I have not included all technical details of Matthew’s email
|  here, to keep this focused on the procedural problems he points out.
|  Matthew, maybe you can raise the good technical points on Github
|  separately?)
|  
|  
|  Cheers,
|  Joachim
|  
|  
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/