Focalboard 贡献者 PR 提交检查清单从 CLA 签署到代码合入的完整流程【免费下载链接】focalboardFocalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.项目地址: https://gitcode.com/GitHub_Trending/fo/focalboard导读本文以 Focalboard 仓库的贡献文档 docs/contribution-checklist.md 为主线完整梳理社区开发者向该开源项目提交 Pull RequestPR前必须逐项核对的操作清单并结合仓库内的 CI 配置、测试体系、本地化工具链与代码审查流程说明每一条检查项背后的真实工程约束。读完本文你将能理解 Focalboard以及同类 Mattermost 系开源项目的合入门槛掌握npm run i18n-extract等关键命令的用法并清楚 PR 从创建、通过自动化构建到完成代码审查的完整生命周期。Focalboard 是一个开源、可自托管的项目管理与看板工具通常被用作 Trello、Notion、Asana 的替代方案。其代码库包含 Go 编写的服务端server/、TypeScript/React 编写的 Web 前端webapp/以及 mac、win-wpf、linux 等多个桌面端实现。社区贡献者的代码要合入main分支需要经过贡献检查清单、自动化构建、代码审查三道关卡本文逐一拆解。一、提交 PR 前的六步检查清单贡献检查清单 明确列出了社区开发者提交 PR 前需要逐项确认的六条硬性要求。下面逐条展开并结合仓库实际文件说明每一条的含义。1. 签署贡献者许可协议CLA第一条要求是签署 Mattermost 的 Contributor License AgreementCLA以便被添加进 Mattermost 的 Approved Contributor List已批准贡献者名单。这是整个贡献流程的法律前提它明确了代码版权的归属与授权方式只有签署过 CLA 的贡献者其提交的代码才能被合法合入上游仓库。签署情况会由维护者在后台核对属于 PR 合入的硬性门槛。2. 工作项必须是 Help Wanted 类型的 GitHub Issue第二条要求你的工作项对应的是目标项目上的Help WantedGitHub Issue。这类 Issue 由维护团队明确标记表示该任务已得到官方认可、适合外部开发者认领从而保证外部贡献与项目整体方向一致。如果你的改动没有对应的 Help Wanted 票则需要走无票贡献流程详见 docs/contributions-without-ticket.md。该文档指出少于 20 行代码的缺陷修复或增量改进通常无需开票即可被接受而超过 20 行的改动核心团队应先行开立 Help Wanted 票以统一项目愿景。即使是无票提交PR 也会先由核心团队的产品经理审查如果核心提交者认为改动显著改变了行为或用户预期仍有权拒绝合入。与核心团队讨论开票事宜可以在 Contributors 频道发起对话或在仓库 Issues 页面新建 Issue。3. 代码必须经过充分测试第三条要求代码经过充分测试包括适当的单元测试和手工测试。Focalboard 的测试体系在仓库中非常完整可以从源码和配置中直接验证Web 前端使用 Jest 运行单元测试配置见 webapp/package.json 中的test脚本jest。仓库内大量组件、工具函数与 reducer 均配有同名.test.ts/.test.tsx文件例如 webapp/src/mutator.test.ts、webapp/src/cardFilter.test.ts、webapp/src/utils.test.ts 等Jest 配置还开启了覆盖率收集collectCoverage: true。端到端测试使用 Cypress测试用例位于 webapp/cypress/integration覆盖建板、卡片徽章、分组、登录等关键路径如createBoard.ts、cardBadges.ts、groupByProperty.ts、loginActions.ts。服务端Go 单元测试覆盖server/app、server/services等目录例如 server/app/app_test.go、server/app/blocks_test.go存储层还通过 server/services/store/storetests 对 sqlite、mysql、mariadb、postgres 四种数据库做一致性验证。在提交 PR 前建议先在本地跑通与 CI 相同的检查命令再提交。具体命令见下文自动化构建一节。4. 用户界面字符串必须进入本地化文件en.json第四条针对包含用户界面文本的改动UI 字符串需要写入本地化文件即webapp/i18n/en.json。然后在 webapp 目录下运行npm run i18n-extract这条命令用于生成/更新英文翻译字符串其底层实现定义在 webapp/package.json 的i18n-extract脚本中i18n-extract: formatjs extract \src/**/*.{ts,tsx}\ --ignore \**/*.d.ts\ \../**/*.d.ts\ --out-file i18n/tmp.json formatjs compile i18n/tmp.json --out-file i18n/en.json npx rimraf i18n/tmp.json它使用formatjs/cli见 devDependencies完成两步工作先扫描src/**/*.{ts,tsx}提取所有翻译 key 生成临时文件再用formatjs compile编译输出到i18n/en.json最后清理临时文件。仓库中的 webapp/i18n/en.json 采用模块名.描述的扁平 key 结构如AttachmentBlock.addElement、BoardComponent.new并在 webapp/i18n 目录下同步维护了 37 种语言文件zh_Hans.json、ja.json、de.json等。在代码中使用翻译文案的典型方式是 React Intl 的useIntl()钩子例如 webapp/src/components/addContentMenuItem.tsx 中的const intl useIntl()以及 webapp/src/components/boardTemplateSelector/boardTemplateSelector.tsx 等大量组件。因此任何新增或修改的 UI 文本都应通过intl.formatMessage/FormattedMessage引用并同步执行npm run i18n-extract更新 en.json而不是硬编码字符串。5. PR 必须从你的 Fork 提交到 main 分支第五条是分支与仓库要求PR 必须从你的Fork提交目标分支为main。这一约定保证了合入历史清晰、review 与 rebase 可控。根目录 Makefile 与 CI 工作流也均以main为基准分支例如 .github/workflows/ci.yml 中push触发器明确监听main与releases-**分支。6. PR 标题必须以 GitHub Ticket ID 开头并填写摘要模板第六条是格式要求PR 标题以 GitHub Ticket ID 开头例如[GH-394]填写仓库提供的 PR 摘要模板。仓库根目录的 pull_request_template.md 就是该模板其结构包含#### Summary描述 PR 做了什么以及 QA 测试步骤如果适用且未写入 ticket#### Ticket Link关联 GitHub Issue如Fixes https://github.com/mattermost/focalboard/issues/XXXXX或 JIRA 票模板注释中还建议为 PR 指派两位 reviewer如不确定可设置Core Focalboard为 reviewer并要求先阅读贡献检查清单与《Submitting Great PRs》一文。二、提交后自动化构建必须通过检查清单最后一段明确了合入前提提交后自动化构建automated build process必须通过PR 才能被接受任何错误或失败都需要先解决。Focalboard 的自动化检查在 .github/workflows/ci.yml 中定义名为 Check-in tests由三组并行任务构成ci-ubuntu-server在 ubuntu-22.04 上对 sqlite、mysql、mariadb、postgres 四种数据库分别执行make server-test-db覆盖服务端全套单元测试ci-ubuntu-webapp先构建 Linux 服务器make server-linux-package再将服务器二进制复制给 Cypress 使用最后执行make webapp-ci即依次运行 lint、单元测试与 Cypress 端到端测试ci-windows-server / ci-mac-server在 Windows 2022 与 macOS 上运行make server-test-mini-sqlite验证跨平台兼容性。其中make webapp-ci对应的命令在根 Makefile 中定义webapp-ci: ## Webapp CI: linting testing. cd webapp; npm run check cd webapp; npm run test cd webapp; npm run cypress:ci而npm run check在 webapp/package.json 中定义为 ESLinteslint --ext .tsx,.ts . --quiet --cache加 Stylelintstylelint **/*.scss的静态检查cypress:ci则通过start-server-and-test先启动服务器runserver-test即运行编译出的bin/focalboard-server再等待http://localhost:8088就绪后执行cypress run。此外还有独立的 .github/workflows/lint-server.yml 负责服务端golangci-lint检查对应make server-lint。因此贡献者在提交 PR 前建议在本地完整复现一遍 CI# 在仓库根目录 make webapp-ci # webapp 的 lint Jest Cypress make server-test # 服务端在 sqlite/mysql/mariadb/postgres 上的测试 make server-lint # 服务端 golangci-lint需先安装 golangci-lint注意server-test中 mysql、mariadb、postgres 三项依赖 Docker 容器配置见 docker-testing 下的 compose 文件分别映射端口 44446/44445/44447sqlite 一项则无需 Docker如果本地环境不具备条件至少保证make server-test-sqlite通过剩余由 CI 矩阵覆盖。三、代码审查社区贡献者的等待与修改循环自动化构建通过后PR 进入代码审查阶段全部流程在 docs/code-review.md 中有详细说明。核心事实是当前所有产品改动都必须由一位核心提交者core committer审查。核心提交者即拥有仓库合并权限的维护者名单见 docs/core-committers.md。对社区贡献者而言典型流程为提交 PR遵循本文的贡献检查清单等待审查者分配产品经理通常会自动关注新 PR 并处理分配如果你一直在与某位核心提交者协作也可以直接联系实在无法推进时可在社区服务器上的 Focalboard 频道求助等待审查预期至少一位审查者在5 个工作日周一至周五法定节假日除外内与你互动。核心提交者分布在全球各地时区可能不同若超过 5 个工作日仍无互动可在 PR 评论中 提醒审查者处理修改意见如果审查者要求修改PR 会从对方的审查队列中消失完成修改后请在 PR 评论中再次 该审查者等待合并较大的 PR 需要更多审查时间所有审查者批准后由他们负责合并你的代码。同时docs/code-review.md 也对审查者core committer提出要求及时响应尽量 2 个工作日内互动、不草率放行避免 rubber stamping、不遗留挂起的审查、存在未解决的修改请求时不得合并。这些规则共同保证了合入代码的质量底线。四、现状提醒贡献流程的适用前提需要特别说明仓库当前的状态根目录 CONTRIBUTING.md 顶部有一则醒目的免责声明——自 2023 年 9 月 15 日起Mattermost 员工不再审查或合并本仓库mattermost/focalboard中 Focalboard 或 Mattermost Boards 插件的 PR并鼓励社区 fork 该仓库继续开发与贡献。文档还列出了过往维护者名单。因此本文描述的检查清单、代码审查流程与合入门槛属于该仓库长期遵循的贡献规范适合作为贡献者理解 Focalboard 工程标准与协作约定的参考对于仍在维护该仓库的 fork 或后续版本这些工程实践CLA、测试、本地化、CI、review仍具有直接的借鉴价值。五、要点速查表步骤要求仓库中的对应依据1签署 CLA见贡献检查清单第 1 条2对应 Help Wanted Issue否则走无票流程docs/contributions-without-ticket.md3单元测试 手工测试Jest 配置与用例在 webapp/package.json、webapp/src 下的*.test.ts(x)4UI 字符串进 en.json运行npm run i18n-extractwebapp/i18n/en.json5从 fork 提交到main分支.github/workflows/ci.yml 的 push 触发器6标题以[GH-xxx]开头 填写模板pull_request_template.md7自动化构建通过.github/workflows/ci.yml、Makefile 的webapp-ci/server-test8通过核心提交者代码审查docs/code-review.md、docs/core-committers.md对于希望向 Focalboard 提交代码的开发者按此清单逐项核对、先在本地跑通 CI 等价命令、遵守 i18n 与测试约定是让 PR 快速进入合入通道的最有效方式。【免费下载链接】focalboardFocalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.项目地址: https://gitcode.com/GitHub_Trending/fo/focalboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Focalboard 贡献者 PR 提交检查清单：从 CLA 签署到代码合入的完整流程
Focalboard 贡献者 PR 提交检查清单从 CLA 签署到代码合入的完整流程【免费下载链接】focalboardFocalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.项目地址: https://gitcode.com/GitHub_Trending/fo/focalboard导读本文以 Focalboard 仓库的贡献文档 docs/contribution-checklist.md 为主线完整梳理社区开发者向该开源项目提交 Pull RequestPR前必须逐项核对的操作清单并结合仓库内的 CI 配置、测试体系、本地化工具链与代码审查流程说明每一条检查项背后的真实工程约束。读完本文你将能理解 Focalboard以及同类 Mattermost 系开源项目的合入门槛掌握npm run i18n-extract等关键命令的用法并清楚 PR 从创建、通过自动化构建到完成代码审查的完整生命周期。Focalboard 是一个开源、可自托管的项目管理与看板工具通常被用作 Trello、Notion、Asana 的替代方案。其代码库包含 Go 编写的服务端server/、TypeScript/React 编写的 Web 前端webapp/以及 mac、win-wpf、linux 等多个桌面端实现。社区贡献者的代码要合入main分支需要经过贡献检查清单、自动化构建、代码审查三道关卡本文逐一拆解。一、提交 PR 前的六步检查清单贡献检查清单 明确列出了社区开发者提交 PR 前需要逐项确认的六条硬性要求。下面逐条展开并结合仓库实际文件说明每一条的含义。1. 签署贡献者许可协议CLA第一条要求是签署 Mattermost 的 Contributor License AgreementCLA以便被添加进 Mattermost 的 Approved Contributor List已批准贡献者名单。这是整个贡献流程的法律前提它明确了代码版权的归属与授权方式只有签署过 CLA 的贡献者其提交的代码才能被合法合入上游仓库。签署情况会由维护者在后台核对属于 PR 合入的硬性门槛。2. 工作项必须是 Help Wanted 类型的 GitHub Issue第二条要求你的工作项对应的是目标项目上的Help WantedGitHub Issue。这类 Issue 由维护团队明确标记表示该任务已得到官方认可、适合外部开发者认领从而保证外部贡献与项目整体方向一致。如果你的改动没有对应的 Help Wanted 票则需要走无票贡献流程详见 docs/contributions-without-ticket.md。该文档指出少于 20 行代码的缺陷修复或增量改进通常无需开票即可被接受而超过 20 行的改动核心团队应先行开立 Help Wanted 票以统一项目愿景。即使是无票提交PR 也会先由核心团队的产品经理审查如果核心提交者认为改动显著改变了行为或用户预期仍有权拒绝合入。与核心团队讨论开票事宜可以在 Contributors 频道发起对话或在仓库 Issues 页面新建 Issue。3. 代码必须经过充分测试第三条要求代码经过充分测试包括适当的单元测试和手工测试。Focalboard 的测试体系在仓库中非常完整可以从源码和配置中直接验证Web 前端使用 Jest 运行单元测试配置见 webapp/package.json 中的test脚本jest。仓库内大量组件、工具函数与 reducer 均配有同名.test.ts/.test.tsx文件例如 webapp/src/mutator.test.ts、webapp/src/cardFilter.test.ts、webapp/src/utils.test.ts 等Jest 配置还开启了覆盖率收集collectCoverage: true。端到端测试使用 Cypress测试用例位于 webapp/cypress/integration覆盖建板、卡片徽章、分组、登录等关键路径如createBoard.ts、cardBadges.ts、groupByProperty.ts、loginActions.ts。服务端Go 单元测试覆盖server/app、server/services等目录例如 server/app/app_test.go、server/app/blocks_test.go存储层还通过 server/services/store/storetests 对 sqlite、mysql、mariadb、postgres 四种数据库做一致性验证。在提交 PR 前建议先在本地跑通与 CI 相同的检查命令再提交。具体命令见下文自动化构建一节。4. 用户界面字符串必须进入本地化文件en.json第四条针对包含用户界面文本的改动UI 字符串需要写入本地化文件即webapp/i18n/en.json。然后在 webapp 目录下运行npm run i18n-extract这条命令用于生成/更新英文翻译字符串其底层实现定义在 webapp/package.json 的i18n-extract脚本中i18n-extract: formatjs extract \src/**/*.{ts,tsx}\ --ignore \**/*.d.ts\ \../**/*.d.ts\ --out-file i18n/tmp.json formatjs compile i18n/tmp.json --out-file i18n/en.json npx rimraf i18n/tmp.json它使用formatjs/cli见 devDependencies完成两步工作先扫描src/**/*.{ts,tsx}提取所有翻译 key 生成临时文件再用formatjs compile编译输出到i18n/en.json最后清理临时文件。仓库中的 webapp/i18n/en.json 采用模块名.描述的扁平 key 结构如AttachmentBlock.addElement、BoardComponent.new并在 webapp/i18n 目录下同步维护了 37 种语言文件zh_Hans.json、ja.json、de.json等。在代码中使用翻译文案的典型方式是 React Intl 的useIntl()钩子例如 webapp/src/components/addContentMenuItem.tsx 中的const intl useIntl()以及 webapp/src/components/boardTemplateSelector/boardTemplateSelector.tsx 等大量组件。因此任何新增或修改的 UI 文本都应通过intl.formatMessage/FormattedMessage引用并同步执行npm run i18n-extract更新 en.json而不是硬编码字符串。5. PR 必须从你的 Fork 提交到 main 分支第五条是分支与仓库要求PR 必须从你的Fork提交目标分支为main。这一约定保证了合入历史清晰、review 与 rebase 可控。根目录 Makefile 与 CI 工作流也均以main为基准分支例如 .github/workflows/ci.yml 中push触发器明确监听main与releases-**分支。6. PR 标题必须以 GitHub Ticket ID 开头并填写摘要模板第六条是格式要求PR 标题以 GitHub Ticket ID 开头例如[GH-394]填写仓库提供的 PR 摘要模板。仓库根目录的 pull_request_template.md 就是该模板其结构包含#### Summary描述 PR 做了什么以及 QA 测试步骤如果适用且未写入 ticket#### Ticket Link关联 GitHub Issue如Fixes https://github.com/mattermost/focalboard/issues/XXXXX或 JIRA 票模板注释中还建议为 PR 指派两位 reviewer如不确定可设置Core Focalboard为 reviewer并要求先阅读贡献检查清单与《Submitting Great PRs》一文。二、提交后自动化构建必须通过检查清单最后一段明确了合入前提提交后自动化构建automated build process必须通过PR 才能被接受任何错误或失败都需要先解决。Focalboard 的自动化检查在 .github/workflows/ci.yml 中定义名为 Check-in tests由三组并行任务构成ci-ubuntu-server在 ubuntu-22.04 上对 sqlite、mysql、mariadb、postgres 四种数据库分别执行make server-test-db覆盖服务端全套单元测试ci-ubuntu-webapp先构建 Linux 服务器make server-linux-package再将服务器二进制复制给 Cypress 使用最后执行make webapp-ci即依次运行 lint、单元测试与 Cypress 端到端测试ci-windows-server / ci-mac-server在 Windows 2022 与 macOS 上运行make server-test-mini-sqlite验证跨平台兼容性。其中make webapp-ci对应的命令在根 Makefile 中定义webapp-ci: ## Webapp CI: linting testing. cd webapp; npm run check cd webapp; npm run test cd webapp; npm run cypress:ci而npm run check在 webapp/package.json 中定义为 ESLinteslint --ext .tsx,.ts . --quiet --cache加 Stylelintstylelint **/*.scss的静态检查cypress:ci则通过start-server-and-test先启动服务器runserver-test即运行编译出的bin/focalboard-server再等待http://localhost:8088就绪后执行cypress run。此外还有独立的 .github/workflows/lint-server.yml 负责服务端golangci-lint检查对应make server-lint。因此贡献者在提交 PR 前建议在本地完整复现一遍 CI# 在仓库根目录 make webapp-ci # webapp 的 lint Jest Cypress make server-test # 服务端在 sqlite/mysql/mariadb/postgres 上的测试 make server-lint # 服务端 golangci-lint需先安装 golangci-lint注意server-test中 mysql、mariadb、postgres 三项依赖 Docker 容器配置见 docker-testing 下的 compose 文件分别映射端口 44446/44445/44447sqlite 一项则无需 Docker如果本地环境不具备条件至少保证make server-test-sqlite通过剩余由 CI 矩阵覆盖。三、代码审查社区贡献者的等待与修改循环自动化构建通过后PR 进入代码审查阶段全部流程在 docs/code-review.md 中有详细说明。核心事实是当前所有产品改动都必须由一位核心提交者core committer审查。核心提交者即拥有仓库合并权限的维护者名单见 docs/core-committers.md。对社区贡献者而言典型流程为提交 PR遵循本文的贡献检查清单等待审查者分配产品经理通常会自动关注新 PR 并处理分配如果你一直在与某位核心提交者协作也可以直接联系实在无法推进时可在社区服务器上的 Focalboard 频道求助等待审查预期至少一位审查者在5 个工作日周一至周五法定节假日除外内与你互动。核心提交者分布在全球各地时区可能不同若超过 5 个工作日仍无互动可在 PR 评论中 提醒审查者处理修改意见如果审查者要求修改PR 会从对方的审查队列中消失完成修改后请在 PR 评论中再次 该审查者等待合并较大的 PR 需要更多审查时间所有审查者批准后由他们负责合并你的代码。同时docs/code-review.md 也对审查者core committer提出要求及时响应尽量 2 个工作日内互动、不草率放行避免 rubber stamping、不遗留挂起的审查、存在未解决的修改请求时不得合并。这些规则共同保证了合入代码的质量底线。四、现状提醒贡献流程的适用前提需要特别说明仓库当前的状态根目录 CONTRIBUTING.md 顶部有一则醒目的免责声明——自 2023 年 9 月 15 日起Mattermost 员工不再审查或合并本仓库mattermost/focalboard中 Focalboard 或 Mattermost Boards 插件的 PR并鼓励社区 fork 该仓库继续开发与贡献。文档还列出了过往维护者名单。因此本文描述的检查清单、代码审查流程与合入门槛属于该仓库长期遵循的贡献规范适合作为贡献者理解 Focalboard 工程标准与协作约定的参考对于仍在维护该仓库的 fork 或后续版本这些工程实践CLA、测试、本地化、CI、review仍具有直接的借鉴价值。五、要点速查表步骤要求仓库中的对应依据1签署 CLA见贡献检查清单第 1 条2对应 Help Wanted Issue否则走无票流程docs/contributions-without-ticket.md3单元测试 手工测试Jest 配置与用例在 webapp/package.json、webapp/src 下的*.test.ts(x)4UI 字符串进 en.json运行npm run i18n-extractwebapp/i18n/en.json5从 fork 提交到main分支.github/workflows/ci.yml 的 push 触发器6标题以[GH-xxx]开头 填写模板pull_request_template.md7自动化构建通过.github/workflows/ci.yml、Makefile 的webapp-ci/server-test8通过核心提交者代码审查docs/code-review.md、docs/core-committers.md对于希望向 Focalboard 提交代码的开发者按此清单逐项核对、先在本地跑通 CI 等价命令、遵守 i18n 与测试约定是让 PR 快速进入合入通道的最有效方式。【免费下载链接】focalboardFocalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.项目地址: https://gitcode.com/GitHub_Trending/fo/focalboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考