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