与 openSUSE 社区讨论、定义并保持透明

大家好：

SUSE Linux Enterprise 团队承认 openSUSE 社区需要与 SUSE 建立更好、更透明的协作关系。我们现在有一个契机去思考和改变。

SUSE Linux Enterprise 和 openSUSE 之间的共生关系是真实存在的，我们共享的代码远不止代码本身，我们使用相同的工具，如 Open Build Service、openQA、相似的维护流程、人员（发布经理、贡献者等）等等。

过去我们可能有些沉默，但这并不意味着我们没有发展；多年来，我们已经创建了更多的联系，例如 Package Hub，通过 SLE Factory First Policy 为 SUSE 员工和我们的技术合作伙伴促进贡献，在开发阶段通过 SLE 公开发布计划 提高可访问性，仅举几个例子。

但现在我们有一个加速的契机，尤其是在提高我们缺陷和功能请求的透明度方面，以使 openSUSE 发行版和社区受益。所以我们听取了你们的意见，今天我们想澄清和改进流程，为了我们所有人，并提供一些关于 SUSE 内部讨论如何打破所谓的“封闭大门”的见解。

所以，废话不多说，以下是我们的行动计划

• 更新并创建 openSUSE wiki 页面以澄清流程
  • Luboš Kocman 已经开始记录 检索 SLE 功能请求的流程，他的计划是在 10 月或更早的时候提出一个真实且更好的功能流程，供外部贡献者使用。
  • 我们还将审查和改进“如何为 Leap 贡献，openSUSE Leap 开发阶段”，以澄清和正式化多年来一直存在但未记录的信息。
  • 创建关于我们的“SLE Factory First Policy”的新页面，以及潜在的维护和质量保证主题。
• 更公开地讨论 openSUSE 和 SLE 的关系，
  • 在 openSUSE 虚拟峰会 上，将展示“openSUSE Leap 的当前和未来战略”和“Jump！当前状态和即将发生的变更”。
  • 在“SUSE 如何构建其企业 Linux 发行版”博客文章中即将出现的主题。
  • 在 虚拟 SUSECon 上，将发表关于“SLE 和 openSUSE 之间关系”的演讲。
• 找到打开我们的 bugzilla.suse.com 的正确方法
  • SUSE 致力于保护我们的客户和合作伙伴在我们的工具（如 Bugzilla）中托管的私有数据。他们信任我们处理他们高度敏感的数据，因此我们非常重视这个话题。但是，由于 Bugzilla 实例已从 MicroFocus 完全移交给 SUSE，我们现在完全控制 Bugzilla，因此我们可以讨论如何更改我们的内部流程，以结合数据隐私和开放性。
  • 已经成立了一个小组（Vincent Untz、Anna Maresova 和 Vincent Moutoussamy）来推动内部项目，并将负责与所有利益相关者（包括 openSUSE 社区）讨论提案。
• 特别关注 openSUSE 15.2（以及未来）Leap 错误报告
  • 最后，openSUSE Leap 发布经理 Luboš Kocman 致力于审查、分类 openSUSE Leap 15.2 错误和功能请求（为 openSUSE Leap 15.2 创建错误报告），并将其升级到 SLE 产品和发布经理。

我们相信这是一个令人兴奋和雄心勃勃的计划，我们希望尽快分享更多具体信息。

与此同时，请随时与“openSUSE 和 SLE”演讲者、Luboš 以及在此线程中留下评论或向我们发送反馈。

敬请关注，待在家里，注意安全，保持绿色。

SUSE Linux Enterprise 团队