[ghc-steering-committee] Unhappy proposers

[Joachim Breitner]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190417/acd96a72/attachment.sig>