[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnu-patches back log

From: Pjotr Prins
Subject: Re: gnu-patches back log
Date: Wed, 1 Mar 2017 15:06:51 +0000
User-agent: Mutt/1.6.2 (2016-07-01)

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]