Matthew Pickering <matthewtpicker...@gmail.com> 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.
>
For what it's worth, I am happy to try to find reviewers for a
newcomer's patch. However, on the whole it is better for everyone
involved if the contributor does it:

 * the contributor is more involved in the process and, consequently,
   more invested

 * the process moves more quickly since the contributor doesn't need to
   wait for someone else to find reviewers for their work

 * me and the rest of us at Well-Typed are less of a bottleneck and
   therefore have more time for improving GHC
 
Of course, even with this policy, if I see a patch languishing then I
will try to handle it. In my view all we are doing here is setting the
preferred default; .

> A maintainer can make a value judgement about a patch that is isn't
> worth reviewing, but such
> situations are exceedingly rare. Everyone contributes patches in good
> faith in order to make the compiler better.
>
> Realistically it's impossible to be a good reviewer without having
> implemented patches on the code base. If you don't
> have a good handle for how things work then it's too big to get a feel
> for just by reading the code. You need to learn how things
> fit together by getting stuck writing patches.
>
> At least some of the maintainers are paid to maintain GHC and as such,
> should be expected to perform responsibilities that
> volunteers are not willing to perform. One of these tasks should be
> finding reviewers for all patches and making sure contributions
> do not languish indefinitely.
>
> Apart from this one point the suggested process sounds good but it
> seems to have stalled in the last month.
>
Indeed I've been stuck in an endless cycle of pre-release tasks.
Hopefully this will end today.

Cheers,

- Ben

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to