I, for one, would be willing to review patches, hoping that in turn my patches would be reviewed instead of staying in limbo forever, which is a drag on me submitting more patches.
Is there a procedure to follow, or do I just start replying "LGTM" to patch email threads ? Cheers, Edouard. Steve George <st...@futurile.net> writes: > Hi, > > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? > > Patch flow is a pipeline, to change it we could: > > a. Increase the number of committers - more people to do the > work > b. Increase the efficiency of existing committers > c. Open the gates by decreasing the quality expected from patches > > We essentially decided to focus our discussion on (b). We looked at > things that 'hinder' and 'help' patch review: > > > Hinders > ======== > > - All our patch reviewers are volunteers doing it in their spare time. > > - For a volunteer reviewing someone else's work is not very rewarding, most > would prefer to use that precious time to scratch their own itch. > > - Can feel like an Sisyphean task: no matter how many patches someone reviews > there are more, exacerbated by the number of Guix packages. > > - Sense of responsibility: the minute that a reviewer looks at the patch they > are now stuck with it > > - Repetitive and boring: often patches have minor issues, but it's the same > sorts of issues time and time again. > > - Risk of negative social interaction: having to tell someone that their patch > is incorrect, or that their contribution cannot be used is difficult and > draining. Some people felt it was better to say nothing, rather than to > respond to a patch. > > > Helps > ====== > > This led us to the focus on the fact that **reviewing and applying > patches can be different people** > > We looked for ideas to create more reviewers, make reviewing easier and > more fun: > > > - Share in the work > -------------------- > > 1. encourage new reviewers to step forward - making it more known that > reviewing > patches helps to get them applied. Anyone can review patches. > > 2. create directed 'how-to' documentation for reviewing and connect it to QA > so > that 'new reviewers' know what to do > > 3. create documentation about 'when' and 'how' it's appropriate to send a 'v2' > version of a patch so that the QA system builds and accepts it. Sometimes, > patches rot because non-committers don't want to be seen as 'stealing' > someone's > work with a v2 patch - but making the small changes and resubmitting to QA is > what is required. > > 4. Pay someone else to do it. Noted but out of scope. > 5. Remove old packages overhead. Old untouched packages create mental > overhead, > and make the task of maintaining the repository in a good state more > difficult. > We could remove old 'untouched' packages and ones that no-longer compile. We > have methods to hide and notify. > > > - Make it more fun > ------------------- > > 1. do online sessions around reviews, some sprints or pairing - both social > and > a way to spread skills > 2. find ways to recognise and appreciate reviewers - 'reviewer of the month' > 3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader board > for reviews. Make it a group goal 'can we beat januarys reviews number' > 4. create some graphs / leaderboard so we know how many patches are being > reviewed and we can recognise the contribution > > > - Automate it away > ------------------- > > 1. Chris is continuing to try and automate away the boring work - general > agreement in the group that QA has made a lot of difference. > > 2. general discussion about create a 'guix review' command (Nix has one) which > would download a branch with the appropriate patch and build it locally. This > is > for instances where some adjustment is needed or to check a build. While this > can be done today, it's a number of steps and quite involved. > > > Agreed Actions > ============== > > * [Chris]: continuing his work to improve QA automation. Implication was we'll > need some reports / graphs - but these were not discussed in detail. > > * [Futurile]: organise a **patch review online sessions**. To run every 13 > days > (so it rotates through the week) - for 3 months to see if it has any > traction. > Co-ordinate with maintainers so that patches that are reviewed can be > committed > > > Actions looking for someone - you? > ==================================== > > * Carry forward the 'guix review' command idea > > * Write an RFC and discuss the idea of removing older 'bit-rot' packages > > * write 'how-to' documentation for reviews and when it's socially > acceptable to do a v2 patch. A checklist-like approach. > > > If you were in the discussion and I've misrepresented your point, or forgotten > an important aspect please please reply and correct me. > > Also, if you would like to help on any of the tasks please email back to the > group so we can all co-ordinate. > > Finally, thank-you to everyone who came along and put their shared brain power > to the task - look forward to doing some patch reviews together online in the > coming weeks! > > Thanks, > > Steve/Futurile
