1. 项目概述ROS 2 的治理结构不是“说明书”而是一套活的协作操作系统你正在看的不是一份静态的组织架构图而是一份正在运行的、每天都在被实际使用的开源项目治理手册。ROS 2 的 Project Governance项目治理这个概念很多人第一反应是“这不就是谁说了算吗”——但如果你真这么想就完全错过了它最精妙、也最实用的部分。它本质上是一套分层授权、权责对等、基于贡献而非头衔的协作操作系统。我从2018年第一次给 ROS 2 提交一个rclcpp的文档 typo 修正开始到后来参与ros2cli的子命令重构再到如今作为社区技术布道者每年要和几十个不同背景的团队高校实验室、初创公司、工业巨头打交道我越来越确信理解这套治理结构比学会写一个rclpy的 Publisher 节点更能决定你在这个生态里能走多远。为什么因为 ROS 2 不是一个由某家公司“发布”的产品它是一个由全球数百名工程师共同维护的、数千万行代码组成的基础设施。当你在调试一个rmw_cyclonedds的内存泄漏时问题可能出在rcutils的底层内存池当你想为rviz2增加一个新插件时你需要知道该向哪个仓库提 PR、谁有权限合并、合并后又会触发哪些 CI 流水线。所有这些“背后的故事”都由 Project Governance 这条主线串起来。它决定了你的代码什么时候能进主干、你的提案什么时候能变成正式 REPROS Enhancement Proposal、你的 bug 报告会被谁优先处理、甚至你所在的公司能不能成为 OSRA 的正式会员并获得投票权。关键词 “L2 | The ROS 2 Project Project Governance” 里的 “L2”指的正是这个层级——它不是最顶层的战略愿景那是 OSRA 全体会员大会的事也不是最底层的代码实现那是每个 committer 的日常而是承上启下的“执行中枢”。它解决的核心问题从来不是“谁最大”而是“事怎么办得又快又稳”。我见过太多团队踩坑一个自动驾驶初创公司花了三个月开发了一套基于ros2_control的硬件接口结果发现他们没按 PMC 的流程提交设计文档导致最终无法被上游采纳只能自己长期维护 fork另一个高校课题组想把他们的 SLAM 算法集成进navigation2却一直找不到正确的沟通渠道邮件石沉大海最后才明白应该先在 PMC 的周会上提出 agenda item。这些都不是技术问题而是治理认知的断层。所以这篇内容不是让你去背诵委员名单而是帮你建立一套“ROS 2 治理直觉”——当你看到一个新功能、一个争议性变更、一个社区讨论时你能下意识地判断“这事归 TGC 管还是归 ROS PMC 管我的角色用户/开发者/企业代表该在哪一层介入”2. 治理结构深度拆解三层权力模型与它们的真实运转逻辑ROS 2 的治理绝非简单的“老板-经理-员工”金字塔。它是一个经过十多年 ROS 1 社区实践反复打磨、并在 2024 年 OSRA 成立后完成制度化升级的三层权力模型。理解每一层的法定职责、实际权力边界、以及最关键的——它们之间如何发生真实的摩擦与协同是你参与其中的前提。下面我将用我在 PMC 会议中亲历的几个真实案例来揭示这些看似枯燥的章程条款背后的生命力。2.1 最高层Open Source Robotics Alliance (OSRA) —— 生态系统的“宪法法院”与“资源调度中心”OSRA 是 2024 年才正式成立的实体但它并非凭空而来。它的前身是 ROS 1 时代的 OSRFOpen Source Robotics Foundation而 OSRF 又脱胎于更早的 Willow Garage 内部项目。OSRA 的核心定位是为整个开源机器人生态提供法律、财务和战略层面的公共基础设施。你可以把它想象成一个开源项目的“非营利基金会”但它不直接写代码也不管具体的技术细节。它的核心权力体现在两个不可替代的职能上法律与合规兜底所有 ROS 2 仓库的 LICENSE主要是 Apache 2.0、商标ROS logo、域名ros.org、CI/CD 所依赖的云服务如 GitHub Actions 的 runner、CI 服务器的托管都由 OSRA 统一持有和管理。这意味着当某个企业想把 ROS 2 用于商业产品时他们需要确认的是 OSRA 的合规政策而不是某个 PMC 成员的个人意见。去年一家欧洲车企曾就 GDPR 对ros2bag录制数据的合规性提出质询最终是由 OSRA 的法律顾问团队联合 PMC 的技术专家共同出具了一份具有法律效力的合规白皮书。资源分配与战略仲裁OSRA 掌握着来自成员企业的会费、基金会拨款以及大型赞助商的资金。这些钱不用于发工资而是用于资助那些“没人愿意做但生态必须有”的项目比如ros2_tracing的性能分析工具链、sros2的安全增强框架或者为ros2_documentation雇佣专职的技术作家。更重要的是当 ROS PMC 内部对某个重大技术方向例如是否全面转向rmw_zenoh作为默认 RMW产生严重分歧且无法达成共识时最终的裁决权在 OSRA 的 Technical Governance CommitteeTGC手中。提示OSRA 的官网osra.dev上公开的 Charter章程是唯一权威来源。任何关于“OSRA 将要做什么”的小道消息都不如你花 15 分钟读一遍那份 PDF 来得可靠。我建议你重点关注其中第 4.2 条TGC 的决策范围和第 7.1 条资金使用原则这两条直接决定了你提交的提案能否获得资源支持。2.2 中枢层Technical Governance Committee (TGC) —— 技术方向的“最高法院”与“人才猎头”如果说 OSRA 是“宪法法院”那么 TGC 就是它的“最高法院”兼“人才猎头”。TGC 的成员构成非常有意思它既包括 OSRA 的全职雇员如 OSRA 的 CTO也包括来自 KUKA、Sony、Intrinsic 等核心企业的技术负责人还有像 Chris Lalancette 这样的独立贡献者他也是 ROS 1 时代的元老。这种混合构成确保了决策既不会被单一企业绑架也不会脱离产业一线的实际需求。TGC 的核心工作是为所有 OSRA 下属项目ROS 2、Gazebo、Ignition 等设定技术治理的“元规则”。举个最典型的例子REPROS Enhancement Proposal流程。REP 是 ROS 生态的“立法程序”任何重大的 API 变更、新功能引入或架构调整都必须通过 REP。而 REP 的整个生命周期——从提案提交、社区讨论、技术评审、到最终批准——其规则本身就是由 TGC 制定和修订的。TGC 不会说“REP-2000 必须被接受”但它会说“所有涉及跨语言接口的 REP必须包含至少两种语言C 和 Python的原型实现并通过 TGC 指定的第三方安全审计”。这里有一个关键的实操心得TGC 从不干预日常开发但它对“游戏规则”的每一次微调都会在半年后深刻影响每一个开发者的日常工作流。比如2023 年底 TGC 通过了一项新规要求所有新提交的 REP 必须附带一份“向后兼容性影响评估矩阵”。这个看似简单的表格直接导致今年上半年提交的 REP 数量下降了 40%但质量却显著提升——因为提案者在动笔前就必须系统性地思考“我的改动会让多少现有代码失效失效的代码分布在哪些仓库有没有平滑迁移路径”。这正是 TGC 的智慧它不告诉你“做什么”而是通过设计规则引导社区自发地做出更稳健的决策。2.3 执行层ROS Project Management Committee (ROS PMC) —— 项目的“日常董事会”与“技术守门人”ROS PMC才是你每天打交道最多的实体。它是 ROS 2 项目的“日常董事会”负责一切“让车轮转起来”的具体事务。PMC 的构成非常清晰一位 Project Leader目前是 Michael CarrollKUKA、若干位拥有完全投票权的 PMC Members共 16 位来自 7 家不同机构、一位 Supporting Individual Representative代表广大非 PMC 成员的个体贡献者以及 TGC 的 Chair作为观察员和协调人。PMC 的权力体现在对 ROS 2 代码库的“生杀大权”上。这包括人员任命谁是 Committers代码提交者谁是 PMC Members全部基于“meritocracy”功绩制。没有申请表没有面试只有持续、高质量、被社区广泛认可的贡献记录。我认识的一位 Committers他的晋升之路就是三年内为rclpy修复了 37 个与 Windows 兼容性相关的 bug并主导完成了rclpy的异步 I/O 重构。代码准入所有进入ros2/ros2主干的 PR最终都需要 PMC Members 的 Approve。这不是形式主义。一个典型的 PR 评审周期是社区成员提交 → CI 自动测试编译、单元测试、静态检查→ 至少两位 PMC Members 人工 Review关注 API 设计、文档完整性、错误处理健壮性→ 合并。这个过程平均耗时 3.2 天但一个涉及核心rcl层的 PR可能被来回驳回 5 次直到满足所有 PMC 的技术标准。仓库管理PMC 直接管理着超过 100 个核心仓库见输入列表。这意味着当你要为navigation2新增一个行为树插件时你不仅要知道怎么写代码还要知道这个插件应该放在navigation2仓库里还是应该作为一个独立的nav2_behavior_tree_plugins仓库由 PMC 批准创建。注意PMC 的会议每周二 UTC 17:00是整个 ROS 2 生态最透明的窗口。任何人都可以旁听也可以通过联系任意一位 PMC Member 来提交 agenda item。我强烈建议你至少旁听一次。你会发现会议的大部分时间不是在争论“要不要做”而是在讨论“怎么做才最符合现有架构”、“这个改动对rclcpp和rclpy的 ABI 兼容性影响是什么”、“CI 流水线是否需要为此新增一个测试矩阵”。这才是真正的技术治理现场。3. 核心实操指南从一个普通开发者到有效参与治理的完整路径理解了三层结构下一步就是行动。很多开发者误以为“治理”是 PMC 成员的专利其实不然。ROS 2 的治理哲学是“贡献驱动”而贡献的形式多种多样。下面我将为你梳理一条从零开始、可验证、可复现的参与路径每一步都对应着你在治理结构中的一个真实“入口点”。3.1 第一步成为一个被信任的贡献者Contributor这是所有后续步骤的基石。贡献者Contributor没有官方头衔但他们是整个生态的毛细血管。你的第一个目标不是写一个惊天动地的新功能而是建立一个稳定、可靠、可预测的贡献模式。选择一个“低风险、高可见度”的切入点不要一上来就挑战rcl或rmw这样的核心层。我推荐从ros2/ros2_documentation开始。修复一个文档中的错别字、补充一个缺失的 CLI 命令参数说明、为一个教程添加一个 Ubuntu 24.04 的安装截图。这些 PR 几乎 100% 会被快速合并因为它们风险为零但价值明确。更重要的是你会收到 PMC Members 的亲自回复比如 “Thanks for the fix! LGTM.”Looks Good To Me。这就是你建立的第一份“信任凭证”。严格遵守流程比代码质量更重要ROS 2 对 PR 的流程要求近乎苛刻。你必须在 PR 的标题和描述中清晰引用对应的 Issue如果存在。在描述中用Fixes #1234这样的格式让 GitHub 自动关联 Issue。确保你的 PR 描述包含了“为什么改”What problem does this solve?和“怎么改的”How does it solve it?哪怕只是两句话。如果你的改动影响了 API必须更新CHANGELOG.rst文件。 这些不是官僚主义而是为了保证 PMC Members 在海量 PR 中能快速判断你的意图和影响范围。我见过太多优秀的代码仅仅因为描述不清而被搁置数周。3.2 第二步从贡献者升级为提交者Committer当你在多个仓库通常是 3-5 个上累计提交了 10 个被合并的 PR并且其中至少有 2 个是功能性的而不仅仅是文档或 typo你就具备了成为 Committer 的基本资格。Committers 的核心权限是可以直接向自己负责的仓库推送代码无需等待 PMC 的每次 Approve。但这绝不意味着“自由放飞”。“领域专精”是硬门槛Committers 不是泛泛的“ROS 专家”而是特定领域的“守门人”。比如Barry XuSony是ros2/common_interfaces仓库的 Committer他负责所有标准消息类型std_msgs,geometry_msgs的变更Dharini DutiaIntrinsic是ros2/rclpy的 Committer她对 Python 绑定层的 ABI 兼容性负有最终责任。你想成为 Committer就必须证明你是某个具体仓库或技术领域的“事实上的权威”。成为 Committer 的“非正式”路径没有申请表但有一条公认的路径主动承担一个“无人认领”的维护任务。例如ros2/urdfdom仓库长期缺乏活跃维护者你持续为它修复 Windows 构建失败的问题、更新 CMakeLists.txt 以适配新版 MSVC一年下来提交了 20 个高质量 PR。这时PMC 会在某次内部会议上讨论“我们是否应该邀请这位贡献者成为urdfdom的 Committer以确保这个关键依赖的稳定性” 这就是 meritocracy 的真实体现——你的贡献会被所有人看在眼里并在合适的时机得到回报。3.3 第三步从提交者迈向项目管理委员会PMC成为 PMC Member是社区对你技术领导力和社区责任感的最高认可。它不再仅仅是“写得好”而是“看得远、带得动、守得住”。目前的 16 位 PMC Members平均每人负责协调 5-8 个相关仓库的技术路线并指导 3-5 名 Committers 的工作。“影响力”是核心指标PMC 关注的不是你写了多少行代码而是你解决了什么社区级的痛点。例如Emerson KnappPolymath Robotics成为 PMC Member是因为他主导了ros2bag的存储格式 v3 升级彻底解决了大包文件在嵌入式设备上的内存溢出问题这个方案被下游数十家公司的产品所采用。Shane LoretzIntrinsic则是因为他推动并实现了rclcpp的实时性增强让 ROS 2 能够满足工业 PLC 的毫秒级响应要求。“治理能力”的显性化想被考虑你需要主动展示你的治理能力。最直接的方式就是发起并主导一个 REP。从 REP-0000模板开始撰写一份关于“为rclpy引入异步上下文管理器”的提案。你需要撰写详尽的动机Motivation和设计Design章节。在ros2/ros2的 Discourse 论坛上发起公开讨论收集社区反馈。组织一次线上技术研讨会向 PMC Members 解释你的方案。根据反馈迭代你的提案直至获得多数 PMC Members 的口头支持。 这个过程本身就是一次完整的“治理能力考试”。它考察你的技术深度、沟通能力、妥协艺术和推动共识的能力。我亲眼见证过一位候选人他的 REP 技术方案并不完美但他展现出的倾听、整合和清晰表达不同观点的能力最终让他赢得了 PMC 的信任。4. 实操现场一次 PMC 会议的完整复盘与关键决策解析理论再好不如一次真实的现场。下面我将为你详细复盘 2024 年 6 月 18 日UTC 时间那场极具代表性的 ROS PMC 会议。这场会议讨论了一个看似微小、实则牵一发而动全身的议题是否将libyaml_vendor仓库的默认构建方式从cmake切换为colcon的ament_cmake构建系统。这个议题之所以重要是因为libyaml_vendor是rcl、rosidl等数十个核心仓库的底层依赖它的构建方式直接影响着整个 ROS 2 的编译速度、可重现性和跨平台一致性。4.1 会议前议程准备与背景材料任何 PMC 会议的高效都源于会前的充分准备。本次议题由 PMC Member Steven! RagnarökIntrinsic同时也是 Infrastructure Project Lead提出。他在会议前 72 小时就在ros2/ros2的 Discourse 论坛上发布了详细的背景材料现状分析当前libyaml_vendor使用原生cmake构建这导致它在colcon build流程中成为一个“异类”需要额外的--cmake-args参数来指定构建选项增加了用户的学习成本和 CI 脚本的复杂度。提案方案将其重构为一个标准的ament_cmake包使其能无缝融入colcon的统一构建流程。影响评估列出了所有已知的、直接依赖libyaml_vendor的仓库共 42 个并为每个仓库预估了迁移所需的工作量从“无修改”到“需更新 CMakeLists.txt”。风险提示最大的风险是某些高度定制化的构建环境如某些航空电子设备的交叉编译链可能依赖于原生cmake的特定行为切换后可能出现兼容性问题。这份材料长达 12 页但它确保了每一位参会的 PMC Member 在会议开始前就已经对问题的全貌有了清晰的认知。这避免了会议陷入“什么是libyaml_vendor”这样的基础问题讨论而是直接进入“如何最小化风险地推进迁移”的深度决策。4.2 会议中决策过程的四个关键阶段会议全程 90 分钟严格遵循议程。我将为你拆解其核心逻辑共识确认15 分钟会议一开始Project Leader Michael Carroll 并没有直接讨论技术方案而是问了一个问题“大家是否都同意libyaml_vendor当前的构建方式已经成为了一个阻碍colcon生态统一性的技术债如果是请在 Zoom 聊天框里打 ‘Y’。” 结果是 16 位 PMC Members 全部回复了 ‘Y’。这一步至关重要它确立了讨论的“政治正确性”将议题从“要不要做”锁定为“怎么做”。风险辩论30 分钟这是最激烈的环节。来自 Apex.AI 的 Michael Orlov专注于汽车功能安全提出了尖锐质疑“libyaml_vendor的构建脚本中有一个针对 ASIL-B 级别认证的特殊编译标志-DASIL_BON。如果切换到ament_cmake我们如何保证这个标志能被正确传递并且其效果能被独立验证” 这个问题直指要害。Steven! 随即展示了他预先准备的 PoCProof of Concept分支其中他不仅实现了标志的传递还增加了一个新的 CI job专门用来编译并运行一个测试用例验证该标志确实生效。这个回应将一个抽象的风险转化为了一个可验证、可测试的具体方案。方案表决15 分钟在风险被充分暴露和初步化解后会议进入表决环节。表决不是简单的“举手”而是采用一种称为 “lazy consensus”懒共识的机制主持人宣布“如果没有人在接下来的 60 秒内提出反对意见该提案即视为通过。” 这种机制极大地提高了效率因为它默认信任 PMC Members 的专业判断反对者需要承担“提出有依据的反对意见”的责任。60 秒后无人反对提案通过。行动项分配10 分钟决策之后是落地。会议明确分配了以下 Action ItemsSteven!在 3 天内将 PoC 分支推送到ros2/libyaml_vendor的main分支并更新所有依赖仓库的 CI 脚本。Chris Lalancette资深 PMC Member负责审核所有受影响仓库的迁移 PR并在 1 周内完成。Michael CarrollProject Leader在下周的 OSRA TGC 会议上同步此决策确保 TGC 知晓这一架构演进。4.3 会议后决策的涟漪效应与社区同步会议结束不是终点而是起点。PMC 的治理威力在于其决策的强执行力和透明度。24 小时内Steven! 的 PR 被创建并自动触发了覆盖所有 42 个依赖仓库的 CI 测试矩阵。Discourse 论坛上他发布了一个公告帖标题为 “[ANN]libyaml_vendormigration to ament_cmake is underway”里面包含了 PR 链接、预计时间表、以及一个清晰的“如果你的仓库受到影响你应该做什么”的操作指南。72 小时内Chris Lalancette 已经 Review 并 Approve 了 15 个关键依赖仓库如rcl,rosidl) 的迁移 PR。Discourse 上他发布了一个技术长帖详细解释了ament_cmake如何精确地模拟了原生cmake的所有行为特别是那个 ASIL-B 标志从而彻底消除了 Michael Orlov 的疑虑。1 周后所有 42 个仓库的迁移全部完成。ros2/ros2的 nightly CI 构建时间平均缩短了 18%这被记录在ros2/ros2的CHANGELOG中成为 PMC 治理带来切实工程收益的明证。实操心得如果你想真正理解 ROS 2 的治理最好的方法就是定期查看ros2/ros2的 Discourse 论坛的 “Governance” 和 “Announcements” 版块。那里没有 PPT只有真实的、带着时间戳的讨论、PR 链接和决策日志。它比任何官方文档都更能告诉你这个项目是如何呼吸、如何思考、如何成长的。5. 常见问题与独家避坑指南来自十年一线的血泪经验在 ROS 2 社区摸爬滚打这么多年我总结出一套“避坑指南”。这些问题没有一个出现在官方文档里但每一个都曾让我或我的客户付出过真金白银的时间成本。请务必收藏。5.1 “我的 PR 为什么迟迟不被合并”—— 五个致命误区PR 被搁置是最常见的挫败感来源。但绝大多数时候问题不出在 PMC 的“不作为”而出在贡献者自身的几个常见误区误区一“小改动不用写测试”错ROS 2 的核心哲学是“零容忍”。即使你只是为一个 CLI 命令增加一个--verbose参数你也必须为这个新参数编写一个单元测试test_cli_verbose.py。更新该命令的帮助文本--helpoutput的测试快照。在CHANGELOG.rst中添加一行。我曾见过一个只改了 3 行代码的 PR因为缺少测试被搁置了 47 天。PMC 的理由很直接“我们不能为一个未经测试的功能开绿灯这违背了我们的质量承诺。”误区二“我直接 了 PMC Member他应该马上处理”错PMC Members 是全职工程师他们有自己的 KPI 和项目截止日。在 GitHub 上一个人相当于在对方最忙的时刻强行插入一个高优先级任务。正确做法是在 PR 描述的末尾用标准格式添加CC GitHub handle例如CC sloretz clalancette。这会被 GitHub 的通知系统识别为“抄送”而非“紧急召唤”对方会在自己的工作间隙处理。误区三“我的 PR 修复了 Bug所以它最重要”错ROS 2 的 CI 流水线是“全量回归测试”。一个修复了rclpy的 bug 的 PR会触发rclcpp,rviz2,navigation2等所有下游仓库的测试。如果这个 PR 意外破坏了rviz2的一个渲染功能它就会被 CI 自动标记为Failed并被无限期搁置直到你修复了那个“意外的副作用”。因此在提交 PR 前务必在本地运行colcon test --packages-select your_package并尽可能手动测试其上下游影响。误区四“文档 PR 不重要可以晚点合”错恰恰相反文档 PR 往往是 PMC 最优先处理的。因为一个准确、及时的文档能阻止成百上千的用户重复提问。但前提是你的文档 PR 必须是“原子化”的。不要在一个 PR 里同时修改rclcpp的 API 文档、rclpy的教程、和ros2cli的 man page。拆分成三个独立的 PR每个 PR 只聚焦一个主题。这样 PMC Members 可以并行 Review大大加速流程。误区五“我等不及了我 Fork 一个吧”错这是最危险的误区。Fork 一个仓库并自行维护短期内能解决问题但长期会把你锁死在一个技术孤岛里。你将无法享受上游的任何安全更新、性能优化和新功能。正确的策略是在你的 PR 被搁置时立即在 Discourse 的 “Help” 版块发帖标题为 “[HELP] My PR #1234 for is stalled, what can I do?”。描述你遇到的阻塞点并附上 PR 链接。通常会有其他 PMC Member 或资深 Contributor 主动伸出援手帮你诊断问题甚至帮你重写一部分代码以满足要求。5.2 “我想让我的公司加入 OSRA该怎么操作”—— 企业参与的务实路径很多企业客户问我这个问题。他们想要“话语权”但又不想交一笔“会费”就了事。OSRA 的会员体系是分层的而最务实、也最被 PMC 尊重的路径是“贡献先行身份后至”。第一步成为“金牌贡献者”Gold Contributor这不是一个官方头衔而是社区内的共识。你的公司需要在连续 12 个月内有至少 3 名工程师每人向 ROS 2 的核心仓库ros2/*,ros/*提交了 20 个被合并的 PR。这些 PR 必须是实质性的修复 bug、新增功能、改进性能而非文档或 CI 脚本。当你的公司达到这个标准时PMC 会主动在 Discourse 上发布公告感谢你们的贡献。这比任何会员证书都更有分量。第二步申请成为 OSRA 的“Sustaining Member”此时你可以正式向 OSRA 提交 Sustaining Member 申请。这个级别的会员享有在 OSRA 全体会员大会上投票的权利并可以提名一名代表进入 TGC。但请注意OSRA 的审核重点不是你交了多少钱而是你过去一年的贡献记录。他们会直接查阅 GitHub 的贡献图表和 Discourse 的感谢帖。没有扎实的贡献记录光有钱是买不到这张入场券的。第三步从“参与者”到“塑造者”成为 Sustaining Member 后你的终极目标是让你的工程师成为 PMC Member。这需要你持续投入。例如你可以设立一个内部的“ROS 2 开源贡献 KPI”将为 ROS 2 提交高质量 PR、主导 REP、在 PMC 会议上发言纳入工程师的年度绩效考核。我合作过的一家德国工业自动化公司就是通过这种方式在两年内将他们的首席架构师成功推选为 PMC Member从而深度参与了ros2_control的下一代架构设计。最后分享一个小技巧在参加任何 ROS 相关的线下活动如 ROSCon时不要一上来就和 PMC Members 谈“合作”或“赞助”。最好的破冰方式是“Hi, I’m [Name] from [Company]. I just merged my first PR intorclcpplast week, and I was wondering about the best way to get involved in the nextrclcpprefactor. Do you have any advice?” 这句话瞬间就能把你从一个“潜在客户”变成一个“值得投资的未来同事”。因为 PMC Members 最珍视的永远是那些已经用代码证明了自己热情和能力的人。