TC Elections October 2014

任何基金会个人成员都可以提出参选（除去年 4 月当选为一年任期 TC 成员的七位成员：Thierry Carrez、Jay Pipes、Vishvananda Ishaya、Michael Still、Jim Blair、Mark McClain、Devananda van der Veen）。无需提名。他们可以通过发送电子邮件至 openstack-dev@lists.openstack.org 邮件列表，主题为“TC candidacy”，截止日期为 10 月 10 日 05:59 UTC 来进行。电子邮件可以包含候选人平台的描述。候选人资格将由选举官员在验证候选人的选民身份后确认。

确认的候选人

结果

新当选的 TC 成员（6 名），任期一年

Monty Taylor
Sean Dague
Doug Hellmann
Russell Bryant
Anne Gentle
John Griffith

结果：http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4

TC Election Questions

为了帮助选民更多地了解候选人，模板问题将于 9 月 26 日 23:59 UTC 在此 wiki 页面上发布，供 tc 候选人在他们的提名电子邮件中回答。作为鼓励选民的一种方式，选举官员可能会采用候选人电子邮件中相同问题的回复，并编写博客文章，以帮助选民了解情况。保持问题 > 答案的格式将有助于使用这些数据（如果确定这样做可行且对选民有帮助）。

选择这些主题是为了为选民提供一系列项目，以便比较候选人在类似问题上的观点。您可以回复主题，回答问题，或不回复。您的回复选择将在答案按主题组织时与您的姓名一起标识，以帮助选民更好地了解各个候选人。这是我们第一次这样做，因此回复的发布位置可能会在收到回复后决定。答案将由选举官员在此 wiki 页面上发布。请在您的候选人声明电子邮件中包含一个明确定义的章节，以便选举官员可以自信地复制/粘贴。

模板

Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack Mission?

Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical committee mission?

Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?

Topic: Rate of Growth
There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?

Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?

Topic: Communication
How would you describe our current state of communication in the OpenStack community?

Topic: Relationship with the Foundation Board
The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?

Responses to TC Election Questions

Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?

Russell Bryant 概括一下，使命宣言是“创建一个无处不在的开源云计算平台，无论规模大小，都能满足公共和私有云的需求，并且易于实施且具有大规模可扩展性”。

“无处不在” - 我认为我们在这一方面做得很好。OpenStack 正在疯狂发展，并且被广泛使用。支持公司的列表 [7] 令人印象深刻。贡献者的数量和多样性更令人印象深刻。话虽如此，我们不应该自满。还有很多要做。

“公共和私有云” - 我认为我们很好地致力于支持这两种用例。

“无论规模大小”、“大规模可扩展性” - 这可能取决于你问谁。 :-) 我们的可扩展性取决于项目。在某些领域，我们做得很好。在所有领域，我们还有改进的空间。我认为我们最大的失败是未能很好地向社区传达期望。有些人期望他们可以将集成发布的每个组件扩展到大型公共云规模。事实并非如此，我们在设定期望方面做得不好。这是我想改进的一点。

“易于实施” - 我认为 OpenStack 远非简单。它也是一个大规模分布式系统，具有极大的灵活性，因此可以支持大量的不同用例。因此，我们应该相应地设定期望。但是，我认为仍然有大量的可用性改进空间。

Doug Hellmann 我对我们的社区所创造的一切感到惊叹。我们有一些真正出色的开发团队正在构建出色的软件。我们定期向系统中添加新组件，并且我们的功能集与社区的多样性一样。我们的工作并不完美，但随着我们继续根据经验和用户输入对其进行改进，我们不断改进我们的工作方式和我们所创造的产品。

然而，在每次发布后的用户反馈中都有一些反复出现的主题：我们需要使 OpenStack 更易于操作、更易于使用和更易于调试。我们正在开始构建跨项目团队，以更直接地处理这些领域的一些问题，重要的是我们要优先处理这项工作，并将可用性和可扩展性视为功能。

Sean Dague 我们的使命宣言是：“创建一个无处不在的开源云计算平台，无论规模大小，都能满足公共和私有云的需求，并且易于实施且具有大规模可扩展性。” (https://openstack.org/blog/2010/07/introducing-openstack/)

我真的觉得我们现在只是勉强及格。我认为当前服务的增长以及我们实施它们的方式（通过引入许多新的外部依赖项）并没有忠于“易于实施”。我认为这排除了小型机构使用 OpenStack。如果 OpenStack 只是大型复杂机构工具箱中的工具，它就不会变得无处不在。

Linux 首先由小型 ISP 部署，这些实体只有少数员工。如果 OpenStack 只能通过拥有非常熟练的集成商才能部署，那么它从定义上来说就不能无处不在。

我对较小的内核/层/环/区域/集成发布的感觉很大程度上受到我们正在失去 OpenStack 小型用户的影响。而这是我们可以解决的。

Zane Bitter （顺便说一句，使命在这里：https://wiki.openstack.org/wiki/Main_Page 以防你没有记在心里。）

我认为我们所有人在几个方面都有很多工作要做：- 特别是“易于实施”和“大规模可扩展性”。但我非常乐观地认为这项工作将会完成，因为我们已经建立了一个健康、蓬勃发展的社区来完成它。

Adam Lawson *“创建一个无处不在的开源云计算平台，无论规模大小，都能满足公共和私有云的需求，并且易于实施且具有大规模可扩展性。”*

使命宣言的全部意义在于仅仅确定我们组织内努力实现或完成的目标。话虽如此，我认为技术领导力是实现技术目标的第一步。因此，TC 的存在是积极的第一步。但这只是许多步骤中的一步。在本 TC 周期内，我希望 TC 能够展示领导力，以减少遗留的技术债务并解决 API 和模块标准化。OpenStack 目前存在一些影响我们扩展能力的问题，虽然其中一些可以通过组织方式解决，但技术债务和标准化是难以解决的挑战，甚至可能无法在单个发布周期内 100% 解决。但我期待 TC 如何引导流程和产品的改进，并帮助推动使命。另外值得一提的是，“易于实施”仍然只是一个目标，部署和管理 OpenStack 的工程要求仍然是许多组织的障碍。但我们拥有不止一种工具来帮助那些想要使用 OpenStack 但……无法使用的人。这是我真正希望尽快改变的事情。

David Lyle “创建一个无处不在的开源云计算平台，无论规模大小，都能满足公共和私有云的需求，并且易于实施且具有大规模可扩展性。”

我认为这是一个非常广泛的使命。广度不是问题，但这里有一些含义。OpenStack 需要具有包容性，为了实现无处不在，我们需要努力允许部署者满足他们广泛变化的需求。因此，我们需要支持一个大型生态系统。OpenStack 周围的生态系统当然很大，但 OpenStack 和非 OpenStack 之间存在着相当明显的二分法，认识到更大的生态系统对于生态系统健康非常重要。对于公共与私有以及大规模可扩展性方面，我认为我们还有进步的空间。在 OpenStack 上运行公共云需要进行不小的更改，并且 OpenStack 在可扩展性方面还有改进的空间。我们需要获得来自非常大的部署者的更多反馈，以确保我们满足这些可扩展性需求。

John Garbutt 这是一个大胆的使命，我认为它仍然是正确的。

“服务于开发者、用户和整个生态系统”我认为我们需要更好地服务于整个生态系统。

看看 Vi 与 Emacs。StachTach 与 Celiometer？我们是一个庞大的社区，我们应该学会拥抱多样性，即使目标不完全一致。但我们仍然希望任何人都能轻松地加入任何正在进行的工作。人们投资于竞争的初创公司。

另一方面，我们的用户很难知道哪些驱动程序的组合可以为您提供正常工作的系统，以及解决用户想要解决的问题的系统。发行版和顾问正在帮助解决这个问题。但我不知道供应商是否总是知道他们需要以最有用的方式参与。

我们需要更好地理解“互操作性”在这个更广泛的范围内意味着什么。但让人们轻松地使用多个不同的 OpenStack 实现非常重要。Nova API 应该始终表现得像 Nova API，Cinder API 应该始终表现得像 Cinder API，等等。

Monty Taylor 如果你最近没有读过它

“创建一个无处不在的开源云计算平台，无论规模大小，都能满足公共和私有云的需求，并且易于实施且具有大规模可扩展性。”

如果有人认为我们已经完成了“易于实施”，我很乐意认识他们。我认为我们一直专注于其他部分 - 我希望更多地关注“易于实施”。

Anne Gentle 技术社区现在由大量的不同的人组成，谢天谢地，因为使命是针对私有和公共云的宏伟而全面的使命。此外，它还包含“无处不在”一词，这使其范围更加广泛。我们正在为地球构建云，我认为我们正在努力、阻止、清除和努力满足使命。我们正在努力解决“易于实施”的问题，但我们已经走了很长的路。

Eoghan Glynn 坦率地说，我会给我们的努力打个A+，但执行力更像是B-。在兴奋和热情地添加新的闪亮功能时，我们有时会忽略用户真正需要的东西，从而降低了用户体验。在这方面，我也有过失，甚至可能更甚。但我认为，在现阶段，如果我们将重心稍微向另一方向倾斜，并将一些精力集中在解决大规模运营我们产品的实际挑战上，将对我们的用户社区大有裨益。

Dean Troyer 我认为孵化/集成项目的快速增长分散了TC的关注和精力，并且很明显，忽视OpenStack项目的自然分层结构行不通。

John Griffith 再次重申一下我们的使命：“打造无处不在的开源云计算平台，无论规模大小，都能满足公有云和私有云的需求，并且易于实施且具有大规模可扩展性。”

所以，我一直觉得这个使命宣言有点难以消化。我认为“无处不在”的部分正在实现，并且正在成为现实，并且我认为公有云和私有云之间也取得了一个不错的平衡，而且“规模”这个相对术语可以被解释为迄今为止得到相当程度的解决。

这些是好的……现在来说说不太好的；“易于实施”；我认为部署的情况并不像有时描述的那么糟糕，但肯定还有提升空间。一直困扰我的一件事是，一直以来都“交给了各个发行版”来提供他们定制的部署工具，而我们从未能够作为一个社区提供一个通用的部署基础。我认为这太可惜了，你可以构建最伟大的软件项目，但如果人们无法理解所有组件，更不用说相当容易地安装和配置它，那么它就无法发挥其潜力。

从TC的角度来看，说实话，我真的不确定TC在整体使命中扮演着什么角色。在我看来，TC实际上已经变成了一个委员会，主要负责投票决定项目孵化和诸如项目使命宣言之类的提案。在我看来，它并不是非常技术性的，而且效率也不高。

在我看来，TC需要进行一些改变，正如其他人提到的那样，摆脱仅仅投票决定孵化动议和使命宣言或差距分析工作，而是真正专注于影响OpenStack整体的技术决策，这将是很好的。例如，我认为TC可以更积极地深入了解所有OpenStack项目的实际整合方式，它们在哪些方面做得好，哪些方面做得不好，并提供一些指导和投入以及技术领导和方向。我当然不是说他们应该成为一个全能的监督小组，但我认为目前的重点是错误的。

主题：技术委员会使命：你觉得技术委员会在履行技术委员会使命方面做得如何？

Monty Taylor 如果你最近没有读过它

“技术委员会（“TC”）的任务是为OpenStack整体（所有官方程序，如下定义）提供技术领导力。它执行OpenStack的理念（开放性、透明性、通用性、集成性、质量……），决定影响多个程序的问题，形成技术决策的最终上诉委员会，并通常对所有OpenStack项目进行监督。”

我认为在过去一年里，自从我们全面选举以来，TC一直在做得越来越好。从历史上看，TC有点不愿意承担“技术领导力”这两个词。在过去一两个周期中，TC一直在持续地更多地承担起这个责任，我认为这种趋势需要继续下去。

Anne Gentle 我觉得TC支持着构成OpenStack的所有项目的技术贡献者。我们不断寻求改进和挑战程序的方法。我们开始要求程序对其集成负责。我们通过定义项目维护的所有代码作为OpenStack的一部分（定义的部分）来突破OpenStack定义的界限。是的，这是一种对我们的活跃技术贡献者社区的防御，但它也是我们理念的声明——开放性、透明性、通用性、集成性和质量。

John Griffith （从使命宣言中阅读：[2]）

我不确定在OpenStack当前的状态下以及项目和拟议项目的数量下，TC是否可以为此责怪。事实是，仅仅尝试了解生态系统中不断变化的各个项目，更不用说所有新提出的项目，已经变成了一项全职工作。我认为如果TC能够进行一些调整和改进，使其在项目的技术方向上更积极地参与，这将会有所帮助；例如，推动像使安装成为一个社区努力、提供真正有效的HA选项以及最重要的是推动OpenStack中的每个项目负责改进升级过程。

我认为目前TC中的许多人实际上正在很好地推动这些举措，但我认为这不是由他们在TC中的角色驱动的，而是更多地是由于他们的辛勤工作和奉献精神以及他们已经站出来证明自己是领导者。

Adam Lawson *"技术委员会（“TC”）的任务是为OpenStack整体（所有官方程序，如下定义）提供技术领导力。它执行OpenStack的理念（开放性、透明性、通用性、集成性、质量……），决定影响多个程序的问题，形成技术决策的最终上诉委员会，并通常对所有OpenStack项目进行监督。”*

我认为TC到目前为止做得相当不错，考虑到团队及其章程都比较新。虽然TC一直在为各个组件提供领导力，但我不会将TC今天描述为提供高度可见的领导力（对于开放性和透明性是必要的），我希望看到有所改进。TC目前的工作主要集中在为有意义的程序集成提供安全保障，并确保挑战得到最佳解决，但TC需要更好地识别这种技术治理模式的良好/定义不明确的边界。换句话说，TC需要更好地成为一个好的TC。TC的实例化是一个完美的起点，但房间里的粉象是关于跨项目和架构指导；确保OpenStack作为一个整体朝着不需要容纳我们不应该做的事情的方向发展。缺乏API标准化就是一个朝着没有大局观的方向前进的很好的例子。

关于大帐篷模型、层/级联、扩展文档等来回沟通和辩论一直可见，并且对立观点的坦诚令人惊叹。但我们确实可以从一些结构调整中受益，以便更多提交给团队的决策同样可见，一个可见和透明的决策过程使那些使用OpenStack的人能够理解指导它的架构视角。不仅仅是邮件列表中有100多条回复的决策

“对所有项目的监督”是一个我预计我们有一些容易实现的成果的领域。我们今天关注的重点是可以理解的，因为影响各个程序的许多火灾无法忽视。但我们有一个很大的机会（再次提到这个词）在更大的架构决策上取得进展，这些决策可能需要更多的前期工作，但从长远来看会产生巨大的回报。希望使用OpenStack的客户经常会因为一个很好的理由而打出“持续变化=不稳定”的牌；OpenStack离成为大众生产质量还有很长的路要走（即，不需要大量的重新开发需求）。我相信TC可以并且应该通过更好的解决方案层面的领导力来影响这一点。

部署挑战已经准备好接受关注了。
一个可以启动一个可以通过网络访问的实例的可用默认“开箱即用”配置仍然是一个挑战。在我看来，早就该解决了。
像Oslo这样的程序解决了库需求，使云更接近生产能力，但实际上不应该是可选的。做好某件事不应该是可选的。事实上，生产环境不应该是许多选项中的一个，尽管OpenStack PoC和试点项目普遍存在；它应该是一个一致的设计假设。将一个特性限制到

“足够好”是问题的一部分。它必须是生产就绪的，否则它就不够好。这已经准备好接受关注了。

我可能无法解决所有这些问题，并且一些想法可能需要更多的跨对话，但如果我当选，我希望倡导改进TC处理问题和评估潜在解决方案的方式。

John Garbutt TC显然一直在努力做得更好，并尝试新的想法，这很好。

发展集成发布的概念是使系统扩展的关键。孵化过程似乎存在很多摩擦。

帮助分享所有项目中有效的方法，似乎是提供大规模技术领导力的关键。这正在发生，这很酷。

TC应该缩小其范围到少数几个项目吗？我不确定。也许需要建立一个不同的组来处理与该组项目相关的具体问题？也许ttx的跨项目会议已经是该组的开端？

Zane Bitter （那个在这里：https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee）

我认为TC在鼓励OpenStack的理念方面做得很好，但我认为整个项目的规模已经超出了其提供_积极_技术领导力的能力。我们需要建立这种能力。

Sean Dague 使命：技术委员会（“TC”）的任务是为OpenStack整体（所有官方程序，如下定义）提供技术领导力。它执行OpenStack的理念（开放性、透明性、通用性、集成性、质量……），决定影响多个程序的问题，形成技术决策的最终上诉委员会，并通常对所有OpenStack项目进行监督。(https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)

在当前的TC中，我是OpenStack社区中最新的成员之一。说实话，我对TC花费了多少时间来评估新的项目请求感到惊讶（并且这个数量正在随着时间的推移而增长）。我认为TC提供技术领导力，甚至理解影响多个程序的问题的使命，当该治理的范围包括整个OpenStack生态系统时，会变得非常紧张。我认为这将限制TC在距离太远时进行监督的有效性。

Russell Bryant TC使命宣言可以在治理仓库中找到[8]。当前版本是：“技术委员会（“TC”）的任务是为OpenStack整体（所有官方程序，如下定义）提供技术领导力。它执行OpenStack的理念（开放性、透明性、通用性、集成性、质量……），决定影响多个程序的问题，形成技术决策的最终上诉委员会，并通常对所有OpenStack项目进行监督。”

TC只有两年历史。如果你回顾我们的历史，我认为TC在OpenStack发展壮大的过程中，在发展流程和结构方面做得很好。流程和结构的下一个演变一直是最近讨论的最主要领域。我对我们能够解决这些问题非常乐观。

我们改进技术领导力的方法收到的讨论较少。随着OpenStack发展到越来越多的项目，我认为围绕标准化进行领导变得越来越重要。我希望TC能够启动一个关于API的努力，以帮助提高我们的一致性和整体质量。我们还在讨论拥有一个跨项目规范仓库。TC拥有这个仓库是有道理的，以帮助为影响许多项目的开发工作提供更多的结构。

David Lyle “技术委员会（“TC”）的任务是为OpenStack整体（所有官方程序，如下定义）提供技术领导力。它执行OpenStack的理念（开放性、透明性、通用性、集成性、质量……），决定影响多个程序的问题，形成技术决策的最终上诉委员会，并通常对所有OpenStack项目进行监督。”

技术委员会在上一轮中花费了大量时间充当守门人。我希望它在 OpenStack 的整体架构方向上发挥更大的作用。我认为我们面临的最大挑战之一是愿景和方向的一致性。我认为这应该由技术委员会作为仲裁者和架构委员会来负责。我并不认为整体技术方向应该由技术委员会决定，而是技术委员会仅仅有助于统一该方向并确保一致性。显然这是一项艰巨的任务，但我相信 OpenStack 需要更清晰的方向。

Dean Troyer 我认为这个问题和前一个问题是相互关联的，现在是时候检查一下我们目前的状态以及我们想要达到的目标了。这个讨论已经开始了，但还没有明确的答案。

Eoghan Glynn 坦白说，如果我认为这无法改进，我就不会竞选了。

一方面，我认为对已经集成的项目的差距分析是一件好事，也是健康的，并且肯定有助于在 Juno 中将资源集中在技术委员会认为存在缺陷的领域。

另一方面，我对技术委员会关于项目状态的一些讨论结果感到非常失望。在我看来，缺乏尽职调查和指导。如果我们继续让技术委员会对项目的未来做出重要决定（无论是它们的集成状态还是它们的“生产就绪”），那么我认为我们需要确保技术委员会从更早的阶段就充分了解项目的方向，并在它认为项目需要纠正方向时发出公平的警告。

Doug Hellmann 我们正在实现大部分使命，但我们可以做得更好。

Zaqar 毕业的讨论是一个很好的例子，说明我们需要重新思考如何将新的项目团队引入 OpenStack。有一些类似的建议完全放弃我们当前的孵化和集成流程，这是一个选择。另一个是建立我们需要客观技术评估项目的资源。我倾向于将这两个想法结合起来，从用户的角度评估项目的几个标准，但根据社区的考虑来决定团队的“官方”状态。

我们还认识到我们需要某种方式来处理跨项目计划，例如改进我们的日志记录以使调试更容易，但我们还没有建立正式的结构来实现这些目标。我们设置这些类型工作的临时工作组的方式将取决于更大的治理讨论的结果，但我认为它们应该由技术委员会组织。

主题：贡献者动机：您将如何描述贡献者动机的各个方面？

Eoghan Glynn 我之前的大部分开源经验都来自各种 Apache 项目，相比之下，OpenStack 贡献者社区更偏离纯粹的志愿主义，转向企业贡献者，这非常明显。通过这种方式，我认为这实际上是我们的社区的优势。它肯定有助于努力的连续性和可持续性。它还有助于确保不太光鲜，但极其重要的工作，例如稳定维护和漏洞管理得到应有的关注。

然而，尽管存在这种偏差，但我深知我们正在构建一个“广阔的教会”。我认为我们都受益于积极努力建立贡献者社区的多样性，并利用各种动机的贡献者的能量。不仅仅是因为这是正确的事情，而且是因为这是*明智的*事情……确保我们能够获得所有人才，尤其是来自代表性不足的群体。为了这个目的，我继续支持 GNOME OPW 等项目的努力，以及他们最近向更广泛的贡献者背景扩展的举措。

John Garbutt 我认为我们是一个解决问题者社区，渴望协作并产生影响。

我们中的许多人将这项工作作为（全部或部分）全职工作。这导致人们被置于一个能够工作的问题的范围受到雇主限制的位置。

我们需要更好地教育那些雇用从事 OpenStack 工作的人们，他们如何才能从他们的投资中获得最大收益。例如，不进行上游测试，真的会造成损害。

David Lyle 贡献者贡献的动机各不相同。人们出于个人兴趣、公司利益、学术兴趣以及所有这些的任何组合来贡献。公司利益涵盖很多方面，从用户到运营商，从供应商到消费者。我们优秀的多元化贡献者社区的许多想法帮助我们前进并保持诚实和进步。

归根结底，OpenStack 是一种可用的云软件。我们需要权衡“如果那样做会很有趣”与“这在从小测试云到大型公共云的实际应用中如何工作”。服务应该努力跨越这个范围工作。困难在于将这些不同的动机集中成一项有凝聚力的努力。

Dean Troyer 我认为从宏观层面上看，这是重新评估我们现有结构的原因之一。我们是一个由企业驱动的项目，尽管个人努力保持独立，但企业的影响正在以个人可能没有预料到的方式被感受到，例如，“集成”是项目最有价值的属性，并且是许多公司管理人员投资的指标。

在个人层面上，我看到人们想要创造更好的云并创建让我们实现它的工具和组件。我们有一些程序需要完善（CLA 等），并且有一些重大的扩展问题需要解决（审查积压），以便保留和利用带到 OpenStack 的新贡献者的能量。

Anne Gentle 我认为您现在已经看到我在过去几年在技术委员会上代表跨项目影响的增长速度了。文档程序不得不调整期望并教育传入的程序，OpenStack 文档不仅仅是项目逐一的，而是一种伞式努力。人们来到 docs.openstack.org 获取 OpenStack 文档，而不是 nova 或 glance 文档。我希望我展现了面对增长速度的勇气和务实性。

Adam Lawson 我喜欢我今天早些时候读到的内容：“人们想要做有意义且喜欢做的事情的工作。” 这很好地概括了 OpenStack 贡献者，但它也概括了我们中的许多人，不是吗？我们中的许多人很幸运能够全职从事 OpenStack 工作。还有许多其他人以消费者、用户、运营商、解决方案架构师的身份与 OpenStack 合作，这并不是他们的全职工作，但他们出于其他原因参与 OpenStack 社区。无论出于什么原因（慈善、我的好外貌），人们都希望从事重要的事情，如果它不重要，就没有继续的动力。

即使我们意见不一致，我也看到社区内的友好互动。这很有动力。
我看到社区成员互相征求和提供帮助——即使是在技术上可以被称为竞争对手的公司之间。这很有动力。
我看到那些靠销售和支持 OpenStack 专有部署来谋生的人，向那些不使用他们的产品甚至可能永远不会使用他们产品的人提供他们的帮助和观点。这很有动力。

OpenStack 社区培养的文化令人钦佩，对于一个社交驱动的人（尽管我有点害羞），我必须说，只要技术委员会坚持并推进这种文化，那些渴望参与的人就会很容易找到动力。

对于那些需要一些帮助的人，我认为 Upstream University 是另一个鼓励新贡献者并让他们通过学习/知识以及看到他们的辛勤工作被无数公司和个人使用和消费来获得授权和动力的场所。John Griffith 我认为这个问题问的是“我认为激励真正致力于 OpenStack 的人的是什么”，所以我将以这种方式来回答它。有趣的是，肯定有许多公司拥有可以被认为是“军队”的贡献者。然而，在谈论动机时，重要的是激励贡献者本身的是什么；当然，我们中的许多人受到雇主和薪水的激励，毫无疑问，这会影响我们日常的决策。也就是说，在一天结束时，我与大多数人交谈的人只是喜欢成为社区的一部分并有机会成为开源专业人士。无论他们最终如何到达那里，在我看来，我定期合作的大多数人都是由 OpenStack 本身以及成为“大事”的一部分的机会所激励的。

Russell Bryant 人们想要做有意义且喜欢做的事情的工作。OpenStack 显然是一个产生巨大影响的项目。我们还需要确保它是一个令人愉快的社区参与其中。有很多事情可以使一些社区比其他社区更令人愉快。有我们想要避免的显而易见的事情，这些事情涵盖在社区行为准则 [15] 中。我认为感觉没有效率会损害动力。我们需要继续努力识别和解决阻碍完成工作的障碍。

Sean Dague 我不太确定这个问题的意图，但我会尝试一下作者可能想表达的意思。今天大量的 OpenStack 工作都是赞助的。其中一些非常以供应商为导向，用于 OpenStack 变更日志中供应商想要的功能，其中一些是热爱这个社区的人，并找到了支持它的人。我们社区中许多领导人没有与他们开始从事 OpenStack 工作时相同的公司这一事实证明了这种热情。

我真的希望看到更多的微型贡献者，以及更多的人觉得即使他们没有特权全职从事它，他们也能对 OpenStack 产生影响。

Doug Hellmann 我不知道我们是否有数字，但我的印象是，我们的大部分贡献来自至少部分受雇于从事 OpenStack 工作的人。他们对项目的整体承诺，超出他们的专业领域，因许多原因而异。我们希望每个人都对整个项目有强烈的承诺，但这并不总是现实的，因为它并不总是由个人来决定他们可以投入多少时间和精力来从事 OpenStack 工作，或从事特定领域的工作。这完全是正常的，可以接受的。我们可以并且确实欢迎来自各种各样的人的各种原因的贡献。

Zane Bitter 我不会，但既然你问了……OpenStack 不是一个业余爱好项目。没有主要的开源项目是这样的。绝大多数贡献者能够贡献是因为它对他们的雇主有益，要么是因为他们直接使用 OpenStack 解决问题，要么是因为他们销售与 OpenStack 互补的东西。我们需要尽可能地使贡献变得容易和愉快，以便第一组人能够贡献，以便第二组人能够在长期利益中贡献，而不仅仅是在短期利益中贡献。

Monty Taylor 我很确定我们的大多数贡献者都是作为他们工作的一部分来贡献的。我认为这使得我们的动态与“传统”开源项目有点不同。

也就是说，我看到了一群核心审查员，我不认识他们。这太棒了。

我无法说出每个人的动机——但我可以告诉你我的动机是什么。

云正在接管我们思考 IT 的方式。这不再是如果，而是什么时候。但即使这样，云也比一个目的地更像一个想法。当我们开始时，对“云”只有一个合法的定义，那就是亚马逊。亚马逊是一家由无情的独裁者运营的闭源公司。我不想生活在一个需要他的许可才能使用计算机的世界里。

在过去的四年里，我们已经取得了重大进展，重新定义了云可以是什么。容器和裸机现在是合法的构建块，我认为人们越来越理解你可以使用云来有效地运行除规模扩展的短暂计算模式以外的其他东西。

这个方向和这种转变是互联网保持开放和运行所必需的。我认为人们必须让它们发生。我很幸运能够为之做出贡献——所以我一直在从事 OpenStack。

主题：增长速度：OpenStack 技术社区的增长速度非常快，这是无可争辩的。这种速度带来了一些什么后果？

Dean Troyer 如上所述，当我们试图扩大集成项目的范围时，我们失去了重点。与其很好地完成少量事情，不如承受做很多事情的压力。

Anne Gentle 希望您现在已经看到我多年来在技术委员会上代表这种增长速度的跨项目影响。文档程序不得不调整期望并教育传入的程序，OpenStack 文档不仅仅是项目逐一的，而是一种伞式努力。人们来到 docs.openstack.org 获取 OpenStack 文档，而不是 nova 或 glance 文档。我希望我展现了面对增长速度的勇气和务实性。

Monty Taylor 有一些核心审查员，我不认识他们。这太棒了。

一些后果是，我们必须不断重新评估我们的工作方式。我确信这让人们感到沮丧——但我们已经多次重构了我们的组织和治理方式，因为每个先前的系统都达到了扩展的临界点。程序的引入就是一个例子——在2010年它们并不需要，但在2013年它们解决了一个问题。有可能它们作为一种组织结构已经过时了，或者有可能它们仍然有助于我们完成工作，但需要调整范围。关于“大帐篷目标导向门户”的讨论表明我们整体集成故事的脆弱性——再次由规模引起，并且意外地由我们实际参与并没有回避大规模 captive 集成带来的挑战所导致。

Sean Dague 增长速度使得大多数项目贡献者只贡献于他们的一个工作。随着时间的推移，每个项目的文化变得非常不同，对于每个项目可接受的补丁文化、可接受的审查文化、如何处理错误、什么被验证等等，都有了不同的标准。

当我加入这些项目时，其中一个不使用非 Python OpenStack 项目的口号是，共同的语言和共同的工具将意味着开发人员和操作人员可以轻松地从一个项目移动到另一个项目来解决问题。

我认为我们所看到的爆炸式增长，以及所有这些活动部件的统一集成所面临的挑战，表明统一体验不仅仅是共同的语言和工具。

我认为这也在很大程度上超出了横向工作的能力范围。文档、质量保证、稳定维护、安全，现在都必须做出选择，并留下很多内容被搁置。

举个例子：我最近开始处理 Nova 针对一个 14 个月前公开的安全问题的最终修复——https://bugs.launchpad.net/keystone/+bug/1188189。坦率地说，尚不清楚这个问题是否已在其他项目中完全解决。

Adam Lawson 我认为 Openstack 正处于经历前所未有的增长烦恼的临界点。我认为我们甚至没有触及当我们达到我们的长期采用目标/里程碑时，这些烦恼会是什么样子。但痛苦会带来改变，而带来改进的改变是好的。所以我们都能感觉到变革即将到来。

快速增长的一个后果可能是 Openstack 及其社区的不同领域之间的不成比例。代码可能会领先于文档，对流程的需求可能会领先于这些流程的定义，而规模需求可能会揭示所有那些我们过去一年一直乐于忽视的丑陋问题。

我不认为增长本身会带来后果。不想说陈词滥调，我认为 Openstack 正在接近与增长相关的挑战，我们需要将这些挑战视为真正的机会。只要我们专注于手头的任务，不要忘记“为什么”，不要让可能需要解决挑战的纠正措施受到影响，我认为我们将继续在周期中站稳脚跟。

Doug Hellmann 如此快速的增长迫使我们思考如何组织自己并明确、更快速地进行更改，而不是允许缓慢演变。我们已经有很多博客文章和邮件列表讨论了通过治理模式的改变来处理增长的方法。这些是我们作为社区需要做出的重要决定，我们需要仔细权衡每个问题的双方。

例如，我们希望更具包容性，并将更多的项目团队纳入 OpenStack，但这样做会进一步增加我们的跨项目团队帮助我们处理文档、基础设施和发布管理的容量压力。项目更多的创造性自主权可能会增加部署者和用户的复杂性，因为我们正在远离一致的模式。为创建新项目提供激励措施可能会减少对现有项目进行协作的激励措施，最终损害这两个项目。

制定我们对现有政策集所需的更改需要更多的思考和讨论 [1]，因为我们试图预测拟议更改的后果，并制定新的政策，这些政策足够灵活，可以继续维持健康的社区。

Eoghan Glynn 显然，我们正在接近增长路径上的一个拐点，即我们的跨项目关注点继续扩展以满足不断增长的需求的能力不再能被视为理所当然。

我的直觉是，首先检查我们如何组织这些跨项目关注点，看看是否可以提高可扩展性上限，然后再采取将这些跨项目资源分配给较少项目的路线。

John Griffith 确实，没有人能争辩说增长是巨大的。也没有人能争辩说存在后果。我之前关于 TC 当前角色和功能的声明（更准确地说，我的批评）是这种巨大增长的直接结果。我们开始使用的模型根本无法扩展到我们已经增长的水平。

我认为事情开始崩溃，首先是当前治理模型的有效性；但更糟糕的是，我认为我们阻止了“随意”贡献者。就个人而言，当我三年前第一次为 OpenStack 做出贡献时，当我提交的补丁更新在没有得到任何人审查的情况下空置两天时，我感到非常沮丧。目前，大多数人认为两天被认为是快速的周转时间。关键是，有好的想法和好的贡献的人在混乱中迷失了，他们不会再回来。

John Garbutt 是的，它正在伤害，并且它触及了所有方面。但这很有趣，并带来了新的想法和挑战，这使我们不断发展和适应。我们需要注意去学习那些阻碍我们的东西。

Russell Bryant 就像任何有增长的组织一样，我们有成长的烦恼。我会说识别和致力于这些成长的烦恼一直是 TC 所做的事情的核心部分。我预计这种情况将继续下去。下一轮似乎也不例外。

David Lyle 惊人的增长速度是我们的最大资产。它也是我们最大的痛点。我们需要重新评估我们的流程以应对这种增加的压力。我认为我们需要保持包容性，但要适度地减少生态系统对 OpenStack 跨项目资源的消耗。

Zane Bitter 最大的也是最重要的后果是，我们有很多才华横溢的贡献者正在努力解决用户真正存在的问题，并以 OpenStack 的方式公开地解决这些问题。另一个是，我们已经超出了在较小项目中具有意义的一些集中共享资源结构。我们需要致力于去中心化和建立沟通路径。

主题：新贡献者体验：您目前如何描述新贡献者的体验？

Anne Gentle 作为过去两年 GNOME 妇女外展计划的管理员，我帮助对实习生进行入职，他们必须提交补丁才能完成申请。实际上，之前的实习生在将新来者引入我们的社区方面做了大部分工作。我认为这是因为他们的眼睛对您在弄清楚我们独特的流程时会遇到的困难最为敏锐。我也对一个帮助他人学习的奇妙小社区的成长感到惊讶，这看到新贡献者涌入的最佳部分。我们已经做了很多工作来简化 git review 的安装，并专门设置 gerrit 远程仓库。因此，非常最初的入职体验可以变得更好。现在，我们几年前的体验也不是很好，因为审查越来越难通过，我们的门户塞满了想要进入的补丁。我认为我们可以同时改进两种体验，以使其对所有贡献者更好。

Doug Hellmann 毫无疑问，OpenStack 有一个陡峭的学习曲线，无论作为用户还是贡献者。

文档作为参考很有用，但没有什么能比有经验的指导者亲手帮助你更有效。当我开始贡献时，我受益于一对非正式的导师。他们引导我完成了设置我需要的工具和开发环境的漫长过程，直到我能够提交我的第一个补丁，帮助我充分利用设计峰会，并通常让我更容易进入社区。今天，社区中我们有一些正式的计划来匹配导师和新社区成员。这些计划值得我们支持，但从日常来看，我们都可以通过回答问题和自由分享我们的知识来互相帮助。

Sean Dague 太糟糕了。

24 步 CLA 疯狂，多个 ID，签署东西，才能达到提交你的第一个补丁的程度，这太疯狂了。

你只有一次机会给人留下第一印象，今天我认为贡献 OpenStack 的流程，甚至在上传到 Gerrit 之前，就足够繁琐，以至于我们阻止了大多数我们最好的未来 OpenStack 贡献者存在。

这需要改变。

Adam Lawson 我之前提到了 Upstream University，我认为重申一下，致力于重要的事情是激励人心的。

然而，我不认为维持现状是技术领导力（由 TC 提供）可以接受的方法。怪癖、“这就是我们一直以来做的方式”和“适应它”完全不可接受。如果我们认为这有助于改进，我们不能阻止改变，但我们也不能允许不必要或优先级不高的改变对我们整个项目的进展产生负面影响。

话虽如此，我确信为 Openstack 做出贡献的新贡献者（不仅仅是随意贡献）了解在高容量开源项目（如 Openstack）中做出贡献的动态。对于那些不了解的人来说，学习曲线可能很陡峭，但有益。我们需要小心不要为了包容性而牺牲流程。

如果我当选，我的一个目标将是通过流程（或流程）促进卓越的产品，从而实现经验丰富的开发人员的可扩展贡献管道——同时为刚刚开始使用 Openstack 开发节奏的人提供有效的入职流程。我认为优先级肯定需要在我们获得最大的收益的地方，因为我们的资源显然是有限的，但我希望有效的贡献者体验能够很好地适应新老贡献者，并且我希望如果我们失败了，我们不要害怕挑战现状。

Zane Bitter 我想猜想是令人沮丧的。这个过程从一堆需要跳过的障碍开始，最终以 CLA 结束。至少第一个补丁会收到友好的“欢迎新贡献者”消息。从那里，我们应该记住，体验因项目而异。较小的项目可能大部分都还好，但较大的项目难以提供新贡献者需要的及时反馈。在某些情况下，这会因官僚主义流程和审查吹毛求疵而加剧（可以概括为通常以程序为导向而不是以结果为导向的观点）。

Russell Bryant 我怀疑成为新贡献者会让人感到不知所措。加入如此庞大且活跃的项目，由于多种原因，令人望而却步。我欢迎并赞赏所有帮助入职新贡献者的努力。

David Lyle OpenStack 对新贡献者来说有很多优点。关于如何贡献的文档易于发现且非常全面。提交补丁所需的信息也呈现得很好。OpenStack 开发人员也是一个非常开放和包容的社区。新贡献者受到文明、尊重和赞赏的对待。我为此感到自豪，并努力保持这一点。从那里，贡献者的体验变得更令人望而却步。虽然关于入门的文档非常好，但仍然需要大量的流程和配置才能将该文档应用于贡献您的第一个补丁。希望贡献者的补丁是一个错误修复。一旦跨越了这一障碍，体验就会更好。补丁审查的周转时间也是一个很大的问题，并且再次回到处理 OpenStack 的规模问题。

我知道已经进行了许多关于 CLA 要求方面的讨论。对于大多数贡献者来说，这并不是什么阻碍。但是，我理解有些雇主不愿意让员工根据 CLA 要求做出贡献。我想努力包括这些贡献者。

John Griffith 我在之前的问题中稍微提到了这一点，但我想在这里添加更多内容。我认为大多数新贡献者的体验简直太糟糕了！更糟糕的是，我参与过讨论这个话题，有些人诚实地说“我不关心，那不是我的问题”。多年来，我听到 OpenStack 被称为“Ego Stack”，并且很多人告诉我它不是一个友好的环境。我认为我们中的许多人已经存在一段时间了，有时会认为 OpenStack 不仅仅是一个相当庞大且相当复杂的活动部件集合，而且我们还有一些非常具体的做事方式。我们有时也会对审查过于严厉（不是说这是好事还是坏事，只是说当我阅读审查评论时，我有时会为另一端的人感到难过）。

我认为我们都应该承担更多指导者的角色。关于这个话题，另一个经常出现的问题是CLA，邮件列表和一些人的博客文章中对此有很多讨论。我可能应该在这里分享我的观点，因为它似乎相关；我一直不明白这有什么大不了的，而且从来没有人告诉我他们因为这个原因不会为Cinder贡献代码，或者它给他们造成了任何不必要的负担。我当然不是说这些说法不真实或没有道理，我只是说，如果你正在寻找一位TC候选人来对抗CLA，我肯定会让你失望的。我真的不明白为什么这对于某些人来说是一个热门话题，我宁愿坦诚地表达我的看法，而不是忽视它。

Dean Troyer 贡献代码的机制（CLA、账户等）可以做得更好。我不认为CLA能带来价值。我看到的大部分初始贡献都只是微不足道的拼写错误修复之类的，因为他们需要专注于流程而不是内容才能开始。

Monty Taylor OpenStack针对高吞吐量进行了优化，牺牲了单个补丁的延迟。这意味着我们的一些流程可能对不同背景的人来说显得陌生或不透明。然而，考虑到该项目在过去相当长的一段时间内每六个月翻一番，如果解决这个问题会牺牲那些每周为OpenStack投入80小时的人的效率，我认为这并不是一个优先事项。

对于那些有一段时间没有参与其他开源项目贡献的人，我建议你去做一下。每个大型项目都有其自身的怪癖。我们的虽然很长，但文档记录良好且一致。

Eoghan Glynn 为了回答这个问题，我试着把自己想象回到我最初学习的阶段。当然，那时的项目和服务数量远没有现在这么多，但关键要素基本保持不变。

首先，好的方面...

我发现当时非常有用的一个方面是能够在虚拟机中轻松启动一个完整的迷你云，然后亲自动手尝试破译日志、窥探服务之间传递的消息、查看数据库等。考虑到我们日常工作中对它的高度依赖，很容易忘记devstack有多么有用。我发现它是一个巨大的助力，来自一个设置任何类型的生产环境模拟都非常棘手的情况。

我还发现各种“老手”乐于以友好和不带评判的态度回答我的愚蠢的新手问题。我们永远不应该低估我们社区的这种品质，任何过去曾与知识囤积作斗争的人都会证明我们在这方面的开放程度。

接下来，不好的方面...

我们在gerrit上有一种文化，新手有时会觉得他们被忽视了，或者至少他们的补丁没有得到他们期望的及时处理。我知道我曾经陷入过这种困境，在提交git推送后，几乎立即通过IRC对潜在的审查者进行全面施压。结果可想而知，适得其反。我认为我们可以通过从一开始就设定更现实的审查周转时间期望来更好地服务于新贡献者。

最后，丑陋的方面... ;)

啊，是的，那个许多人又爱又恨的贡献者许可协议。说实话，第一次遇到这个协议时，被要求签署它对我来说更像是一种烦恼，但由于过去几个周期一些TC成员的努力，我现在对这个看似不必要的法律主义对某些贡献者引入的实际和实际困难有了更清晰的认识。毋庸置疑，我将完全支持TC继续努力用开发者行为准则取代CLA。

John Garbutt 我很享受我被欢迎进入OpenStack社区的方式。但当时很可怕，现在肯定更糟了。我们都需要尽自己的一份力量，对人们保持开放和欢迎。

但我们可能应该看看有多少人正在离开我们的社区。我确实看到有人因为对贡献流程感到沮丧而退出。有时在感觉他们的想法被“撕碎”之后感到精疲力竭，或者感觉他们正在与毫无意义的官僚主义作斗争。解决方案很难，但感觉更好地记录流程的“意图”会有所帮助，更好地设定辩论的期望会有所帮助。我发现，与其试图“合并我的补丁”，不如更好地协作“解决我的问题”。

主题：沟通：你将如何描述OpenStack社区当前的沟通状态？

Zane Bitter 我们沟通很多，而且是公开的，这很好。难点在于过滤信息洪流。随着我们进一步分散，我们需要通过建立固定的（而不是临时的）沟通渠道来缓解这个问题，以便人们能够听到他们需要的信息，而不会被淹没。Oslo联络计划就是一个很好的例子，说明了如何实现这一点。

Anne Gentle 与如此庞大且不断增长的人群进行沟通可能很困难，但我认为我们拥有可用的渠道，并具有适合我们社区的自主选择策略。TC在许多渠道上倾听，我知道我仍然订阅了所有邮件列表，没有过滤器，并且我们努力撰写摘要博客文章，以便让每个人（而不仅仅是ATC列表订阅者）了解我们在做什么。我们理解它的重要性，并且TC中有许多优秀的作家和沟通者，他们将沟通作为优先事项。

Monty Taylor 如果你把这封邮件读到这里，那么沟通就很好。:)

在技术社区内部，我认为我们的沟通还不错。另一方面，突破我们的圈子需要改进。了解我们正在做什么作为内部人员已经很困难了，更不用说作为外部人员了。同样，由于我们针对开发者之间的沟通进行了优化，让运营商和用户发声也很困难。

Doug Hellmann 我们的发展使沟通更具挑战性，但我们正在适应。

规范流程有助于技术规划、设定期望和记录决策。尽管如此，我们还有很多举措与规范没有直接关联——特别是那些跨越项目边界和发布的举措。

我告诉Oslo团队，我本周期的座右铭是“写下来”，我的意思是，我们应该清楚地记录我们的讨论和决策，这样当某个话题再次出现时，我们不必依赖记忆。

沟通是维持健康的开源社区的关键。跟上可能很困难，但我们都必须关注其他团队发出的消息，留意任何相关内容，然后参与对话。

Sean Dague 我将“我们”理解为OpenStack社区中的我们所有人。最好的说法是碎片化。我们有邮件列表，但由于许多努力都在列表上（例如，Nova和Fuel在同一个列表上），这意味着许多事情都会丢失。我们有很多项目特定的IRC频道……但#openstack-dev上的流量却很少。据我所知，只有少数核心开发者目前正在监控#openstack-dev以获取有趣的内容，这给任何非专用跨项目工作增加了巨大的负担。

Russell Bryant 我们沟通的方式似乎与其他大多数开源社区非常典型。我们非常重视邮件列表和IRC。我们也有大量的面对面会议。对于那些能够参加的人来说，我认为它们很有帮助。我们需要继续关注那些无法参加所有活动的人。

John Garbutt 还不算太糟糕。我认为我们可以做得更好，为没有以前开源社区经验的人提供支持。有很多邮件，但标签似乎可以使过滤其中的一些邮件成为可能。

跨项目讨论似乎随着年中会议有所改善。当然，需要跟踪已决定的内容，并与那些无法参加的人分享。我希望有一天，我们能够实现有效的远程参与。

John Griffith 好的事情是，我认为考虑到我们面临的挑战，我们的沟通还算不错。我认为大多数人目前都通过IRC上的公开讨论和在邮件列表中提出问题和疑虑进行开放沟通。唯一的问题是，现在越来越难以跟上。因此，就社区的开放性和沟通而言，我认为我们做得很好。就沟通量和保持最新状态所需的精力而言，这有点让人不知所措。我认为你需要专注于最有趣或最适用于你自己的某些领域/项目。

