The demo studio has outlived its usefulness. Most submissions these days border on spam, it is dragging down the perf of mdn, and there are several other more popular demo sites on the web now (codepen, etc). To keep it alive we'd have to sink some work into it to move it to AWS with MDN and I don't see it having much of a payoff. We should shut it down instead.

Moving over to MDN product for triage, discussion, articulation.

\o/ On the content side, I only wonder if there is a reliable way to find link to it from MDN wiki articles: I would like to be sure not to have dead links there.

We will need to have a good landing/shut-down page for external links anyway. So I assume "find dead links in wiki articles" is not a blocker?

We need a plan for handling all the impacts of this, both technically and communicating it to contributors. For example, what happens to the links on profile pages to demos that users have contributed? For some contributors, having a demo on MDN is very much a point of pride. At the very least, we should email the demo contributors, explaining what we are doing, so it's not a surprise that their demo disappeared.

(In reply to Janet Swisher from comment #4) > We need a plan for ... [stuff] Here's the beginning of a plan: https://docs.google.com/document/d/1XP1v8C84Un2k8lU4wGOdldEYnklm0_ozM-UCcP4XMdM/edit# It needs lots of work. Let's make heavy use of the "out of scope" section. :)

ni :hoosteeno to mail to lists.

Mail sent to mdn@ https://groups.google.com/forum/#!topic/mozilla.mdn/s6NY2GxnKw4

/me pours some Chimay on the ground for his first contribution to MDN :)

That said, +1 to this as an interested observer. IMO, we never *quite* gave it the support it needed across the org. Excising the `kuma.demos` app can probably also take out `kuma.actioncounters` and `kuma.contentflagging`. If those haven't been incorporated into the wiki already, I'd suggest those built-in apps are terrible unless someone improved them greatly since I last touched them. There might also be some things in `kuma/core/utils.py` that can be cleaned up too... Hopefully some of the above is helpful

I worked very closely with the Demo Studio over the years and agree that it should be decommissioned. The maintenance cost is not small and there are better alternatives today. In our messaging around this change, we should be sure to acknowledge the positive impact the Demo Studio had. It surpassed Chrome Experiments in number of entries and helped debunk the growing myth that Chrome was needed to make the most of the modern Web. (Many Demo Studio entries are just Chrome Experiment entries with added vendor prefixes.) The phrases "works best in Chrome" and "works only in Chrome" evoke much more skepticism today than they did five years ago, in part because we now have such strong counter-examples to point to. But we solved that problem, so I agree it's time to move on.

If we have a quick way of freezing uploads, we should do that soon and not wait. This is easier to manage if we're don't have new demos uploading. I wrote a little script to scrape MDN and grab the studio and stats: https://github.com/lonnen/demo-studio-scraper I used the script to generate a spreadsheet with all the demos titles, authors, views, and likes: https://docs.google.com/a/mozilla.com/spreadsheets/d/1oMtIg6uKdMGxgT-06Kq-vxzMXR4IKUVs5CEGV3y2UhU/edit?usp=sharing Hopefully this is useful in populating our plan document. The script could probably be modified pretty quickly to grab the zip archive of each demo. We can dump that to github or somewhere a little more permanent where people could grab a backup of their stuff, if they want it.

> The script could probably be modified pretty quickly to grab the zip archive > of each demo. We can dump that to github or somewhere a little more > permanent where people could grab a backup of their stuff, if they want it. GitHub probably isn't the right place for permanent archival. Not only does it feel wrong to use a sophisticated social versioning system for a snapshot of static assets; GitHub soft-caps repos at 1G[0]. Since we're moving to AWS, perhaps we could carve out a 7G bucket for storage (but not web hosting) of this content. I imagine after the first month it would be accessed very infrequently, and would probably cost less than a dollar a year. That would allow interested demo creators to download their demo, if they choose, and upload it elsewhere. We could EOL this bucket after some period. I've added "archive all backups" to the spec. [0] https://help.github.com/articles/what-is-my-disk-quota/

Would it be possible/worth while to help migrate some of the most popular demos to another service (like code pen) and put redirects in place? I hate the idea of breaking so many links around the web :( For example: Bannana Bread accounts for about half the traffic demo studio gets with over 9000 visits a month. I imagine authors would have to be contacted directly? Probably a lot of foot work. As for code samples on profiles we could add a code pen username field to the user profile page (I don't know if we could actually pull in demos from code pen but that would be cool too)

Oh I see "Handling top-tier demos" are already being considered in the document :)

I'm totally in favor of focusing kuma to being the wiki software (plus incidentals) and moving the demos to a better place. In that sense I was wondering if JSFiddle or Mozilla Thimble wouldn't be good places for the smaller demos as we would retain some of the community aspects of the demos? For the latter we could even maybe get some help bulk importing the demos? Other than that I like :hoosteeno's suggestions to just provide a S3 bucket with the zipped demos, that we could even link from the single static page to inform about the demos' move. I agree with Janet that we shouldn't burn bridges with our community so to say and make the impact on their online portfolio as small as we can currently afford time-wise. Updating the demo links in user profile to link to the S3 buckets for a time (e.g. while users migrate to another place) would certainly have a small technical complexity.

Assuming we disable uploads, would it be hard to continue hosting static demos? For example: https://developer.cdn.mozilla.net/media/uploads/demos/m/e/meinstuhlknarrt/48e42ffb6378cd3d148db72e4898a821/petes-adventure_1359487936_demo_package/index.html The maintenance cost should be low. We would have no templates or assets to maintain. We would just keep serving these files. That would free us from the burden of choosing top-tier demos and would probably make our contributors happier, too.

The idea being... we could link to those static demos from a basic homepage along with a brief notice about the Demo Studio being over. Should be pretty simple.

:openjck No, assuming we can just move those with us to AWS to S3 we can just continue to serve the demos. That said it's possible that we'll be getting a separate domain from Cloudfront and not use developer.cdn.mozilla.net for our CDN domain since custom SSL certs on Cloudfront cost extra IIRC. But maybe we need to talk to cloudops about this first. :travis Do you know if we can expect to continue to use the "developer.cdn.mozilla.net" domain as the Cloudfront domain for when we've moved our static files to AWS?

Let me be clear: we are shutting this down. We are not re-homing it. I'd rather not maintain any archive ourselves long term. We can put a memorial page up in the wiki, or in gh-pages, at which we point the 3XXs. Let's handle the communication well, and then let it go.

We should contact the Internet Archive at the same time we make our first announcement to our users.

(In reply to Stephanie Hobson [:shobson] from comment #20) > We should contact the Internet Archive at the same time we make our first > announcement to our users. FWIW, Jason Scott <jason@textfiles.com> might be a good contact for that. He works for the Internet Archive and has shepherded virtual metric tons of good stuff into their collections.

It looks like Justin created the plan and identified sub-bugs, but never created those bugs. I'm going to create those bugs, even if they are immediately closed, just so we know that everything is covered.

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/03cb00983d7e99ad6e0b52f1df8fe5191e4801de Bug 1223109 - decomission demo studio https://github.com/mozilla/kuma/commit/bb0996c0784f51e7e990b0fcab96715997cd04be Merge pull request #3698 from mozilla/rm-demos Fix bug 1223109 - decomission demo studio

Reopening this tracking bug since there are two sub-bugs remaining: one for updating MDN articles and one for WebOps work that needs to happen after the deployment.

Closing now that all the dependencies are closed