OpenV2X 社区章程正式颁布

本章程在OpenV2X 第一届董事会议，经董事会投票讨论、修改、表决通过，特此颁布正式章程。

本文档为OpenV2X 社区章程和治理框架，描述OpenV2X 社区协作机制，以便为企业和贡献者加入 OpenV2X 项目提供公平的环境和开放的流程。

一、OpenV2X 社区愿景

技术愿景

OpenV2X 开源项目基于开放源码方式，整合5G、C-V2X、AI、MEC等技术组合，支持海量路侧信息收集、融合、智能运算和云边协同能力，遵循国际 V2X和“新四跨”协议的标准接口定义，具备厂商兼容、接口透明、生态开放的能力，解决当前C-V2X车路协同系统（Cooperative Vehicle Infrastructure System, CVIS）中路侧系统遇到的 “平台不开放”、“生态不多样”、“算法不解耦”、“5G 未联动”的问题，构建未来5G/6G网络下路侧开放基础架构（Road Side Open Infrastructure，RSOI）的事实标准，更好地服务智能的车和行动的人。

产业愿景

通过围绕构建满足智能汽车实际使用需求、符合国内/国际标准接口、具备实际落地运营能力、面向未来技术路线的架构为核心，按照自愿、公平、透明、开放的原则进行组织和运作，吸纳并理解智慧汽车制造企业、智慧道路管理方、路侧公共基础设施运营方的需求，整合路侧设备厂商、电信运营商、应用开发商、研发机构、服务商和产业组织在内的产业力量，落地为主，完全开放，适当超前，共筑互利共赢的路侧开放基础架构开放生态。

开放协议

OpenV2X 将遵循 Apache V2.0开源协议开放。

托管机制

OpenV2X 源码将同时托管在Gitee和Github上。

二、项目范围治理

OpenV2X 项目主要致力于路侧开放基础设施的模块，车侧的相关能力实现原则上不包含在 OpenV2X项目范围中。

OpenV2X 项目定位可以随着未来需求变化而演进，相关具备新功能子项目将开放给社区，由开发者自由发起，成为孵化期项目（Incubation Project）。但是从孵化期项目转换为社区正式项目（Official Project），将由社区技术委员会（TSC）投票决定。

- OpenV2X 未来一年的项目范围和目标架构

中心侧：

▪统一管理界面：Central Portal: 用于统一整合、管理和呈现所有边缘数据的中心管理平

5G MEC 边缘侧：

▪边缘管理界面 Edge Portal：用于单个5G MEC机房、覆盖区域性多个路口的二级管理界面

▪边缘设备管理服务 Device Management ：部署都在单个5G MEC机房中，用来路侧设备RSE的信息、状态和配置的服务

▪边缘数据流式服务 Data Processing Flow：用来处理路侧信息融合、预警的数据处理模块、包含数据转换(Transsform Driver)、预处理算法（Pre-process Algorithm）、特定领域算法（Specific Algrithm）和后处理算法（Post-process Algorithm）四个插件式算法模块以及相应第三方驱动和算法库。

▪消息服务MQ Server：用来接受和处理RSE、RSU等结构化数据，数据遵循“新四跨”协议标准

▪TCP服务 TCP Server（规划中）：用来接受RSE路侧设备非结构化数据（裸数据，如原始视频流、原始雷达数据流等）的服务

▪运维代理Maintenance Agent（规划中）: 支持系统监控和运维的服务，用以收集单个5G MEC机房中关键服务的健康状态。

▪车载服务Car Service(规划中)：提供给车的按需增值生态服务

模拟器：

▪路侧设备模拟器 Roadside Equipment Simulator：用来模拟路侧雷达、视频、RSU设备的模拟器，模拟路侧信息的上报、接收、多路模拟数据输入等能力。

​不包含在OpenV2X规划中的能力：

• 车载操作系统

• 车路相关的硬件

• 第三方服务如精准地图、位置信息等

• RSU硬件和软件能力，比如通过PC5或者V2X向车推送的控制信息

三、社区会员

OpenV2X 的社区会员由董事会员、高级会员和普通会员组成。

