I think it is helpful for community people if Xamarin.Forms team write down more documents about the Xamarin.Forms architecture, design principle and its workflow in Github or MS docs.
From my point of view, I use Xamarin.Forms to create my products, I will have 2 choice when I meet the bugs , one is submit issue to github and waiting it'll be fixed for someday and another is submit issue to github and fixed it by myself.
After clone source code and debug it , it is difficult to understand how the features work. For example https://github.com/xamarin/Xamarin.Forms/issues/8521
Another example is the Xamarin.Forms' page navigation feature on android side. It's easy understand the navigation feature among activities on Native Android . But on Xamarin.Forms it seem like it use one main activity to handle all page (maybe)(except the native forms and the native view).

I think this is great.

Splitting up the gallery and showcases for specs/issues etc into smaller projects which can be worked on and showcased easier is a big advantage in the dev-cycle.

One of that most problematic things to do is having several different versions where bugs are fixed in or features being introduced in and then when moving on being improved on.
Having several smaller instances helps with this a lot.

One other thing that I am thinking of is using codespaces and in the future github-codespaces, where one can attach dotfiles for an issue (including the right xamarin version etc) and then we could just use codespaces or checkout that version.

Best would be if the smaller control-gallery-parts can then be available as projects which are available separately and can just be opened up in codespaces. I can see a lot of benefit in the combination of smaller control-apps and codespaces.

I guess what I am trying to say is:

• Multipart-control-gallery
• codespaces support
• dotfiles in issue

Edit: added third point.

I agree I've had a few issues open for months at a time. I've cloned XF but just get lost in it.
So a doc for video just showing how the solution works would be great.

The more .Netty this can be the better.

1. Remove magic strings and untyped bindings from the core. Don't require anyone contributing to the repo to write an untyped binding or a non-type-checked string. This will dramatically reduce bugs, make fixing bugs a lot easier, and make refactoring easier so that new bugs don't appear.
2. Don't require contributors to deal with any markup layer. Some developers will want to use XAML or CSS but contributors fixing bugs should not need to care about these things. Only people working on markup languages, which should be a layer on top of the real .Net classes, should need to care about this layer.
3. The renderer approach should be structured in such a way that failure to implement a property change (or a type error in doing so as above) is a type error.
4. Where appropriate, there should be a tolerance for implementing some features without platform-specific bindings at all, e.g. using SkiaSharp or Shapes or composite MAUI objects, for reliable cross-platform implementations that display the same and don't introduce new bugs.

At one point we were testing out a direction of having a simplified SLN users can contribute to like this

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

Just provide a very targeted "Contributor.sln" where contributors can demonstrate a fix or an API

Remove all the current galleries and just focus it down to the platforms and a MainPage

Would a Solution Filter be better? You don't have to maintain two solutions.

We'll see what all gets developed with Solution Filters

AFAIK currently they don't work on vsmac and they are a bit weird when you have multi targeted projects. Once we we can have first class support for multi targeting and the head projects can just be sdk style then I think the need for solution filters isn't as high.

The other annoying thing is that VS for Windows currently builds all the targets when you have multi targeting whereas vsmac just builds the one for the platform head you are running.

The other annoying thing is that VS for Windows currently builds all the targets when you have multi targeting whereas vsmac just builds the one for the platform head you are running.

Getting support for that in VS for Windows would be awesome! I could get rid of all these extra configs I made to only build the platform I'm working with at the moment.

Agree that the current multi-targeting story on VS for mac is incredibly frustrating. Unfortunately, multi-targeting is such a great option that I still choose it as my approach and just serve as tech support for others on the team that run into issues. Its a never ending stream of frustration.