<br><div class="gmail_quote"><div dir="auto">On Wed, 2 May 2018 at 8:28 PM, Simon Peyton Jones <<a href="mailto:redirect@vodafone.co.nz">redirect@vodafone.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">| > Sometimes, a language extension idea could benefit from<br>
| some community discussion before it's ready for a formal proposal.<br>
| <br>
| Can I point out it's not only ghc developers who make proposals.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">| I'd rather you post this idea more widely.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">(I meant for David to post more widely the idea of using Github issues tracker. Because I suspect the people who would most benefit from the 'community discussion' are not participants on ghc-devs.)</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The Right Thing is surely for the main GHC proposals pav[g]e<br>
<a href="https://github.com/ghc-proposals/ghc-proposals" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals</a><br>
to describe how you can up a "pre-proposal". That is, document<br>
the entire process in one, easy to find, place.<br>
<br>
Mind you, I'm unclear about the distinction between a pre-proposal<br>
and a proposal. ...</blockquote><div dir="auto"><br></div><div dir="auto">Thanks Simon,</div><div dir="auto"><br></div><div dir="auto">Speaking as a non-developer of ghc, often there's a bright idea with no very clear notion how best it fits into Haskell, or could be implemented effectively/efficiently:</div><div dir="auto"><br></div><div dir="auto">* maybe it's something seen in another language;</div><div dir="auto">* maybe the proposer finds themself writing the same boilerplate repeatedly, and wonders if that's a common idiom the language could capture;</div><div dir="auto">* sometimes it starts as more of a 'how do I do this?' question; then you get told you can't; then other people chip in with 'yes I'd like to do that too'.</div><div dir="auto">* sometimes it's more of a niggle: this really annoys me/is awkward/is confusing every time I bump into it/even though I can work round it.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Both are drafts that invite community discussion,<br>
prior to submitting to the committee for decision.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">I'm guessing as to why David raised the question. I've noticed (a minority of) proposals generate a huge amount of discussion, a lot of which is: you can already do that, or nearly all of that, or there's good reasons why ghc/Haskell shouldn't do that. Then maybe the difficulty that needs tackling is that the submitter isn't really following the process/perhaps the process document should be clearer about what threshold of readiness the ideas should be in before formalising(?) I'll try to avoid specifics here, but two proposals I can think of essentially amounted to: Language XXX has YYY; language XXX is similar to Haskell; I think YYY is great; please put YYY in Haskell; P.S. I don't really understand ghc and all the extensions it now offers.</div><div dir="auto"><br></div><div dir="auto">As you've remarked yourself, sometimes the 'community discussion' gets so convoluted and sidetracked it's impossible to make out where the proposal is at, and whether all objections have been addressed. That's the point at which IMO the proposal should be withdrawn and resubmitted as a 'fresh start'.</div><div dir="auto"><br></div><div dir="auto">OTOH, as I said, there's plenty of other forums those less formal/pre-proposal discussions could happen. Some used to happen on Trac/started life as bug reports -- which is rightfully discouraged. _Could_ happen but often doesn't raise a response. What if Github issues tracker just becomes another backwater where ideas go to get ignored?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">AntC</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
| -----Original Message-----<br>
| From: Glasgow-haskell-users <glasgow-haskell-users-<br>
| <a href="mailto:bounces@haskell.org" target="_blank">bounces@haskell.org</a>> On Behalf Of Anthony Clayden<br>
| Sent: 02 May 2018 02:34<br>
| To: <a href="mailto:glasgow-haskell-users@haskell.org" target="_blank">glasgow-haskell-users@haskell.org</a>; <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| Subject: Re: Open up the issues tracker on ghc-proposals<br>
| <br>
| > On May 1, 2018, at 2:24 PM, David Feuer <david.feuer at<br>
| <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>> wrote:<br>
| ><br>
| > Sometimes, a language extension idea could benefit from<br>
| some community discussion before it's ready for a formal proposal.<br>
| <br>
| Can I point out it's not only ghc developers who make proposals. I'd<br>
| rather you post this idea more widely.<br>
| <br>
| As a datapoint, I found ghc-users and the café just fine for those<br>
| discussions.<br>
| Ghc-users seems to have very low traffic/is rather wasted currently.<br>
| And I believe a lot of people pre-discuss on reddit.<br>
| For ideas that have been on the back burner for a long time, there's<br>
| often wiki pages. (For example re Quantified<br>
| Constraints.)<br>
| <br>
| > I'd like to propose that we open up the GitHub issues<br>
| tracker for ghc-proposals to serve as a place to discuss pre-proposal<br>
| ideas. Once those discussions converge on one or a few specific plans,<br>
| someone can write a proper proposal.<br>
| <br>
| I'm not against that. There gets to be a lot of cruft on some<br>
| discussions about proposals, so I'd expect we could archive it all<br>
| once a proposal is more formalised.<br>
| <br></blockquote></div>