- 社区组织总体思路

• 董事会员是OpenV2X开源项目成败的核心，开源社区是技术驱动型的协作，而开发者是开源社区成功的核心资源，没有开发者的贡献，开源社区将会走向败亡。因此对于会员体系中的董事会员，把单位是否投入资源进行代码开发作为评判要素。

• 高级会员的组成主要邀请在OpenV2X有代码贡献或者有相关实践的单位参加。

• 普通会员秉持开放的原则，相关会员发出申请，董事会员投票通过即可参加。

- 董事会员

拥有权利：

• 任命一位有投票权的代表参加董事会，商议并投票决定OpenV2X的重大决策。

• 首年拥有提名一位 TSC 代表候选人的权利。

• 在 OpenV2X 以董事会员名义展示 logo。

• 授予OpenV2X社区董事会员授牌。

履行义务（以下任意一项不满足，则自动取消董事席位）：

• 至少承担一个功能的PTL工作，且拥有至少1名项目Core核心开发者。

• 缴纳项目年费（1万/年）（特别说明：由于OpenV2X开源项目社区是依托上海开源信息协会成立的开源社区，相应年费缴纳至上海开源信息技术协会。在成为OpenV2X董事会员的同时，也自动获得上海开源信息协会理事级别资格，申请流程参考上海开源信息协会入会流程）。

申请条件：

• 至少承担一个功能的PTL工作，或者拥有至少1名项目Core核心开发者。

• 曾经是高级会员。

- 高级会员

拥有权利：

• 在OpenV2X 以高级会员名义展示logo。

• 授予OpenV2X社区高级会员证书。

申请条件（至少满足一项）：

• 有至少一个员工成长为项目正式的commiter。

• 参与并领导一个需求工作组。

• 提供一个在OpenV2X社区官网公开的实践分享案例。

• 为社区提供开放实验室环境。

• 曾经是董事会员单位。

在满足前提的条件下，如果单位曾经担任过董事会员，则自动成为高级会员；如果单位未曾担任过董事会员，则需要提交相关申请，并获得OpenV2X社区董事会通过。高级会员无需每年申请，直至会员提出书面或者邮件申请撤销高级会员资格。

- 普通会员

拥有权利：

• 在 OpenV2X 以普通会员名义展示 logo。

履行义务（至少满足一项）：

• 有至少一个员工成长为项目正式任命的 committer。

• 为社区提供开放实验室环境。

- 会员加入流程

1. 填写企业会员入会申请表格，打印并加盖公章。并且准备好公司营业执照扫描件一份。

2. 将以上电子材料发送至秘书处邮箱：openv2x@shanghaiopen.org.cn。

3. 社区秘书处协助待加入伙伴申请材料的提交和跟踪反馈。

4. 董事会定期对待加入伙伴申请材料进行讨论，并给出审核建议。

四、社区治理

OpenV2X 社区治理机构包含董事会、秘书处和技术指导委员会（TSC），最高决策机构是董事会，董事会下设秘书处，技术指导委员会是技术决策机构，TSC 下设项目组（PG）和工作组（WG）。

- 董事会（Board）

董事会负责社区的整体策略和伙伴生态建设。

- 董事会成员

• 首次董事会设置5~7个成员席位，由OpenV2X社区发起单位组成。董事会成员可以经由董事会成员、秘书处提议，经董事会表决实现总体席位扩充，但总数应保持单数。

• 每个高级会员可以任命一名投票代表。

• TSC 主席自动成为董事会的一名参会代表。

• 秘书处工作人员例行参会支持。

说明：相同的法人公司只能有一名投票权的董事会代表，可以有多名参会代表。

- 董事会职责

• 审批和更新社区章程。

• 选举董事会主席。

• 拓展和审批新的社区伙伴。

• 决策关键营销策划。

• 决策建立或者撤销下属治理机构。

• 提名和选举秘书处的秘书长和副秘书长。

• 投票表决社区中所有无明确决策机构的其他事项。

- 董事会会议

• 董事会会议将仅限于董事会代表、TSC 主席、秘书处主席、邀请嘉宾等参加。

