PostgreSQL formalizes its community complaint process

A community rule needs someone to receive a complaint and a process for deciding what happens next. PostgreSQL's new Code of Conduct makes those responsibilities explicit. Its importance lies partly in the expected behavior it describes, but also in the arrangements that let a participant report a problem without inventing a procedure during the dispute.

The September 18 announcement says that the Core Team has finalized the policy after a long consultation. It names a five-person committee chaired by Stacey Haysler, with Laetitia Avrot, Vik Fearing, Jonathan Katz and Ilya Kosmodemiansky. The committee is responsible for complaints. The announcement credits Haysler's work in developing the policy and forming the committee.

I default to PostgreSQL for relational systems, so its community is relevant to how I assess the technology. A database's source code does not explain every dependency involved in using it. People need to ask questions, report defects and discuss proposed behavior. A defined participation policy gives those interactions an explicit framework without deciding the technical questions in advance.

Scope follows community participation

The policy published with the announcement covers community interaction even when it takes place outside postgresql.org infrastructure, unless another applicable code takes precedence. That matters because the project is a community of participants as well as a collection of hosted services. Restricting policy to a hostname would leave its scope dependent on where a discussion happened.

At the same time, the document recognizes event-specific policies. It encourages conference organizers to maintain their own codes and makes them responsible for handling inappropriate conduct at their events. This is a practical division of responsibility. The person organizing a particular space needs an applicable procedure, while the project maintains expectations for its broader community.

The conduct provisions encourage constructive discussion of software and community work. They prohibit personal attacks and other specified behavior, including threats and unwelcome sexual attention. That distinction leaves room for a strong technical disagreement. A proposal can be criticized in detail without making the contributor's personal characteristics part of the argument.

For a technical project, preserving that distinction matters to the quality of a review. The useful evidence concerns what the code does and which assumptions it makes. A personal attack supplies no additional evidence about either. A rule against it does not require agreement about the patch under discussion.

Investigation has a separate responsibility

The Core Team appoints the committee and its chair. Core Team members do not serve on the committee, because the Core Team oversees it. The initial policy requires at least four committee members and limits service to three years, with a minimum requested commitment of one year. These provisions define an institution with continuing responsibilities beyond the first set of volunteers.

That separation is useful because receiving and investigating complaints is different work from the Core Team's oversight. A complainant has a designated destination. The project also has a specified authority for appointing and overseeing the people who receive the report. Neither responsibility has to be inferred from someone's technical prominence.

Reports go to the committee, with another committee member available individually when a complaint concerns one of its members. The document asks for incident details and relevant evidence, including timing and witnesses. These requests help distinguish an investigation from an unstructured exchange of impressions. They give the committee material with which to establish what happened.

The committee aims to finish an investigation within two weeks when the parties cooperate. If it needs longer, it is to provide a status report and estimated completion date. The policy therefore treats the time target as an aim, not a guarantee that every case can be decided on schedule. That is a useful distinction for a process whose evidence may take time to obtain.

Confidentiality and review have stated limits

The policy promises confidentiality to the extent possible while allowing an adequate investigation. It also excludes an involved committee or Core Team member from proceedings in that role. Both provisions acknowledge constraints on the process. An investigation may need to disclose enough information to establish facts, while a person directly involved should not decide the matter through their official position.

Possible results include a determination that no violation occurred, private or public reprimands, apologies, and temporary or permanent exclusion from community spaces. The list includes loss of commit privileges. A participation policy can therefore affect technical access as well as discussion access, which makes the decision procedure consequential for the project itself.

Temporary or permanent bans receive Core Team review before the parties are informed. If the Core Team disagrees, it must give its reasoning to the committee for further consideration. When agreement cannot be reached, the Core Team's decision prevails. That establishes where final authority lies instead of leaving a serious sanction dependent on an undefined escalation path.

I consider the explicit statement of that authority useful. A policy should let participants understand who investigates and who can ultimately determine a contested outcome. Those roles can be assessed more clearly when the document names them than when authority emerges informally after a complaint is filed.

Reporting does not end with a decision

The initial policy allows either party to appeal within one week and asks for new information that could support reconsideration. It retains incident records for three calendar years after the final item in the file. It also calls for an anonymized annual report summarizing complaint types and actions. These are distinct ways of handling information after the immediate investigation.

An appeal gives a route for additional evidence. Record retention supports continuity while placing a stated duration on sensitive files. An anonymized report gives the wider community information about the process without making every complaint public. Each arrangement serves a different audience with a different need for detail.

The policy also prohibits retaliation against someone who reports a complaint or assists an investigation. Without that provision, a reporting procedure could exist formally while participants still faced penalties for using it. The September publication therefore defines both the initial route for a complaint and expectations for what happens around that route as the committee investigates and communicates its decision.