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

...

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

On Wed, Apr 17, 2019, at 07:02, Simon Peyton Jones via ghc-steering-committee wrote: details.

...

It may be that we could articulate some of these tensions on our wiki

...

Doing so won't solve them but might help people to feel less badly

...

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@haskell.org> | On Behalf Of Joachim Breitner | Sent: 17 April 2019 11:30 | To: ghc-steering-committee@haskell.org | Cc: Matthew Pickering | 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

...

| 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

pages. treated. 7) and 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@joachim-breitner.de | http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Mittwoch, den 17.04.2019, 14:00 -0400 schrieb Eric Seidel:

Good point. I've noticed that as well. We get to a point where everyone has made their position fairly clear, but there's no consensus. And then things linger..

if there is really disagreement, then we vote. At least that the process. It is a fallback (and I think we never needed it), but there is a way forward. It would be up to the shepherd to determine that it is time to vote.

I'm not really sure what to do in this case either. Perhaps a default response would make sense. Another option would be that when we reach an impasse, we reach out to the author and invite them to address the concerns directly.

Well, we now want to involve the author during the discussion anyways, so hopefully this will not be needed. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Wed, Apr 17, 2019 at 11:01 AM Joachim Breitner wrote:

...

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 :-)

Likely not possible from a technical point of view, but without enforcement not possible from a social point of view. I think if we move the discussion to Github, we have to face (and maybe benefit!) from a larger group of participants.

(You can lock conversations, but that would also lock out the original author, see https://help.github.com/en/articles/locking-conversations)

Yeah, I didn't mean that we should do anything technical, just have this be the specified process and hope that people more or less follow it. Obviously, if someone has something productive to say during the committee discussion, they can mention it and we can try to address it. However, I think there is a benefit to encourage the community to give their feedback before the committee discussion has begun, as I think this 1) helps improve proposals, and 2) enables us (the committee) to read through the discussion to see what the current opinions are--- I find this quite helpful, as it gives me an idea of what people like/dislike, and sometime points out issue I hadn't thought about. -Iavor

Thanks, Joachim, for writing the initial post and suggesting concrete directions. And, thanks, Matthew (who, at some point, got dropped off this conversation -- no doubt unintentionally), for speaking up about your dissatisfaction instead of just stewing. I agree that we should make it a policy not to make a "reject" recommendation without writing on the GitHub issue first, in order to invite a rebuttal. However, I'd prefer to keep discussions on this list, for the reasons others have mentioned. Primarily, I'm worried that GitHub can be a noisy place, and if we have our deliberations there, our status as a decision-making committee is somewhat compromised. On the other hand, an easy practice that could increase discoverability and transparency is to have the shepherd post a link to the on-list conversation on the GitHub trail at the end of deliberations. Our thoughts are then preserved nicely. Richard

On Apr 17, 2019, at 5:43 PM, Eric Seidel wrote:

Iavor's point about keeping the committee discussion restricted to the committee is basically my only reason for preferring to keep the discussion on the mailing list.

It seems useful to have a separate place for us to deliberate and formulate a response to the proposal, not for any notion of privacy or secrecy (our discussions are already public, as they should be). Rather, it's just easier to keep the discussion focused when we have a smaller group of participants.

If there's a feeling that our discussions are not visible enough, perhaps we could deliberate proposals on a separate, locked issue? That might satisfy both desires, though it also feels a bit laborious..

On Wed, Apr 17, 2019, at 14:23, Iavor Diatchki wrote:

...

On Wed, Apr 17, 2019 at 11:01 AM Joachim Breitner wrote:

...

...

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 :-)

Likely not possible from a technical point of view, but without enforcement not possible from a social point of view. I think if we move the discussion to Github, we have to face (and maybe benefit!) from a larger group of participants.

(You can lock conversations, but that would also lock out the original author, see https://help.github.com/en/articles/locking-conversations)

Yeah, I didn't mean that we should do anything technical, just have this be the specified process and hope that people more or less follow it. Obviously, if someone has something productive to say during the committee discussion, they can mention it and we can try to address it.

However, I think there is a benefit to encourage the community to give their feedback before the committee discussion has begun, as I think this 1) helps improve proposals, and 2) enables us (the committee) to read through the discussion to see what the current opinions are--- I find this quite helpful, as it gives me an idea of what people like/dislike, and sometime points out issue I hadn't thought about.

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Yes, I think, this is an improvement. Cheers, Manuel

Am 18.04.2019 um 18:21 schrieb Joachim Breitner :

Hi,

based on this discussion I am making a concrete proposal here:

https://github.com/ghc-proposals/ghc-proposals/pull/221

The main idea is that if the shepherd intends to reject the proposal, they have to first discuss this with the authors, to give the authors a chance to respond, tweak, or point out misunderstandings in the shepherd’s perception.

So the process of accepting proposals is unchanged, and still on the list, rejecting a proposal is now a two step process: the shepherd discusses it with the authors on GitHub (and anyone else interested, of course), and then there is a shorter discussion on the mailinglist, with hopefully all facts clarified.

This does not move all discussion to Github yet, so it is the smaller change, in a way. But of course committee members are encouraged to join GitHub discussions early, especially if they are unhappy with a proposal.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee