fig-tlo_PHP-FIG的过去，现在和未来

迷南。 2022-12-03 09:26 136阅读 0赞

fig-tlo

The PHP Framework Interoperability Group (PHP-FIG, or just FIG for short) is at a crossroads. Many electrons have been sacrificed talking about FIG’s tribulations of late, but sadly much of it has been FUD, with little effort spent on the positive. At SitePoint’s invitation, I’d like to offer a more positive outlook on FIG and the PHP community, and demonstrate why FIG can, and should, continue to have a positive impact on the PHP ecosystem.

PHP框架互操作性小组(PHP-FIG，或简称为FIG)正处于十字路口。 最近，许多电子都被牺牲掉，讨论了FIG的分布，但可悲的是，其中大部分是FUD，几乎没有花任何精力在正极上。 应SitePoint的邀请，我想对FIG和PHP社区提供更积极的看法，并说明为什么FIG可以而且应该继续对PHP生态系统产生积极影响。

![Illustration of an ancient War Council][]

By way of introduction, I am the FIG representative for Drupal and have been continually since November 2009, just shy of 7 years now, making me one of the longest-running FIG representatives. I was the Editor of PSR-6 and the current Editor of PSR-13, and also helped on the PSR-3 and PSR-7 specifications in particular. Along with Phil Sturgeon I helped design the current FIG workflow for PSRs. On the Drupal side, I was one of the main drivers behind Drupal 8 adopting PSR-0 and PSR-3.

作为介绍，我是Drupal的FIG代表，自2009年11月以来一直担任该职位，距现在只有7年的时间，这使我成为运行时间最长的FIG代表之一。 我是PSR-6的编辑者，也是PSR-13的当前编辑者，尤其是在PSR-3和PSR-7规范方面也有所帮助。 我与Phil Sturgeon一起帮助设计了PSR的当前FIG工作流程。 在Drupal方面，我是Drupal 8采用PSR-0和PSR-3的主要推动力之一。

## 不舒服的开始 **(**An Uncomfortable Beginning**)** ##

FIG was founded in 2009 under the name “PHP Standards Group” after an initial meeting at php\[tek\] in Chicago in May. Initially it was setup with a mailing list at standards@lists.php.net, with the purported goal of establishing its first spec — the [PSR-0][] autoloading standard — and presumably others as community-wide standards.

FIG于5月在芝加哥的php \[tek\]举行了首次会议之后，于2009年以“ PHP Standards Group”的名义成立。 最初，它是通过在standards@lists.php.net上的邮件列表进行设置的，据称其目标是建立其第一个规范( [PSR-0][]自动加载标准)，并可能将其作为整个社区的标准。

The unsurprising “who do you think you are?” backlash to that presumption was swift and decisive, and the group was quickly thrown off of lists.php.net, instead setting up a Google Group for coordination. Little else was done by the PHP Standards Group for the next few years, other than admitting a few additional people/projects in late 2009 (including yours truly, representing Drupal). The PHP Standards Group hadn’t yet earned the right to call itself that in the eyes of the community.

毫不奇怪，“您认为自己是谁？” 对此推定的强烈反对是决定性的，该小组很快就脱离了lists.php.net，而是成立了一个Google小组进行协调。 PHP标准小组在接下来的几年中几乎没有做其他事情，除了在2009年末接受了一些其他人员/项目(包括您的代表Drupal的人)。 PHP Standards Group尚未获得在社区眼中自称的权利。

## 缓慢但稳定的增长 **(**Slow but Steady Growth**)** ##

Fast forward to October 2011. After being completely dead for 2 years, the group started to come alive again. It renamed itself to the hopefully-less-controversial “Framework Interoperability Group”, although it still had no effective bylaws nor a defined mission statement, working instead on “whatever we decide to work on.” Among the specs that were tackled in that period were the [PSR-1][] coding standards, [PSR-2][] coding style standards, and [PSR-3][] logging interface.

快进到2011年10月。在完全死了2年之后，该小组又重新恢复了生命。 尽管它仍然没有有效的章程或明确的使命声明，但它仍将自己重命名为希望较少争议的“框架互操作性小组”，而是致力于“无论我们决定如何努力”。 在此期间解决的规范包括[PSR-1][]编码标准， [PSR-2][]编码样式标准和[PSR-][PSR-3] 3日志记录接口。

There was some debate around whether interfaces were even “fair game” for FIG to define, since it had no mission statement. Therefore, in March 2013 I ran a poll to gauge whether those involved in FIG (both project members and otherwise) favored “soft specs” (like coding standards) or “hard specs” (like interfaces), and the [results came back][] solidly for “all of the above, but with lean toward interfaces”. A [similar poll][], shortly afterward, showed a modest lean toward forward-looking but practice-informed specs (rather than “only document what’s been done” or “build new stuff from whole cloth” extremes).

由于接口没有任务说明，因此对于接口的定义是否甚至是“公平游戏”存在一些争议。 因此，在2013年3月，我进行了一项民意测验，以评估参与FIG的人员(无论是项目成员还是其他成员)是否偏爱“软件规格”(例如编码标准)还是“硬件规格”(例如接口)， [结果][results came back]对于“以上所有内容，但都倾向于界面”。 不久之后的一次[类似民意测验显示][similar poll] ，它对前瞻性但具有实践依据的规格略有倾斜(而不是“仅记录已完成的工作”或“从整体上构建新的东西”)。

Despite the “framework” in the name, FIG was also never limited to just “framework-ish” projects. Aside from being an extremely ill-defined word to begin with, FIG’s membership quickly grew to the point that pure-framework members were a decided minority alongside stand-alone libraries, CMSes, Wikis, e-commerce suites, and other stand-alone applications. The benefits of collaboration and interoperability are not limited to “frameworks”.

尽管名称中有“ framework”(框架)的名称，FIG也从来不仅仅局限于“ frameish-ish”项目。 除了最初的定义非常不明确之外，FIG的成员资格Swift发展到这样一个程度：纯框架成员与独立的库，CMS，Wiki，电子商务套件和其他独立的应用程序一起成为决定性的少数群体。 。 协作和互操作性的好处不仅限于“框架”。

Participation in FIG was also ill-defined. The initial founders were mostly project leads, but not entirely. Early on, there were many debates on whether members were “people” or “projects”; that is, were FIG members ambassadors acting on behalf of their projects, or were they simply people determined “cool enough” to have a vote for life by virtue of happening to lead a project? That was put to a vote in April 2013, and the bylaws clearly amended to make voting representatives ambassadors on behalf of their project. Despite the clear result, a select few refused to acknowledge that decision and act as though it never happened; there was some validity to their claim as in practice one is always interacting with a person, not with a “project”, and humans are humans, but the group and the bylaws had spoken.

对图的参与也不清楚。 最初的创始人主要是项目负责人，但不是全部。 早期，关于成员是“人”还是“项目”的争论很多。 就是说，FIG的大使是代表他们的项目行事，还是只是人们刚好确定自己“够酷”，以通过碰巧领导一个项目来对生命进行投票？ 该法案已于2013年4月付诸表决，并且对章程进行了明确修订，以使有投票权的代表代表他们的项目。 尽管取得了明确的结果，但仍然有少数人拒绝承认这一决定，并且表现得好像从未发生过。 他们的主张有一定的道理，因为在实践中，人们总是与人互动，而不是与“项目”互动，人是人，但是团体和章程已经讲过。

Another issue that arose was the ownership of a spec in development. Technically no one was responsible for anything, so multiple specs (those which became the PSR-4 autoloading standard and the PSR-6 caching standard) had multiple competing versions from different people and no one could keep track of which was the “real” version. Clearly that was suboptimal.

出现的另一个问题是开发规范的所有权。 从技术上讲，没有人负责任何事情，因此多个规范(这些规范成为PSR-4自动加载标准和PSR-6缓存标准)具有来自不同人员的多个竞争版本，没有人可以跟踪哪个是“真实”版本。 显然，这不是最理想的。

In July of 2013, therefore, the group adopted a new workflow bylaw, authored primarily by Phil Sturgeon and myself, which defined a clear Editor, Coordinator, and Sponsor for a PSR in draft, creating the skeleton of a working group. Under that model, the group passed the [PSR-4][] autoloading standard, [PSR-6][] cache standard, and [PSR-7][] HTTP messaging standard.

因此，该小组于2013年7月采用了新的工作流程章程，该章程主要由Phil Sturgeon和我本人撰写，为草稿中的PSR定义了明确的编辑，协调员和赞助者，从而创建了工作组的框架。 在该模型下，该小组通过了[PSR-4][]自动加载标准， [PSR-6][]缓存标准和[PSR-7][] HTTP消息传递标准。

## 社区影响 **(**A Community-Wide Impact**)** ##

The various PSRs that FIG has published have, of course, impacted the PHP community far beyond the handful of member projects. Defined standards in a vacuum have a way of doing that.

当然，FIG出版的各种PSR对PHP社区的影响远远超出了少数成员项目。 真空中定义的标准可以做到这一点。

*  PSR-0 was a key enabler for Composer, which has transformed the PHP ecosystem.
    
    PSR-0是Composer的关键推动力，它已经改变了PHP生态系统。
 *  PSR-1 and PSR-2 together are now a preset in many IDEs, which makes them the default coding standard for nearly all PHP projects (except a select few with massive code bases that predate PSR-2, for whom switching is impractical despite pressure to do so).
    
    现在，PSR-1和PSR-2一起已成为许多IDE中的预设，这使它们成为几乎所有PHP项目的默认编码标准(除了少数具有PSR-2之前的大量代码库的人，尽管面临压力，但切换是不切实际的)这样做)。
 *  The PSR-3 logger has been installed, [according to Packagist][], over 37 *million* times. For PSR-7, it’s around 11 million.
    
    [根据Packagist的说法][according to Packagist] ，PSR-3记录器已安装超过3700 *万*次。 对于PSR-7，大约为1100万。
 *  The PSR-7 HTTP messaging standard has spawned a cottage industry of experimentation with HTTP middleware that has already been adopted to some degree or another by many if not most major projects.
    
    PSR-7 HTTP消息传递标准催生了一个对HTTP中间件进行试验的家庭工业，该工业已经在某种程度上被许多(即使不是大多数)大型项目采用。

Despite its contentious beginnings, FIG has effectively become the standards body for PHP. It took time for it to earn it, but it did, thanks to the work of dozens of people, both FIG members and not. A [Reddit thread][] started last January showed that, while not universal, there was a clear preference for FIG to step up and accept that role formally.

尽管有争议的开始，FIG实际上已经成为PHP的标准主体。 它花了一些时间才能赚到，但是由于许多人的辛勤工作，无论是无花果成员还是无花果，它的确做到了。 去年1月启动的[Reddit线程][Reddit thread]表明，虽然不是通用的，但显然FIG倾向于采用并正式接受该角色。

Today, FIG has a number of specs in various stages of development, ranging from just-getting-started to nearly-complete, including:

如今，FIG在开发的各个阶段具有许多规范，从入门到接近完成，包括：

*  [PSR-9][] ([background][]) and [PSR-10][] ([background][background 1]) – Security reporting and automated security advisories.
    
    [PSR-9][] ( [背景][background] )和[PSR-10][] ( [背景][background 1] )–安全报告和自动安全公告。
 *  [PSR-11][] ([background][background 2]) – Dependency Injection Container interoperability.
    
    [PSR-11][] ( [背景][background 2] )–依赖注入容器的互操作性。
 *  [PSR-12][] ([background][background 3]) – Revised coding standards to take PHP 7 into account.
    
    [PSR-12][] ( [背景][background 3] )–修改了编码标准，以考虑到PHP 7。
 *  [PSR-13][] ([background][background 4]) – Hypermedia link handling.
    
    [PSR-13][] ( [背景][background 4] )–超媒体链接处理。
 *  [PSR-14][] ([background][background 5]) – Event manager/dispatcher.
    
    [PSR-14][] ( [背景][background 5] )–事件管理器/调度程序。
 *  [PSR-15][] ([background][background 6]) – HTTP Middleware for PSR-7.
    
    [PSR-15][] ( [背景][background 6] )–用于PSR-7的HTTP中间件。
 *  [PSR-16][] ([background][background 7]) – A simplified, simple-case cache interface (designed to easily wrap PSR-6).
    
    [PSR-16][] ( [背景][background 7] )–简化的简单案例缓存接口(旨在轻松包装PSR-6)。
 *  [PSR-17][] ([background][background 8]) – HTTP Factories for PSR-7.
    
    [PSR-17][] ( [背景][background 8] )– PSR-7的HTTP工厂。

Most of the Editors of those proposals are not themselves FIG members. Whatever the intent of the initial half dozen people, FIG has long since grown beyond its humble beginnings.

这些建议的大多数编辑者本身都不是FIG成员。 无论最初的六打人的意图如何，FIG早已超越了不起眼的起点。

## 成长的烦恼 **(**Growing Pains**)** ##

Nevertheless, FIG’s internal process hasn’t grown up with the group as well. Initially modeled on the free-for-all chaos of PHP-Internals, it has adopted process as needed. (Although it might be more accurate to say that it initially wasn’t modeled on anything other than “we haz a mailing list”.) Many people in recent years have pointed out FIG’s structural issues.

但是，FIG的内部流程并未随小组一起发展。 最初以PHP-Internals的所有混乱为模型，并根据需要采用了过程。 (尽管也许说它最初不是基于“我们没有邮件列表”以外的模型来建模，但可能更准确。)近年来，许多人指出了FIG的结构性问题。

*  Being a project lead doesn’t necessarily make someone the best at designing standards, whether interface standards or more “soft” specs.
    
    成为项目负责人并不一定会使某人在设计标准方面最出色，无论是接口标准还是更多的“软”规范。
 *  Most project leads, or their representatives, have plenty of things on their plate besides FIG and so frequently pay attention only during votes, even if then. Several votes have failed simply due to lack of quorum, and many mundane administrative tasks simply went unaddressed as no one knew who was supposed to even do them.
    
    大多数项目负责人或其代表除了FIG之外，还有很多事情要做，因此即使在投票时也要经常注意。 仅仅由于缺乏法定人数而导致几张选票失败，而且许多平凡的行政任务根本没有解决，因为没人知道谁应该这样做。
 *  Although the single Editor makes for a clear point-of-authority, that person may not be the only, or best, authority on the topic of a given spec. In an ideal case, many people directly involved in or impacted by a spec would have an equal seat at the table.
    
    尽管单个编辑者提供了明确的授权点，但该人可能不是给定规范主题的唯一或最佳授权。 在理想情况下，许多直接参与规范或受规范影响的人都可以在席位上享有平等的席位。
 *  The process is still too opaque to outsiders, and even to some insiders. It’s sometimes difficult to tell where to get involved in a given spec, as there’s no consistency at all.
    
    对于外部人员，甚至对于某些内部人员而言，该过程仍然是不透明的。 有时很难说出要加入给定规范的位置，因为根本没有一致性。
 *  The membership rules still privilege project leads over anyone else; the PHP community has dozens upon dozens of smart, skilled developers who would be valuable to have working on specs, but because they’re not a project lead or a lieutenant of a project lead, they’re never allowed a vote.
    
    会员规则仍然是特权项目的领导者。 PHP社区中有数十名聪明，熟练的开发人员，他们对制定规范很有价值，但是由于他们不是项目负责人或项目负责人，因此他们永远都不会投票。
 *  Despite that, the idea that FIG’s work impacts only member projects has become, as shown above, almost comically naive. Yet only a select few are even welcome at the table.
    
    尽管如此，如上所示，FIG的工作仅影响成员项目的想法几乎变得可笑天真。 然而，只有少数几个人受到欢迎。

In late 2015, FIG added a 3-person Secretary position, elected by project reps, to handle managerial tasks but stay out of technical tasks. I personally feel that change has been a resounding success, as managerial tasks are actually getting done now, and the secretaries have been able to help standardize and formalize much of the necessary paperwork around creating specs. (There’s more to it than just talking a bit!) Still, though, FIG is incomplete.

2015年底，FIG增加了一个由项目代表选举产生的三人秘书职位，以处理管理任务，但不参与技术任务。 我个人认为变更已经取得了巨大的成功，因为管理任务实际上已经完成，并且秘书们能够帮助标准化和规范化有关创建规格的许多必要文书工作。 (不只是说一点而已！)但是，FIG还是不完整的。

That came to a head in December 2015 and into January, with [several][] [threads][] discussing FIG’s various shortcomings. I tried to draw them together into a broader view of the “[State of FIG][]” in mid-December, which spawned a lengthy but lively conversation, largely with agreement on the problems. That included discussion of the process followed by other standards bodies, including [ISO and IETF][]. That, in turn, led me to post, in mid-January, a [proposal concept inspired by IETF][] that I dubbed “FIG 3.0”. (FIG 2 being the Editor/Coordinator/Sponsor model from 2013, FIG 1 the total free-for-all before that.) I encourage those who are interested in the subject to read at least the start of those threads for background.

在2015年12月到1月间达到[了][several] [顶峰][threads] ，有[多个][several] [线程][threads]讨论了FIG的各种缺点。 我试图在12月中旬将它们汇总为“ [无花果状态][State of FIG] ”的更广阔视野，这引发了一场漫长而生动的对话，并在很大程度上同意了这些问题。 其中包括对其他标准机构(包括[ISO和IETF)][ISO and IETF]遵循的过程的讨论。 反过来，这又促使我在1月中旬发布了[受IETF启发][proposal concept inspired by IETF]的[提案概念][proposal concept inspired by IETF] ，我将其称为“ FIG 3.0”。 (图2是2013年的编辑器/协调器/赞助商模型，图1是之前的全部免费。)我鼓励那些对主题感兴趣的人至少阅读这些线程的开头作为背景。

The proposal met with widespread approval, although not universally so. I therefore set about turning the brain dump into a more formal change to the bylaws, with a great deal of help from Michael Cullum, which was [posted to the list][] in April.

该提案获得了广泛的认可，尽管并非普遍如此。 因此我开始转向大脑转储到该章程更加正式的变更，与迈克尔·卡伦，这是帮助大量的[发布到列表][posted to the list]中的四月。

## 图3.0 **(**FIG 3.0**)** ##

The full proposal is viewable in the [pull request][], and Michael has written a [very good summary][] of its major changes. I will summarize them only briefly here.

完整的建议可以在[pull请求中][pull request]查看，Michael对其主要更改进行了[很好的总结][very good summary] 。 在这里，我将仅简要概述它们。

First, and most importantly, it adds a for-reals mission statement to FIG:

首先，也是最重要的是，它向FIG添加了一个真实的任务说明：

> The PHP Framework Interoperability Group (The PHP FIG) aims to advance the PHP ecosystem and promote good standards by bringing together projects and people to collaborate. It develops and publicises standards, informed by real-world experience as well as research and experimentation by itself and others, to form PHP Standard Recommendations (PSRs).
> 
> PHP框架互操作性小组(PHP FIG)旨在通过将项目和人员聚集在一起进行协作，以改进PHP生态系统并提高良好标准。 它根据实际经验以及自身和其他人的研究和实验来制定和发布标准，以形成PHP标准建议(PSR)。

That is not actually a new concept. It is formalizing, in writing, what FIG is already doing and has been for some time, and supported by the polls conducted previously.

这实际上不是一个新概念。 它正在以书面形式正式确定FIG在做什么并且已经有一段时间了，并得到先前进行的民意调查的支持。

Second, Working Groups become larger with a minimum size of 5. Those Working Group members can be project-affiliated or not, but are intended to be those with a direct stake in a given spec. Cache library authors for a caching library, for instance, or asynchronous library implementers for a PSR on Promises. Those directly-impacted people have a clear “seat at the table”, and a vote in the Working Group itself before a PSR is approved, even if they’re not a member project. Moreover, the final vote cannot happen until there are at least two implementations in existence that demonstrate that a proposal is both viable and likely to be adopted by someone. This change is derived directly from IETF.

其次，工作组的规模最小为5个。这些工作组成员可以是项目下属的，也可以不是项目下属的，但这些成员是在特定规格中具有直接利益的成员。 例如，用于缓存库的缓存库作者，或用于Promises上PSR的异步库实现者。 这些直接受影响的人有一个明确的“议席”，并且在批准PSR之前在工作组中进行投票，即使他们不是成员项目也是如此。 此外，只有在存在至少两种实施方案证明某项提议既可行又可能被某人采纳后，才能进行最终表决。 此更改直接来自IETF。

Third, the final vote on the spec, after the Working Group is done with it, is handled by an elected 12-person Core Committee. The Core Commitee’s job is to maintain consistency and excellence in all of FIG’s work, balancing both established patterns and forward-looking developments, and act as semi-outside reviewers of the Working Group’s efforts. They may be project representatives or not; that opens up FIG participation even further to the many experts in PHP who are not project leads. Moreover, they are elected not just by project representatives but by anyone who has been actively involved in FIG; that includes all Working Group members, who may or may not be project representatives.

第三，在工作组完成对规范的最后表决后，由当选的12人核心委员会处理。 核心委员会的工作是在FIG的所有工作中保持一致性和卓越性，平衡既定模式和前瞻性发展，并担任工作组工作的半外部审核者。 他们可能是项目代表，也可能不是。 这使非项目领导PHP专家甚至进一步参与了FIG。 而且，它们不仅由项目代表选举，而且由积极参与图的任何人选举产生。 包括所有工作组成员，他们可能是也可能不是项目代表。

The project representatives, then, need only be involved at select times for voting on the Core Committee and when their project is relevant to a Working Group, which they can then join. If not, then their silence or uninvolvement doesn’t impact quorum or otherwise hinder the development of a spec that’s irrelevant to them anyway.

