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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs