(jp) =
貢献してくださる方へ PHP、ユーザーランド開発者から。
に積極的に取り組んでいる人々に感謝することから始めましょう。 PHP 事業。 コア、拡張機能に貢献したり、ドキュメントを維持したり、投票したりする人 RFCs: 仕事でも私生活でも毎日使える言語をありがとう。 PHP は長年にわたって私にとって非常に便利なツールであり、多くの貢献者が毎日それを改善するのを手伝ってくれているのを見るのは良いことです.
また、私は皆と同じように、確証バイアスの影響を受けやすいことにも言及したいと思います。 この手紙で 1 つか 2 つの考えを述べるときは、できるだけ客観的になるように最善を尽くしますが、自分のレンズを通して見ているのであって、他の誰かのレンズを通して見ているわけではありません。
この手紙の目的は会話を始めることなので、皆さんのご意見をお待ちしております。 また、私の意見と一致しない場合は、遠慮なく同意してください。
たくさんの良いことを列挙することで続けることができます — たくさんあります. とはいえ、私はこの手紙の話題を維持したいので、そうはしません。 私が不満を持った開発者であるとは思わないでください。言いたいことを効率的に伝えたいだけです。
方法について書きたいと思います PHP 最近形作られ、開発されています。 私は、ユーザーランド開発者として、使用について少し知っていると感じています PHP 実際のプロジェクトで。 私は、この件に関して情報に基づいた適切な意見を持っていると信じています。
最近、私たちは、 RFC 投票プロセス。 投票規則の最近の変更に加えて、いくつかの物議を醸すものもありました RFC投票を通過し、いくつかの、場合によっては多くの論争を引き起こした.
最近の 2 つの RFC頭に浮かぶのは、短い開始タグの非推奨と、いくつかの小さな非推奨のタグです。 PHP 7.4.
両方 RFCこれらの変更が言語にとって実際に有益かどうか、わずか 2/3 の多数決で許可されるべきかどうか、言語に有害であると見なされるべきかどうかについて議論を引き起こしました。 PHP コミュニティ。
これらの議論のほとんどの根拠は、 PHP 可能な限り下位互換性を維持しようとします。 この背後にある主な考えの 1 つは、ユーザーに最新の状態を維持してほしいということです。 PHP バージョンであるため、アップグレードの問題をできるだけ少なくする必要があります。
当然のことながら、5.* の時代から教訓を学びました。 私もすべての意見に同意します PHP 開発者とエコシステムは最新の状態を維持するよう努めるべきです。 これは、企業や開発者がすべてのプロジェクトの開始時にクライアントに伝える必要があるメッセージです。安全で最新の状態に保つには時間と費用がかかり、それを回避する責任ある方法はありません。
プロフェッショナリズムの特徴です。
一方で、クライアントと一緒にこのプロフェッショナリズムを達成したい場合は、アップグレードに妥当な時間を費やすことも許可されています. 後方互換性のない変更があっても、世界の終わりではありません。 対処できます。
日常のユーザーとして PHP、更新が必要なレガシープロジェクトの共有もありました。 これを教えてください：私ははるかに好きです PHP 私がアップグレードに費やす時間を減らすのではなく、前進して成熟することです。
成熟した言語では、いくつかの古いレガシーがクリーンアップされていることは明らかです。 これは、言語が同じことを行うために 2 つの方法を削除する場合があることを意味します。 これは、たとえば、短い開始タグが非推奨になり、削除されたことを意味します。 これは、コードが壊れることがあることを意味します。 そして、言語が健全で健全な方法で進化する限り、私は気にしません。
あなたが後方互換性の熱心な警備員の 1 人なら、あなたの言いたいことがよくわかります。 しかし、あなたがそれから作ることはそれほど大したことではないと思います。 破壊的な変化があるからといって、世界が終わるわけではありません。 私たちユーザーランド開発者が管理します。
終わりのない議論を何度も繰り返して時間を無駄にしないようにしましょう。 バランスよく前に進みましょう。
時間の使い方といえば。 内部では、投票の仕組みと物議を醸すものをどうするかについて話し合ってきました RFCもう何ヶ月も。
他のコミュニティがこれをどのように行っているかを調べ始めるべきではありませんか? 確かに PHP そこにある唯一のオープンソース言語になることはできませんか?
現在の方法を呼び出しましょう PHPそれが実際に何であるかについての開発：同じ議論が毎週または毎月ベースで何度も繰り返され、何の進展もありません。 人々は定期的に他人を個人的に攻撃しています。 取るに足らない RFC 数か月の議論が必要で、承認後に再投票が必要です。 大規模なメーリング リスト以外に、建設的なフィードバックを共有する良い方法はありません。 有権者のグループは実際の正確な表現ではないようです PHP コミュニティ。
このシステムは、少なくとも部分的には壊れていると言っていいのでしょうか?
私たちのシステムは徹底的に評価されるべきだと思います。 したほうがいい 外部のオープンソース コミュニティがどのように機能するかを見てください。 PHP 健全な方法でプロジェクトを前進させ続けることができます。
一例は TC39、管理する委員会 エクマスcript、別名 JavaScript。 アクセル・ラウシュマイヤー博士は、 TC39 プロセスが動作します。 JavaScript が好きか嫌いかは別として、この言語が何年にもわたって成功を収めていることを考えると、JavaScript がすぐに何かを行っていることは明らかです。
彼らが正しく理解していることの 1 つは、コミュニティとのオープンなコミュニケーション チャネルです。 GitHub を介したコントリビューターとユーザーの間の透過的でアクセス可能なコミュニケーション。 これを行うもう 1 つの言語は Rust で、言語がどのように形成されているかを議論するためのオープン フォーラムを提供します。
GitHub やフォーラムのようなオープンな場所は、ほとんどのユーザーランド開発者が内部メーリング リストで経験する障壁を減らします。 私たちの多くはそれを読んでいますが、実際に意見を表明できると感じているユーザーランド開発者はほとんどいません。 これには、次の 2 つの理由があると思います。
- メーリング リストは、フォーラムやスレッドに比べてナビゲートするのが難しい
- 基本的な良識と適切な節度が欠けている、敵対的な場所であることが多い
より良いコミュニケーションにより、2 つのグループ間の現在の切断が解消され、 PHP 実際の大多数になる PHP ユーザーはそれを望んでいます。
コミュニケーション以外に、言語にどのような機能を追加するかという問題があります。 TC39 言語がどのように進化できるかについて明確なフレームワークを提供します。 それはより優れていて混乱の少ないシステムです PHPさんの現在 RFC 処理する。
すでに述べましたが、 RFC プロセスは、過去数か月間、断続的に議論されてきました。 それは多くのポイントにあります RFC メーリング リストに提案があると、同じ議論が何度も繰り返されますが、結果はありません。 のような委員会をもう一度見てみましょう。 TC39、そしてそれを一度だけ修正します。
現在の壊れたプロセスを修正するためにやるべきことは他にもあります PHPの開発ですが、今日ここにすべてをリストすることはできません。 ですので、会話を続けていくのは良いことだと思います。 私の提案は、さらに議論できる Reddit に行くか、私にメールを送ることです。
敬具
ブレント
8 月 29 日更新: Joe Watkins が親切にも返信を書いてくれました。 ここで読むことができます。
ジョーズへの私の返信はここで読むことができます。
//platform.twitter.com/widgets.js