fig-tlo

Many thanks to Cal Evans, Nate Abele, and Larry Garfield for peer reviewing this article. We appreciate our amazing peer reviewers for continuously making SitePoint content the best it can be!

非常感谢Cal Evans ， Nate Abele和Larry Garfield的同行审阅本文。 感谢我们出色的同行评审，他们不断使SitePoint内容达到最佳状态！

(Disclosures: I am one of the founders of the FIG. Along with Nate Abele, I am the longest continuously-serving Voting Member in the group. I was the primary driving force behind PSR-1, PSR-2, and PSR-4; their wide adoption has contributed greatly to the legitimacy of the FIG. I am recorded as the coordinator or sponsor on other PSRs as well. I assisted in creating some of the bylaws that hypothetically guide the members of the group, including a prominent role in writing the voting rules themselves. I was the subject of the secretaries’ first, and currently only, temporary ban from posting to the FIG mailing list. I was also the subject of a failed attempt to have me removed from the group. I oppose the FIG 3.0 proposal to re-constitute the group in place.)

( 披露：我是图的创始人之一。与Nate Abele一起，我是该小组中任职时间最长的投票成员。我是PSR-1，PSR-2和PSR-4背后的主要推动力我被记录为其他PSR的协调者或赞助者，并协助制定了一些章程，假设性地指导了该小组的成员，包括在我自己写投票规则。我是秘书的首要任务，也是目前唯一的临时禁止将其张贴到FIG邮件列表的对象；我也是试图将我从小组中撤离的失败对象。图3.0建议重新组建到位。)

另类期货 (Alternative Futures)

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

拉里·加菲尔德(Larry Garfield)在他的文章《 PHP-FIG的过去，现在和未来》中 ，从创建之初到其可能的未来之一，对他对FIG的印象进行了旋风之旅。 我鼓励您在继续之前完整阅读它。

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

在此，我将尝试解决Larry文章中的一些错误和遗漏，并为FIG提供两个其他可能的未来。

PHP-FIG 3.0：是否修订版？ (PHP-FIG 3.0: Too Revisionary?)

I have stated elsewhere that what I have called the “founding” vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as “revisionist history” and asserts the true founding intent was more in line with what I have called the “grand” vision (that is, an overarching standards group for all PHP coders, member projects or not).

我在其他地方已经说过，我所谓的FIG的“基础”愿景是专注于成员项目，在它们之间找到共同点，并整理这些共同点。 拉里(Larry)谴责我的说法是“修正主义者的历史”，并断言其真正的成立意图更符合我所谓的“宏伟”愿景(即，所有PHP编码人员(无论是否有成员项目)的总体标准组)。

To support his position, Larry quotes David Coallier’s post of Brett Bieber’s meeting notes.

为了支持他的立场，拉里引用了大卫·科利尔(David Coallier)在布雷特·比伯(Brett Bieber)会议记录中的帖子 。

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

本次会议的目的是开发一套PHP项目可以努力采用的通用标准。

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开发人员的资源提供。

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis’s post than Larry did:

拉里(Larry)也从特拉维斯·斯威斯古德 ( Travis Swicegood)那里说了类似的话。 与拉里(Larry)相比，我会引用特拉维斯(Travis)的职位：

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. … I’d love to see an officially sanctioned standard come out of our work. … When code is published for public consumption in a year, 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运行它”，我会很喜欢。

At first, this appears to be substantial evidence of Larry’s claim. However, one should remember that a “goal going into” a meeting is not the same thing as a “result coming out of” a meeting.

起初，这似乎是拉里主张的实质证据。 但是，应该记住，“进入”会议与“从会议中得到的结果”不是一回事。

So it may well be true that some of the participants had something more like the “grand” vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the “grand” vision. Instead, it was to adopt the more limited, “for the group members” approach.

因此，很可能有些参与者在初到时就想到了更像“宏伟”的愿景。 但是，我本人曾参加过首次会议，所以我个人记得，最终的决定不是追求“宏伟”愿景。 取而代之的是，采取更为有限的“为团体成员”的方法。

To provide more support than my own memory of the discussion, I submit the following:

为了提供比我自己的讨论更多的支持，我提交以下内容：

• Travis himself says in the same post linked above, “We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects.“

  特拉维斯说，自己在上面链接同一职位，“我们决定以形成我们项目的官方小组来监督这个标准和对工作在我们项目更好，更广泛采用的标准的创建。 “