• 董事会会议遵守董事会投票中的法定人数和投票要求。其中董事会代表和 TSC 主席拥有投票表决权，秘书处主席和邀请嘉宾无表决权。

• 除非董事会另有决定，否则将是私人会议。董事会可以邀请嘉宾，但是嘉宾没有表决权。

- 董事会成员选举和更换

第一年董事会员由发起单位组成，任期至2023年12月份为止。

从2023年11月开始，OpenV2X 秘书处将辅助推进董事会的改选，根据以下原则组建新的董事会：

• 在过去一年中，代码贡献（Commit数量）前七的单位自动成为董事会员候选单位，由协会秘书处发起邀请，如候选单位在20个自然日内提交申请，并缴纳年费，则正式成为董事会会员。

• 如有候选单位放弃申请，则按照候选单位放弃的数量，按照代码贡献（Commit数量）顺延取相应的候补单位，由协会秘书发出邀请，如候选单位在20个自然日内提交申请，并缴纳年费，则正式成为董事会会员。

• 如有候选单位放弃申请，则按照候选单位放弃的数量，按照代码修复错误的贡献（Bugfix数量）取相应的候补单位，由协会秘书发出邀请，如候选单位在20个自然日内提交申请，并缴纳年费，则正式成为董事会会员。

• 如果所有参与代码贡献的单位都已经发出邀请，董事会如席位依然未满七个，则停止发出邀请。当年董事会按照不满七个组织。

• 高级会员数量不限，但是必须满足前提条件中的一项才能申请。

- 董事会主席选举

• 已成功当选的投票代表均可提名竞选董事会主席。

• 已成功当选的投票代表均可投票选举主席。

五、社区技术委员会（TSC）

- 社区技术委员会成员

TSC 成员由社区核心贡献者和 RM（Release Manager，版本经理）组成。

首次 TSC 成员由高级伙伴指定的代表组成。任期至2023年12月，后由选举产生，每年选举一次。

TSC 主席首次被指定，任期至2023年12月，后续由选举产生，每年选举一次。每次选举 TSC 代表后两周内完成 TSC 主席的选举。

- 社区技术委员会职责

• 敦促社区参与者遵守社区贡献者守则。

• 根据用户需求制定社区技术发展路线和技术架构演进，并牵引实施落地。

• 协调社区跨项目合作，组织跨项目技术问题讨论，并进行决策。

• 对社区版本发展负责，促进社区技术生态健康发展：批准项目的生命周期流程，并牵引实施落地。

• 对社区版本的安全质量负责：批准社区的版本发布活动和维护流程，质量和安全漏洞的要求和管理机制。

• 为满足社区需求，变更社区技术指导委员会的组织结构及运作方式，决策项目组和工作组的成立或者撤销，以及社区技术角色的设置和当选离任机制。

社区技术委员会的运作，社区项目组（PG）和社区工作组（WG）等技术组织由社区技术委员会负责制定，本章程不涵盖。

- 董事会及子委员会的投票

董事会和其子委员会的法定人数达到所需投票代表的 50%。如果会议的提前通知已按照正常的方式和时间安排，即使不符合法定的人数，董事会也可以继续开会，但在会议上不进行任何决策。

理想的决策是协商一致的结果。但若有任务决定需要通过表决才能继续推进的情况时，代表们将通过投票进行表决。

除了章程的修改外，其他的会议表决方式采用简单多数制。即与会代表达到法定人数后，与会代表中超过51%的情况即可通过表决。如果不是通过会议的方式，而是电子投票的方式，需要超过全体代表的51%才能表决通过。

章程的修改必须经全体董事会委员三分之二表决通过。

六、项目贡献者治理模式

OpenV2X 项目的个人贡献者可以成为团队的成员，每个团队都有明确的目的与职责，以及所负责维护的 git 库列表。

团队通过在 github 上的 Issue 与 Pull Requests 等功能进行协作与共创。理想情况下，团队会根据职责边界进行划分，来承担 OpenV2X 项目在不同领域的职责。一个代码库通常应该只属于一个团队，以便于多个团队可以在不同领域进行合作。

例如：