因此，项目代表仅需要在选定的时间参与核心委员会的投票，并且他们的项目与工作组相关时就可以参加。 如果不是这样，那么他们的沉默或不参与不会影响仲裁或以其他方式阻碍与他们无关的规范的制定。

The Secretary position continues essentially unchanged; The Core Committee and Secretaries are peers, equals handling different parts of FIG. The Secretaries keep the machinery working while the Core Committee provides both technical oversight for the Working Groups and an “outsider’s view” to a given spec.

秘书的职位基本上保持不变； 核心委员会和秘书是同行，等同于处理图2的不同部分。 秘书让机制保持运转，而核心委员会既对工作组提供技术监督，又对给定的规范提供“局外人的看法”。

That addresses, I believe, most of FIG’s structural challenges today while creating an environment in which the PHP community can work more efficiently and effectively to everyone’s benefit.

我相信，这解决了FIG当前的大多数结构性挑战，同时创建了一个环境，在该环境中PHP社区可以更有效地工作，从而使每个人都受益。

## 太有远见了吗？ **(**Too visionary?**)** ##

Although the proposal early on met with broad approval, it has more recently met with some opposition. The primary objection is that it is “too far” from FIG’s original purpose, and it should either therefore be abandoned or used as the foundation for a new group, possibly with FIG itself shutting down in response. Paul Jones in particular has [repeatedly declared][] that it is against the “founding vision” of FIG, which was exclusively to standardize existing practice for member projects only.

尽管该提案在初期得到了广泛的认可，但在最近却遭到了一些反对。 主要的反对意见是，它与FIG的原始目的“相距太远”，因此应该放弃它或将其用作新组的基础，可能是FIG本身因此而关闭。 特别是保罗·琼斯(Paul Jones) [一再声明][repeatedly declared] ，它违反了FIG的“基础构想”，该构想仅是为了规范成员项目的现有实践。

However, the “founding vision” of the PHP Standards Group, [according to the moderator of the original meeting][] where it was founded, was for a closed group without public involvement. At the same time, influencing new, not-yet-created, not-member projects was clearly a goal:

但是，PHP标准组成立[的最初会议的主持人认为][according to the moderator of the original meeting] ，PHP标准组的“成立愿景”是针对没有公众参与的封闭组。 同时，影响尚未创建的，尚未成立的新项目显然是一个目标：

> I would love it if the first comment on blog posts or mailing list messages announcing the new code is “wow, that’s great, but you should run it through phpcs.”
> 
> 如果对发布新代码的博客文章或邮件列表消息的第一条评论是“哇，那太好了，但是您应该通过phpcs运行它”，我会喜欢的。

The [first non-test post to the list][], from David Coallier, stated unambiguously:

大卫·科利尔(David Coallier)的[第一篇非测试文章][first non-test post to the list]明确指出：

> Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards **provided as a resource for all PHP developers**.
> 
> 每个项目可能都有特定的标准，这些标准可以扩展并进一步定义应如何使用这些标准，但是目标是将一组PHP标准**作为所有PHP开发人员的资源提供** 。

(emphasis added) and

(添加了重点)和

> A central, moderated mailing list to discuss PHP coding standards was proposed, to be hosted on lists.php.net. The list shall have public archives and **unmoderated posting privileges will be granted by election by those with posting privileges**. Each major project may have more than one member, but each project shall have only 1 vote towards standards decisions and membership.
> 
> 提出了一个讨论PHP编码标准的中央审核邮件列表，该邮件列表托管在list.php.net上。 该列表应具有公共档案，具有**发布特权的人员将通过选举授予不受限制的发布特权** 。 每个重大项目可能有不止一个成员，但是每个项目对标准决策和成员资格只有一票表决权。

(emphasis added).

(添加了重点)。

It was only *after* the backlash, on the original [php-standards list][] and elsewhere that the party line shifted to be “just for us”. However, if we want to look for the founder’s vision, there it is: A closed list creating standards “as a resource for all PHP developers.” And nowhere in those statements is there a claim to only standardize “what has already been done”.

只是*在*强烈反对之后，在原始的[php-standards列表][php-standards list]和其他地方，派对路线才转变为“只为我们而已”。 但是，如果我们要寻找创始人的愿景，那就是：创建标准的封闭列表“作为所有PHP开发人员的资源”。 在这些陈述中，没有地方声称只能标准化“已经完成的事情”。

The closed list idea was abandoned very early. The “just for us” line was mostly a defense against the (valid) accusations of over-reach. And no mention whatsoever of being only backward-looking.