Dean Troyer 有足够多的不同沟通渠道，以至于任何人很难监控所有渠道，同时还有时间编写代码。

Eoghan Glynn 我们有很多“官方”的沟通渠道：设计峰会、邮件列表、年中会议、gerrit、记录的IRC会议等等。所有这些都有其优点和缺点，但作为一个社区，我们正在学习如何使用和过滤它们，尽管它们像消防水管一样。

此外，还有一个新兴趋势，即重要的讨论是在这些官方渠道之外发起和发展，例如通过临时讨论和博客文章。我对这不太满意，因为这样的渠道更难进行双向的包容性对话。

此外，与任何我经历过的技术社区一样，有很多共享的“部落知识”存在于人们的脑海中。我可能和别人一样有罪，甚至更多。这只是每天发生的事情，因为知识积累的速度超过了将其记录下来的时间。然而，我们都需要尝试强迫自己花时间将这些知识片段写在一个可发现的地方，以便为后来者提供面包屑踪迹。

Adam Lawson 虽然我认为我们整体的沟通令人鼓舞，并且正在朝着积极的方向发展，但我认为跨项目以及开发人员和用户之间的沟通仍然是一个挑战。可以理解，因为你有多个邮件列表，有无数的更新和程序所有者和贡献者不可能阅读每条消息来查看是否有需要他们关注的事情。IRC和电子邮件是我们擅长的领域，但我设想将运营商峰会扩展到包括跨项目峰会，在2-3个互补的程序之间进行头脑风暴（例如，Swift/Sahara、TripleO/Ironic/Nova）将非常有益。我知道我们已经有了年中会议，但这种级别的协作甚至可能受益于一个专门的设计峰会。没有赞助商——只是一个技术方向共享聚光灯的OpenStack的地方。只是一个想法。

