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
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