From: Patrick Steinhardt <ps@pks.im>
To: Derrick Stolee <stolee@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] ReviewingGuidelines: encourage positive reviews more
Date: Thu, 25 Jul 2024 16:11:42 +0200 [thread overview]
Message-ID: <ZqJdHlwIhv7NwJzq@tanuki> (raw)
In-Reply-To: <3fc33179-cd65-454b-a68e-f1113926eefe@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]
On Thu, Jul 25, 2024 at 09:31:46AM -0400, Derrick Stolee wrote:
> On 7/25/24 2:51 AM, Patrick Steinhardt wrote:
> > On Wed, Jul 24, 2024 at 02:14:37PM -0700, Junio C Hamano wrote:
> > > I saw some contributors hesitate to give a positive review on
> > > patches by their coworkers. When written well, a positive review
> > > does not have to be a hollow "looks good" that rubber stamps an
> > > otherwise useless approval on a topic that is not interesting to
> > > anybody.
> >
> > Oh, yes, this addition is very welcome indeed! It's a painpoint of ours
> > at GitLab, and folks were indeed quite unsure about how to handle
> > positive reviews. I was trying to guide them into the direction of
> > "reverbalizing" and "thinking out aloud" parts of a patch series that
> > are tricky in order to demonstrate that they have indeed read through
> > the patches and understand them. Having all of this written down
> > explicitly should hopefully help them.
>
> I'll add the perspective of my experience here that this is a good
> pattern to follow. One thing that also helps is to avoid doing an
> "internal review" for experienced contributors.
Absolutely! We originally had an internal review first, but I also
changed that procedure earlier this year. Now we have an optional
internal review in case people aren't yet all that familiar with the
mailing list workflow, but more experienced contributors should send
their patches to the mailing list directly.
For one this has sped up our own processes. But second, it allows
reviewers to get more exposure to the mailing list as they are also
encouraged to always review on the mailing list directly.
> When Microsoft was first building up new contributors in this space,
> we were overcautious and performed an internal review before going
> to the mailing list. While this is good for a contributor's first
> series, it loses the benefits of doing review in the open.
Same.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-25 14:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 21:14 [PATCH] ReviewingGuidelines: encourage positive reviews more Junio C Hamano
2024-07-24 21:39 ` Eric Sunshine
2024-07-25 6:51 ` Patrick Steinhardt
2024-07-25 13:31 ` Derrick Stolee
2024-07-25 14:11 ` Patrick Steinhardt [this message]
2024-07-25 15:49 ` [PATCH v2] " Junio C Hamano
2024-07-26 12:22 ` Patrick Steinhardt
2024-07-26 20:20 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZqJdHlwIhv7NwJzq@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=stolee@gmail.com \
/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