I'm not sure how this would go - I assume it'd take a lot of effort since there's thousands of wikis that exist and it'd have to be added to each LocalSetttings.php of wikis (is that it? It's been a while), plus it needs to be tested first if it'd actually work! This is merely a suggestion so that hopefully there's a bigger audience to test Refreshed, and users could give more feedback on how it could be improved :) Merely an idea - thoughts on this?
So this was probably worded a bit badly. I'm sure that @SamanthaNguyen's intention wasn't to have unstable, potentially broken code deployed on ShoutWiki.
We have always believed in skins. The more the merrier, as they say. Our skin portfolio is unique, and that's a strong selling point -- we offer our users choices, real choices. We do not believe in "one size fits all" because we know better. Right now we offer 13 different skins for our users to choose from (even if the WordPress ports aren't yet available via CreateWiki, but individual users can choose to use them via their preferences/global preferences). If we compare Refreshed to many of our other skins (for example, using this table), it fares at least as well as the others, if not better. Refreshed was designed to be responsive and ad-friendly, both of which are important considerations. It has received more functional commits this year than many of the other skins currently deployed (ref).
That being said, this wouldn't be a problem-free deployment. Looking at the upstream workboard, there are some bugs which definitely matter, such as accessibility or platform compatibility related ones. Not to mention the hard dependency on WikiFont, which has caused headache to devs in the past and kinda still does.
For wide-scale deployment on ShoutWiki, we'd need to add advertisement code to ShoutWikiAds (a hook that hooks into Refreshed's RefreshedFooter hook), like this, plus a screenshot for CreateWiki (and maybe a tag/project on Phabricator?), as well as adding the skin to GlobalSettings.php (for global availability) and hubSettings.php (for CreateWiki on Hub) but those should be relatively easy to do.
I don't think that any of the aforementioned issues are showstoppers, but cc'ing @isarra for further design & UX review and commentary.