(jp) =
<!–
–>
ジョー、私の手紙に時間を割いて返信してくれてありがとう、本当に感謝しています! こちらに返信させていただきます。
あなたの返信は、P++ の悪ふざけに対処することから始まりました。
議論の多くは、開発者には 2 つのキャンプがあるという P++ の議論中になされた主張に基づいています。
実際のところ、私は P++ ギャラクシーの議論全体の前に手紙を書き始めました。 しかし、生活が邪魔になり（私の息子は8月の初めに生まれました）、それが出版するのにほぼ1か月かかった理由です.
P++ が言及される前に、このトピックについてすでに多くの考えを持っていたことを明確にしたかっただけです。
これらの派閥が実際には存在しないことは、RFC の履歴を見ればわかります。
それを派閥と呼ぶかどうかにかかわらず、最近の RFCs、彼らはほとんどの場合、の将来について議論するために話題を逸らしてきました PHP より広いスケールで。 確かに人は少ないかもしれませんが、それでも大きな声が聞こえてきます。
いくつかの例:
これは、これらの議論のほとんどがどのように進むかです:
- ニキータは言葉を前進させようとする
- Zeev および/または Stas は後方互換性を支持しており、同じ長い会話が何度も繰り返されています。
- サラは妥協点を守ろうとする
- ドミトリーは取り組んでいます PHP8 バックグラウンドのどこかで、これらの議論から離れます
ルールは何年も前に書かれたものです – おそらくまったく異なる、社会的コーディング以前の世界のために – 私たちはほとんどの場合、ルールが書かれているとおりにうまく従っています。
あなたは問題の本質、つまり道に取り組んだと思います PHP これらの現代では、内部作業は時代遅れで非効率的です。
ルールが網羅的ではないことを指摘することは重要です。私たちの行動の多くは慣習によって決定されます。 これに反論して、考えられるすべての行動を徹底的に列挙するように努めるべきだと言うことができます。
柔軟に対応できる、賢明で現代的なルールセットが必要だと思います。
最近、短い PHP タグ構文を非推奨にして削除するために RFC が実施されました。
下位互換性を維持することについては私の意見がありますが (手紙の最初の部分で取り上げました)、短い構文から取り除くことが最も重要なことだと思います。 RFC プロセスが明らかに壊れており、修正が必要です。
ここにあるのはプロセスの失敗であり、それ以上のものではありません。 私とおそらく他の人たちは、将来この同じ失敗をどのように回避できるかを検討しています. 現時点では、正式な非推奨ポリシーを導入することが望ましいと思われます。これにより、まったく同じ失敗を回避するという目標が達成され、新しいバージョンの PHP を採用する際の信頼性が高まる可能性があります。
これについて私たちが同じページにいることをうれしく思います。内部に関するコメントから、バランスの取れたソリューションも探していることがわかります. 私の質問は、これが現在のシステム内で可能かどうかです。 私たちはぐるぐる回っているように感じ、進歩はほとんどありません。
まず、わかりやすくするために。 何かが物議をかもしていると判断する方法には注意が必要です。 大声で、物議を醸すと同じではありません
それは本当ですが、いくつかの大きな声が発達に影響を与える可能性があります. PHP 大幅。 主要な貢献者は多くなく、同じ議論を読んで返信するのに多くの時間を費やさなければなりません。 私は自分自身で内部リストを最新の状態に保つように努めているので、これが徹底的な作業であることはわかっています。
プロセスの変更にかかる時間と労力は相当なものであり、プロセスが失敗している、または失敗して損害を与える可能性があることが明らかな場合にのみ優先されます。
おもう PHP 不必要な議論が何度も繰り返されているため、ゆっくりと進化しているだけです。私はそれを失敗したプロセスと呼んでいます.
これを示すデータのサンプルをあなたが持っていると確信しています。
はい、以前にいくつかの最近の例をリンクしました。
一部の人々がインターネット上で自分自身を振る舞うことができないように見えるのは事実ですが、私は彼らが現実の生活では合理的な人々であると確信しています (読んでください: 信じなければなりません). これらの人々は、自分のことをすぐに明らかにし、何も言うことがないことを証明します。
これらの人々は戻ってきて、彼らを止める方法がないので、ある種の節度が設けられると思います. これは、メーリング リストだけでは不十分な場合です。
メーリング リストがコミュニケーションの良い方法であるとは言えませんが、それは私たちが持っているものです。 ただし、それだけではありません。
確かに、あなたがリストしたチャンネルはまだコア開発者とユーザーランド開発者の間のギャップを埋めているようには見えません. これは、ユーザーランド開発者があらゆる種類のソーシャル メディアで意見を表明していることからも明らかです。 公開フォーラムはここに行く方法だと思います。
これは定期的に言及されていますが、それが真実である限り、それはコミュニティのせいであることを指摘する最初の人になると思います.
ここには 2 つのグループがあります。
- 非常に多くの投資を行っている人々 PHP、しかし、トピック外で疲れる会話のため、内部の議論とは何の関係も望んでいません
- 実際に投票や意見の形で貢献したいが、方法がわからない人。
ウィキはこれについてあまり明確ではありません：
PHP にコードを提供した php.net VCS アカウントを持つ人々
php.net VCS アカウントを持つ人によって選ばれる PHP コミュニティの代表者 PHP ベースのプロジェクト (フレームワーク、cms、ツールなど) の主任開発者 内部ディスカッションの定期的な参加者
個人的には、この 2 番目のグループに属していると思いますが、私の認識が正しいかどうかはわかりません。 そして、私は他の何人かの開発者を思い浮かべることができます。 PHP コミュニティ。
私は尋ねる必要がありますか？ 実は、コアメンバーに個人的に質問したのですが、返事がありませんでした。 内部リストでこの質問をする必要がありますか? よくわかりません。
これも、コア開発者とユーザーランド開発者の間のコミュニケーションの失敗の例です。 越えられないと認識されている障壁があります。
実際に障壁があると言っているわけではありません。私を含め、多くのユーザーランド開発者がこのように認識しているとだけ言っておきます。
ジョー様、再度のご返信誠にありがとうございます。 私はそれを高く評価し、私のコメントを読むのを楽しみにしています.
敬具
ブレント
//platform.twitter.com/widgets.js