贡献者漏斗的真实瓶颈
很多项目贴 good first issue，新人点进去却发现：复现含糊、环境起不来、PR 晾一周------第一个 PR 的摩擦比写代码还大 。ERD Online 把「两小时内合入首个 PR」当运营指标，而不只是贴标签。北极星是「每周有版本保存的活跃项目」；贡献者漏斗同样要可度量：从 clone 到第一个绿勾 merge 的时间。
issue 四件套（缺一不算 good first）
- 复现/期望：一步截图或 curl；写清改前/改后。
- 文件锚点：如版本面板组件附近------减少「从哪下手」搜索（贡献者可查 GitHub 源码树）。
- 验收标准 ：对应 E2E 或
mvn test/yarn test命令；能自动化就不写「应该没问题」。 - 范围上限：单 PR ≤200 行为宜；大了拆成「先补 testid / 先修文案」子 issue。
反例：「优化设计器体验」------黑洞，不是 good first。正例：「关系图画布空态 CTA 补 data-testid=canvas-empty-cta，并在自动化测试中断言可见」。
CONTRIBUTING 写死入口
- 后端：按开发文档用 tmux 保障进程（端口 9502）
- 前端：yarn start + HMR，勿为「生效」反复杀 8000
- MySQL/Redis：Colima + docker compose 起容器（勿 brew services 抢端口）
改 Java / yml 后按文档重启后端；改前端等 HMR。PR 描述贴「我跑了哪些验证」------维护者不用猜。定位纪律：E2E 优先 getByRole / getByTestId，禁止 .ant-* 碰运气。
Review SLA
首个贡献者 48 小时没回音，大概率永久流失。纪律：
- good first PR 目标 2 小时内 first review（工作时段）
- 需要改则一次性列全 comment，避免「改完又来三条」
- 小 fix 过了就 merge，不为「显得严谨」拖天数
合入后立刻感谢 + 指下一个同主题 issue------让「第一个」变成「第二个」的入口，而不是一次性体验。
现在就能 pick
- ReactFlow 节点 aria-label /
data-testid - i18n 键补全、CHANGELOG「验证点」补全
- 文档错别字、
/compare对照维度更新 - 空态 / 键盘陷阱回归补强
GitHub Issues 筛 good first issue：
👉 打开 GitHub 仓库（Issue / PR） ：https://github.com/erdonline/erdonline?utm_source=csdn&utm_medium=article&utm_campaign=launch&utm_content=good-first-issue-two-hours
路线图与参与
第一个 PR 不需要完美，需要可验证、可 review、可 merge。提 PR 前先看仓库里 open 的 good first------我们会优先 review 带验证命令的 PR。