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