[ghc-steering-committee] GHC proposal process: merging and closing

[Spiwack, Arnaud]

Hi Joachim,

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

I would consider that they were implicitly vetted by whomever merged the CR
into GHC master. Or is it too much of a stretch? Obviously they are changes
which have somewhat side-stepped the process which probably only happens
because the dust hasn't quite settled yet.


>    About documentation: The proposal can still be linked, during its
>    implementation. Are you worried that the pull request will be lost
>    somehow?
>

Not really. But if a proposal is not vetted, referring to it is less strong
an argument when you ask for merge, of course. Merge serves as a witness of
vetting. On the other hand, if this was the only reason to merge proposal,
we should remove them when they are implemented. What I was trying to get
at, is that we probably want proposals to stay, because they serve as
documentation even after they have been implemented.


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

To be fair, I said "could".

And the idea is that a proposal contains a lot beyond what the manual will.
The entire specification section must make it to the manual. However, the
motivations will usually be much shortened, and the alternatives will
typically not be in a manual at all. A proposal also has a link to the
github discussion which can give really insightful historical perspectives
on a feature. So giving a link to the proposal could help someone who, for
instance, is considering contributing an extension to a given feature. It's
not something that should be prominent. But can feature in a "further
reading" section, together with the relevant scientific articles.


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

I agree that it is a matter of reading people's psychology right. No mean
feat!

I would personally go for closing after a while. Certainly with the
friendly message!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180223/6c8ed3b0/attachment-0001.html>