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. 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. On Sat, Sep 12, 2020, 09:15 Bertram Felgenhauer via Libraries < libraries@haskell.org> wrote:
Oliver Charles wrote:
On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries wrote:
In any case I think that any change to the library proposal process should cater to all three types of stakeholders (and possibly others I have failed to think of). In its current form, I believe
[1]https://github.com/haskell-core/core-libraries-proposals
fails to do that for observers.
Could you explain why this fails? I watch the ghc-proposals GitHub project and get notified of all comments, so feel as an observer my needs are well catered for. Furthermore, having each proposal be a PR can let me see how a discussion is factored back in to the proposal, as comments become a diff.
Unless somebody force-pushes a new version, in which case I think the old version is lost forever.
What do you feel a ML has that GitHub + watching does not have?
I suppose that works, for people with a GitHub account (possibly a strawman; I do have one). But it should be mentioned somewhere! The experience can also be improved by conventions. For example, I'd like the PRs that constitute proposals to come with a synopsis of the proposal as the description, because the descriptions end up in the notifications, whereas the actual commits do not. So to avoid having to check every proposal on GitHub, such a synopsis would be useful. Maybe this should be self-evident, but it's not mentioned in the README document.
There's also the loss of threading mentioned elsewhere. I cannot say how bad this is in practice (I delete GitHub notifications after reading them). We can see in the libraries archive that for larger proposals we often have several subthreads about different aspects of the proposal (and I frequently skip over whole subthreads when I'm not intersted the aspect under consideration).
I also find that with email it's easy to send a comment just to the author (e.g. for typos). GitHub makes this harder (I suppose you /can/ open a ticket in the author's clone of the repo...).
And, obviously, there's resistance to change.
While we're comparing these things, what are the problems that the new process is meant to solve?
Cheers,
Bertram _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries