Xamarin.FormsチームがXamarin.Formsのアーキテクチャ、設計原則、およびそのワークフローに関するドキュメントをGithubまたはMSドキュメントにさらに書き留めておけば、コミュニティの人々にとって役立つと思います。
私の観点からは、Xamarin.Formsを使用して製品を作成します。バグに遭遇したときに、2つの選択肢があります。1つはgithubに問題を送信し、いつか修正されるのを待つこと、もう1つはgithubに問題を送信することです。自分で修正しました。
ソースコードのクローンを作成してデバッグした後、機能がどのように機能するかを理解することは困難です。 例：https：//github.com/xamarin/Xamarin.Forms/issues/8521
もう1つの例は、Android側のXamarin.Formsのページナビゲーション機能です。 ネイティブAndroidのアクティビティ間のナビゲーション機能は簡単に理解できます。 しかし、Xamarin.Formsでは、1つのメインアクティビティを使用してすべてのページを処理しているようです（おそらく）（ネイティブフォームとネイティブビューを除く）。

これは素晴らしいと思います。

仕様/問題などのギャラリーとショーケースを、作業して簡単に紹介できる小さなプロジェクトに分割することは、開発サイクルの大きな利点です。

最も問題のあることの1つは、バグが修正されたり、機能が導入されたりして、改善が進むときに、いくつかの異なるバージョンを使用することです。
いくつかの小さなインスタンスがあると、これに大いに役立ちます。

私が考えているもう1つのことは、コードスペースと将来のgithub-codespacesを使用することです。ここでは、問題のドットファイル（適切なxamarinバージョンなどを含む）を添付して、コードスペースを使用するか、そのバージョンをチェックアウトできます。

小さいcontrol-gallery-partsを、個別に利用でき、コードスペースで開くことができるプロジェクトとして利用できる場合に最適です。 小さなコントロールアプリとコードスペースの組み合わせには多くのメリットがあります。

私が言おうとしていることは次のとおりだと思います。

• マルチパートコントロールギャラリー
• コードスペースのサポート
• 問題のドットファイル

編集：3番目のポイントを追加しました。

一度に数か月間、いくつかの問題が発生していることに同意します。 XFのクローンを作成しましたが、迷子になっています。
したがって、ソリューションがどのように機能するかを示すビデオのドキュメントは素晴らしいでしょう。

.Nettyが多いほど、これは優れている可能性があります。

1. コアからマジックストリングと型なしバインディングを削除します。 リポジトリに貢献している人に、型なしのバインディングまたは型チェックされていない文字列を書くように要求しないでください。 これにより、バグが劇的に減少し、バグの修正がはるかに簡単になり、新しいバグが表示されないようにリファクタリングが簡単になります。
2. マークアップレイヤーを処理するために寄稿者を必要としません。 一部の開発者はXAMLまたはCSSを使用したいと思うでしょうが、バグを修正する貢献者はこれらのことを気にする必要はありません。 実際の.Netクラスの上のレイヤーであるマークアップ言語で作業している人だけが、このレイヤーに注意を払う必要があります。
3. レンダラーアプローチは、プロパティ変更の実装の失敗（または上記のように実装する際のタイプエラー）がタイプエラーになるように構成する必要があります。
4. 必要に応じて、プラットフォーム固有のバインディングをまったく使用せずに一部の機能を実装することには許容範囲があります。たとえば、SkiaSharp、Shapes、または複合MAUIオブジェクトを使用して、同じものを表示し、新しいバグを導入しない信頼性の高いクロスプラットフォーム実装を実現します。

ある時点で、単純化されたSLNユーザーがこのように貢献できる方向性をテストしていました。

https://github.com/PureWeen/Xamarin.Forms.Sandbox

コントリビューターが修正またはAPIをデモンストレーションできる非常にターゲットを絞った「Contributor.sln」を提供するだけです

現在のギャラリーをすべて削除し、プラットフォームとMainPageに焦点を合わせます。

ソリューションフィルターの方が良いでしょうか？ 2つのソリューションを維持する必要はありません。

ソリューションフィルターで何が開発されるかを見ていきます

AFAIKは現在、vsmacで動作せず、マルチターゲットプロジェクトがある場合は少し奇妙です。 マルチターゲティングのファーストクラスのサポートが可能になり、ヘッドプロジェクトをSDKスタイルにすることができれば、ソリューションフィルターの必要性はそれほど高くないと思います。

もう1つの厄介な点は、マルチターゲティングを使用している場合、VS for Windowsは現在すべてのターゲットを構築しますが、vsmacは実行しているプラ​​ットフォームヘッド用のターゲットを構築するだけです。

もう1つの厄介な点は、マルチターゲティングを使用している場合、VS for Windowsは現在すべてのターゲットを構築しますが、vsmacは実行しているプラ​​ットフォームヘッド用のターゲットを構築するだけです。

VS for Windowsでそれをサポートするのは素晴らしいことです！ 現在使用しているプラ​​ットフォームのみを構築するために作成したこれらの余分な構成をすべて取り除くことができました。

VS forMacの現在のマルチターゲティングストーリーは非常に苛立たしいものであることに同意します。 残念ながら、マルチターゲティングは非常に優れたオプションであるため、私はそれをアプローチとして選択し、問題が発生したチームの他のメンバーの技術サポートとして機能します。 その終わりのない欲求不満の流れ。