[ghc-steering-committee] Unhappy proposers

Wed Apr 17 17:43:16 UTC 2019

I also think it's better to have all the discussion in one place.  However,
I think it would be beneficial to preserve the following two features of
the current process:

   1. Proposals are still submitted to the committee for review (and we get
an e-mail about it).  This is useful for me, as while I sometimes read
through proposals if I have some free time, I certainly don't track all of
them all the time.  But I do go and read them once Joachim sends the e-mail
that we should be discussing them.

   2. I think it would be good to try to keep the committee discussion on
Github more or less restricted to the committee and the proposal author.  I
think this would help keep steer discussions towards termination (which is
sometimes difficult even when we are restricted to just the committee :-)

Finally, I'd say that if we are going to discuss things on Github, then we
should probably make the mailing list private, since it won't really
contain any information of interest to the community.  And, it would make
it possible to have a private discussion, if we need to (of course, we
could do that anyway by e-mailing everyone explicitly, but that's a bit of
a pain).

On the topic of delay: to me it feels that a lot of the time when we have a
long delay, is when there isn't a clear consensus in the committee about
what to do---I am not sure what we can do about it.  My personal preference
is that in such cases we should reject "new features" and accept
"incomplete fixes", but of course we just have to deal with it on a case by
case basis.

-Iavor

On Wed, Apr 17, 2019 at 8:16 AM Eric Seidel <eric at seidel.io> wrote:

> The cost/benefit and audience points are important issues that we have to
> consider when evaluating a proposal, but I'm not sure that they are that
> relevant to this particular situation.
>
> It seems like the big issue apart from the delay (which I think we can all
> agree is a problem) was a failure of communication. We were under the
> impression that rejecting the programs would also solve Matthew's problem,
> but it seems we were mistaken. I think that alone points to the need for a
> more flexible process than an up-or-down decision.
>
> I like Joachim's first suggestion for point 3, that we deliberate on the
> list, present an initial response, and invite a rebuttal from the author
> before making a final decision. I think that keeping our initial
> deliberations on the list makes sense because it provides a more focussed
> forum for us to discuss the proposal. But I don't feel too strongly about
> deliberating on the list vs github.
>
> Thank you for sharing your frustrations with us, Matthew. We all
> appreciate the work you do.
>
> Eric
>
> On Wed, Apr 17, 2019, at 07:02, Simon Peyton Jones via
> ghc-steering-committee wrote:
> > 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/
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190417/ee83b085/attachment-0001.html>