From: Arun Isaac <arunisaac@systemreboot.net>
To: 71622@debbugs.gnu.org
Cc: "Ludovic Courtès" <ludo@gnu.org>, jgart <jgart@dismail.de>
Subject: bug#71622: mumi CLI client features for review checklists
Date: Mon, 17 Jun 2024 23:42:43 +0100 [thread overview]
Message-ID: <87r0cv6vj0.fsf@systemreboot.net> (raw)
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 written well?")
(tag . review-good-synopsis-description))
((name . tests-run)
(description . "Are the package tests being run (if available)?")
(tag . review-tests-run))
[…]))
[…])
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! :-)
next reply other threads:[~2024-06-17 22:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 22:42 Arun Isaac [this message]
2024-06-18 4:16 ` bug#71622: mumi CLI client features for review checklists Suhail Singh
2024-06-27 12:21 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://issues.guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r0cv6vj0.fsf@systemreboot.net \
--to=arunisaac@systemreboot.net \
--cc=71622@debbugs.gnu.org \
--cc=jgart@dismail.de \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).