No, I'm not sure. Now those changesets are buried somewhere. The
hypothesis
is that channeling some attention to them cannot make
things worse.
Perhaps
the nitpicking helps to bring back the attention of
the maintainers?
Ways it could make things worse:
*incorrect advice given (if the newbies knew what to look for in a patch,
by definition i wouldnt call them a newbie). This is a real risk if we
start directing inexperianced people to do code review. Patch contributors
are often new people too, leading them astray has a big cost
*giving people false hope that their patch will get metged and in the end
making them more fet up with the entire process.
If a newbie tests a patch and then says something like - this fixes the
problem for me, that is mildly helpful. I worry if we start encouraging
newbies to do CR from the how to become a mw hacker page, we will end up
with silly comments like "-1: missing trailing ?>".
Maybe we can dig deeper in the metrics, and find changesets with last
versions of patches waiting for a first review, a different case from,
say,
open changesets with many versions, many comments and
some +1 (a place
where a newcomer would not add much).
Most patches are like the former. Its relatively rare to have a patch with
many versions and a couple +1's unless its actively in the process of being
reviewed or pending some external event.
Many tasks that are considered
uninteresting/unexciting/unfulfilling by
experienced contributors are interesting/exciting/fulfilling for new
contributors. Again, the EASY bugs are a good example. Ideas to define
good
tasks for newcomers in our review queues are welcome.
Sure, but its kind of an oxymoron to say, hey people who are new and
unfamilar with our social and technical conventions, please asses wether
this patch meets those social and technical conventions.
--
Bawolff