Proposed changes to merge request workflow
ben at smart-cactus.org
Fri Nov 8 18:30:01 UTC 2019
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs