同步操作将从 openEuler/community 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
这里记录了openEuler社区当前的运作方式。
openEuler社区遵循以下原则:
openEuler社区遵循社区行为准则
请查看社区成员
请查看社区团体
openEuler社区主要的组织构成是SIG。
每个SIG的共同目的都是针对特定的一个或多个主题,推动交付成果输出,并争取让交付成果成为openEuler社区发行的一部分或者openEuler扩展包的一部分。SIG的每个可识别的部分都属于该SIG,包括存储库、目录、API、测试、问题、PR等。
SIG在任何给定时间内必须至少有一个或多个Maintainer。Maintainer负责SIG的运作,通过SIG的治理实现特定的目标,并与团队成员一起与技术委员会、其他SIG组、用户进行交流协同。
每个SIG都必须有一个章程,其中规定了SIG的业务范围(主题、代码库、目录等)、职责、权限区域,如何选择/授予权限/领导权的成员和角色,如何制定决策和解决冲突,如何管理章程等信息。在一些跨SIG流程(如发布流程)和资产(如存储库)的广泛指导原则约束下,SIG可以相对自定义的更改其操作方式。
SIG组内的交流必须是公开的,以确保其他SIG组的社区成员可以找到讨论、会议、涉及和决策的记录,SIG也需要定期向社区传递项目的工作概要。
有关SIG的治理的更多详细信息,请参考SIG治理、SIG治理要求。
SIG文件夹内记录了openEuler社区当前的所有SIG。
SIG:顾名思义,是一个团队,代表一群**“人”**
项目:是为了完成某一特定目标而相互关联的任务,代表一组**“事”**
SIG会针对一个或多个主题树立目标,从而成立项目去实现目标。目标的交付成果(包括代码和软件包)保存在repository内。所以项目和repository是息息相关的。综上SIG、项目和repository的关系是:
一个SIG至少有一个项目
一个项目对应一个或多个repository(交付成果为便于管理,会保存在多个相关的repository内)。
一个项目可以由SIG内的一部分人参与,也可以由SIG内的所有人参与。
由于项目的相关任务和成果均在repository上管理,所以在openEuler社区,项目等同于repository(ies),它可以代表一个repository,也可以代表一组相关的repository。
SIG是在公开场合运作的自愿团体,任何人都可以加入。但因为某些领域需要谨慎处理(例如安全性),所以委员会不公开成员资格,而且并不总是公开运作。
技术委员会可以根据需要,在有限的时间内成立某一特定委员会。委员会的成员资格由技术委员会决定,但所有委员会成员必须是社区成员。与项目一样,委员会也有章程,并定期向社区和技术委员会报告。
Committee文件夹内记录了openEuler社区当前的所有的委员会。
一方面,跨SIG协调的成本是昂贵的,虽然社区的大部分工作不需要协调,但仍然避免不了有跨越边界的工作(依赖等)。在这种情况下,期望多个SIG之间互相协调并达成共识比较困难,组建联合工作组就显得很有意义了。
另一方面,一些SIG确实会对所有SIG产生影响,比如发布、测试、打包等。即使都不需要这些的软件,有时也可能需要进行变更或影响到其他SIG。在这种情况下,所有SIG都应遵守社区范围内的沟通流程。
例如:具有影响力的提案需要在社区范围内公告,以便于其他SIG的成员有机会提供反馈和指导。不过本领域的项目拥有本领域的决策权。如果跨项目争议时间较长,则可以上升到技术委员会。
openEuler Gitee下的所有的Repository都应该遵循openEule的Repository指南中描述的过程。
所有贡献者都必须签署openEuler CLA,请具体看这里。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。