From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: gnu-patches back log Date: Wed, 1 Mar 2017 15:06:51 +0000 Message-ID: <20170301150651.GC12261@mail.thebird.nl> References: <20170301081739.GA10117@mail.thebird.nl> <20170301111715.GA11182@mail.thebird.nl> <20170301.134855.1978548551800956096.post@thomasdanckaert.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj5td-0003Sk-Hx for guix-devel@gnu.org; Wed, 01 Mar 2017 10:10:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cj5tZ-00063G-Hy for guix-devel@gnu.org; Wed, 01 Mar 2017 10:10:29 -0500 Received: from mail.thebird.nl ([95.154.246.10]:44402) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cj5tZ-000632-8u for guix-devel@gnu.org; Wed, 01 Mar 2017 10:10:25 -0500 Content-Disposition: inline In-Reply-To: <20170301.134855.1978548551800956096.post@thomasdanckaert.be> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Thomas Danckaert Cc: guix-devel@gnu.org On Wed, Mar 01, 2017 at 01:48:55PM +0100, Thomas Danckaert wrote: > > This is the first thing I am trying :). The main difference with the > > existing approach is that I want to have more engagement from fresh > > contributors who can also peer review. Review is an excellent way of > > learning. How exactly we are going to do this is not clear yet. But > > that is what I am thinking. > > Speaking for myself as a new/beginning contributor: there is a finite amount > of time I can (want to) spend on Guix, and a large number of things I want > to fix/improve/experiment for myself. I now try to review some patches > occasionally, but of course that takes away from the time I have to work on > the issues I care most about myself. (And for other contributors: time that > cannot be spent on the many other important things that need to be done.) > > I understand that in the long term, time spent supporting new contributors > (i.e. helping the community grow) will probably benefit Guix (and therefore > also me) more than trying to do everything myself, but it takes some effort > to adopt this mindset. > > > Meanwhile I want to know what limits people actually have. I think 2 > > weeks is not acceptable (but that should be obvious). > > Of course this is personal, but for me it is acceptable. I assume that, when > a patch is good, it will eventually make it in, and accept that, sometimes, > I have to be patient (of course faster is always better). I see a lot of > dedication and effort from everybody here, and accept that a patch I submit > might not be on the top of anyone's priority list. > > So, I hear your call to slightly reconsider priorities for my Guix-time, and > try to spend more time mentoring (and will try to do that, as far as I can > :) ), but also think contributors should assume everybody here is doing > their best, and have some patience. Thanks Thomas. Exactly what I am asking. One thing to consider is that review also allows one to learn about how to do things. To write scientific papers I learnt the most from reviewing others people's papers. The mind shift I am asking for is that we stop seeing review as something that can only be handled by experts. Some write that the review process is hard - but from what I saw on the ML it the comments can be split into a number of recurring sub-types. Like: - wrong indentation (lint should see that) - naming conventions - solution conventions (i.e., standard ways of doing things) - problems around licensing and included code - missing tests - incompleteness - splitting of packages - versions (git checkout or old release) etc. I think it is possible to create a check list with examples that newcomers can use (and even old hands). During review you can simply point to the relevant section. Maybe we can start a review checklist on the wiki and every time someone does review, instead of writing it in a message, update the wiki and point to that section. That way review could end up being a bunch of URL's. Also the person writing a package can point to URL's instead of explaining everything. Again, this may appear like extra work, but in the end it could save us time. How about that? Pj. --