发布说明的目标受众

• 我们有3个潜在的发布说明受众
  • 直接使用库或其他代码的开发者。
  • 部署者和运维人员。
  • 最终用户。
• 正在讨论的两种文档
  • Reno [1] 用于发布说明 [2]
    • 请记住，受众*不是*那些必然会查看代码或基于我们生成的库编写应用程序的人..
    • 突出显示部署者和运维人员需要的信息，例如配置选项或服务行为的更改。
    • 描述最终用户可能需要了解的REST API更改。
  • 树内开发者文档 [3] 供开发者使用。
    • 内部细节、库API更改等——任何部署者看不到的更改。
• 这两组文档的用途不同，因此我们需要考虑在每个文档中发布哪些信息。
• 完整线程 [4]

一项关于拆分设计峰会的提案

今天

• 从一开始，我们就在设计峰会上进行面对面交流，讨论开发周期，设定目标并组织未来6个月的工作。
• 同时举行了一场更传统的会议，以确保上游和下游社区之间的互动。

当前问题

• 对于开发者
  • 由于来自会议的诸多干扰，很难专注于上游工作。
  • 因此，峰会效率较低，我们需要在周期中间进行补充会议以集中精力。
• 对于公司
  • 将所有开发者飞往昂贵的城市和会议酒店参加峰会成本很高。——峰会地点触达各地的用户目标并不一定与设计峰会地点目标一致。
  • 没有足够的时间在最新版本的基础上构建产品。

• 用户没有足够的时间试用新版本以提供反馈。
• 寻找能够容纳这两个活动的场地变得越来越复杂。

如何拆分活动

• 第一个活动将面向OpenStack的上游技术贡献者。
  • 在一个更简单、更精简的环境中举行，让所有OpenStack项目团队在独立的房间里开会，但同时在一个共同举办的活动中，方便进行跨项目的临时讨论。
  • 它将举行在更接近贡献者中心的位置，在成本更低的地方。
  • 它将在前一个周期特性冻结后几周/之前/举行。周期之间有很多重叠。周期工作在前一个周期特性冻结时开始，而还有5周的时间。大多数人在RC1时全力投入下一个周期。在那个时间之后组织活动，让我们可以在最佳时刻组织工作并启动新周期。它还允许我们利用在一起的时间，快速解决可能出现的发布关键问题。
• 第二个活动将是主要的下游商业会议。
  • 包括高端主题演讲、市场和分组讨论。
  • 在发布后两到三个月组织，以便给下游用户部署和在发布基础上构建产品的时间。
  • 这将更好地让我们收集有关最新版本的反馈，并收集下一个周期的需求。
  • 希望参与会议的贡献者子集可以收集和转达反馈给其他团队成员（类似于运维人员周期中间会议）。
• 拆分应该减少周期中间会议的数量，但是，如果仍然需要，可以在会议活动中举行（在周期中间）。
• 拆分意味着我们需要错开活动和周期。在巴塞罗那和美国第一季度峰会之间有很长一段时间，我们可以利用这段时间插入一个较小的周期（Ocata），在2017年3月初发布，并在P周期开始时，即2017年2月中旬举行第一次特定的贡献者活动。考虑到2016年和2017年已经计划的活动，这是我们能够进行过渡的最早时间。我们将在巴塞罗那举行最后一次缩减规模的设计峰会，以计划较短的周期。
• 运维人员周期中间会议将继续举行。

提出的担忧和解答

• 这会创建两个活动而不是一个。会造成社区分裂，开发者会跳过主会，而非开发者不会向贡献者特定的活动提供任何反馈。
  • 主会仍然会有很多战略讨论。
  • 我们将在那里查看N-1版本，并开始为N+1版本制定计划和跨项目主题。
  • 我们不需要每个开发者都在那里，但仍然需要相当一部分开发者，每个团队都有代表，这样我们才能进行战略和跨项目讨论。
  • 想要了解开发情况的人仍然可以只参加一次旅行，因此社区分裂是不必要的。我们仍然会在主会中得到充分代表。
• 将主会作为资助开发者旅行的借口。有些开发者仅仅因为主会同时举行才被派往设计峰会。
  • 如果你不得不假装参加峰会才能参加设计峰会，那么其中就涉及欺骗。你应该与你的雇主讨论在哪次活动中参加对你最有价值。
  • 基金会也有旅行支持计划来弥补差距 [5]。
• 担心以美国为中心（从“更接近贡献者中心”翻译而来）。这使得旅行成本更便宜，但以牺牲我们社区非美国部分成员的成本为代价。
  • 目标是“最小化和*平衡*现有贡献者的旅行成本”。仍然会有一些大陆轮换，但我们需要平衡成本和公平性。
• 失去周期中间会议的精神。有些人真的很喜欢当前的周期中间会议：分离的小型活动，只有你的小型团队在场。拆分似乎减少了这种可能性、需求或资金。
  • 虽然希望提议的格式能够满足我们所有的团队社交需求，但确实会有其他人，而且感觉会不那么排他性和特殊。
  • 权衡是让人们聚集在一起鼓励跨项目合作并打破壁垒。
• 完整线程 [6]