# 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]