Tobias Bernard解释了Gnome的电源结构

2021-06-14 22:23:29

GNOME社区的新人经常有很难了解我们如何设置目标,做出决策,承担责任,优先顺序任务等等。简而言之:他们想知道权力在哪里。

当您不知道如何运作的事情时,它很自然地提出了基于可用信息的合理的故事。例如,有些人直觉假设由于我们的产品在苹果和世界上的苹果和微软制作的功能和外观中,我们还必须以类似的方式组织。

这导致他们认为GNOME是由集中式公司开发的分层结构,其中开发人员由他们的经理分配任务,基于更高管理的路线图,营销部门协调公开的消息,等等。基本上,他们认为我们是一个技术公司。

人们制作客户服务风格投诉,就像他们买的公司他们买的公司

围绕资源的一般困惑如何分配(“当他们甚至没有y时,为什么他们在x上工作?”)

如果您已经在社区周围待了一段时间,您知道该项目的这种观点与事物实际工作的情况无关。但是,鉴于现实的复杂程度是多么复杂,有些人有这些误解并不奇怪。

要了解如何真正完成,我们需要检查所涉及的各种群体,以及它们如何互动。

GNOME基金会是一个拥有GNOME商标,托管我们的Gitlab等基础设施,组织会议,并雇用一家全日制GTK开发人员的美国非营利性。这意味着除了为所述GTK开发人员设置优先级,它几乎没有对发展的影响。

实际制作产品的人是志愿者(因此,对没有人回答),或者在一个雇用人们在侏儒各地工作的十几家公司中的一个工作。所有这些公司都有不同的兴趣和焦点领域,具体取决于他们使用GNOME如何,往往会贡献。

在实践中,“雇用”贡献者和志愿者之间的界线可以相当模糊,因为许多贡献者都支付了一些特定事物,而且还为他们的空闲时间贡献了Gnome的其他部分。

每个模块(例如App,库或系统组件)具有一个或多个维护者。他们负责审查拟议的变更,发布和一般管理项目。

理论上,每个模块的个体维护者对这些模块的绝对功率有更多或更少。它们可以合并对代码,添加和删除功能的任何更改,更改用户界面等。

但是,在实践中,维护人员很少在未经项目中与其他利益相关者咨询/沟通的情况下进行非琐碎的变化,例如与用户体验相关的事物的设计团队,受到改变影响的其他模块的维护者,或者如果依赖关系改变。

发布团队负责协调整个GNOME软件套件作为单个连贯产品的释放。

除了每年出去两大版本(加上各种点版本),他们还策划了什么和不是核心GNOME软件集的一部分,处理GNOME FLOTPAK运行时,管理依赖项,修复构建故障,以及其他相关任务。

释放团队有很大的力量,他们真的决定了什么,而不是侏儒的一部分。它们可以从核心集添加和删除应用程序,并设置系统范围的默认设置。但是,它们实际上并不实际开发或维持大部分模块,因此它们可以具体影响产品的程度是有限的。

对于自由软件项目Gnome可能有些异常,有一个非常活跃和备受尊敬的设计团队(如果我这样说:P)。与用户体验有关的任何东西都是他们的purview,并且在理论上他们有最终的说法。

这包括大多数主要产品举措,例如引入新的应用程序或功能,重新设计现有的应用程序,以及应用程序和系统的可视化设计,设计模式和指南等等。

但是:没有任何迫使开发人员遵循设计团队指导。设计团队的力量主要在于人们信任他们做出正确的决定,并与他们合作实施他们的设计。

没有人或团体最终通过自己的项目的方向有很大的力量。任何主要倡议都需要来自多个群体的人们共同努力。

信任其他团队的人们的能力,特别是当它不是您的专业领域时

相信人们首先关心Gnome(而不是说,他们的雇主的利益) 信任人们在长远来看(而不是试图迅速降落东西然后消失) 这种信任的氛围虽然在大多数参与者之间存在很少的直接沟通,但是跨越数十个模块和数百个贡献者的令人惊讶的顺利和高效的合作。 这总结了该系列的第一部分。 在第2部分中,我们将研究如何从概念到运输的功能的各种阶段。