Matthew Pickering
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