Alexander Borisov <lex.borisov@gmail.com> writes:
I have a question for the community. While waiting for feedback on my
own patches, I was wondering: is there value in me reviewing other
people's patches, even though I am not a committer here?
Yes, absolutely. Even if you don't catch every problem that a

person with committer-level experience might catch, every problem
you do catch is one less thing for the eventual committer to deal
with.

Another reason why we encourage people of all experience levels

to do code reviews is that that is amazingly useful for gaining
familiarity with the Postgres code base, which is important for
becoming a more senior-level contributor. Committers don't appear
out of nowhere; they gained the necessary knowledge by working on
patches, both their own and others'.

I’ve been around here for over a year, and sometimes it feels like the

project lacks a dedicated coordinator to direct contributor and reviewer
efforts. Because of this, I'm not always sure which patches deserve
attention first.
You presume a degree of top-down organization that doesn't exist

around here. People work on whatever catches their fancy (or,
perhaps, what their company wants them to work on ... but that is no
business of the community at large). That applies to reviews just as
much as to writing the patches in the first place. So review what you
find interesting or what you think you can say something useful about.

On Fri, Jan 30, 2026 at 01:07:20AM +0300, Alexander Borisov wrote:

I saw that reviews by third parties (not contributors and committers)
are included in the commit log header.

In general, I want to understand how useful this is for committers.
There are several level of reviews, of course, but I tend to find all

of them useful. Even a small set of contributions like checking if a
patch runs or catching typo or project-style mistakes is the set of
things that helps in reducing the overall workload when a patch is
picked up to be integrated into the tree.

This is a very situational and case-by-case handling, of course. It

makes more sense to question the design of a 3k patch than complain
about two typos in it. A trend that I think lacks a lot in terms of
patch authors and reviews is that it is usually possible to split a
patch in multiple simpler patches, where initial pieces are more
focused on refactoring or some beautification. I'd encourage authors
and reviewers in spending time in finding and in suggesting such
things, as it can reduce a lot the work overall. And it's easier to
pick up for a committer.

On Thu, Jan 29, 2026 at 3:07 PM Alexander Borisov <lex.borisov@gmail.com > <mailto:lex.borisov@gmail.com>> wrote:

I have a question for the community. While waiting for feedback on my

own patches, I was wondering: is there value in me reviewing other
people's patches, even though I am not a committer here?

Non-committers moving patches from "needs review" to "ready for > committer" is a critical activity here.  It is part of the soft contract

one enters into when authoring patches - to try and perform an amount of > review work equivalent to what you are asking from others.

As for which ones to review - everyone has their own natural > prioritization methodology (and capabilities) just by interacting with > the project and community.  I'd suggest you don't overthink things and > just do what feels right to you.