• 核心团队对 Request For Comments（RFC） 流程和相关设计原则拥有权威，但不能直接推送到 OpenV2X 代码库。

• 维护团队有权管理 OpenV2X 代码库并提交 RFC 以制定符合 OpenV2X 核心设计原则的路线图， Pull Requests 来实现提案的规划和实施，日常 BUG 修复。

• 核心团队与维护团队合作，以确保新的提案不会带来不必要的风险或成为代码维护的负担。

• 基础架构团队维护 OpenV2X 项目所涉及的基础代码库、基础配置、CI/CD环境、测试环境和资源等基础设施及所需代码维护。

• 社区团队负责 OpenV2X 各媒体渠道的运营，通过线上、线下的活动吸引 OpenV2X 贡献者和用户，并建立开源共赢的生态合作。

随着更多职责边界被发现，团队可能会从更大的团队中分离出来。应特别注意承担过多职责的团队，因为可能会忽略重要的领域。

- 贡献者

贡献者描述可以提交到./contributors目录下，提交的Pull Requests将由核心团队成员进行审查。欢迎贡献者们提交，之后你的相关信息会体现在对应的发布贡献者清单中。

该文件的名称应与您的github账号一致，每个 ./contributors/*.yml 文件都有以下字段：•name - 贡献者的真实姓名，或者如果不想公开，也可以使用昵称。•github - 贡献者的 github 登录名。

每个贡献者都将被授予 OpenV2X github 组织的成员资格。这并不会带来太多权限的提升，因为所有代码库的访问权限都是由所负责的团队单独管理。

- 团队

团队描述可以提交到./teams目录下。提交的 Pull Requests 将由所负责的团队成员审核，核心团队将会联系所有受影响的团队或个人进行审核。

每个 ./teams/*.yml 文件都有以下字段：•name - 团队名称，与文件名相同,使用英文小写。•purpose - 团队关注点的一个简要描述。•responsibilities - 团队职责的详细列表，或一个职责列表说明的链接。•members - 团队的贡献者列表，例如./contributors/foo.yml的foo。•repos - 团队的github代码库列表。

每个团队都必须有一个明确的目的来说明其目标，团队还负责维护其职责清单。这样做可以为新人澄清团队的范围，并且更容易判断团队何时超负荷从而决定何时对团队进行拆分或重组。

每个团队都列出了与./contributors下的文件名相对应的成员（不带 .yml）。

每个团队都列出了具有维护权限的 github 代码库。

虽然每个团队都可以确定自身的工作模式与流程，但还是强烈建议每个团队的工作都能做到公开透明，无论是在github上还是在其他可以公开访问的工具上，只要这样做有利于团队与社区发展。

建议：团队流程可以在一个由团队专门管理的新代码库中定义。可以通过向此代码库提交PR来创建团队代码库。请参阅代码库。

- 投票

除非通过团队自己的流程另有说明，否则任何决策都是通过团队成员投票达成。

每项决策都需要66%以上的投票比例才能通过。（实施上述流程也将需要66%的投票比例。）

投票可以通过PR审查、发表评论或其他某种形式的记录来发起，过程和结果最好是能永久保存。

团队不需要有指定的领导者，团队可以选择指定一名领导者并通过团队之间的投票来定义他们的角色和职责。

- 加入团队

要提议添加团队成员（您自己或代表其他人），请先提交将他们添加为贡献者的 PR，然后再提交将他们列为所需团队成员的 PR。

将某人添加到团队的 PR 需要足够多的批准审阅者才能通过投票过程。审查 PR 的社区团队成员负责根据目标团队的规模和投票流程确定所需的投票数，并在获得必要的票数后合并 PR，如果无法获得必要的票数则关闭 PR。

核心治理团队的加入规则并无特殊性，投票可能完全是基于成员的主观判断，加入的难度因团队而异。一般来说，没有事先交流或前期的信任基础的申请几乎肯定会被拒绝。

- 离开团队

团队成员可以随时通过提交PR将自己从成员列表中删除来选择离开团队，自愿离开团队不需要投票。

要将其他人从团队中删除，请提交PR，它将使用与加入相同的投票流程。被提名要除名的成员也一样可以参与投票。

建议：各团队定期回顾贡献者和团队成员对项目的贡献情况，来决定吸纳和移除团队成员，从而保障团队内的活跃度。

- 创建新团队

可以随时通过提交 PR 来申请组建新团队，由核心团队审核后组建和确定团队成员和初始职责。（只有一个成员的团队不是一件好事，所以请尽量招募团队成员。）

如果一个新团队是从更大的团队中拆分出来的，您将必须协商相关代码库的所有权，理想情况下将它们完全转移到新团队。（这显然需要得到原始团队的批准。）

- 代码库

OpenV2X项目的代码库描述放在./repos目录下，更新的Pull Requests将由基础架构团队审查。

每个./repos/*.yml文件都有以下字段：

•owner - 代码库所属空间地址（企业、组织或个人的地址path）。

•repo - 代码库路径（path）。

•name - 代码库名称。•description - 代码库描述，可选。

•private - 代码库公开或私有。

•default_branch - 默认分支。

•homepage - 主页（eg: https://xxx.org），可选。

•has_issues - 允许提Issue与否，默认：允许（true）。

•has_wiki - 提供Wiki与否，默认: 提供（true）。

•can_comment - 允许用户对代码库进行评论，默认：允许(true)。

•issue_comment - 允许对“关闭”状态的 Issue 进行评论，默认：不允许(false)。

•pull_requests_enabled - 接受 pull request，协作开发，默认：允许（true）。

•online_edit_enabled - 是否允许代码库文件在线编辑，默认：允许（true）。

•lightweight_pr_enabled - 是否接受轻量级 pull request，默认：允许（true）。

所有代码库均配置为合并PR后删除分支。

代码库的永久删除必须由基础架构团队的成员手动完成。

- 修改治理模式

核心团队将审查此流程 (README.md) 的 Pull Requests。

- github 组织设置

除了本文档外，此代码库还包含 OpenV2X github 组织状态的实时配置，所有配置都会自动应用并每天同步以防止漂移。

七、行为准则

- 我们的承诺

为建设开放友好的环境，我们贡献者和维护者承诺：不论年龄、体型、身体健全与否、民族、性征、性别认同与表征、经验水平、教育程度、社会地位、国籍、相貌、种族、信仰、性取向，我们项目和社区的参与者皆免于骚扰。

- 我们的准则

有助于创造积极环境的行为包括但不限于：

•措辞友好且包容

•尊重不同的观点和经验

•耐心接受有益批评

•关注对社区最有利的事情

•与社区其他成员友善相处

参与者不应采取的行为包括但不限于：

•发布与性有关的言论或图像、不受欢迎地献殷勤

•捣乱/煽动/造谣行为、侮辱/贬损的评论、人身及政治攻击

•公开或私下骚扰

•未经明确授权便发布他人的资料，如住址、电子邮箱等

•其他有理由认定为违反职业操守的不当行为

- 我们的义务

项目维护者有义务诠释何谓“妥当行为”，并妥善公正地纠正已发生的不当行为。项目维护者有权利和义务去删除、编辑、拒绝违背本行为标准的评论（comments）、提交（commits）、代码、wiki 编辑、问题（issues）等贡献；项目维护者可暂时或永久地封禁任何他们认为行为不当、威胁、冒犯、有害的参与者。

- 适用范围

本行为标准适用于本项目。当有人代表本项目或本社区时，本标准亦适用于此人所处的公共平台。

代表本项目或本社区的情形包括但不限于：使用项目的官方电子邮件、通过官方媒体账号发布消息、作为指定代表参与在线或线下活动等。代表本项目的行为可由项目维护者进一步定义及解释。

- 贯彻落实

可以致信[contact@OpenV2X.org]，向项目团队举报滥用、骚扰及不当行为。维护团队将审议并调查全部投诉，妥善地予以必要的回应。项目团队有义务保密举报者信息。具体执行方针或将另行发布。

未切实遵守或执行本行为标准的项目维护人员，经项目负责人或其他成员决议，可能被暂时或永久地剥夺参与本项目的资格。