Proposed changes to merge request workflow

Ben Gamari ben at
Fri Nov 8 18:30:01 UTC 2019

Simon Peyton Jones via ghc-devs <ghc-devs at> 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?


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list