封闭列表的想法很早就被放弃了。 “只为我们而定”这句话主要是针对(有效)超范围指控的辩护。 更不用说只是向后看了。

Clearly to claim the vision of “the founders” was strictly a backward-looking, for-us-only organization is revisionist history.

显然，声称“创始人”的愿景严格来说是一种回顾主义的历史，它是一个向后看，仅供我们使用的组织。

## 一个新的小组？ **(**A new group?**)** ##

A number of people have proposed that the FIG 3 changes should not be adopted by FIG, but by a newly-created organization instead. The argument goes that FIG’s job is done, and a new group would be able to proceed without any of the karma that FIG has accrued, good or bad. That too, I feel, is an odd argument to make.

许多人提出，图3的更改不应被图采用，而应由新创建的组织采用。 有论据认为FIG的工作已经完成，并且新团队将能够继续前进，而无需FIG产生的任何业力(好坏)。 我认为，这也是一个奇怪的论点。

Today, FIG has no mission statement. So how can it be declared “done”? There’s no acceptance criteria defined! The closest we have is an entry in the FAQ on the website, which states FIG exists to “talk about the commonalities between our projects and find ways we can work together”. Given the number of PSRs in some stage of development right now, there still seems to be plenty to talk about.

今天，FIG还没有任务说明。 那么如何将其声明为“完成”？ 没有定义接受标准！ 我们最接近的是网站上常见问题解答中的条目，其中指出FIG存在以“谈论我们的项目之间的共性并找到我们可以一起工作的方式”。 鉴于目前处于发展中某个阶段的PSR数量众多，似乎还有很多话要讨论。

Any good karma that FIG has built up over the past 7 years is not the property of a select few. It is the result of the blood and sweat of everyone that has worked on any spec that had been adopted and is in use, both project reps and not, everyone that has talked up FIG at conferences or in their projects, and everyone whose developer lives have been made better by FIG’s work. Most of those people were not founders of the group. In fact, most of the original founders stopped being active in FIG long ago.

FIG在过去7年中建立的任何良好业障都不是少数几个人的财产。 这是每个人都在努力采用和采用的任何规范(无论是项目代表)还是不是所有人，在会议上或他们的项目中谈论过FIG的每个人以及开发人员生活的每个人的辛勤工作的结果通过FIG的工作已经变得更好。 这些人大多数都不是该组织的创始人。 实际上，大多数原始创始人在很久以前就不再活跃。

Conversely, any bad karma that FIG has built up won’t magically go away by using a different name for a new group. If it’s obviously a continuation of FIG (which to anyone who cares it would be), few FIG detractors are going to suddenly reset their opposition to it. And those whose issue isn’t with FIG but with select members of FIG would only care whether or not those individuals are involved.

相反，FIG积累的任何不良业力都不会为新组使用不同的名称而神奇地消失。 如果它显然是FIG的延续(对于任何关心它的人都是如此)，那么几乎没有FIG的批评者会突然对他们重新提出反对。 而那些问题不是图的问题，而是图的选择成员的问题，只会关心那些个人是否参与其中。

Could a new organization work? As long as FIG itself shut down and publicly stated that the new organization was its successor, it probably could. That seems an excessive amount of rigamarole and politics just to protect a fictional “vision”, however.

一个新的组织可以工作吗？ 只要FIG本身关闭并公开声明新组织是其继任者，它就可能会这样做。 但是，为了保护虚构的“视觉”，似乎存在过多的琐事和政治。

The worst case scenario would be for a new group to form yet FIG not shut down. Then PHP would end up with two competing standards bodies, which rather defeats the purpose of having a standards body.

最坏的情况是要形成一个新的组，而FIG不会关闭。 然后，PHP最终会有两个相互竞争的标准机构，而这违背了建立标准机构的目的。

## 结论 **(**Conclusion**)** ##

FIG has had a tumultuous history, to be sure. However, is history has a very clear trajectory: toward more community participation and toward a more robust structure to support such participation. Its founding as “the PHP Standards Group” included publicly stated goals of being of use to the entire PHP community. In practice, it cannot be otherwise; PHP projects are no longer islands, so standards adopted by many projects eventually have an impact on almost all projects. The entire concept of interoperability cannot succeed if only member project “cool kids” adopt them.

