From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 17 18:43:18 2024 Received: (at submit) by debbugs.gnu.org; 17 Jun 2024 22:43:18 +0000 Received: from localhost ([127.0.0.1]:38353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJL4I-0001gj-8t for submit@debbugs.gnu.org; Mon, 17 Jun 2024 18:43:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:47474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJL4G-0001gb-4O for submit@debbugs.gnu.org; Mon, 17 Jun 2024 18:43:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJL4D-0002qT-DX for bug-mumi@gnu.org; Mon, 17 Jun 2024 18:43:13 -0400 Received: from mugam.systemreboot.net ([139.59.75.54]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJL49-0001mM-Um; Mon, 17 Jun 2024 18:43:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=systemreboot.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qAXaRVa1XLZmKs1Dcu8dVKBEmaraBlN9vmqlXcDf2nQ=; b=GAkX9e8jVSD5T6EAjk7/0zsew1 /8lgzqGsyel08oIh/VuNLFtCngsDCgW6+tujtjw6sjqDbs3PxVqkavsxnVz9Cr548oQk2napFM/5E TQWgxBF4BO5eIDFxPsfCxp9wApI39uH3ZtJ933+kHdOznr4D++P+/0xZYBj3ZY2s86ObwBP6CHsc6 AkeCJ9q3ygZc/CEZw8tUEs5lQ1sOw39qUfTlzvQtJ8miNNQK0CV3+aSWE2AsRz86VSUQeJMLjapIA 0OlHG5+yOpJxvTYjnJjdK60o6BW/7Fzz28P04W+DN3Nn3ztPRAlzQO1WRgeMsMNck9nvV/jgOkrlO eHHAViDA==; Received: from [192.168.2.1] (port=53102 helo=localhost) by systemreboot.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.1) (envelope-from ) id 1sJL0X-0007C5-2d; Mon, 17 Jun 2024 23:39:26 +0100 From: Arun Isaac To: bug-mumi@gnu.org Subject: mumi CLI client features for review checklists Date: Mon, 17 Jun 2024 23:42:43 +0100 Message-ID: <87r0cv6vj0.fsf@systemreboot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=139.59.75.54; envelope-from=arunisaac@systemreboot.net; helo=mugam.systemreboot.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , jgart X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) The mumi CLI must provide features to help go through a review checklist. A system that allows even those without commit access to contribute meaningfully to the review process could be a big win. We can use this issue to brainstorm ideas. One idea could be as follows. # Idea 1 Projects provide a review checklist in their .mumi/config. For example, something like ((review-checklist . (((name . good-commit-message) (description . "Are the commit messages written well= ?") (tag . review-good-commit-message)) ((name . good-synopsis-description) (description . "Are the synopsis and description wri= tten well?") (tag . review-good-synopsis-description)) ((name . tests-run) (description . "Are the package tests being run (if = available)?") (tag . review-tests-run)) [=E2=80=A6])) [=E2=80=A6]) When a reviewer checks one of these items (say the good-commit-message), they run something like $ mumi review --tick good-commit-message and that sets the review-good-commit-message tag on the issue. We could also have a status command like $ mumi review --status that lists the complete checklist with a tick mark by items that have been checked. This system is really a convenience wrapper around tagging. So, it can be searched with something like $ mumi search tag:review-good-commit-message One might however argue that such searching is not very useful. One possible downside is that this ties each project (guix, mumi, etc.) to a single checklist. For example, what about guix patches that are not for packages? Perhaps it is an idea to allow multiple checklists per project. Another downside is that this does not provide for multiple reviewers to review and verify each other's findings. In other words, there is no way for two reviewers to register that they both verified something independently. # Idea 2 A second much simpler idea is to implement templates for `mumi compose'. Projects provide templates under .mumi/templates. For example, $ cat .mumi/templates/review [ ] Are the commit messages written well? [ ] Are the synopsis and description written well? [ ] Are the package tests being run (if available)? Then, when reviewers review something, they compose an email like so $ mumi compose --template review that composes an email with this template. The reviewer puts an 'x' by items they have checked. The downside of this method is that this is just unstructured text. There is no way for mumi to understand what parts of the review checklist have been completed and thus generate useful reports, filtering, etc. Thank you for listening to my brain dump! Suggestions welcome. Cheers! :-) From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 18 00:18:02 2024 Received: (at 71622) by debbugs.gnu.org; 18 Jun 2024 04:18:02 +0000 Received: from localhost ([127.0.0.1]:39072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJQID-0001q3-PD for submit@debbugs.gnu.org; Tue, 18 Jun 2024 00:18:02 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:41186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJQIC-0001pm-DV for 71622@debbugs.gnu.org; Tue, 18 Jun 2024 00:18:01 -0400 Received: by mail-qt1-f195.google.com with SMTP id d75a77b69052e-440621418aaso4472421cf.0 for <71622@debbugs.gnu.org>; Mon, 17 Jun 2024 21:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718684212; x=1719289012; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Xm5Ad6f5/svGnydkxXaNt/MgXbtuvKP5GWctdU+wWS8=; b=jplIdaOj0Ujw4ZOiaUY2nTtE9Bk/IOxOTa0prz8up6qUch9727xQAPJ84RrrFMgqao Wd5zN+0zHoVeVqs+rLMCrQ+MA2qqISsQTFWm2Il8eExv9ArsoL134F71jX4mXSW9mGUK DFtOx0CSJ+WQKtrh+KM9BglsIZyy7Cuk/5Nvuw1/NXx4OuaEgd25HwwFvE3HqzOkgaVT 5V+CzyBwFNpYcyASZGCdKJDAlobdjaYA4RiDg49cmkFRKTu/yRYqpVCg5pRUZ3IGfdkA i4q4gJVT8AjvT4nAEcZ8X3lZhcQq+OZXrzdJtRNo83yW+l4gwG45r01B6kDqnYRzP/Ti YgJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718684212; x=1719289012; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Xm5Ad6f5/svGnydkxXaNt/MgXbtuvKP5GWctdU+wWS8=; b=WBD4RyCnIW9xQzgo0vg3r8jXp4qMfrvzLroDIhoYKJ2zwCGdrgTAs4D7xZh0DJ1RWM yJ57FrdIHgmjrKQyoMJp1us0brHVvDv2zA5xsHFB1+SJRi14HVc58FPYoo0azd0vtwe0 GwL80E+1QpKTyqQG+JgHf56OGqwCJFeJgZSkERXjEw1c7D1Vn5dvXGaO58eZ9SnIAuDf Kxkl+yNyOJlOCTUJkw+q1KJ1bqtXB7Agg+iyJNVWYzWURaXR8mHKW7FPA8yq0+0jui8N mU1TFBTs5b2ae1y+ZI+wt67corMOPdHF+5Nn+rjmCQSmshqGQM4WwbpV6dySGBIz6Svh OD6g== X-Gm-Message-State: AOJu0Yx9GC0ySAYhqz0eeCj/bqNKu2A6kCBnZA4MHCOPxUDiziaA4STV IGz9glCl5yzBWTLB+XVNvqPqY8xoVB3zsLcz/x+JOLpvFXviNRDE X-Google-Smtp-Source: AGHT+IGV+qNwdPMSDH4g4y7cg33qE8sKeK2i52nC4cnQgBXXCUl18/eHbZj80CeuqN8+W0QXNX/ggA== X-Received: by 2002:a05:622a:1999:b0:440:586f:498f with SMTP id d75a77b69052e-44216bbe282mr124850801cf.6.1718684212201; Mon, 17 Jun 2024 21:16:52 -0700 (PDT) Received: from gnus (static-198-54-132-177.cust.tzulo.com. [198.54.132.177]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-441f2ffb4bbsm53058491cf.87.2024.06.17.21.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 21:16:51 -0700 (PDT) From: "Suhail Singh" To: Arun Isaac Subject: Re: bug#71622: mumi CLI client features for review checklists In-Reply-To: <87r0cv6vj0.fsf@systemreboot.net> (Arun Isaac's message of "Mon, 17 Jun 2024 23:42:43 +0100") References: <87r0cv6vj0.fsf@systemreboot.net> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 18 Jun 2024 00:16:51 -0400 Message-ID: <87o77y3mx8.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 71622 Cc: 71622@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= , jgart X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Arun Isaac writes: > # Idea 1 > > Projects provide a review checklist in their .mumi/config. I think idea #1 can add considerable value. I'll note some opinionated observations below. > For example, something like > > ((review-checklist . (((name . good-commit-message) > (description . "Are the commit messages written we= ll?") > (tag . review-good-commit-message)) > ((name . good-synopsis-description) > (description . "Are the synopsis and description w= ritten well?") > (tag . review-good-synopsis-description)) > ((name . tests-run) > (description . "Are the package tests being run (i= f available)?") > (tag . review-tests-run)) > [=E2=80=A6])) > [=E2=80=A6]) I think the fact that the names are distinct from the actions (the tag that is to be added) is quite important. I.e., the "review-checklist" should provide a convenience around "well-defined state transitions" where the state is being recorded by usertags, but could also be extended to include issue status (open, close, owner etc). For instance as noted in : - When setting yourself as the reviewer, ensure that no-one else has set themselves as the owner. - Assuming above is true, when adding under-review tag, also add yourself as the owner. On a related note, perhaps "review-workflow" might be a better name than "review-checklist"? > When a reviewer checks one of these items (say the good-commit-message), > they run something like > $ mumi review --tick good-commit-message > and that sets the review-good-commit-message tag on the issue. It may be important that when a tag is set, that others are unset. It would help if this were possible to express via the review-checklist. For instance as noted in : There are three possible transitions after a review is completed: - Addition of reviewed-looks-good, removal of under-review . - Addition of escalated-review-request, removal of under-review . - Addition of waiting-on-contributor, removal of under-review . The user-interface (as well as the configuration) should focus on those transitions. Some transitions may indeed be simple and may only result in the addition of a single tag, whereas others may be more complex. Additionally, given the current state, only some transitions may be "sensible" and permissible, i.e., it would help to be able to express conditional/guarded transitions. > One possible downside is that this ties each project (guix, mumi, > etc.) to a single checklist. I think that that's actually a benefit. It can aid review of the transition rules for them to be in one place. > For example, what about guix patches that are not for packages? > Perhaps it is an idea to allow multiple checklists per project. One way to address this would be to have the ability to have multiple conditional "checklists" (or workflows) that are mutually exclusive and exhaustive. I.e., support for nested "checklists" in addition to guarding would be sufficient, but may not be necessary. > Another downside is that this does not provide for multiple reviewers to > review and verify each other's findings. In other words, there is no way > for two reviewers to register that they both verified something > independently. Could that be addressed by ensuring that the control messages are also cc'd to the specific issue? --=20 Suhail From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 27 08:24:21 2024 Received: (at 71622) by debbugs.gnu.org; 27 Jun 2024 12:24:21 +0000 Received: from localhost ([127.0.0.1]:41182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMoAm-0007dJ-Rn for submit@debbugs.gnu.org; Thu, 27 Jun 2024 08:24:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMoAl-0007d1-17 for 71622@debbugs.gnu.org; Thu, 27 Jun 2024 08:24:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sMo8V-0000Qb-1A; Thu, 27 Jun 2024 08:21:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=qkHW+mI5NJnDLDmIlGsf8PfuPt+uemakyhIpHc5/3JY=; b=b6S9QOb/R3r3P2EDdHFt qkHCJM9+XOwyuPqDrUzlG/DmuLeG/A4XoREzXcZA2w7KQ6mYYLxLj9yAOzGh2k5UxsiDLt+TaTFn8 6Wd+5LUfgHX6KwITXsE+48fEWfZmCQgLx/acNT6FFUNNTsO7+4dQ19hhli86IARfYAKV0jHQeRCw0 5I1vdNpunrrAM2NcRdF5WTkEMS1xVu+lp7vBp/5jR3m/8Og4aEpaDAnq0r9iC2jR/iYMtRqXGPFnZ 2pouDzGyBEEMU9/rOWIr8LIEXGPtbYUQOmIG2eeRAGf8hb6jcsvJQ5JKyUbVPVwd5zFq+gWHaaHkv K6aokm57clJChg==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Arun Isaac Subject: Re: bug#71622: mumi CLI client features for review checklists In-Reply-To: <87r0cv6vj0.fsf@systemreboot.net> (Arun Isaac's message of "Mon, 17 Jun 2024 23:42:43 +0100") References: <87r0cv6vj0.fsf@systemreboot.net> Date: Thu, 27 Jun 2024 14:21:55 +0200 Message-ID: <87v81u7ezg.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71622 Cc: 71622@debbugs.gnu.org, jgart X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Arun, Arun Isaac skribis: > # Idea 1 > > Projects provide a review checklist in their .mumi/config. For example, > something like > > ((review-checklist . (((name . good-commit-message) > (description . "Are the commit messages written we= ll?") > (tag . review-good-commit-message)) > ((name . good-synopsis-description) > (description . "Are the synopsis and description w= ritten well?") > (tag . review-good-synopsis-description)) > ((name . tests-run) > (description . "Are the package tests being run (i= f available)?") > (tag . review-tests-run)) > [=E2=80=A6])) > [=E2=80=A6]) [...] > # Idea 2 > > A second much simpler idea is to implement templates for `mumi > compose'. Projects provide templates under .mumi/templates. For example, > $ cat .mumi/templates/review > [ ] Are the commit messages written well? > [ ] Are the synopsis and description written well? > [ ] Are the package tests being run (if available)? I prefer #2: it=E2=80=99s familiar to anyone used to Git{Hub,Lab}, it=E2=80= =99s simpler, good enough, and doesn=E2=80=99t go too far to provide a technical solution= to a social problem. Alongside, a =E2=80=98mumi approve=E2=80=99 command that would set the =E2=80=98reviewed-looks-good=E2=80=99 tag would be a great step forward. Thank you! Ludo=E2=80=99.