David Lyle 对于一个全球开发者社区来说，我认为沟通非常好。然而，从我收到的反馈来看，沟通的负担过重。拥有19多个公认的项目和20多个其他卫星项目争夺开发者的视线，对于贡献者来说，过滤和找到对他们重要的项目来说，这非常令人不知所措。我认为这主要是社区增长的另一个症状。

主题：与基金会理事会的关系：技术委员会在几个不同的方面与基金会理事会互动。你将如何描述这些互动？

John Garbutt 由于我以前没有在TC工作过，很难评论。看起来他们正在互相交谈，这很好。

David Lyle 作为过去几年技术委员会的观察者，我见证的公开互动主要集中在Def Core上。技术委员会和基金会理事会在这个问题上存在根本性的分歧。这是可以预料的，因为这两个机构的目标非常不同。理事会的角色是保护OpenStack商标，许多公司都为此投入了大量资金。允许商标具有非常广泛的定义可能会降低这项投资的回报。技术委员会由OpenStack的构建者组成，他们相信开放的开发流程。限制运营商使用OpenStack以满足商标应用方式，这与开放流程背道而驰。结果是僵局。我的立场是，OpenStack的组件是可替换的，商标的负担应该允许API兼容性，但我站在开发者这一边。

Doug Hellmann 我对技术委员会（TC）与理事会的关系印象比其他候选人要好一些。我们是不同的组织，有着不同的视角，但我们都在努力做我们认为对OpenStack项目最有利的事情，这意味着我们需要合作。在亚特兰大的面对面会议上，这种态度在某些方面表现了出来，而在IRC或电话会议中并不总是如此。我们在DefCore和CLA等问题上进行了激烈的辩论，对于拥有如此不同视角的组织来说，这是很自然的，但我们也在继续合作，寻找解决这些和其他问题的途径。

