Hi Arnaud, thanks for raising this; let me lay out the reasons for doing it the current way (which is intentional, but not unchangeable): * Merging unapproved, but implemented proposals. This would mean that there would be some proposals in the directory https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals that were not vetted, discussed and approved. Is that desirable? It seems it would water down the status of the rest. About documentation: The proposal can still be linked, during its implementation. Are you worried that the pull request will be lost somehow? You also write that the manual should link proposals (I guess that applies to all proposals). I don’t think we would be doing our users a favor here; they expect and deserve a comprehensive and self- contained manual. * Closing: We briefly had this discussion a while ago. The rationale to not close tickets that were not officially rejected is because contributor motivation is a scarce resource, and me just going around closing people’s proposals just because they are not able to press forward a lot. I am nudging stagnant proposals, and eventually mark them as “dormant”, as a more friendly way of closing them. Many authors then close them voluntarily when they have abandoned it. Note that the overview at https://github.com/ghc-proposals/ghc-proposals links to “≡ List of proposals under discussion” which includes only the somewhat active propsoals. Maybe I can close dormant porposals when nothing has happened in $n$ months, with a friendly message that it can be re-opend any time. Cheers, Joachim Am Freitag, den 23.02.2018, 15:08 +0100 schrieb Spiwack, Arnaud:
Dear all,
Joachim directed me here to raise some remarks about the proposal process that I've brought up.
Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.
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.
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.
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.
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.
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.
What does everybody think?
[1] https://github.com/ghc-proposals/ghc-proposals/pull/5
Best, Arnaud Spiwack _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/