Fwd: New Libraries Proposal process

[Bertram Felgenhauer]

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