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