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]
