The value of "Reviewed-by:", give and ask for it.

The value of "Reviewed-by:", give and ask for it.

[Carlos O'Donell]

Community,

Please consider asking for and giving "Reviewed-by:"

I want to thank Adhemerval who has really taken the "Reviewed-by:" process
to heart and in 2021 has absolutely blown past me in number of recorded
reviews. I want to challenge the rest of you to provide "Reviewed-by:" as
part of the review process.

It is a practice that has three important benefits:

(1) It allows you to programmatically track your own reviews and
    set your own goals against those reviews. It may even allow
    you to show value to your employer, that even if you didn't
    get a commit, you contributed to the review of an important
    feature.

    Corollory: If you are the receipient of a review, please include
    the review in your commit. If you use `git-pw * apply` then
    the 'Reviewed-by:' is aggregated by patchwork for you automatically.

(2) It sets a clear boundary for when you are complete with the
    review of a work carried out by your peer. Setting boundaries is
    important. Your peers know you are done the review when you grant
    the "Reviewed-by:" line.

    Corollory: Ask for 'Reviewed-by:' from your reviewers. It makes the
    reviewer an engaged part of the process of review.

(3) It enables automation at the CI/CD level. We can use Reviewed-by:
    in an automated fashion to drive cleanup and review of patches
    through patchwork. Patches that have Reviewed-by: and have not
    been committed should get immediate review to determine what is
    lacking for commit.

Thank you. Any feedback on this is appreciated.

-- 
Cheers,
Carlos.

Re: The value of "Reviewed-by:", give and ask for it.

[Joseph Myers]

On Fri, 7 May 2021, Carlos O'Donell via Libc-alpha wrote:

> (1) It allows you to programmatically track your own reviews and
>     set your own goals against those reviews. It may even allow

> (2) It sets a clear boundary for when you are complete with the
>     review of a work carried out by your peer. Setting boundaries is

Fundamentally, these two points seem in tension with each other.  Setting 
the clear boundary means that Reviewed-by *only* tracks a review that says 
that a patch is OK exactly as-is; it doesn't track a review saying a patch 
is OK with changes, or earlier reviews resulting in a revision of a patch 
(but the earlier reviews may well be more involved than the later ones).

-- 
Joseph S. Myers
joseph@codesourcery.com