治理¶

核心团队(/about/team.md)的忙碌小蜜蜂们肩负着多重职责，确保整个BeeWare这个蜂巢持续运转。这是一个不断发展的项目，因此本页面内容可能随时变更。

这些包括但不限于回复问题、审查和合并代码、指导新的贡献者以及 BeeWare 项目的整体架构。

有一些人，我们信任他们，让他们做出代码决定；有一些人，我们信任他们，让他们做出代码和组织决定；还有一个人负责引导整个组织的愿景，并在社区无法达成共识时受托做出最终决定。

团队资历¶

BeeWare项目中的不同资历等级为：

蜜蜂，或工蜂¶

BeeWare 社区的任何成员。鉴于我们在 GitHub 上公开协作，任何人都可以提出代码修改建议并实现代码合并。您贡献能力的唯一限制在于：您的工作需由具备合并权限的团队成员进行合并。

养蜂人¶

一位被认可为可信贡献者的蜜蜂。这些蜜蜂在BeeWare项目的特定领域长期展现出卓越能力，既可能体现在技术层面（精通JavaScript、Python、Objective-C；掌握GTK+、macOS知识），也可能体现在其他层面（社区管理、代码审查）。养蜂人还可能获得其专业领域所涉项目的提交权限。

高级养蜂师¶

在GitHub中拥有高级访问权限的养蜂人，同时肩负着监督整个项目的额外责任。他们能够做出架构决策，但最终需向BDFN负责。

暂任蜜蜂仁慈独裁者（BDFN）¶

对终身仁慈独裁者的诠释：项目方向与决策的最终责任归属于BDFN。使用"暂任"而非"终身"，呼应了Django倡导的核心维护者责任不应贯穿个人整个自然生命的理念。开源世界之外还有生活，保持代码与生活的平衡及整体福祉至关重要。

BeeWare 的 BDFN 是 Russell Keith-Magee。

创始养蜂人¶

首位站在山丘上，发现有牦牛需要剃毛的人。这个角色永恒不变，无限延续；然而它本身并不赋予组织内任何额外权力。目前，创始养蜂人同时担任BDFN职务；但这一状况可能随时间推移而改变。

指南（非正式规则）¶

与任何拥有多人提交权的项目一样，团队应遵循一些一般准则：

向更广泛的社区展现项目的良好形象
请以尊重的态度对待针对任何BeeWare项目的每项咨询与贡献
假设每个人都有善意，即使他们措辞不当
假设当有人以"错误"的方式行事时，那必然是我们未能有效传达流程所致。
假设任何愤怒或挫败感的表达，都源于真心想要使用BeeWare工具/库的初衷。
鼓励社区其他成员在自己的交流中体现这些理念，无论是在BeeWare社区内部还是外部。
养蜂人切勿提交自己的代码
例外："某些东西严重损坏，需要立即修复"
例外：BDFN（未来可能变更）
所有提交给核心团队成员审核的代码，都应由另一位团队成员进行审核。
例外：BDFN（未来可能变更）
所有代码在合并前都应通过持续集成测试
例外情况：已知存在缺陷但因其他原因需要提交的代码
例外情况：代码所在仓库的持续集成测试不足
例外：勤奋且尽责胜过完美却不作为
尽可能实现验收流程的自动化
这意味着测试、代码检查、拼写检查、代码覆盖率检测等等。

成为养蜂人¶

新的养蜂人是否加入团队完全由现有的核心团队决定。虽然目前还没有这方面的明确规则，但一般来说，如果某人对 BeeWare 项目做出了坚实的贡献，则会被邀请成为项目的养蜂人。这也可以扩展到具有特定可能现有团队所缺乏的领域知识（例如，iOS/macOS）的人。这也不一定要基于 commits。任何能证明对整个项目有既得利益的人都可以要求获得向项目 commit 的许可。

所有新加入的养蜂人都将接受项目核心价值观与指导方针的"入职培训"（暂无更贴切的表述）。核心价值观概要详见关于页面。团队成员需恪守这些价值观，并参与关于价值观持续发展的讨论。

任何养蜂人，不管是新手还是老手，都没有期望作为任何一个项目的唯一维护者。有很多养蜂人，还有更多的人可以提供帮助、建议和指导。

"提交位"？¶

在 Unix 系统中，一个文件中的单个位用来表示执行文件的权限。在源代码控制系统中，也有类似的位表示合并代码的权限。如果说某人拥有“commit 位”意味着他们拥有代码库的写入权限。用 GitHub 的术语来说，这意味着他们有能力合并拉取请求并将代码直接提交到项目。