I think the major concern I have with this is, as pointed out in 5712, it would effectively become a monorepo, likely one repeating the helm stable/unstable repo adventure. That's probably solvable with some scheme like setting up a "kubernetes-sigs-helm-contrib" organization or project that then hosts or links to separate repos, though that might have costs to the Kubernetes project that I don't know about.
Apart from that, it sounds like these charts would inherently tend to be charts for SIG projects not written by anyone in the SIG. There are some abstract philosophical concerns I have with that, but the practical ones include things like:
* Alignment between the chart and the project's current best practices and future goals
* Alignment between the chart and prevalent patterns of end-user use of the project, especially as those patterns change over time
What these boil down to is "Is this chart a robust, usable way to consume this project's output, and will it continue to be so?"
I think mainly my expectation would be that if a Helm chart is a desirable way to package the work of a SIG, and a chart contributed to that SIG is solid, that that SIG in fact would then host it in their repo, and their reluctance to do so (in the absence of other info) would lead me to question if one of those two premises in fact isn't true of that chart. There might be edge cases where the SIG agrees the chart is good on those criteria but still chooses not to host it, but I'd want to see more about what the reasons in such cases might be and if they might be solvable without creating an "out -of-tree charts" collection that will probably be tagged "beta" forever in most users' heads. -- Joe