Hi! I'm a complete newbie to Guix, which has the dual effects that I'm much more excited about it than I otherwise might be, but the disadvantage that I know nothing and am more likely to cause problems than not at the moment. Nevertheless I thought I might be able to contribute something to the discussion.
Something that is not obvious to me when people refer to reviewing patches, is whether this is purely a matter of adding new packages to the main guix channel, or of reviewing changes to the system in general, or both. As a novice, I can imagine becoming comfortable as a package reviewer much more quickly than as a reviewer of core patches to the system. It's also not obvious to me whether you mean exactly "reviewing a backlog of existing patches" or additionally "increasing the amount of patches submitted and applied". I feel like both are probably good things but I can't tell what you're focussing on exactly. If lots of gems were imported from other repos like RubyGems and PyPi, which as I understand it is currently a partly-automatic partly-manual process, would that be considered a win? What about increasing version coverage among those packages that are covered? One point brought up here is about tooling. I wonder whether there is any scope for fully automatic review. In other words, for some classes of package we might be able to say that if it builds in CI, and maybe the built package has a command that's considered enough to say "it's working", then that's all the review that's needed. I guess I'm mostly thinking here of cases where the package is imported, partially or entirely automatically, from another repo (as with `guix import`). So one could argue that as long as it looks like "the rubygems import is working" then the guix package thus imported can be assumed to be working too. I guess when I say this I am still mostly thinking of importing entire histories of a package (lots of versions simultaneously) without multiplying out the work involved to a huge degree. One of the points brought up earlier is whether it would be better to have interactive "review parties" or comprehensive documentation about what constitutes a good review. Obviously these are not mutually exclusive. But for my part, I think documentation gives you more "bang for your buck", for a few reasons: 1. Documentation is online all the time, whereas interactive sessions are subject to people's work schedules, time zones, personal commitments, etc. 2. Documentation is more likely to be complete, and to become more likely to be complete over time, whereas in meetings (or when doing your first solo review following the meeting) it is easy to forget some steps or criteria to check. 3. Reading docs can be done by anyone, with no commitment to follow up. I think some people are just scared off socially by the idea of having to join a meeting in order to learn how to do reviews well. Obviously this is a personal thing and varies - some people find a welcoming atmosphere in a virtual meeting much better than a faceless documentation screen. For my part I think I would prefer to read until I know the basics, and then might prefer to do it alongside other people. A "patch party" would not convert me from non-contributor to contributor, but it might convert me from a seldom-contributor to an active one. Again, there is obviously variation here among people. In case it is not obvious, I have only recently joined guix-devel, but would be keen to help out if I can. If there are things I can read to get "up to speed" that would be really helpful! All the best, Dan
