作为社区讨论的结果，OpenStack 基金会正在改变其为社区制作的活动格式，从 2017 年开始。该提案是将目前每六个月一次的、作为主要 OpenStack Summit 一部分的 Design Summit 分为两部分：在主要 Summit 上进行跨社区讨论和用户输入（我们称之为“什么”讨论）的“论坛”，以及一个独立的“项目团队大会”活动，供项目团队成员见面并完成工作（“如何”讨论和冲刺）。目的是减轻对单独的周期中期会议的需求，因此开发团队将继续每年开会四次，两次与广大社区开会，两次在一个更小、更集中的环境中开会。发布周期也将调整，以便在发布和 Summit 之间有更多空间。此次变更引发了很多担忧和问题——本次 FAQ 的目的是试图解决它们。
请注意，我们曾举行社区全体会议来解释 OpenStack Design Summit 不断变化的格式。您可以观看此次录音以了解更多信息。
问：这次变革如何帮助上游开发者？
答：在 Summit 周期间，上游开发者有许多不同的目标。我们利用 Summit 来沟通新事物（发表演讲）、学习新事物（参加演讲）、获得用户和运营商对我们最新发布的反馈、收集痛点和未来开发优先级、提出变更并听取社区意见、招募和入职新团队成员、进行重要的跨项目讨论、与现有项目团队成员会面、启动新周期工作，以及完成工作。4 到 5 天的时间根本不足以完成所有这些，所以我们通常会放弃一半的目标。大多数人会 Skip 参加演讲。有些人会放弃发表演讲的想法。有些人会放弃跨项目讨论，导致它们没有足够的代表性来真正发挥作用。有些人会退出自己的项目团队会议去别处。时间冲突让我们在会话之间跳来跳去，导致我们通常无法倾听反馈、痛点或新来者。到周末，我们会精疲力竭，无法完成任何事情。我们需要腾出一些时间。有些目标只能在 Summit 环境下实现，那里代表着我们的整个社区——我们应该将这些目标保留在 Summit 周。有些目标在没有干扰的环境下实现效果更好——我们应该为它们组织一个单独的活动。
问：“论坛”是什么？
答：“论坛”是 Design Summit（Ops+Devs）的一部分的代号，它仍然会在主要 Summit 活动中举行。它将主要专注于下一个版本的战略讨论和规划（“什么”），基本上是下一个发布周期的开始，即使开发还要 3 个月才会开始。我们仍然应该利用我们整个社区（Devs、Ops、最终用户……）的代表性来举行跨社区讨论。这意味着从用户和运营商那里获取关于我们最新版本特定项目的反馈，收集痛点和未来开发的优先级，提出变更并了解社区的意见，以及招募和入职新团队成员。我们希望在[一个中立的场地]进行，而不是有单独的“Ops”和“Dev”日，这样讨论就不会受到会议所有者的影响。此活动将在上一个版本发布至少两个月后举行，以便用户有时间测试并提供有价值的反馈。
问：“项目团队大会”是什么？
答：“项目团队大会”是 Design Summit 的一部分的代号，现在将作为一项独立活动举行。它将主要为项目团队提供空间，以做出实施决策并开始开发工作（“如何”）。这就是我们将进行重要的跨项目讨论，与现有项目团队成员会面，建立共同理解，启动新周期开发工作，并通常完成工作的地方。OpenStack 项目团队将被分配单独的房间，可以开会一到两天，形式[松散]（没有 40 分钟的插槽）。如果您自认为是某个特定 OpenStack 项目团队的成员，您应该[肯定]参加。如果您不是特定项目团队的一员（或者无法选择 一个 团队），您仍然可以参加，但您在该活动的体验可能不是最佳的，因为该活动的参与者的目标是完成工作，而不是听取反馈或与新来者互动。此活动将在[上一个版本发布时间]左右举行，届时开发人员已准备好将开发工作完全切换到新周期。
问：这次变革如何帮助整个 OpenStack？
答：将更大的 Summit 活动从上一个版本[推远]应该会[极大]改善反馈循环。目前，在 Summit 上征求反馈不起作用：用户根本没有时间使用上一个版本，因此我们收集的大部分反馈都基于 7 个月前的[上一个]版本。这也[不是]推动新功能的[正确]时机：我们[已经]在[新]周期中[处于]领先地位，现在添加新优先级[为时已晚]。新的“论坛”活动相对于开发周期的位置应该足够晚，可以获得[上一个]版本的反馈，并且足够早，可以影响[下一个]周期中要完成的工作。通过腾出 Summit 周期间开发者的时间，我们还[期望]改善所有[参与者]的 Summit 体验：开发者将[更容易]参与并倾听。峰会的技术内容也将受益于[更多]上游开发者提供讲座和参与小组讨论。最后，将 Summit 安排在[发布]之后，应该有助于供应商准备和宣布基于最新版本的产品，从而使 Summit 市场[更]具吸引力和[相关性]。
问：变更何时发生？
答：Summit 的预订[已]排到 2017 年，所以我们[无法]很快[移动]它们。相反，我们建议[逐步]调整发布周期。巴塞罗那和波士顿之间实际上有 7 个月，所以我们有机会在这里[逐步]调整周期，影响[有限]。想法是进行一个 5 个月的发布周期（10 月至 2 月之间），在 2 月底举行第一次项目团队大会，然后回到 6 个月的周期（3 月至 8 月），并在其中期（5 月）举行波士顿 Summit（和论坛）。因此，在巴塞罗那之后，即 2017 年，变更[将]开始生效。这为我们研究场地和完善新活动格式[提供了]时间。
问：关于周期中会议？
答：周期中冲刺会议是由项目团队单独组织的，作为聚集团队成员和完成工作的一种方式。随着主要 Summit 会议上的干扰越来越多，并且项目团队很难在 Design Summit 上聚集、建立社交联系并普遍[高效]，周期中冲刺会议越来越受欢迎。我们希望团队在项目团队大会上[找回]失去的生产力和社交联系，从而消除对单独团队冲刺会议的需求。
问：这个项目团队大会很可能也是一个[盛大]的活动。我怎么能[在那里]变得[高效]？或者和我的[小]团队[建立]社交联系？
答：项目团队大会比 Summit（大约 400-500 人，而不是 7500 人）要[小]得多。项目团队被安排在单独的房间里，[很]像一个[共同]定位的周期中冲刺会议。唯一[大家]会面的时候是[午餐]时。不会有晚间派对：鼓励项目团队组织单独的团队晚餐并建立[牢固]的社交联系。
问：这种新格式是否真的有助于[跨项目]工作？
答：不幸的是，跨项目工作是许多与会者在努力应对 Summit 周期间必须完成的[诸多]事项时放弃的事情之一。跨项目研讨会最终[变得]越来越[无效率]，尤其是在[达成]决策或[产出]工作方面。周期中冲刺会议最终成为了可以完成工作的地方，但它们是[单独]组织的，这意味着跨项目团队（基础设施、文档、QA、发布管理……）的成员参加所有这些会议的成本[非常高]。我们基本上以一种使跨项目工作成本过高的方式[安排]了我们的活动，然后[纳闷]为什么我们在招募人员[来]做这项工作时遇到这么多困难。新格式确保我们有一个地方可以真正[进行]跨项目工作，而[不会]有任何其他事情与之冲突，就在项目团队大会上。它[极大]地减少了文档人员（例如）需要前往[参加]与项目团队成员[进行]面对面工作的地方的数量。它为垂直团队中的项目团队成员提供了一个选择，可以打破他们各自的[孤立]，并加入这样的跨项目团队。它允许我们为特定的跨项目[倡议]分配单独的房间，[超越]现有的[水平]团队，以[完成]特定的跨项目工作。
问：在主要 Summit 上是否仍然需要开发者？
答：上游开发者在主要 Summit 上仍然[非常]需要。Summit 是（并且一直是）反馈循环发生的地方。所有项目团队都需要在那里[出席]，以参与[规划]，收集对其项目的反馈，参与跨社区讨论，接触新成员并入职新开发者。我们也非常希望开发者在 Summit 的会议部分发表演讲（我们实际上[期望]他们会有[更多]的空闲时间[来]发表演讲，并且 Summit 的技术内容[因此]会[得到]改进）。所以是的，开发者在主要 Summit 上仍然[非常]需要。
问：如果整个团队[不]每 3 个月见面一次，我的项目团队就会[分崩离析]。我们以前在 Design Summit 和我们单独的周期中项目团队会议上都是这样做的。我担心我们会失去每 3 个月[一起]聚会一次的能力。
答：如前所述，我们希望项目团队大会比当前的 Design Summit[更]高效，从而减少对周期中冲刺会议的需求。也就是说，如果您[确实]仍然需要组织一次单独的周期中冲刺会议，那么您[绝对]可以自由地这样做。我们计划在主要 Summit 活动中提供场地，以便您可以[在那里]举行周期中冲刺会议，并[利用]已经[聚集]的大量人员。如果您决定举办一次周期中冲刺会议，您应该[沟通]您的团队周期中会议将与 Summit[共同]地点举行，并且[强烈]鼓励团队成员参加。
问：我们是一个[小]团队。我们目前不做周期中会议。感觉[通过]您的[变更]，我们每个周期需要[旅行]两次而不是一次。
答：您需要决定是否认为需要让团队[一起]聚集起来完成一些工作。如果您[是]，您应该（作为一个团队）参加项目团队大会。如果您[不]是，您的团队应该 Skip。[PTL]和任何对您团队中的跨项目工作感兴趣的人[仍然]绝对应该参加项目团队大会，但您不需要让所有团队成员都[去]，因为您在那里不会有团队房间。在所有情况下，您的项目都希望有[一些]开发者[出席] Summit，与社区[其他]成员互动。
问：我参与的项目[主要]由[单一]供应商驱动，我们[大多数]人[在]同一个办公室工作。我不确定[我们]所有人都[需要]去一个[远程]地点来[完成]一些工作！
答：您说得对，[不需要]。我们可能不会为单一供应商项目团队在项目团队大会上提供[特定]场地。PTL（以及任何其他[感兴趣]的人）[应该]仍然参加项目团队大会，以参与跨项目工作。而且您[也]绝对应该[参加] Summit，与其他组织和贡献者互动，并[增加]您的[联盟]多样性，以便您[能够]利用项目团队大会。
问：我是一名翻译，我应该去参加项目团队大会吗？
答：I18n 团队当然可以在项目团队大会上开会。然而，考虑到该团队的性质（成员众多、地理分散、来自我们社区、Ops、Devs、用户），利用 Summit 来聚集翻译人员可能更有意义。Summit 不断接触新的社区和国家，而项目团队大会可能会[专注于]主要的开发者领域。我们可能通过在“论坛”上举行 I18n 会议或研讨会来获得更好的外展效果。
问：很多人参加当前的 Design Summit 来一窥“幕后制作”，这可能[导致]他们参与其中。新的格式是否会危及这种入职？
答：确实，Design Summit 是向世界展示开放设计工作方式的重要组成部分。然而，这总是以牺牲现有项目团队成员的生产力为代价的。在 40 分钟的会议中，一半的时间将用于向新来者总结主题的历史。热烈的讨论会[被]后面的人打断，他们要求[与会者]使用麦克风。我们曾试图在 Design Summit 分离鱼缸和工作间，将讨论/反馈会议与团队成员工作会议分开。这[曾经]奏效过一段时间，但人们开始绕过它，导致一些工作间看起来像[拥挤]的鱼缸。最终，这会让所有[参与者]都体验[糟糕]，并[产生]很多社区[紧张]。在新格式下，“论坛”会议仍将允许人们[观察]开放设计的运作，并且由于这些会议[专门]设置为[倾听]会议（而不是“完成工作”会议），我们将花时间[互动]和倾听。我们将腾出时间进行[特定]的入职和教育活动。一周内[更少]的日程冲突意味着我们不必[总]是奔向下一个会议，并且[很]可能[有]更多时间在走廊交流中接触他人。
问：Ops 周期中会议呢？
答：Ops 会议仍在进行，而且在未来一两年内很可能不会[有]太大变化。在 5 月份，成立了“Ops 会议团队”来回答关于会议未来的问题，并积极组织即将举行的会议。该团队的一部分定义是：“保持 ops 会议的精神”——会议由 ops 运行，为 ops 服务，并将继续如此。如果您有兴趣，请加入该团队，讨论会议的数量和地区位置，以及它们的内容。
问：Summit 的 ATC 通行证怎么样？
答：OpenStack 基金会为过去六个月有过贡献的上游贡献者（不是所有 ATC）提供折扣通行证，以便他们能更轻松地参加 Summit。我们可能会改变模式，因为我们将为第二个活动[提供]资金，但将[专注于]最小化需要同时参加 Summit 和项目团队大会的人员的成本。最初的建议是为项目团队大会收取[最低]费用（以更好地[估算]出席人数并[尽量]减少赞助商的出现），然后任何亲身参加项目团队大会的人将获得折扣代码参加下一个 Summit。也正在为用户委员会（例如 Ops）代表的贡献者考虑类似的事情。同时，我们可能会[加强]旅行支持计划，以便我们能够让所有需要的人参加[正确]的活动。