• Cal Evans, also present at the meeting, presents a summary narrative:

  卡尔·埃文斯(Cal Evans)也在会议上作了总结性发言：

  • “To paraphrase the goal of this group, we are saying ‘Hey, we are all agreeing that we are going to code this way and we’d like you to do it to.'” (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating “That should have read: To paraphrase the goal of this group, we are saying ‘Hey, we are all agreeing that we are going to code this way.‘”)

    “为了解释这个小组的目标，我们说的是：“嘿，我们都同意我们将以这种方式进行编码，我们希望您这样做。”(这意味着Larry拥有正确的权利？不，Cal在随后的一封电子邮件中纠正了自己，并指出：“那应该读：为了解释该小组的目标，我们说的是：“嘿， 我们都同意我们将以这种方式进行编码。 ””)

  • In that same later email, Cal also says, “This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. … While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group.”

    在同一封电子邮件中 ，Cal还说：“该小组并没有把自己摆在最重要的位置，说我们最了解。 我们正在尝试找到许多项目之间的共同点， 以便全世界PHP开发人员可以在这些项目的代码之间移动，而不必每次都重新学习标准。 …虽然我很乐意看到该小组同意的标准被整个PHP社区广泛采用，但这不是该小组的目标。”

• Matthew Weier O’Phinney says, “We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. … Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. … If anything, we’re keeping a very close eye on the community, and involving them as much as possible — via our individual projects.“

  Matthew Weier O'Phinney说：“我们代表着大量的组件库和框架，拥有成千上万甚至数百万的用户。 我们代表该组中的那些用户 。 …第三，这些标准不是强制性的。 您可以采用或不采用它们。 我们只是推荐它们，并且承诺我们的代表性项目将使用它们。 …如果有的话，我们会密切关注社区，并通过我们的个人项目尽可能多地参与其中。 “

• Nate Abele’s recollection of the initial meeting is similar: “The point of coming together on the standards which we agreed to was to provide our collective user community with some semblance of interoperability between our projects, and provide a way forward for other projects who’d like to interoperate with ours as well.”

  内特·阿贝勒(Nate Abele)对初次会议的回忆是类似的：“将我们同意的标准集中在一起的目的是为我们的集体用户社区提供我们项目之间的某种互操作性 ，并为那些愿意我也希望与我们进行互操作。”

  Nate goes on to say, “Everyones has an individual choice whether or not they even find these standards useful for them, but we as project leaders have elected to use these standards in our code, so if you plan on using any of our projects, you’ll be using the standard anyway, so we might as well be open with people about what those standards are, just in case others do find them useful (which, in my arrogance, I’m going to suggest that, if we as lead developers and prominent community members do, then yes, others might as well).”

  Nate继续说：“每个人都有自己的选择权，无论他们是否认为这些标准对他们都有用 ，但是作为项目负责人， 我们选择在我们的代码中使用这些标准 ，因此，如果您打算使用我们的任何项目，无论如何，您都将使用该标准，因此我们也可能会与人们讨论这些标准的含义，以防万一其他人发现它们很有用(以我的傲慢，我建议，如果我们领导开发人员和杰出的社区成员，那么是的，其他人也可以)。

(All emphasis above is mine; spelling and grammar errors in quotes are as-written.)

(以上所有重点都是我的；引号中的拼写和语法错误均按原样书写。)

Contra Larry’s assertions, then, one can see that from the very beginning, the group resolved to focus on its own members. At the same time, we were aware not only that others would be watching and might choose to adopt our practices, but also that the group could speak only for its own members, and not for anyone else. That is, some might choose the FIG’s work as a “role model”; but then, the nice thing about role models is that yours do not have to be the same as everyone else’s.

因此，可以从Contra Larry的主张中看出，该小组从一开始就决心专注于自己的成员。 同时，我们不仅意识到其他人会注意并可能选择采用我们的做法，而且该小组只能代表自己的成员发言，而不能代表任何其他人发言。 也就是说，有些人可能会选择FIG的作品作为“角色模型”。 但是，关于角色模型的好处是，您不必与其他人一样。

To conclude: While Larry accuses me in his article of “protect[ing] a ‘fictional’ vision”, it would be more accurate to say that I strive to honor the true founding vision of the group — one that Larry appears to disagree with.

