Proposed changes to merge request workflow

[Ben Gamari]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191108/de700e22/attachment.sig>