Fwd: New Libraries Proposal process

[Carter Schonwald]

Thank you Bertram!
I think these are very important perspectives and questions  that I feel
arent being answered.

Secondarily, I worry that some of these approaches turn into
professionalizing activities people do as volunteers for fun! Supporting
contributors of all walks and backgrounds is very different from workflow
management with full time administrative supoort...

If certain folks find an issue tracker helps them, great! But it would be
good to clearly articulate who benefits and who it hinders and what are
examples where actually progressing improvements has been stymied where the
issue indeed lies with not having an issue tracker.  I absolutely agree
that all things being equal, having task journals of items and their
specifications is great. But ... that presupposes a lot more suport Labor
is available in a semi professional capacity than I think can be done while
being inclusive.

I could be totally wrong, but it’s a concern I have

On Sat, Sep 12, 2020 at 12:15 PM 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/dd6a340f/attachment.html>