以真实贡献、开放协作和长期维护，形成可持续的技术社区。
社区以共同解决技术问题、积累可复用成果和培育贡献者为目标。技术判断以问题价值、证据、质量与可维护性为依据，尊重不同经验和技术路线。
社区规则适用于各项目的共同协作；具体项目可以制定附则，说明其技术范围、交付和验证要求，并与本公约保持一致。
- 个人、团队和机构均可参与交流与贡献；社区重视实际工作和持续责任〔01.1〕。
- 资源、赞助与商业合作可以支持社区发展，不自动换取技术决策权〔01.2〕、项目背书或发布资格。
子午约定子午社区与项目附则的适用关系，以及赞助不自动产生本社区背书和发布资格，为子午约定。
公开开源成果依许可证开放；正式共建先确认共同规则与参与范围。
任何人均可在相应公开入口使用项目、提出问题、参与讨论或提交贡献〔02.1〕。已公开开源的代码与资料依各自许可证使用、修改和分发，包括许可证允许的商业使用，均不以加入社区为前提〔02.2〕。
拟开展正式共建、深度技术协作或申请访问未公开材料的参与方，应先认可公约并完成入社确认。正式合作可根据需要确认参与身份、所属机构或代表授权、联系方式、贡献方向及资料权限；收集的信息仅用于必要的协作与管理。
- 入社不自动授予全部资料、仓库或基础设施的访问权。
- 未入社的合作沟通仅限已公开材料与经授权的口头介绍，不提供未公开书面材料；已公开开源内容不受此项限制。
- 不得以入社、缴费、赞助或另签社区协议作为行使既有开源许可证所授予权利的附加条件〔02.3〕；许可证本身的义务仍须遵守。
子午约定正式共建先认可公约并入社、身份与授权确认、未入社的资料交流边界，均为子午约定；公开开源内容按各自许可证处理。
贡献不只包括代码；可复核的工作与持续维护同样重要。
社区认可代码与工程实现〔03.1〕、数据处理、任务与评测设计、实验验证、问题反馈、评审、文档、答疑〔03.2〕和社区协调等贡献。评价应结合质量、实际采用、持续性与协作责任，避免以单一数量指标代替判断。
每项正式共建应说明所解决的问题、交付范围、负责人、来源和使用权限，以及计划采用的验证方式。重要贡献应保留可追溯的交付与评审记录，真实呈现各参与方的工作。
- 提出想法、提供设备和资源、组织交流均可得到相应认可；是否形成组件交付，应依据实际成果判断。
- 尊重已有作者和第三方成果，注明适用的引用、署名与许可证要求。
- 使用辅助工具不免除提交者对贡献质量与测试的责任〔03.3〕；提交者还须对来源与表述真实性负责。
子午约定数据、任务、实验等贡献类别、正式共建记录要求，以及提交者对来源与表述真实性的责任，结合子午项目实践制定；贡献认可不自动等同于联合发布资格。
协调人帮助协作，维护者对成果负责；权限随责任授予。
社区协调人负责组织沟通〔04.1〕、参与确认、规则维护与跨项目协调。项目维护者负责相应领域的技术评审〔04.2〕、交付验收、版本维护与贡献者支持；具体职责、负责范围与权限应有记录〔04.3〕。
角色与权限依据持续贡献、专业判断、协作表现和实际承担的责任授予〔04.4〕，并根据参与情况调整。授权应满足实际工作需要；角色变动、长期离开或不再承担职责时，应完成相应交接与权限调整。
- 授权属于承担职责的个人，不因任职机构或赞助金额自动获得〔04.5〕，也不随机构内部人员变动自动转移。
- 赞助与资源提供方可以提出建议，技术取舍仍按贡献、证据与项目需要决定〔04.6〕。
- 涉及本人、任职机构或直接合作方的资格认定、资源分配与争议裁决时，应披露相关关系并按事项回避。
子午约定社区协调人与项目维护者的具体设置、授权调整、利益关系披露及回避流程，为子午约定。
重要事项书面讨论，优先形成共识；关键成果由非作者复核。
日常事项由相应负责人在授权范围内推进。重要技术方向、跨项目安排、关键规则及其他重大事项，应先形成书面提案（RFC），说明问题、目标、方案、替代选择〔05.1〕、影响与负责人，并留出适当讨论机会〔05.2〕。
决策以共识为先；必要时采用表决〔05.3〕，应事先公布该事项的表决资格、范围与程序，由无利益冲突且有表决资格的维护者过半同意通过，并记录理由、异议与结果。适合公开的结论和依据应公开〔05.4〕；涉及受限信息的记录按其权限保存。
- 关键交付须有明确负责人，并至少由一名非作者完成复核；复核应覆盖适用的接口、来源、测试或验证证据。
- 评审意见应针对成果与证据，作者应回应意见、修订或说明保留理由〔05.5〕。
- 紧急处理须记录原因、决策人及影响，并及时补充复核和必要的修复。
子午约定表决资格与无利益冲突维护者过半规则、关键交付负责人加至少一名非作者复核，以及受限记录边界，均为子午约定，不是上述项目规则的照搬。
原有权利归属不因入社改变，资料共享依据明确授权。
加入社区、参加讨论或提交贡献，不自动转让既有知识产权。贡献的使用、修改、分发与公开方式，应遵循相应许可证、权利人的授权及明确约定；代码、数据、模型、文档等可具有不同的授权条件。贡献者应确认自己有权提交相应材料，并在需要时取得雇主或其他权利人的授权〔06.1〕。
资料分为公开、受限和机密。公开资料按已公布的条件使用；受限资料仅供获授权人员在约定范围内使用；机密资料须有明确的保密范围和接触授权。资料提供方应说明类别与共享条件，接收方不得未经许可转发、公开或扩大用途。
- 未说明公开权限的非公开资料，应先确认授权再分享；入社身份不能代替资料授权。
- 正式合作涉及保密、专有交付或商业安排时，另行明确约定；商业合同和赞助不自动购买社区技术背书或联合发布资格。
- 发布前确认第三方权利、许可证与必要署名；本公约不替代各项目许可证，也不改变已合法获得的许可权利，包括许可证允许的商业使用。
- 项目应说明贡献进入项目时的授权与对外发布时的许可证；是否采用 DCO、CLA 或其他贡献确认机制，应另行明确〔06.2〕，不因引用其他社区规则而自动采用。
子午约定权利归属、公开／受限／机密分类、具体授权与保密范围、合同及发布资格边界，均为子午自行约定，并受各成果已有许可证和有效授权约束。
联合发布以实际组件贡献为基础，署名与对外表述应对应事实。
以子午社区或项目名义开展联合发布，参与方须有已交付、可核验且被共同成果实际采用的组件贡献，并完成相关验收与发布授权。联合发布前，应共同确认贡献清单、采用范围、验证结论、署名和对外表述。
社区及项目名称、标识和官方背书应依相应授权使用〔07.1〕，不得因入社、参会或赞助而声称获得官方推荐、认证或联合发布资格。引用和事实性介绍应真实、准确，不制造未经授权的关联〔07.2〕。
- 组件贡献可以是代码、数据处理、任务图、推理与执行、评测、仿真或真机验证等被实际采用的交付。
- 仅提供资金、设备、算力、场地或一般交流支持，可按事实获得支持署名或致谢，不自动构成联合发布资格。
- 本条不限制既有开源许可证允许的使用、修改与分发，也不剥夺作者或第三方依法、依许可证应有的署名与权利。
- 社区或项目的官方成果说明须区分已实现、已验证和待研究内容，不夸大合作关系或技术能力。
子午约定实际组件贡献、采用和验收作为联合发布条件，支持署名与联合发布的区分，以及子午和项目的品牌授权流程，均为子午约定。
对事讨论，保护隐私；处理有依据、有回避、有复核。
成员应尊重不同背景与观点，建设性地提出批评，不得骚扰、歧视、人身攻击、威胁、泄露他人私人信息〔08.1〕或报复善意举报。本条适用于社区沟通渠道、项目协作、活动及代表社区开展的对外交流。〔08.2〕
举报和争议应由未涉事、无利益冲突的负责人员受理；在必要范围内核实事实，保护举报人及相关人员隐私〔08.3〕，听取当事人说明，并采取与情节和影响相称的措施〔08.4〕。正式受理方式与负责角色应在公约实施前公布。
- 处置可包括沟通纠正、警告、限制访问或协作权限、暂停或终止参与〔08.5〕；应说明依据〔08.6〕和适用范围。
- 当事人可申请由未参与原处理且无利益冲突的人员复核；不得由被举报者单独受理或裁决相关事项。
- 成员可退出；承担维护职责或保管社区资料、账号与资源的，应完成必要交接和权限处理，继续遵守已有保密及许可义务。
- 退出或权限调整不抹除真实贡献记录，也不追溯剥夺已合法取得的许可和署名权利。
子午约定利益冲突回避、陈述与复核、退出交接和既有权利保护，以及正式受理方式的公布要求，为子午约定。
规则随实践改进，修订留痕，既有权利得到尊重。
本版本为讨论稿 v0.1，用于形成社区共识。正式实施、后续修订和项目附则调整，应通过书面提案与适当讨论，按本公约的决策机制确认，并公开版本、变更内容与适用时间。
修订应解释目的和影响；涉及既有合作安排时，应明确过渡方式。不得以单方面修改公约追溯剥夺已合法获得的许可、署名或其他既有权利。
- 保留重要决策、修订理由〔09.1〕与异议记录，使成员能够理解规则变化。
- 项目附则应明确适用项目，不将某一项目的技术要求自动扩展为全社区要求。
子午约定讨论稿状态、版本管理、实施与过渡安排、项目附则适用边界及不追溯剥夺既有权利，为子午约定。