Zane Bitter 让TC和理事会在任何问题上达成一致是一项巨大的挑战，因为这个组合群体非常庞大（大约30人）。在这种规模下，讨论不可避免地会进展缓慢，而且理事会不像TC那样在会议之间进行广泛的公开讨论。培养关系很重要，但大部分工作仍将由联合小组委员会完成。

Eoghan Glynn 有趣的是，这两个治理结构的人员组成在某种程度上是交织在一起的。这显然给参与这两个组织的人带来了挑战，确保他们能够“转换角色”并适当地切换上下文。但至少可以确保理事会不会置身于象牙塔中，与日常技术领导脱节。就我所见到的实际互动而言，TC以明确的方式表达了他们希望切换到DCO的偏好，并让理事会一次性地处理CLA问题，这让我感到欣慰。

Adam Lawson 项目治理和技术领导之间存在天壤之别。我承认我还没有在TC的背景下与基金会成员坐下来讨论过，所以我无法说明它现在运作得好不好。但我可以说的是，我读过其他曾担任TC的候选人分享的内容，我的理解是情况似乎有些冷淡。

但我以前遇到过这种情况。无论如何，我认为明确定义基金会和TC的角色和责任，将有助于他们更有效地合作。我期待着亲身体验这种互动，并做出自己的判断。但在那之前，继续前进！

Russell Bryant 我们的互动正在改善。我们开始在OpenStack峰会上举行联合会议。在DefCore主题上，整个开发周期也进行了很多互动。我期待着继续与理事会合作，在有意义的领域进行合作。

Sean Dague 困惑吗？不，我的意思是，我很困惑，因为坦率地说，他们互动的方面似乎并不多。我对DefCore的看法很复杂，因为它似乎很多重要的工作是在旧金山的面对面会议上完成的。而且一直存在对意图的真正困惑。

除此之外，我觉得理事会/TC的互动并不多。亚特兰大的联合会议很好，我认为会议上提出的一些问题得到了讨论。但我认为理事会试图定义商业生态系统和市场动态，而TC试图定义一组能够完成特定功能的组件，并且即使添加了更多组件也能继续完成该功能，两者范围实际上非常不同。说实话，目前TC和理事会之间存在的脱节可能主要在于我们的角色似乎只有在商标定义附近才会重叠，因此基于各自面临的日常挑战，存在着截然不同的视角。

Monty Taylor 糟糕透顶，但正在好转。我们在亚特兰大举行了一次不错的TC/理事会会议，并计划在巴黎举行另一次会议。

我认为我们面临的最大问题是如何以富有成效的方式互相争论。TC和理事会都必须更好地直接和公开地表达彼此的观点，当我们觉得对方没有尽到责任时。在DefCore中，我们从理事会那里获得了一些信息，如果直接表达出来可能会更好——而且我认为一旦Rob和TC代表开始直接会面，这些问题就得到了更有效的解决。同样，TC刚刚通过一项决议，要求理事会考虑DCO作为我们的CLA。显然，理事会有权做任何事情——但我们有责任让他们知道我们的意见。

简而言之，我们正在学习如何在尊重界限的同时，诚实地表达需求，进行合作。这是一段旅程，我认为我们必须认真对待。

Anne Gentle 我们与理事会的互动包括电话会议、面对面会议和IRC会议。我个人认为面对面会议很有价值，因为更容易进行沟通，获得更丰富的反馈，从而了解互动的进展情况。在IRC上，输入/输出的丰富度有所权衡，但也具有精确的表达能力，能够在有更多思考时间时回顾，并且具有开放性，因为任何人都可以随时阅读互动内容。我们的理事会一直很稳定，多年来变化不大，这有助于随着时间的推移建立关系。我知道我可以联系到成员，并且成员在我寻求帮助时也确实帮助过我。我感觉我们都在努力应对增长速度，并感到我们无法像以前那样敏捷。但我们都致力于为所有人提供一个开放的云，我认为这种共同的使命增强了我们的互动。

John Griffith 嗯……好吧，我真的不确定。当我过去在TC时，理事会和TC之间确实没有太多的互动或沟通，而且我所经历的少数几次体验坦率地说，并不令人愉快或富有成效。所以我真的没有太多的见解，而且我所经历的（非常有限）经历并不好。

尽管如此，我相信在过去几个月里，已经做出了一些努力来改善这种情况，并以富有成效的方式增加互动和沟通，我认为这很好，而且非常需要。

Dean Troyer 我主要看到围绕DefCore工作的互动，发现双方似乎都不想说“这就是OpenStack”，因为害怕踩到别人的脚趾。

TC Elections October 2014

目录