尧图网站建设 
FreeCAD 贡献流程FCP全解析从 Issue 到 Pull Request 的完整协作指南【免费下载链接】FreeCADOfficial source code of FreeCAD, a free and opensource multiplatform 3D parametric modeler.项目地址: https://gitcode.com/GitHub_Trending/fr/FreeCADFreeCAD 的贡献流程FreeCAD Contribution Process简称 FCP是该项目所有代码合并与质量控制的制度核心其设计灵感源自 Collective Code Construction ContractC4后者本身又是 GitHub 上经典 Fork and Pull 模型的演进。本指南以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内的 AI_POLICY.md、LICENSE、.github/pull_request_template.md 与 src/Doc/CONTRIBUTORS 等真实文件系统讲解 FreeCAD 的贡献规则、角色分工、PR 验收标准与合并流程。读完本文你将清楚知道如何正确地提交一个被 FreeCAD 维护者认可的 Pull Request理解有效 PRValid PR的确切定义并掌握与 AI 辅助贡献相关的披露要求。1. FCP 的定位与设计目标FCP 是一份面向 FreeCAD 所有贡献者与维护者的流程规范。文档开篇即声明其中使用的 MUST、SHOULD、MAY 等关键词遵循 RFC 2119 的语义——MUST 表示强制要求SHOULD 表示强烈建议MAY 表示允许。同时文档第 0 节明确说明 FreeCAD 正处于过渡期当前规则属于GUIDELINES指导方针实际流程在过渡期间可能与书面流程存在偏离任何偏离都应被记录和讨论。FCP 的七条核心目标直接决定了后续所有规则的取向提供透明、公平的贡献流程让贡献以尽可能快的速度被合并在鼓励试验与冒险的同时保持并提升代码质量通过培育庞大的活跃贡献者池减少对单个贡献者的依赖包容多种观点、汇聚多样化技能营造让贡献者学习与提升技能的鼓励性环境保护 FreeCAD 项目的自由与开放本质。2. 基本事实git、GitHub、Issue 与 PRFCP 第 2 节确立了项目协作的技术底座这些事实在仓库中均有对应版本控制FreeCAD 使用 git 分布式版本控制系统代码托管主应用及相关子项目的源码托管在 github.com 的 FreeCAD 组织下问题定义问题Problem是离散、明确界定的限制或缺陷bug问题追踪FreeCAD 使用 GitHub 的 issue 追踪系统记录问题和贡献帮助请求与一般性讨论请使用项目论坛不要占用 issue 通道贡献定义贡献Contribution是解决单个问题的一组代码变更验收方式FreeCAD 使用Pull RequestPR工作流来评估与接受贡献。3. 四类角色User / Contributor / Maintainer / AdministratorFCP 定义了四个明确的角色权限边界清晰角色定义权限User用户使用 FreeCAD 软件的更广泛社区成员可以提交 issue、在 PR 上评论Contributor贡献者提交解决已识别问题的贡献的人除非同时是 Maintainer否则没有仓库提交权限任何人不区分、不歧视都有平等的成为 Contributor 的权利Maintainer维护者合并贡献的人负责执行流程拥有仓库提交权限可以合并 PRAdministrator管理员维护指定 Maintainer 名单的额外权限角色管理组织与团队名单值得强调的是Contributor 与 Maintainer 不得直接向目标分支提交变更第 6.8 条——所有代码变更都必须走 PR 通道这保证了审查的可追溯性。4. 许可、所有权与署名FCP 第 4 节明确了法律层面的三条底线许可证FreeCAD 以LGPL 2.0 或更高版本LGPL2发布细节见仓库根目录的 LICENSE 文件实际文件为 GNU Lesser General Public License Version 2.1兼容性所有贡献必须使用兼容许可证同时贡献者需合理保证其贡献不侵犯第三方版权或许可条款第 5.15 条版权归属所有贡献归其作者所有除非转让给他人FreeCAD没有强制性的版权转让政策。关于署名有两点可操作的规定希望出现在应用关于About对话框 Credits 部分的贡献者应自行修改 src/Doc/CONTRIBUTORS 文件并提交仅包含此修改的单一 commit的 PR不愿承担贡献版权的贡献者可以选择在文件许可证代码块中标注Copyright (c) 2022 The FreeCAD project association fpafreecad.org将版权转让给 FreeCAD 项目协会。5. 贡献要求什么才算有效 PRFCP 第 5 节定义了贡献者提交 PR 时必须满足的全部要求第 5.16 条将这些要求统称为有效 PRValid PR的判定标准。逐条解读如下5.1 形式与身份要求贡献以PR 形式提交维护者与贡献者必须拥有 GitHub 账号应该使用真实姓名或众所周知的别名若 GitHub 用户名与 FreeCAD 论坛用户名不同应尽力避免混淆。5.2 内容与范围PR应该是恰好一个问题的最小、准确回答一个 PR 对应一个问题PR应该避免给项目增加新依赖除非别无选择——这保护了 FreeCAD 庞大的构建体系仓库 cMake/FreeCAD_Helpers/ 下的 Setup* 系列脚本正是这套依赖管理的外化体现代码必须遵守项目已定义的代码风格规范PR不得包含来自其他项目的非平凡代码除非贡献者本人就是该代码的原作者。5.3 提交与构建质量若 PR 包含多个 commit每个 commit在与该 PR 之前所有 commit 合并后必须能干净编译每个 commit应该为项目历史增加价值检查点 commitcheckpoint commits应该被 squashPR必须在所有目标平台上干净编译并通过项目自测——仓库根目录的 tests/ 目录含 161 个*.cpp测试源文件与 tests/CMakeLists.txt 就是这套自测体系的落点破坏扩展所用 Python API 的变更应该避免若不可避免破坏面必须最小化且 PR必须清晰描述所有破坏性变更并给出替代方案贡献者应该主动搜索会受影响的插件addons并在 PR 中列出。5.4 提交信息与 PR 描述每个 commit message必须简明解释该 commit 达成的效果并遵循git commit --help文档 DISCUSSION 章节的建议PR 标题必须简明概括其成果正文可以按需详细若 PR 改变用户界面UI正文必须包含 UI 变更展示最好附上前一版与新版状态的截图——这一要求在 .github/pull_request_template.md 的 Before and After Images 小节中同样被固化。5.5 他人工作的引用若 PR 包含其他作者的工作例如从他人 fork 中 cherry-pickPR 描述第一行必须给出恰当署名例如This is work of XYZ cherry-picked from link所有 commit必须具有正确的作者归属original author 创作、PR 提交者提交对 cherry-pick 的 commit 的修改应该以后续 commit 形式进行若无法做到被修改的 commit必须在 commit message 中包含Co-Authored-By尾部标记。6. 贡献流程从 Issue 到合并FCP 第 6 节描述了端到端的工作流共 19 条可归纳为五个阶段6.1 阶段一识别问题并提交 Issue变更遵循准确识别问题 应用最小、准确解决方案的模式User 在 GitHub issue 追踪器上记录 issue 来请求变更issue 作者应该描述其面临或观察到的问题允许附上论坛或外部资源的链接但 issue应该完整准确不应要求读者跳转到论坛或其他平台才能理解内容issue 作者应该描述最低可接受条件minimum acceptable conditionissue 作者应该聚焦用户任务避免与其他软件方案做比较用户或贡献者应该就观察的准确性及解决问题的价值寻求共识。6.2 阶段二提交 Pull Request贡献者必须向项目创建指向回项目的 pull requestContributors 与 Maintainers不得直接向目标分支提交变更对解决方案的讨论用户可以直接评论在 GitHub 的 PR 上论坛上的相关讨论应该被劝阻并引导回 PR 或关联 issue——这保证了讨论记录集中在可追踪的位置。6.3 阶段三维护者审查与合并接受或拒绝 PR维护者必须使用 GitHub 界面操作维护者不应该合并自己的 PR除非a特殊情况如其他维护者长期无响应b该维护者同时是该工作台workbench或子系统的首席开发者维护者必须快速合并来自其他贡献者的有效 PR维护者可以酌情合并未完全达到有效标准的 PR目的是结束无果的讨论、将有害贡献记录在历史中、或与贡献者互动以改进其贡献质量维护者不得对正确贡献做价值判断——如果对 PR 有不同价值判断应以自己的 PR表达第 6.17 条而非在评论中争执。6.4 阶段四状态管理若 PR 在合并前仍需大量工作应该将其移为draft状态若 PR 已完备但暂时不应合并例如依赖另一个进行中的 PR应该打上On hold标签由 AI 政策引入的Unverified标签机制见 AI_POLICY.md用于标记来自 Developers 组之外的 PR详见本文第 8 节。6.5 阶段五收尾创建 issue 的用户在确认 PR 成功合并后应该关闭该 issue维护者应该关闭长期无人操作或更新的 issue。7. 分支策略与发布FCP 第 7 节确立了极简的分支模型项目必须只有一个分支main它始终持有最新的进行中版本并且应该始终可构建项目不得出于任何原因使用主题分支topic branches个人 fork可以使用主题分支发布稳定版本时维护者必须对仓库打 tag稳定版本必须始终从 main 分支发布。这一单主干 tag 发布的策略极大简化了贡献者的操作心智你只需要保证你的 PR 能干净地合入 main 即可。8. 项目管理Administrator 的职责边界FCP 第 8 节定义了项目治理细节Project Administrator 是 GitHub 组织中的owner角色负责组织管理增删团队成员这是一个由 GitHub 平台催生的技术性角色除少数例外Administrator不做关于个别团队成员的决定而是执行 Maintainers 团队的集体意愿Administrator 由 Maintainers 团队从自身中选出为确保连续性任何时候至少要有四位 Project AdministratorAdministrator 负责管理 Maintainer 名单并保持足够大的 Maintainer 池以保证继任与及时的贡献审查池子不足时Administrator 会请求 Maintainers 增选人员有成功 PR 历史且持续展现专业性的贡献者应该被邀请成为 MaintainerAdministrator应该移除长期不活跃、或屡次未能准确执行本流程的 MaintainerMaintainer 名单必须公开可查并反映项目当前活动Administrator必须迅速行动保护 FreeCAD 基础设施与资源Administrator应该阻止或封禁不良行为者bad actors——即反复无视项目规则与文化、充满敌意或冒犯性、阻碍信息有效交流、在被要求时无法自我纠正的人此类措施应该在公开讨论、给予各方发言机会之后进行。9. AI 辅助贡献FreeCAD 的人工主导政策这是 FreeCAD 贡献流程中近年来最重要的新增内容。FCP 第 5.14 条明确要求贡献必须符合 AI_POLICY.md仓库根目录可查其核心立场是人类在驾驶位humans in the driver seatFreeCAD不接受明显由 AI 生成的代码、commit message、PR 描述以及回应审查意见的回复项目要求贡献者披露 AI 辅助情况在 PR 描述中用自然语言说明并在 commit message 中附 git trailer格式为Assisted-by: [Model-Family] ([Version/ID])例如Assisted-by: gemini-2.5-pro (rev-1) Assisted-by: GPT-4o-2024-08-06PR 模板中有一个必勾复选框见 .github/pull_request_template.mdThis PR is not unverified AI output, I take responsibility for it, and all communication from my side in this PR is done by me personally.来自 Developers 组之外的 PR 会被标记Unverified标签以辅助排查潜在违规经过几次成功贡献后新贡献者会被加入相应组也可主动请求提前加入政策同时提醒贡献者关注 AI 在特权、环境、版权、社会及开源社区层面的负面影响并鼓励了解 frugal AI 与全开放 AI 模型等替代方案。10. 给贡献者的实操建议面向本仓库结合以上规则如果你准备向本仓库提交第一个 PR可遵循如下落地清单先在 GitHub issue 追踪器上描述问题就问题定义与解决价值达成共识后再动笔保持 PR 小而聚焦一个 PR 只解决一个问题避免引入新依赖保证每个 commit 都能独立编译把杂乱的检查点 commit squash 掉提交信息遵循 git 官方规范用标题概括、正文补充修改 UI 时必须附 before/after 截图PR 模板的 Before and After Images 小节已给出占位涉及 Python API 破坏时在 PR 中列出受影响的插件与替代方案涉及 GUI 变更时让 Design Working GroupDWG知晓涉及标准与工作流时让 CAD Working GroupCWG知晓模板 Notes on the PR Review Process 一节对此有完整说明若使用 AI 辅助在 PR 描述中如实披露并按上述格式在 commit 中加Assisted-bytrailer想进入 Credits 名单修改 src/Doc/CONTRIBUTORS 并提交一个只含该修改的独立 commit合并后由你创建的 issue 记得关闭。11. 总结FreeCAD Contribution Process 是一套以C4 / Fork and Pull 模型为哲学基础、以单 main 分支 PR 审查 快速合并有效贡献为操作特征的治理框架。它的核心张力在于既要通过 16 条严格标准编译、测试、风格、署名、API 兼容、AI 政策保证代码质量又要通过维护者必须快速合并有效 PR不得对正确贡献做价值判断等条款保证贡献者的参与体验与公平性。无论你是想修一个 bug、实现一个功能还是参与工作台维护理解这份文档都是你融入 FreeCAD 开发者社区的第一步。【免费下载链接】FreeCADOfficial source code of FreeCAD, a free and opensource multiplatform 3D parametric modeler.项目地址: https://gitcode.com/GitHub_Trending/fr/FreeCAD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FreeCAD 贡献流程（FCP）全解析：从 Issue 到 Pull Request 的完整协作指南
FreeCAD 贡献流程FCP全解析从 Issue 到 Pull Request 的完整协作指南【免费下载链接】FreeCADOfficial source code of FreeCAD, a free and opensource multiplatform 3D parametric modeler.项目地址: https://gitcode.com/GitHub_Trending/fr/FreeCADFreeCAD 的贡献流程FreeCAD Contribution Process简称 FCP是该项目所有代码合并与质量控制的制度核心其设计灵感源自 Collective Code Construction ContractC4后者本身又是 GitHub 上经典 Fork and Pull 模型的演进。本指南以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内的 AI_POLICY.md、LICENSE、.github/pull_request_template.md 与 src/Doc/CONTRIBUTORS 等真实文件系统讲解 FreeCAD 的贡献规则、角色分工、PR 验收标准与合并流程。读完本文你将清楚知道如何正确地提交一个被 FreeCAD 维护者认可的 Pull Request理解有效 PRValid PR的确切定义并掌握与 AI 辅助贡献相关的披露要求。1. FCP 的定位与设计目标FCP 是一份面向 FreeCAD 所有贡献者与维护者的流程规范。文档开篇即声明其中使用的 MUST、SHOULD、MAY 等关键词遵循 RFC 2119 的语义——MUST 表示强制要求SHOULD 表示强烈建议MAY 表示允许。同时文档第 0 节明确说明 FreeCAD 正处于过渡期当前规则属于GUIDELINES指导方针实际流程在过渡期间可能与书面流程存在偏离任何偏离都应被记录和讨论。FCP 的七条核心目标直接决定了后续所有规则的取向提供透明、公平的贡献流程让贡献以尽可能快的速度被合并在鼓励试验与冒险的同时保持并提升代码质量通过培育庞大的活跃贡献者池减少对单个贡献者的依赖包容多种观点、汇聚多样化技能营造让贡献者学习与提升技能的鼓励性环境保护 FreeCAD 项目的自由与开放本质。2. 基本事实git、GitHub、Issue 与 PRFCP 第 2 节确立了项目协作的技术底座这些事实在仓库中均有对应版本控制FreeCAD 使用 git 分布式版本控制系统代码托管主应用及相关子项目的源码托管在 github.com 的 FreeCAD 组织下问题定义问题Problem是离散、明确界定的限制或缺陷bug问题追踪FreeCAD 使用 GitHub 的 issue 追踪系统记录问题和贡献帮助请求与一般性讨论请使用项目论坛不要占用 issue 通道贡献定义贡献Contribution是解决单个问题的一组代码变更验收方式FreeCAD 使用Pull RequestPR工作流来评估与接受贡献。3. 四类角色User / Contributor / Maintainer / AdministratorFCP 定义了四个明确的角色权限边界清晰角色定义权限User用户使用 FreeCAD 软件的更广泛社区成员可以提交 issue、在 PR 上评论Contributor贡献者提交解决已识别问题的贡献的人除非同时是 Maintainer否则没有仓库提交权限任何人不区分、不歧视都有平等的成为 Contributor 的权利Maintainer维护者合并贡献的人负责执行流程拥有仓库提交权限可以合并 PRAdministrator管理员维护指定 Maintainer 名单的额外权限角色管理组织与团队名单值得强调的是Contributor 与 Maintainer 不得直接向目标分支提交变更第 6.8 条——所有代码变更都必须走 PR 通道这保证了审查的可追溯性。4. 许可、所有权与署名FCP 第 4 节明确了法律层面的三条底线许可证FreeCAD 以LGPL 2.0 或更高版本LGPL2发布细节见仓库根目录的 LICENSE 文件实际文件为 GNU Lesser General Public License Version 2.1兼容性所有贡献必须使用兼容许可证同时贡献者需合理保证其贡献不侵犯第三方版权或许可条款第 5.15 条版权归属所有贡献归其作者所有除非转让给他人FreeCAD没有强制性的版权转让政策。关于署名有两点可操作的规定希望出现在应用关于About对话框 Credits 部分的贡献者应自行修改 src/Doc/CONTRIBUTORS 文件并提交仅包含此修改的单一 commit的 PR不愿承担贡献版权的贡献者可以选择在文件许可证代码块中标注Copyright (c) 2022 The FreeCAD project association fpafreecad.org将版权转让给 FreeCAD 项目协会。5. 贡献要求什么才算有效 PRFCP 第 5 节定义了贡献者提交 PR 时必须满足的全部要求第 5.16 条将这些要求统称为有效 PRValid PR的判定标准。逐条解读如下5.1 形式与身份要求贡献以PR 形式提交维护者与贡献者必须拥有 GitHub 账号应该使用真实姓名或众所周知的别名若 GitHub 用户名与 FreeCAD 论坛用户名不同应尽力避免混淆。5.2 内容与范围PR应该是恰好一个问题的最小、准确回答一个 PR 对应一个问题PR应该避免给项目增加新依赖除非别无选择——这保护了 FreeCAD 庞大的构建体系仓库 cMake/FreeCAD_Helpers/ 下的 Setup* 系列脚本正是这套依赖管理的外化体现代码必须遵守项目已定义的代码风格规范PR不得包含来自其他项目的非平凡代码除非贡献者本人就是该代码的原作者。5.3 提交与构建质量若 PR 包含多个 commit每个 commit在与该 PR 之前所有 commit 合并后必须能干净编译每个 commit应该为项目历史增加价值检查点 commitcheckpoint commits应该被 squashPR必须在所有目标平台上干净编译并通过项目自测——仓库根目录的 tests/ 目录含 161 个*.cpp测试源文件与 tests/CMakeLists.txt 就是这套自测体系的落点破坏扩展所用 Python API 的变更应该避免若不可避免破坏面必须最小化且 PR必须清晰描述所有破坏性变更并给出替代方案贡献者应该主动搜索会受影响的插件addons并在 PR 中列出。5.4 提交信息与 PR 描述每个 commit message必须简明解释该 commit 达成的效果并遵循git commit --help文档 DISCUSSION 章节的建议PR 标题必须简明概括其成果正文可以按需详细若 PR 改变用户界面UI正文必须包含 UI 变更展示最好附上前一版与新版状态的截图——这一要求在 .github/pull_request_template.md 的 Before and After Images 小节中同样被固化。5.5 他人工作的引用若 PR 包含其他作者的工作例如从他人 fork 中 cherry-pickPR 描述第一行必须给出恰当署名例如This is work of XYZ cherry-picked from link所有 commit必须具有正确的作者归属original author 创作、PR 提交者提交对 cherry-pick 的 commit 的修改应该以后续 commit 形式进行若无法做到被修改的 commit必须在 commit message 中包含Co-Authored-By尾部标记。6. 贡献流程从 Issue 到合并FCP 第 6 节描述了端到端的工作流共 19 条可归纳为五个阶段6.1 阶段一识别问题并提交 Issue变更遵循准确识别问题 应用最小、准确解决方案的模式User 在 GitHub issue 追踪器上记录 issue 来请求变更issue 作者应该描述其面临或观察到的问题允许附上论坛或外部资源的链接但 issue应该完整准确不应要求读者跳转到论坛或其他平台才能理解内容issue 作者应该描述最低可接受条件minimum acceptable conditionissue 作者应该聚焦用户任务避免与其他软件方案做比较用户或贡献者应该就观察的准确性及解决问题的价值寻求共识。6.2 阶段二提交 Pull Request贡献者必须向项目创建指向回项目的 pull requestContributors 与 Maintainers不得直接向目标分支提交变更对解决方案的讨论用户可以直接评论在 GitHub 的 PR 上论坛上的相关讨论应该被劝阻并引导回 PR 或关联 issue——这保证了讨论记录集中在可追踪的位置。6.3 阶段三维护者审查与合并接受或拒绝 PR维护者必须使用 GitHub 界面操作维护者不应该合并自己的 PR除非a特殊情况如其他维护者长期无响应b该维护者同时是该工作台workbench或子系统的首席开发者维护者必须快速合并来自其他贡献者的有效 PR维护者可以酌情合并未完全达到有效标准的 PR目的是结束无果的讨论、将有害贡献记录在历史中、或与贡献者互动以改进其贡献质量维护者不得对正确贡献做价值判断——如果对 PR 有不同价值判断应以自己的 PR表达第 6.17 条而非在评论中争执。6.4 阶段四状态管理若 PR 在合并前仍需大量工作应该将其移为draft状态若 PR 已完备但暂时不应合并例如依赖另一个进行中的 PR应该打上On hold标签由 AI 政策引入的Unverified标签机制见 AI_POLICY.md用于标记来自 Developers 组之外的 PR详见本文第 8 节。6.5 阶段五收尾创建 issue 的用户在确认 PR 成功合并后应该关闭该 issue维护者应该关闭长期无人操作或更新的 issue。7. 分支策略与发布FCP 第 7 节确立了极简的分支模型项目必须只有一个分支main它始终持有最新的进行中版本并且应该始终可构建项目不得出于任何原因使用主题分支topic branches个人 fork可以使用主题分支发布稳定版本时维护者必须对仓库打 tag稳定版本必须始终从 main 分支发布。这一单主干 tag 发布的策略极大简化了贡献者的操作心智你只需要保证你的 PR 能干净地合入 main 即可。8. 项目管理Administrator 的职责边界FCP 第 8 节定义了项目治理细节Project Administrator 是 GitHub 组织中的owner角色负责组织管理增删团队成员这是一个由 GitHub 平台催生的技术性角色除少数例外Administrator不做关于个别团队成员的决定而是执行 Maintainers 团队的集体意愿Administrator 由 Maintainers 团队从自身中选出为确保连续性任何时候至少要有四位 Project AdministratorAdministrator 负责管理 Maintainer 名单并保持足够大的 Maintainer 池以保证继任与及时的贡献审查池子不足时Administrator 会请求 Maintainers 增选人员有成功 PR 历史且持续展现专业性的贡献者应该被邀请成为 MaintainerAdministrator应该移除长期不活跃、或屡次未能准确执行本流程的 MaintainerMaintainer 名单必须公开可查并反映项目当前活动Administrator必须迅速行动保护 FreeCAD 基础设施与资源Administrator应该阻止或封禁不良行为者bad actors——即反复无视项目规则与文化、充满敌意或冒犯性、阻碍信息有效交流、在被要求时无法自我纠正的人此类措施应该在公开讨论、给予各方发言机会之后进行。9. AI 辅助贡献FreeCAD 的人工主导政策这是 FreeCAD 贡献流程中近年来最重要的新增内容。FCP 第 5.14 条明确要求贡献必须符合 AI_POLICY.md仓库根目录可查其核心立场是人类在驾驶位humans in the driver seatFreeCAD不接受明显由 AI 生成的代码、commit message、PR 描述以及回应审查意见的回复项目要求贡献者披露 AI 辅助情况在 PR 描述中用自然语言说明并在 commit message 中附 git trailer格式为Assisted-by: [Model-Family] ([Version/ID])例如Assisted-by: gemini-2.5-pro (rev-1) Assisted-by: GPT-4o-2024-08-06PR 模板中有一个必勾复选框见 .github/pull_request_template.mdThis PR is not unverified AI output, I take responsibility for it, and all communication from my side in this PR is done by me personally.来自 Developers 组之外的 PR 会被标记Unverified标签以辅助排查潜在违规经过几次成功贡献后新贡献者会被加入相应组也可主动请求提前加入政策同时提醒贡献者关注 AI 在特权、环境、版权、社会及开源社区层面的负面影响并鼓励了解 frugal AI 与全开放 AI 模型等替代方案。10. 给贡献者的实操建议面向本仓库结合以上规则如果你准备向本仓库提交第一个 PR可遵循如下落地清单先在 GitHub issue 追踪器上描述问题就问题定义与解决价值达成共识后再动笔保持 PR 小而聚焦一个 PR 只解决一个问题避免引入新依赖保证每个 commit 都能独立编译把杂乱的检查点 commit squash 掉提交信息遵循 git 官方规范用标题概括、正文补充修改 UI 时必须附 before/after 截图PR 模板的 Before and After Images 小节已给出占位涉及 Python API 破坏时在 PR 中列出受影响的插件与替代方案涉及 GUI 变更时让 Design Working GroupDWG知晓涉及标准与工作流时让 CAD Working GroupCWG知晓模板 Notes on the PR Review Process 一节对此有完整说明若使用 AI 辅助在 PR 描述中如实披露并按上述格式在 commit 中加Assisted-bytrailer想进入 Credits 名单修改 src/Doc/CONTRIBUTORS 并提交一个只含该修改的独立 commit合并后由你创建的 issue 记得关闭。11. 总结FreeCAD Contribution Process 是一套以C4 / Fork and Pull 模型为哲学基础、以单 main 分支 PR 审查 快速合并有效贡献为操作特征的治理框架。它的核心张力在于既要通过 16 条严格标准编译、测试、风格、署名、API 兼容、AI 政策保证代码质量又要通过维护者必须快速合并有效 PR不得对正确贡献做价值判断等条款保证贡献者的参与体验与公平性。无论你是想修一个 bug、实现一个功能还是参与工作台维护理解这份文档都是你融入 FreeCAD 开发者社区的第一步。【免费下载链接】FreeCADOfficial source code of FreeCAD, a free and opensource multiplatform 3D parametric modeler.项目地址: https://gitcode.com/GitHub_Trending/fr/FreeCAD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考