Proposed changes to merge request workflow
Alan & Kim Zimmerman
alan.zimm at gmail.com
Fri Nov 8 20:47:47 UTC 2019
What about some sort of script that detects MR older than x time without a
reviewer, and asks a group of people to take a look.
On Fri, 8 Nov 2019 at 19:36, Richard Eisenberg <rae at richarde.dev> wrote:
> I wonder if it would alleviate the concerns to have a ghc-maintainers
> mailing list. This is distinct from ghc-devs, in that the maintainers have
> GHC as their day job. It would explicitly invite email from folks
> struggling to figure out how to contribute. I don't mean to create more
> mail for Ben et al, but having an explicit "seek help here" direction is
> nice. And (at least for me) mailing a list for help feels more comfortable
> than emailing an individual.
>
> Richard
>
> On Nov 8, 2019, at 6:30 PM, Ben Gamari <ben at smart-cactus.org> wrote:
>
> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
>
> | If the maintainers are not willing to either review or find reviewers
> | for a new contributors patch
> | then it doesn't seem to me that a project wants or values new
> | contributors.
>
> Yes, that would be an unfortunate -- and indeed wrong -- impression to
> convey. Thanks for highlighting it.
>
> You'd like the maintainers to have an *obligation* to cause someone to
> produce a good review on every patch. Here's the worst-case scenario: a
> well-meaning but inexperienced person produces a stream of large,
> ill-thought-out, and mostly wrong patches. To give a guarantee of high
> quality reviews of those patches amounts to a blank cheque on the time of
> volunteers working mostly in their spare time.
>
> Now, of course, that's an extreme scenario. But that's why I'm keen to
> avoid making it an unconditional obligation that the few maintainers must
> discharge.
>
> I don’t think there is really a difference of opinion here. Of course we
> welcome patches; of course everyone will try to help find reviewers if they
> are lacking!
>
> So how about this
> - the author nominates reviewers
> - if he or she finds difficulty in doing so, or the reviewers s/he
> nominates are unresponsive, then he or she should ask for help
> - maintainers should make efforts to help
>
> In my mind there has always been a (perhaps too implicit) promise that
> maintainers are always present in the background and happy to help in
> finding reviewers if asked (and perhaps even if not, if it seems a
> contributor is lost).
>
> Perhaps we should make this more explicit?
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191108/caceb1e7/attachment.html>
More information about the ghc-devs
mailing list