Fwd: New Libraries Proposal process

[Tikhon Jelvis]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200912/5e711644/attachment.html>