Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > I would prefer a community standards document that looks more like this: > ... > > * Be welcoming to new community participants. Help them get oriented, > and be patient with their questions. Gently introduce them to our > community standards, above all by setting a good example yourself. I agree that on-boarding is an important process. In addition to the reviews I'd give to regulars, I personally try to do some of these things: - Even in a negative review, end the message with "Thanks". More important is to express that the particular patch is rejected but contributor's future contribution (either a reroll or a separate topic) is welcome. This is free, and there is no reason not to be nice. - Point out problems in a milder way than usual. Instead of saying "Why is this done like so?", risking to be misinterpreted that I am saying the patch did something wrong and the contributor was a horrible programmer, rephrase it to "Hmph, this may work in such and such cases, but I wonder how well it would in this case?", followed by "How about going this route instead, which would cover all these cases?" Doing so is more time consuming at reviewers' end; once you know the current design well enough, you can immediately smell a wrong approach a lot faster by just looking at code and design in a patch, without having to come up with a concrete example. - Instead of just pointing out minor nits and have the new contributor reroll, point them out, and then show how the patch should have looked like, often after "-- >8 --" and the "From:" line that keeps attribution. Again this is more work at reviewers' end. Coaching new contributors, like mentoring GSoC students, is often more time consuming than scratching the same itch yourself for any reviewer, but it is an investment, which hopefully yields dividend in the longer term. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html