Ludovic Courtès <l...@gnu.org> writes: >> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès <ludovic.cour...@inria.fr>
> But I also view things from a different angle: everyone contributes in their > own way, and each contribution is a gift. Maybe selfishly, but I really agree with this. I think this is just the nature of community-based projects: people are going to scratch their own itch, and when time allows, do altruistic things for other people. Some people (e.g. me) don't have very much time at all to do the altruistic things (which gnaws at me). I do what I can, when I can, and hope that someone else benefits. > A good middle ground may be to provide incentives for review. How? I’m > not sure exactly, but first by making it clear that review is makes the > project move forward and is invaluable. > >>> I think it’s about finding the right balance to be reasonably efficient >>> while not compromising on quality. >> >> I totally agree. And I do not see nor understand where is the >> inefficiency here when asking to go via guix-patches and wait two weeks >> for adding a new package. Often I find that people on projects/teams have fundamentally different understandings of what reviews are for. Are they quality control? Mentoring opportunities? Opportunities to teach others how something new works? A way to encourage cohesiveness in the project? It can help to publicly state the intent somewhere. I think the word "review" is mentioned in the manual 11 times, but nowhere does it say what the review's purpose is. Large, public projects like Guix are a bit different, so I'm not sure this applies, but reviews meant to be gates on quality are my least favorite: (Please note: these are general observations about the industry and not necessarily specific to Guix) - The reviewers are human too, and there are various circumstances where they will miss things. Some of the most insidious forms of this is are: tragedy of the commons, i.e. > Submitter: They always do such a good job catching things. I think this is > good, but I know they'll catch any issues. > Reviewer: I feel bad this has sat for so long, this person usually does a > good job. +1 without a detailed review. > Submitter: A +1! It must not have had any issues. - Unavoidably, because of human nature, groups form, and certain people experience less friction getting patches in. See the last point. - There is a feedback loop present: those who have committed earlier have control and are more likely to reject later commits which don't do things as they would have. Sometimes "quality" is abused as a cover for opinion. Very few people are doing this maliciously, but it still happens. - As I mentioned in another thread[1], trying to chase the ideal of quality may actually be worse in the end, or be a local maxima for quality or utility. Focusing on velocity may help achieve the global maxima for both. As always, there is a balance. > It’s not about urgency but rather about not contributing to the growth > of our patch backlog, which is a real problem. I have often seen folks on various projects worried about the size of various backlogs: bugs, issues, etc. I think it is human to want to try and contain something that appears to be growing, unbounded. I think the thing that bothers us is a sense that the backlog is becoming unmanageable, or too large to triage. I submit that this is actually a tooling and organizational issue, and not an intrinsic issue to be solved. Bugs may still be valid; patches may still have valuable bones to modify. I think the real issue is that as a backlog grows, the tools we're used to using cannot answer the questions we want to ask: what is most relevant to me or the project right now? To me, this sounds like a search and display problem. [1] - https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00081.html -- Katherine