总结：虽然拉里在我的文章“保护[虚构”愿景中指责我”，但更准确地说是我努力兑现该组织的真正创始愿景-拉里似乎不同意这一观点。 。

图2.0工作流程 (The FIG 2.0 Workflow)

Larry seems to think that the new workflow bylaw model is quite a success:

Larry似乎认为新的工作流程章程模型相当成功：

Under that [new workflow bylaw] model, the group passed the PSR-4 autoloading > standard, PSR-6 cache standard, and PSR-7 HTTP messaging standard.

在该[新工作流程条例]模式下，该小组通过了PSR-4自动加载>标准，PSR-6缓存标准和PSR-7 HTTP消息传递标准。

Larry’s narrative here is somewhat misleading. While it is true that PSRs 4 and 6 passed after that bylaw was put in place, those PSRs were transitional cases. PSRs 4 and 6 began before the workflow bylaw, saw significant work, and then were re-adopted by the group after the workflow bylaw was instituted around 2013 Aug.

拉里在这里的叙述有些误导。 确实，在制定该章程后，PSR 4和6才获得通过 ，但这些PSR是过渡性案例。 PSR 4和6开始于工作流程细则之前，经历了重大工作，然后在2013年8月左右制定工作流程细则后被小组重新采用。

To this date, there have been four PSRs that began and finished before the workflow bylaw, two PSRs produced that began before the bylaw and finished after its institution, and only one that began and finished after the workflow bylaw:

迄今为止，已经有四个PSR在工作流程章程之前开始和完成，有两个PSR在该章程之前开始并且在其机构建立之后完成，只有一个PSR在工作流程章程之后开始和完成：

• Pre-bylaw (“FIG 1.0”) – PSR-0 (2010 Nov) – PSR-1 (2012 Jun) – PSR-2 (2012 Jun) – PSR-3 (2013 Jan)

  章程(“ FIG 1.0”)– PSR-0(2010年11月)– PSR-1(2012年6月)– PSR-2(2012年6月)– PSR-3(2013年1月)

• Transitional (started under 1.0, finished under 2.0) – PSR-4 (2013 Dec) – PSR-6 (2015 Dec)

  过渡版(从1.0开始，在2.0以下完成)– PSR-4(2013年12月)– PSR-6(2015年12月)

• Post-bylaw (“FIG 2.0”) – PSR-7 (2015 May)

  章程后(“ FIG 2.0”)– PSR-7(2015年5月)

So, it is difficult to show as yet that the workflow bylaw is a significant aid to producing completed PSRs.

因此，目前还很难证明工作流程章程对于生成完整的PSR至关重要。

测量FIG的影响 (Measuring FIG’s Impact)

Larry tries to quantitatively measure the impact of FIG across all of PHP-land:

拉里(Larry)试图定量衡量FIG在整个PHP领域中的影响：

The various PSRs that FIG has published have, of course, impacted the PHP community far beyond the handful of member projects. … The PSR-3 logger has been installed, according to Packagist, over 37 million times. For PSR-7, it’s around 11 million.

当然，FIG出版的各种PSR对PHP社区的影响远远超出了少数成员项目。 ……据Packagist称，PSR-3记录仪已安装了3700万多次。 对于PSR-7，大约为1100万。

Number of downloads sure seems like a good objective metric, one that quantifies the impact of a package. But you have to be careful to make sure that a metric measures what you think it does. Counting “downloads” can be confounded by a small number of very popular packages that use a PSR package. Further, it is misleading to present numbers without context; they should always be presented in comparison to something else.

当然，下载数量似乎是一个不错的客观指标，该指标可以量化软件包的影响。 但是，您必须小心以确保度量标准可以衡量您认为的功能。 少数使用PSR软件包的非常流行的软件包可能会混淆“下载”的计数。 此外，在没有上下文的情况下提供数字也会产生误导； 应该始终将它们与其他事物进行比较。

I offer a modified way of measuring the number of authors affected by PSRs: the number of dependent packages. This will tell us how many different packages, regardless of their download popularity, use the PSR packages. This should give us some indication (though imperfect) of the number of developers who integrate the FIG work into their own work.

我提供了一种改进的方法来衡量受PSR影响的作者数量：相关软件包的数量。 这将告诉我们有多少个不同的软件包，不管它们的下载受欢迎程度如何，都使用PSR软件包。 这应该给我们一些表明(尽管不完美)的将FIG工作集成到自己的工作中的开发人员的数量。

Since Larry used Packagist, I’ll use that as well. Here are the “installs” (number of downloads) and “dependents” (number of Composer requires in other packages) for the FIG-originated PSR packages:

由于Larry使用过Packagist，因此我也会使用它。 以下是源自FIG的PSR软件包的“安装”(下载数量)和“从属”(其他软件包中的Composer require的数量)：

So: the authors of 165 packages use psr/cache, 1943 use psr/log, and 711 use psr/http-message.

因此，165个软件包的作者使用psr/cache ，1943年使用psr/log ，711个使用psr/http-message 。

By way of comparison, here are three non-PSR packages originating outside of FIG. (These are not randomly selected; they are merely the first ones that came to my mind.)

通过比较，这是源自图2外部的三个非PSR封装。 (这些不是随机选择的；它们只是我想到的第一个。)

This is to say that the authors of 1313 packages use doctrine/dbal, 792 use nesbot/carbon, and 711 use vlucas/phpdotenv. These packages are not the result of FIG deliberations. They exist entirely outside of the PSR process. And yet they have a comparable number of installs, and almost identical reach (in terms of dependents) across the wider PHP landscape.

也就是说，1313个软件包的作者使用doctrine/dbal ，792个使用nesbot/carbon ，711个使用vlucas/phpdotenv 。 这些软件包不是FIG讨论的结果。 它们完全存在于PSR流程之外。 但是，它们的安装数量相当，并且在更广泛PHP环境中，其覆盖范围(从属方面)几乎相同。

Again, I recommend caution when interpreting the “dependents” count. There can be confounding factors there as well to bias the results. For example, some of the non-FIG packages have been around longer than the FIG ones, so perhaps the PSR packages will catch up given time. Or, one author could create a large number of packages with the same dependents.

同样，我建议在解释“受抚养人”计数时要谨慎。 那里也可能存在混淆因素，使结果有偏差。 例如，某些非FIG软件包的时间比FIG更长，因此PSR软件包可能会在给定的时间赶上。 或者，一位作者可以创建具有相同依赖项的大量软件包。

But even so, this comparison should give proponents of the “grand” vision pause. The FIG’s reach across the entire PHP community may not be as great as they think it is. The attempt to position the FIG as a standards group over all of PHP-land, in light of this comparison, seems presumptuous and conceited.

但是即使这样，这种比较也应该使“宏伟”愿景的支持者停下来。 FIG在整个PHP社区中的影响范围可能没有他们想象的那么大。 根据这种比较，试图将FIG定位为整个PHP领域的标准组，这似乎是自负和自负的。

FIG的合法性来源 (FIG’s Source of Legitimacy)

Larry claims that FIG has a responsibility to live up to:

Larry声称FIG有责任履行：

FIG has effectively become the standards body for PHP. It took time for it to earn it, but it did …

图实际上已经成为PHP的标准主体。 它花了一些时间才能赚到，但是确实做到了……

It’s time for FIG to embrace that reality and help build a better PHP ecosystem for all.

现在是FIG拥抱现实并为所有人构建更好PHP生态系统的时候了。

Perhaps FIG has come to be seen as that, correctly or not. If it has, any legitimacy the FIG has earned has come specifically from not being a formal standards body. The FIG has already helped to “build a better PHP ecosystem for all”, and it has done so by concentrating on its member projects, per the “founding” vision.

也许正确或不正确地将图视为那样。 如果有的话，那么FIG所获得的任何合法性特别是由于它不是正式的标准机构。 FIG已经帮助“为所有人构建了一个更好PHP生态系统”，并且它根据“基础”愿景专注于其成员项目。

The benefits of that work under the “founding” vision have been adopted throughout that ecosystem, indirectly and voluntarily. It did so without being a self-appointed standards body over all PHP programmers. Thus, to claim that a formal body is necessary to achieve “a better PHP ecosystem” is an unsupported assertion.

在“基础”愿景下，这项工作的好处已在整个生态系统中被间接地和自愿地采用。 这样做并非是所有PHP程序员都可以自行任命的标准机构。 因此，宣称正式机构对于实现“更好PHP生态系统”是必要的，这是不受支持的主张。

备选方案1：独立互操作组 (Alternative 1: Independent Interop Groups)

Larry makes several observations about how FIG works, and who works on what, in his article. His observations there are difficult for me to summarize.

拉里(Larry)在他的文章中对无花果的工作原理以及谁在做什么上做了一些观察。 我很难总结他的看法。

However, Michael Cullum (the other author of the FIG 3.0 proposal) has written a TL;DR of FIG 3.0 that does provide a relevant summary:

但是，Michael Cullum(图3.0提案的另一作者)编写了图3.0的TL; DR，它确实提供了相关摘要：

• Everyone has equal say on FIG PSRs, no matter their expertise or their project’s relevance in the PSR’s problem space

  无论他们的专业知识或项目在PSR问题空间中的相关性，每个人都对FIG PSR有平等的发言权

• There are lots of clever awesome people involved in the FIG who are not > project representatives

  FIG中有很多聪明的，很棒的人，他们不是>项目代表

• Member projects find it difficult to engage in everything going on in the FIG

  成员项目发现很难参与图中发生的所有事情

• There is an ongoing question if the FIG produces PSRs for member projects or for the wider community; especially when the wider community pays it so much attention due to its de-facto status as ‘the php standards body’.

  FIG是否为成员项目或更广泛的社区产生PSR，这是一个持续的问题。 特别是当更广泛的社区非常重视时，由于其事实上的“ PHP标准组织”地位。

As for the fourth point, I hope my commentary above has shown that there is no reasonable question that the FIG PSRs are intended primarily for its member projects; others are free to adopt or ignore them as they see fit.

关于第四点，我希望上面的评论表明，没有合理的疑问，FIG PSR主要用于其成员项目。 其他人则可以自由选择采用或忽略它们。

The first three points, though, are all solvable by encouraging *-interop groups, along the lines of container-interop and async-interop. Doing so would solve the top three TLDR points with almost no changes at all to the current FIG structure:

不过，前三个要点都可以通过鼓励*-interop组来解决 ，它们遵循container-interop和async-interop的思路。 这样做将解决当前的FIG结构几乎完全没有变化的前三个TLDR点：

• A *-interop project concentrates on its particular problem, and can invite (or draw the attention of) those who have relevant expertise. Both container- interop and async-interop were able to this successfully.

  *-interop项目专注于其特定问题，并且可以邀请(或吸引)具有相关专业知识的人员。 容器互操作和异步互操作都能够成功地做到这一点。

• A *-interop project need not be limited to only project representatives. It can bring in anyone it wants, according to the desires of the project leads.

  *-interop项目不必仅限于项目代表。 它可以根据项目负责人的需求吸引任何想要的人。

• Interested parties can engage in as many, or as few, *-interop projects as they like, choosing their own level of involvement.

  感兴趣的各方可以根据自己的*-interop选择参与多少个*-interop项目。

Encouraging independent interop groups solves all the TLDR points with less bureaucracy, less centralization, reduced hierarchy, fewer committees, more flexibility, and greater openness. It also gives some level of proof that the proposal put forth by the interop group has actually been adopted across multiple projects, and is ready for recognition. When the interop group is ready, it can come to the FIG (if it wishes) with a well-vetted proposal in place.

鼓励独立的互操作组以更少的官僚主义，更少的集中化，更低的等级，更少的委员会，更大的灵活性和更大的开放性解决所有TLDR问题。 它还提供了某种程度的证据，表明互操作小组提出的建议实际上已在多个项目中采用，并且已经准备好被认可。 当互操作组准备就绪时，可以进入图(如果愿意的话)，并提供经过适当审查的建议。

However, encouraging independent interop groups does not solve the unstated problem of “early prestige”. That is, forming an independent interop group does not give your work the character of being “a standard for all of PHP land” before anyone is actually using your work. For some proponents of FIG 3.0, I opine that “early prestige” is a feature, not a bug.

但是，鼓励独立的互助小组并不能解决“提早声望”这一尚未阐明的问题。 也就是说，在没有任何人实际使用您的工作之前，组建一个独立的互操作组不会使您的工作成为“所有PHP领域的标准”。 对于图3.0的某些支持者，我认为“早期声望”是功能，而不是错误。

备选方案2：解散无花果 (Alternative 2: Disband the FIG)

A second alternative is to declare that the FIG, as originally envisioned, no longer serves a useful purpose, and should disband, perhaps to make room for some other organization.

第二种选择是声明，最初设想的FIG不再有用， 应该解散 ，也许为其他组织腾出空间。

As a founding member of the group, I do not suggest this alternative lightly. However, doing so would give recognition to several realities, as I discuss in my “FIG Follies” blog posts (part 2 and part 3). Those realities are:

作为该小组的创始成员，我不会轻易提出其他选择。 但是，这样做将使我认识到一些现实，正如我在“ FIG Follies”博客文章( 第2 部分和第3部分 )中所讨论的那样。 这些现实是：

• There are currently two rival visions competing within the FIG: one that holds to the “founding” vision, and one that holds to the “grand” vision of FIG 3.0 as a standards body for all of PHP-land.

  当前在FIG中有两种竞争的愿景：一种坚持“基础”愿景，一种坚持作为所有PHP-land的标准主体的FIG.3.0的“宏伟”愿景。

• Just because a change has been voted in, does not mean it cannot be voted out again later. As such, mere votes will not be enough to settle the matter, since the losing side will be well within its rights continue to press its case. The problem is one of world views.

  仅因为更改已被投票通过，并不意味着以后不能再次投票。 因此，仅选票是不足以解决此事的，因为败诉方将在其权利范围内，继续对案件施加压力。 问题是世界观点之一。

• The best long-term solution is for one set of vision-holders to explicitly renounce their vision, and perhaps also exit the FIG. However, neither set of vision- holders is willing to withdraw, since the FIG’s legitimacy and reputation (as earned under the “founding” vision) are too great an asset relinquish.

  最好的长期解决方案是让一组愿景持有者明确放弃他们的愿景，也许还退出图。 但是，这两个愿景持有者都不愿意退出，因为FIG的合法性和声誉(在“基础”愿景下获得的)是一项巨大的资产放弃。

As such, it may be better to disband the group entirely. This effectively means that the different vision-holders surrender to each other simultaneously, rather than continue their rivalry over the FIG.

因此，最好完全解散该小组。 这有效地意味着不同的视觉持有者同时向对方投降，而不是继续与图竞争。

When disbanding the group, the FIG should entrust its assets to an archivist to maintain the PSRs, website, and so on, all in their current state. This leaves the actual productive output of the FIG (i.e., the PSRs) available for posterity. The archivist would hold the FIG name and accounts in trust, and guard them from ever being used again. The archivist might also merge errata and insubstantial changes on existing accepted PSRs.

解散该组时，FIG应将其资产委托给档案管理员，以将PSR，网站等保持在当前状态。 这使得图的实际生产输出(即，PSR)可用于后代。 档案管理员会信任地保存FIG名称和帐户，并防止再次使用它们。 档案管理员可能还会合并勘误表和对现有已接受PSR进行的实质性更改。

Disbanding also leaves the field open for another group to form. If another standards-related group does arise after FIG disbands, that group will need to earn its own way, with its own achievements, under a new name.

解散也使该领域开放给另一个小组形成。 如果在FIG解散后确实出现了另一个与标准相关的小组，则该小组将需要以新的名字赢得自己的成就和成就。

I discuss more details about this alternative in my FIG Follies Part 3 post.

我将在“ FIG Follies第3部分”中讨论有关此替代方法的更多详细信息。

结论 (Conclusion)

Larry has recently called a vote on the FIG 3.0 proposal, which means it is now in the hands of the FIG voting members. If it passes, the above two alternatives may no longer be possible.

拉里(Larry)最近呼吁对FIG 3.0提案进行投票 ，这意味着它现在由FIG投票成员掌握。 如果通过，则以上两种选择可能不再可行。

In my opinion, voting for the proposal means that the FIG’s official opinion of itself will change from “we think we know what’s best for us” to “we think we know what’s best for you.” I believe this would be a change for the worse.

在我看来，对提案投赞成票意味着FIG的官方意见将从“我们认为我们知道最适合我们的东西 ”变为“我们认为我们知道最适合您的东西” 。 我相信这将使情况变得更糟。

翻译自: https://www.sitepoint.com/php-fig-alternatives-the-pros-and-cons-of-various-visions/

fig-tlo