From: Noah Misch <noah@leadboat.com>
To: pgsql-hackers@postgresql.org
Subject: Becoming a committer: form for tracking readiness
Date: Tue, 22 Sep 2026 10:54:49 -0700
Message-ID: <20260922175449.23.noahmisch@microsoft.com> (raw)
Existing committers regularly discuss who to add as a committer. PostgreSQL
is a big and busy place, and many projects are well known to no more than a
few committers. To inform those discussions, we're experimenting with a
fillable form to capture a person's most relevant work. This helps each
committer in those discussions understand a person's contributions beyond the
projects the committer monitored. Committers familiar with the work will
complete the form for other committers to read.
We're sharing the form here for a few reasons:
- If you aim to become a committer, we encourage you to fill out the form
yourself and self-reflect or discuss it with your mentor to plan your path
forward.
- Even if you're not yet ready for commit access, developing in the direction
of the criteria will help PostgreSQL scale.
- We aim to be transparent about how we compare a person's work to some of the
longstanding criteria (https://www.postgresql.org/developer/committers/).
If you have questions about the form, feel free to ask on this thread. This
is an experiment, and we'll revise things over time.
(on behalf of the committers)
# Committer Readiness Template
## Introduction
This is a template for documenting PostgreSQL contributions that show
$CONTRIBUTOR's readiness to be a PostgreSQL committer. The committers will
read it, so the decision process factors in the work most relevant to
committer readiness criteria
(https://www.postgresql.org/developer/committers/).
This is designed for nominating $CONTRIBUTOR to become a committer, but it may
be useful for $CONTRIBUTOR tracking their progress over time, alone or in
collaboration with a mentor.
Complete this template by replacing each square-bracketed placeholder.
## $CONTRIBUTOR identification
Email address(es) used in PostgreSQL community: [answer here]
## Code contributions requiring little revision
This examines committer criteria "high quality code contributions which
require very little revision or correction for commit" and "demonstrated
understanding of the process and criteria for patch acceptance". Describe
five nontrivial commits or commit ranges that best show those criteria.
Choose the commits to show breadth; typically, at least three code subject
areas appear.
Developing a committable patch may require judgment calls around goals like
harmony with existing features, maintainability, and debuggability. Depending
on the subject, acceptance criteria may require supporting evidence, like
alternatives considered, benchmark results, test results, or data on feature
usage among applications/extensions.
Patch versions can appear in two phases:
- WIP: $CONTRIBUTOR marks the patch version WIP. They may ask for feedback on
specific questions that don't require a committable patch version. If they
don't ask specific questions, the patch version is FYI, and if a CommitFest
entry exists, it's in status Waiting on Author. Don't list revisions made
in this phase.
- Normal: Any patch version not marked WIP represents that $CONTRIBUTOR would
commit it if they were a committer. List noteworthy revisions (what changed
between patch versions) made in this phase.
Committers do miss defects, so the goal isn't a 0% revision rate. Some
problems require more architectural complexity, so more revisions are not
automatically worse.
### [Project Name 1]: [commit hash or hash range]
#### What changed between $CONTRIBUTOR's first non-WIP version and the actual commit?
[answer here]
#### What would have been the user impact of pushing without making those revisions?
[answer here]
#### What made this contribution nontrivial to submit in a committable state?
[answer here]
#### If multiple authors were involved, what was $CONTRIBUTOR's specific role?
[answer here]
## Improving patches via review
This pertains to committer criterion "track record of reviewing and helping
other contributors with their patches". List up to five occasions where
$CONTRIBUTOR's pre-commit review or post-commit bug report improved a change.
Improvement could mean stopping a user-visible defect, like wrong behavior,
inconsistent user interface, or major inefficiency. Defects that persisted
through earlier review rounds can carry greater weight. Improvement could
mean broadening of the change scope, like generalizing a feature user
interface to more use cases or completing a bug fix that had missed 1 of the N
buggy code locations. Sometimes the right review outcome is to reject a patch
or revert a commit, so feel free to include such reviews.
### [Review finding 1]: postgr.es/m/[message-id]
#### What noteworthy revisions did this review cause?
[answer here]
#### What would have been the user impact of pushing without making those revisions?
[answer here]
#### If the revisions were not obviously mandatory, how did this review make the case for them?
[answer here]
## Helping with patches
While the evaluative aspect of patch review is essential, we make more
progress when author and reviewer partner to get the patch committable. List
up to five occasions where $CONTRIBUTOR's participation functioned that way
for the benefit of another author's patch. This can take forms like
suggesting resolutions to review findings (including one's own findings),
writing benchmarks, writing test cases, and writing patches for defects in
recent commits. It's okay to list reviews used earlier.
### [Help 1]: postgr.es/m/[message-id]
#### What part of $CONTRIBUTOR's participation went beyond evaluative review?
[answer here]
#### What would likely have happened without that help?
[answer here]
Attachments:
[text/plain] committer-readiness-template.md (4.4K, ../20260922175449.23.noahmisch@microsoft.com/2-committer-readiness-template.md)
download | inline:
# Committer Readiness Template
## Introduction
This is a template for documenting PostgreSQL contributions that show
$CONTRIBUTOR's readiness to be a PostgreSQL committer. The committers will
read it, so the decision process factors in the work most relevant to
committer readiness criteria
(https://www.postgresql.org/developer/committers/).
This is designed for nominating $CONTRIBUTOR to become a committer, but it may
be useful for $CONTRIBUTOR tracking their progress over time, alone or in
collaboration with a mentor.
Complete this template by replacing each square-bracketed placeholder.
## $CONTRIBUTOR identification
Email address(es) used in PostgreSQL community: [answer here]
## Code contributions requiring little revision
This examines committer criteria "high quality code contributions which
require very little revision or correction for commit" and "demonstrated
understanding of the process and criteria for patch acceptance". Describe
five nontrivial commits or commit ranges that best show those criteria.
Choose the commits to show breadth; typically, at least three code subject
areas appear.
Developing a committable patch may require judgment calls around goals like
harmony with existing features, maintainability, and debuggability. Depending
on the subject, acceptance criteria may require supporting evidence, like
alternatives considered, benchmark results, test results, or data on feature
usage among applications/extensions.
Patch versions can appear in two phases:
- WIP: $CONTRIBUTOR marks the patch version WIP. They may ask for feedback on
specific questions that don't require a committable patch version. If they
don't ask specific questions, the patch version is FYI, and if a CommitFest
entry exists, it's in status Waiting on Author. Don't list revisions made
in this phase.
- Normal: Any patch version not marked WIP represents that $CONTRIBUTOR would
commit it if they were a committer. List noteworthy revisions (what changed
between patch versions) made in this phase.
Committers do miss defects, so the goal isn't a 0% revision rate. Some
problems require more architectural complexity, so more revisions are not
automatically worse.
### [Project Name 1]: [commit hash or hash range]
#### What changed between $CONTRIBUTOR's first non-WIP version and the actual commit?
[answer here]
#### What would have been the user impact of pushing without making those revisions?
[answer here]
#### What made this contribution nontrivial to submit in a committable state?
[answer here]
#### If multiple authors were involved, what was $CONTRIBUTOR's specific role?
[answer here]
## Improving patches via review
This pertains to committer criterion "track record of reviewing and helping
other contributors with their patches". List up to five occasions where
$CONTRIBUTOR's pre-commit review or post-commit bug report improved a change.
Improvement could mean stopping a user-visible defect, like wrong behavior,
inconsistent user interface, or major inefficiency. Defects that persisted
through earlier review rounds can carry greater weight. Improvement could
mean broadening of the change scope, like generalizing a feature user
interface to more use cases or completing a bug fix that had missed 1 of the N
buggy code locations. Sometimes the right review outcome is to reject a patch
or revert a commit, so feel free to include such reviews.
### [Review finding 1]: postgr.es/m/[message-id]
#### What noteworthy revisions did this review cause?
[answer here]
#### What would have been the user impact of pushing without making those revisions?
[answer here]
#### If the revisions were not obviously mandatory, how did this review make the case for them?
[answer here]
## Helping with patches
While the evaluative aspect of patch review is essential, we make more
progress when author and reviewer partner to get the patch committable. List
up to five occasions where $CONTRIBUTOR's participation functioned that way
for the benefit of another author's patch. This can take forms like
suggesting resolutions to review findings (including one's own findings),
writing benchmarks, writing test cases, and writing patches for defects in
recent commits. It's okay to list reviews used earlier.
### [Help 1]: postgr.es/m/[message-id]
#### What part of $CONTRIBUTOR's participation went beyond evaluative review?
[answer here]
#### What would likely have happened without that help?
[answer here]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com
Subject: Re: Becoming a committer: form for tracking readiness
In-Reply-To: <20260922175449.23.noahmisch@microsoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox