From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Developers, developers, developers Date: Sat, 15 Nov 2014 12:55:55 +0900 Message-ID: <87d28pw20k.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416023793 30949 80.91.229.3 (15 Nov 2014 03:56:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 03:56:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 04:56:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XpUTJ-0001NO-Nw for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 04:56:25 +0100 Original-Received: from localhost ([::1]:38597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpUTJ-00044x-BN for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2014 22:56:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpUT9-00043y-64 for emacs-devel@gnu.org; Fri, 14 Nov 2014 22:56:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpUSy-0000pH-9t for emacs-devel@gnu.org; Fri, 14 Nov 2014 22:56:14 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:53375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpUSx-0000o0-Vk for emacs-devel@gnu.org; Fri, 14 Nov 2014 22:56:04 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E248E1C3ABD; Sat, 15 Nov 2014 12:55:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BA8E51A2844; Sat, 15 Nov 2014 12:55:55 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177135 Archived-At: Tom writes: > Is there an uptodate list of small tasks which someone can > starts working on? Uh-oh. Wishful thinking alert, here! This takes an amount of maintenance effort comparable to simply fixing bugs yourself for many such tasks. It also seems to require a culture of mentorship to go with it, which Emacs doesn't yet have (at least it's not visible on emacs-devel). For the mentorship aspect, read on. > Keeping such a list increases the administration a bit, but > it would also be beneficial for offloading these tasks to > casual contributors. I know of two projects (Python and Bazaar) that have effectively done this kind of thing, and "a bit" is a huge underestimate of the time that experienced developers need to provide. Emacs might be somewhat less, because Python has a fair amount of formal process and Bazaar's process was extreme and a lot of the mentoring effort was helping the newcomer get with the program. Still, the pure developer mentoring aspect is quite expensive. I think both projects got ample return for the effort, but it was also quite clear that there are two types of experienced developers: those who enjoy personal benefits from being mentors, and those who don't. > E.g. someone says: "I have an hour of free time, I'll fix > something in emacs." People just don't do that very often. Itches and scratching, ya know. That kind of behavior is *much* more popular among core developers than casual contributors. > and he goes to this list, picks a task, does it, sends the patch > and it can be crossed out. But "pick" is a problem, and it makes time estimation difficult. I've often asked for people to deal with NEWS, and get no takers. (It is possible to require committers to write NEWS, as Emacs does.) Tasks like that are easy to estimate: just estimate how much time it would take you to do it. People mostly want to work on bugs or features and develop their design and coding skills. A few will work on tests (more code!). All of these may require far more time (and help) for the newcomer than for an experienced developer. And any code requires review, especially from new contributors. (Note that all review has a mentoring component, of course, but review != mentoring by a long shot.) Usually some core contributor effort (in the form of applying a patch to a workspace, committing, and pushing to the trunk) will be required as well, until the "casual" contributor becomes a regular. > So the regular developers would regularly add these small > tasks to the list which could be done by the casual > contributors, so it would free up core developers to work > on other, more demanding tasks. In Python and Bazaar, it did *not* free up core developers. What actually happened with Bazaar was a few regular contributors were recruited (but they bailed out too when Canonical started withdrawing manpower). With Python (and more recent experience) what is happening is that GSoC wannabes are flocking to the mentorship program. That biases things in favor of code too (Google doesn't permit documentation or even pure testing tasks in GSoC). Net, it has balanced out for both. The main benefit was a few new regular contributors who might not have become regulars without mentoring, as well as a general "newcomers welcome" atmosphere that I believe attracted new developers with little-to-no need for mentoring. > It seems to me the little more administration which > consists of adding these tasks to this list would > be worth it. I think we've found your "little task"! ;-) Seriously, it's worth doing, but curating such a list is a specific task, it's not a good one for distributed effort "a little by each core contributor."