From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 484D3B13 for ; Fri, 30 May 2014 16:40:10 +0000 (UTC) Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C31822033C for ; Fri, 30 May 2014 16:40:09 +0000 (UTC) Date: Fri, 30 May 2014 12:40:05 -0400 From: Theodore Ts'o To: James Bottomley Message-ID: <20140530164005.GX25041@thunk.org> References: <1401294020.13546.95.camel@dhcp-9-2-203-236.watson.ibm.com> <20140528162833.GA23815@thin> <20140528233145.GA14933@cloud> <1401344001.27691.4.camel@dabdike> <20140529233459.GD11741@kroah.com> <1401423973.2163.26.camel@dabdike> <20140530050220.GA2505@kroah.com> <1401427998.2163.37.camel@dabdike> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401427998.2163.37.camel@dabdike> Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.