Re: gnu-patches back log

[Pjotr Prins]

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.
--