<div dir="ltr"><div><div>Both points make a lot of sense to me.<br><br></div>Cheers<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2018 at 14:08, Spiwack, Arnaud <span dir="ltr"><<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>Dear all,<br><br></div><div>Joachim directed me here to raise some remarks about the proposal process that I've brought up.<br><br>Out of the hundred or so submitted proposals, only roughly 
half were closed, including a mere 11 merged.<br></div><br></div>On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented 
before the committee had time to evaluate it, hence became out of scope.<br><br></div>Why do we merge proposals? One reason proposal can be referred to by 
pull requests authors to describe the changes that they're implementing.
 The other reason that I can see is that proposals can serve as 
documentation: they can be referred to inside the documentation to 
explain why things are done the way they are, they can be browsed by 
curious onlookers who want to understand the trade-offs that went into 
this particular design, we could even consider linking to them in the 
manual as longer-form stand-alone pieces of documentation for individual
 features.<br><br></div>From that point of view the backpack proposal 
ought to have been merged: it is still documentation after the 
implementation is finished. Irrespective of whether the committee has 
had to work for it.<br><br></div>On the "closing" side, I think we 
should be better at triaging. It's less important, of course, because 
forgotten PRs fall behind are not seen by anybody. But it could help 
give a valuable feeling of tidiness. I believe a tidy repo makes people 
feel more at ease with sharing their thoughts. And, just as importantly,
 it would help Joachim to manage the proposals: with 40+ open proposals, you
 probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 
proposals to track, Joachim's time would be more efficiently spent.<br><br>I don't believe 
we should hesitate to close a proposal which is not under discussion 
any more, authors can still reopen when they want to get back to 
discussing the matter. There are quite a few dormant proposals, also 
out-of-scope which didn't receive any conversation of late, or 
need-revision which don't seem to be seeing any update. These could all 
be closed.<br><br></div><div>What does everybody think?<br></div><br>[1] <a href="https://github.com/" target="_blank">https://github.com/</a>ghc-<wbr>proposals/ghc-proposals/pull/5<br></div><br></div>Best,<br></div>Arnaud Spiwack<br></div>
<br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
<br></blockquote></div><br></div>