可以肯定，无花果有动荡的历史。 然而，历史有一个非常清晰的轨迹：朝着更多的社区参与和朝着更强大的结构来支持这种参与的方向发展。 它的创建者是“ PHP标准组”，其中包含公开声明的目标，即要在整个PHP社区中使用。 实际上，不能这样； PHP项目不再是孤岛，因此许多项目采用的标准最终会对几乎所有项目产生影响。 如果只有成员项目“酷孩子”采用它们，那么整个互操作性概念就无法成功。

FIG 3 is the next step in that evolution, and an important one. FIG has, over the last 7 years, earned a place as the de facto PHP Standards Group. It’s time for FIG to embrace that reality and help build a better PHP ecosystem for all.

图3是该演进的下一步，也是重要的一步。 在过去的7年中，FIG成为事实上PHP Standards Group之一。 现在是FIG拥抱现实并为所有人构建更好PHP生态系统的时候了。

> 翻译自: [https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/][https_www.sitepoint.com_the-past-present-and-future-of-the-php-fig]

fig-tlo

[Illustration of an ancient War Council]: /images/20221123/d5c9e2c9b7df4f5db7bd90823df96a19.png
[PSR-0]: http://www.php-fig.org/psr/psr-0/
[PSR-1]: http://www.php-fig.org/psr/psr-1/
[PSR-2]: http://www.php-fig.org/psr/psr-2/
[PSR-3]: http://www.php-fig.org/psr/psr-3/
[results came back]: https://groups.google.com/d/msg/php-fig/yS08ZRvFqdM/HXB3gYnblUUJ
[similar poll]: https://groups.google.com/d/msg/php-fig/3hPX9N0eru4/TTQelgrPoBAJ
[PSR-4]: http://www.php-fig.org/psr/psr-5/
[PSR-6]: http://www.php-fig.org/psr/psr-6/
[PSR-7]: http://www.php-fig.org/psr/psr-7/
[according to Packagist]: https://packagist.org/packages/psr/log
[Reddit thread]: https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/
[PSR-9]: https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md
[background]: https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication-meta.md
[PSR-10]: https://github.com/php-fig/fig-standards/blob/master/proposed/security-reporting-process.md
[background 1]: https://github.com/php-fig/fig-standards/blob/master/proposed/security-reporting-process-meta.md
[PSR-11]: https://github.com/container-interop/fig-standards/blob/master/proposed/container.md
[background 2]: https://github.com/container-interop/fig-standards/blob/master/proposed/container-meta.md
[PSR-12]: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
[background 3]: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
[PSR-13]: https://github.com/php-fig/fig-standards/blob/master/proposed/links.md
[background 4]: https://github.com/php-fig/fig-standards/blob/master/proposed/links-meta.md
[PSR-14]: https://github.com/php-fig/fig-standards/blob/master/proposed/event-manager.md
[background 5]: https://github.com/php-fig/fig-standards/blob/master/proposed/event-manager-meta.md
[PSR-15]: https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware.md
[background 6]: https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware-meta.md
[PSR-16]: https://github.com/php-fig/fig-standards/blob/master/proposed/simplecache.md
[background 7]: https://github.com/php-fig/fig-standards/blob/master/proposed/simplecache-meta.md
[PSR-17]: https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory.md
[background 8]: https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory-meta.md
[several]: https://groups.google.com/d/msg/php-fig/zNhayZyXsEw/mfPm1zibCAAJ
[threads]: https://groups.google.com/d/msg/php-fig/RK9UuZjt8j4/-fC76gPRCAAJ
[State of FIG]: https://groups.google.com/forum/#!msg/php-fig/oqO1ZH5tJKU/-tLYaJWVCQAJ
[ISO and IETF]: https://groups.google.com/d/msg/php-fig/oqO1ZH5tJKU/3eV3bw2CEAAJ
[proposal concept inspired by IETF]: https://groups.google.com/d/msg/php-fig/oqO1ZH5tJKU/9yEGYFy7EwAJ
[posted to the list]: https://groups.google.com/d/msg/php-fig/h3wrQePdzfc/ZLYSatxNCAAJ
[pull request]: https://github.com/php-fig/fig-standards/pull/752
[very good summary]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b
[repeatedly declared]: http://paul-m-jones.com/archives/6384
[according to the moderator of the original meeting]: http://travisswicegood.com/2009/06/02/my-goals-for-the-php-standards-group/
[first non-test post to the list]: http://news.php.net/php.standards/2
[php-standards list]: http://news.php.net/php.standards/start/1
[https_www.sitepoint.com_the-past-present-and-future-of-the-php-fig]: https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/