<div dir="auto">One thing I find valuable with the GitHub proposal style—which I've observed in GHC proposals and in Rust—is that each proposal has a document that contains all of the information and gets updated over time. Later on, it's nice to read the final version of a proposal document without needing to go into all of the discussion that led up to it.<div dir="auto"><br></div><div dir="auto">We could still do that while having discussions on a mailing list, of course, but it seems that GitHub makes the connection between discussions and the proposal document more direct.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 12, 2020, 09:15 Bertram Felgenhauer via Libraries <<a href="mailto:libraries@haskell.org">libraries@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oliver Charles wrote:<br>
> On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries<br>
> wrote:<br>
> <br>
> In any case I think that any change to the library proposal process<br>
> should cater to all three types of stakeholders (and possibly others<br>
> I have failed to think of). In its current form, I believe<br>
> <br>
>   [1]<a href="https://github.com/haskell-core/core-libraries-proposals" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell-core/core-libraries-proposals</a><br>
> <br>
> fails to do that for observers.<br>
> <br>
> Could you explain why this fails? I watch the ghc-proposals GitHub<br>
> project and get notified of all comments, so feel as an observer my<br>
> needs are well catered for. Furthermore, having each proposal be a PR<br>
> can let me see how a discussion is factored back in to the proposal, as<br>
> comments become a diff.<br>
<br>
Unless somebody force-pushes a new version, in which case I think<br>
the old version is lost forever.<br>
<br>
> What do you feel a ML has that GitHub + watching does not have?<br>
<br>
I suppose that works, for people with a GitHub account (possibly a<br>
strawman; I do have one). But it should be mentioned somewhere! The<br>
experience can also be improved by conventions. For example, I'd like<br>
the PRs that constitute proposals to come with a synopsis of the<br>
proposal as the description, because the descriptions end up in the<br>
notifications, whereas the actual commits do not. So to avoid having<br>
to check every proposal on GitHub, such a synopsis would be useful.<br>
Maybe this should be self-evident, but it's not mentioned in the<br>
README document.<br>
<br>
There's also the loss of threading mentioned elsewhere. I cannot say<br>
how bad this is in practice (I delete GitHub notifications after<br>
reading them). We can see in the libraries archive that for larger<br>
proposals we often have several subthreads about different aspects of<br>
the proposal (and I frequently skip over whole subthreads when I'm<br>
not intersted the aspect under consideration).<br>
<br>
I also find that with email it's easy to send a comment just to the<br>
author (e.g. for typos). GitHub makes this harder (I suppose you /can/<br>
open a ticket in the author's clone of the repo...).<br>
<br>
And, obviously, there's resistance to change.<br>
<br>
While we're comparing these things, what are the problems that the new<br>
process is meant to solve?<br>
<br>
Cheers,<br>
<br>
Bertram<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>