Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers

[Theodore Ts'o <tytso@mit.edu>]

On Fri, May 30, 2014 at 09:33:18AM +0400, James Bottomley wrote:
> We need to design programs for new people that draw them in, not keep
> them on the periphery.  That's why I think bug fixing is a better
> activity: it means they have to understand some of the code; the change
> can be small and isolated, so they don't have to understand all the code
> and it often encourages people to find out more about whatever they're
> fixing, hence draws them in.

When I need to bring a Noogler (or intern) up to speed, and they are
new to kernel coding or new to the storage subsystem, the two
activities that seem to work the best is (a) bug fixing, and (b)
participating in a rebase to forward port patches to a newer upstream
kernel.

Obviously, the latter isn't applicable for upstream development (but
probably has at least some relevance for companies maintaining
community or enterprise distros).  Also note that one key enabling
technology to let relatively experienced developers do rebases is that
every single commit that they need to rebase is annotated with either
the name of the automated test or test suite, or manual testing
instructions.

We don't even *bother* having Nooglers or interns work on whitespace
or spelling fix ups, even as a "my first patch" so they can learn how
to use Gerrit and other internal tools.  They can learn all of that
while doing work that actually adds real value, such as working on a
backlogged bug report or by forward porting patches.

Cheers,

					- Ted

> We're way off the topic of encouraging reviewers, but the bottom line
> for me is I don't believe starting people out with cleanup type changes
> is a good way to get wider engagement.  It is a good way to increase the
> number of overall patches, all of which need to be reviewed, hence the
> need for more reviewers.