参加大会 CFP（Call for Papers）评审之后，最容易留下的印象不是某个单独的演讲，而是整个选择过程有多像一次复杂的查询：输入是407份提案和228位演讲者，输出却必须满足主题覆盖、内容质量、公司代表性、性别平衡以及时间安排等多个约束。
这是一份基于公开信息和汇总统计的个人复盘。它不讨论具体提案、评分、委员会意见或私人交流，而是关注评审者如何建立判断，以及最终节目单为什么不可能是一个“完美解”。
从抽象评分转向相对比较
PGConf.EU 2026 的 CFP 收到407份提案，来自228位不同的演讲者。评审者阅读了全部提案，但实际投票只覆盖分配到的两个主题轨道，其中包括 Application Developer Community。
一个有效的评审流程通常从摘要开始，然后查看提案中提供的代码、幻灯片、录音或相关文章。如果没有辅助材料，还需要搜索往届 PostgreSQL 大会、PGDays 和社区聚会，确认主题是否已经以相同或相近的形式讲过。评审的核心问题不是“这个提案听起来是否有趣”，而是：
- 听众能学到哪些文档中不容易直接获得的内容？
- 提案是否提供了实际技术、设计权衡、工具或生产经验？
- 内容是否适合目标轨道和演讲时长？
- 它是否能让 PostgreSQL 社区更容易接近，并降低新贡献者参与的门槛？
作者在早期使用了开源终端工具 Confelo。它采用类似 Elo 的成对或多项比较，让评审者回答“这几个提案中，我更愿意听哪一个”，而不是给每份提案单独打绝对分数。
这种方式有一个实用优势：相对判断往往比绝对评分稳定。评审者很难解释一个提案究竟是“7分”，还是“一个非常自信的6分”；但比较两个提案时，差异通常更清楚。Confelo 还支持 CSV 导入导出、保存会话和本地处理数据，有助于分阶段完成评审，并暴露评审者自身判断中的不一致。
407份提案背后的结构
公开汇总数据显示，AI 是最大的单一主题桶，约占完整 CFP 的12%，但远未达到多数。也就是说，剩余357份提案仍然在讨论 PostgreSQL，只是没有让 AI 成为主题中心。
按申报轨道家族统计，DBA 相关提案约占44%，Application Developer 和 PostgreSQL Internals 几乎持平，分别有89份和87份，Community 则有52份。这样的分布也说明，热门技术不会自动覆盖整个大会的内容需求。
分析还发现，407份提案中没有使用“Postgre”这一非正式拼写。这个细节虽然带有玩笑性质，却说明 CFP 文本可以反映社区自己的语言习惯。类似的语言模式适合在选择结束后做统计，但不应该提前影响对单份提案的质量判断。
下面是一个可以直接改造的最小分析脚本。假设你有一个 submissions.csv，包含 topic、track_family 和 company 三列；字段名和分类规则需要根据真实数据调整。
#!/usr/bin/env python3
import csv
from collections import Counter
from pathlib import Path
path = Path("submissions.csv")
with path.open(newline="", encoding="utf-8") as file:
rows = list(csv.DictReader(file))
print(f"total submissions: {len(rows)}")
for field in ("topic", "track_family"):
counts = Counter(row[field].strip() for row in rows if row.get(field, "").strip())
print(f"\n{field}")
for value, count in counts.most_common():
percentage = count / len(rows) * 100 if rows else 0
print(f"{value}: {count} ({percentage:.1f}%)")
company_counts = Counter(row["company"].strip() for row in rows if row.get("company", "").strip())
print("\ncompanies with more than two submissions")
for company, count in company_counts.most_common():
if count > 2:
print(f"{company}: {count}")
运行方式很简单：
python3 analyze_cfp.py
统计脚本只能帮助发现分布和集中度，不能替代评审。一个公司提交很多提案，可能是因为它雇用了大量 PostgreSQL 提交者和核心开发者；如果仅按公司数量机械限额，就可能错过高质量技术内容。
多样性不是一个排序字段
委员会还需要处理公司代表性问题。PostgreSQL 生态中，一些公司长期雇佣 committers 和 hackers，也持续向项目贡献代码，因此自然会提交更多演讲。降低单一公司的集中度，同时不排除强技术提案，需要在质量和代表性之间反复权衡。
更长期的解决方案不是阻止这些公司继续贡献，而是让更多公司招聘、培养和支持 PostgreSQL hackers 与贡献者。当 PostgreSQL 专业知识分布在更多雇主和团队中，CFP 池自然会获得更多演讲者、工作经验和技术视角。
性别平衡面临类似但更直接的限制：委员会只能从收到的提案池中选择。如果女性开发者、DBA、PostgreSQL hacker、贡献者或社区组织者提交得更少，委员会能够调整的空间就会非常有限。因此，改善节目单的起点往往不在评审阶段，而在下一轮 CFP 开放之前，主动鼓励更多人提交提案。
评审也是一次资源调度
评审工作不一定需要实验数据库、多块显示器或稳定网络。摘要、相关材料和往届演讲记录通常可以在离线条件下处理。作者在布拉格、维也纳和布拉迪斯拉发之间乘火车参加社区活动时，利用连续的旅途时间完成了大量评审。
这件事有一个值得借鉴的工程化思路：把任务拆成适合不同工作环境的阶段。
- 在网络稳定时，搜索演讲历史、代码和录音。
- 在移动途中，阅读摘要并做相对比较。
- 在集中时间段，复核边界案例和轨道平衡。
- 在最终选择前，单独检查时长、重复内容和公司集中度。
延误甚至可能变成额外的评审时间。多出25分钟，可能就足以读完几份摘要。这个细节很有趣，但真正重要的是：长流程工作需要被切成可暂停、可恢复的小批次，并且保存中间状态。
节目单不是数学最优解
最终的选择把407份提案、228位演讲者和103个组织压缩成三天的会议节目单。可用的25分钟时段相对较少，而一些最有趣的提案恰好选择了这个时长。即使评审者个人喜欢某个主题，也可能因为时段数量、内容重复或整体结构而无法纳入。
因此，CFP 评审更像带约束的多目标决策，而不是单一分数排序：
- 内容质量需要达到足够高的门槛。
- 轨道之间需要有合理覆盖。
- 公司和演讲者不能过度集中。
- 时长必须适配实际日程。
- 节目还应给新听众和潜在贡献者留下入口。
这些目标之间经常互相冲突。单纯按评分从高到低截取，可能得到技术上很强但主题重复、公司高度集中、社区入口不足的节目单。
给下一轮 CFP 的实践建议
如果你准备提交 PostgreSQL 相关演讲，可以从几个具体方面提高提案的可评审性：
- 用摘要说明听众会带走什么，而不是只列出技术名词。
- 提供代码、幻灯片、录音、博客或此前演讲的链接，帮助评审判断内容深度和重复程度。
- 明确生产环境中的约束、失败经验和设计权衡，避免把官方文档目录改写成演讲摘要。
- 根据内容选择合适时长；需要现场实验、调试或互动的主题，更适合 workshop，而不是被压缩成25分钟。
- 如果你是开发者、DBA、PostgreSQL hacker、贡献者或社区组织者，不要假设“别人会提交”。社区代表性需要真实的提案进入池子。
一份大会节目单的价值，不只在于选出了多少“最高分”提案，还在于它能否让不同背景的听众在三天里持续找到值得参加的内容。CFP 的最后结果必然包含取舍，而这些取舍也正是走廊交流、社区反馈和下一轮提案继续发挥作用的地方。