From a comment I made @UWPCommunityToolkit:
There is a lot of UWP code on GitHub along with various other Xaml variations (with a range of porting efforts) which in theory provides a kind of opportunity for the code to be useful to more people if it can get ingested into the Community Toolkit.
One issue that I am trying to address with my list is that a huge number of projects are not very discoverable due to the very crappy GitHub search engine (combined with lack of searchable terms endemic to volunteer OSS projects)
The other (larger) problem is the social and technical and administrative overhead of ingesting the code. In this area, perhaps you could consider supplementing your current "Pull Based Ingestion" model to add in a "GitHub Issue Driven Push Ingestion" model, which might work by adding a "Toolkit Labs" to your source tree and inserting useful looking items for which you then immediately add GitHub Issues for whatever changes are needed to qualify some code to be promoted out of Labs. When people see useful looking items in "Labs" they will be motivated to look into fixes (in theory) and solves the very real problem that most UWP OSS authors simply won't have the time and motivation to alter their stuff to meet the cultural and technical criteria to provide a Pull.
Right now, my UWP Tools List mainly lists just the projects. I will attempt dig into many of the projects and add some sort of very ad-hoc listing (or a cross-ref listing) of possible useful controls and code for those projects.
From a comment I made @UWPCommunityToolkit:
There is a lot of UWP code on GitHub along with various other Xaml variations (with a range of porting efforts) which in theory provides a kind of opportunity for the code to be useful to more people if it can get ingested into the Community Toolkit.
One issue that I am trying to address with my list is that a huge number of projects are not very discoverable due to the very crappy GitHub search engine (combined with lack of searchable terms endemic to volunteer OSS projects)
The other (larger) problem is the social and technical and administrative overhead of ingesting the code. In this area, perhaps you could consider supplementing your current "Pull Based Ingestion" model to add in a "GitHub Issue Driven Push Ingestion" model, which might work by adding a "Toolkit Labs" to your source tree and inserting useful looking items for which you then immediately add GitHub Issues for whatever changes are needed to qualify some code to be promoted out of Labs. When people see useful looking items in "Labs" they will be motivated to look into fixes (in theory) and solves the very real problem that most UWP OSS authors simply won't have the time and motivation to alter their stuff to meet the cultural and technical criteria to provide a Pull.
Right now, my UWP Tools List mainly lists just the projects. I will attempt dig into many of the projects and add some sort of very ad-hoc listing (or a cross-ref listing) of possible useful controls and code for those projects.