Continuing the discussion from TRANSMISSION #9: Testing Deep-Dive with Tom Coleman:
Thanks for putting this together! I’ll try to think of more and add to it.
Copied from another thread. Please, let’s continue this discussion here, as it will vanish in the original one among a sea of other posts.
I’ve had several packages that aren’t the super heavy hitters but have been around for a long time. It would be a shame to lose all the documentation sites for them.
http://user-status.meteor.com/ - 29k installs of https://atmospherejs.com/mizzao/user-status and 7k of https://atmospherejs.com/mizzao/timesync
http://autocomplete.meteor.com/ - 10k installs
http://turkserver.meteor.com/ - project I’ve been working on for a long time and am about to release in the academic community
Thanks for putting this thread together! So, I ran
list-sites and had 68 sites! d’oh!
About two dozen or so were explicitly labeled test, dev, beta, etc and could be deleted right away. There were a half-dozen past client demos that never really went anywhere, and which I shelved.
Another dozen of the apps relate to the Clinical Track in various ways, and are going to be used as WordPress style sites on a HIPAA Hosting Provider. These are all moving to Modulus, Heroku, or Galaxy (especially if MDG is every willing to sign a HIPAA BAA document in the future).
Benchmarks, Integration Tests, Prototypes, Reference Builds
But there’s another two-dozen sites that are in various stages of development, and can be best described as Benchmarks and Integration Tests. They’re not really package demo sites specifically (although some are). Mostly, they’re subsystems and architecture templates. User Entry, Scheduling, WebRTC, Form Building, Reactive Drag & Drop, Card UI, Image Libraries, Reactive Data Pipelines, Rest API, Payment Portals, etc…
So, yeah. I have maybe 2 dozen websites that… well, we use these sites for benchmarking, integration tests, load testing, compatibility testing, etc. They’re all fine being powered down. They’re definitely not in production. And there’s some tangible benefit to the community having them around.
So, I’m not sure what to do with them at this point. I was really hoping the tier where containers get powered down automatically was going to be kept around. That’s really convenient for these types of package documentation, benchmarks, reference implementations, and the like.
And I was just getting ready to start a new one, as we put the new OAuth2 Server under QA.
user-status is great, using it in several larger projects. Would be a shame if there was no demo of it.
more repasting and more text as I need 20 characters even to repaste
My projects used to some people
It seems like it should be possible to scrape the atmosphere description pages for url’s that link to .meteor.com sites and then keep all that sites for projects that have over x many downloads in the last year? Or something like that?
(I feel safe in suggesting that as I have none of the skills actually required to achieve it…)
Edit: I appreciate that won’t save all that should be saved, but it might save some important stuff that otherwise would be missed.
I have two demo-sites with corresponding GitHub repository
Phone layout demo using Meteor + Framework7 + React + TrackerReact + Webpack
Nobody in the MDG thought about all the demo sites linked to the meteor packages? Really?
@poliuk there are two MDG members confirming that this will be taken care of at the very top of this thread.
…we’re definitely open to doing this. In fact, we’re putting together a
program to recognize and support top technical content contributions
(e.g. tutorials, docs) from the community. Can you please help us
identify more of these must-have resources that currently exist on
but maybe that one can go
Maybe it’s time now to put this decision on hold?
Going out now to scrape community pages to save them for reference. Madness.
I think MDG has severely underestimated the role of *.meteor.com demos and documentation in promoting and generating excitement about Meteor. Once this is taken down, essentially a lot of the documentation of community packages will disappear and I don’t think the ramifications were well considered.
It’s like the one-child policy in China: aimed at population control, but created side-effects of an elderly society with too few young to take care of their two parents and four grandparents, and many “little emperor” members of society that are very self-centered due to having no siblings.
Slack has resulted in wide adoption by providing a free tier that allows a critical mass of core users bring in the rest of the organization and justify paying for a higher tier. Let’s hope this decision doesn’t cause huge repercussions around the Meteor community by destroying the excited base of developers that feeds into the paid services.
Agreed, see post from Fake Geoff Schmidt.
@brajt Yes, to reaffirm our commitment to the community, we’ve already been working on a program (unannounced) that recognizes top community members who have a track record of publishing great content (e.g. tutorials, demos). This program will include top package contributors and offer limited Galaxy hosting for package-related demos. Unfortunately we cannot offer free hosting for demos of any public package (there are 10,000+ packages on Atmosphere!). Instead, we’ll use a combination of criteria (e.g. author activity, popularity/usage trends, peer nominations) to identify a subset of top packages and make sure their demos have a new home on Galaxy.
@marktrang: Hm, what about each developer can get some tokens and then they can or delegate those tokens to projects they care about, or use for their packages. What I worry is that you will create a form of inefficient central government deciding who can host demos for free, instead of having a way for authors of packages decide what they prefer and care about. So maybe they want to create something new, which is not yet visible to people. How could they direct resources towards this?
So the question is not just how to handle current top packages, but how to handle future ones?
@marktrang it sounds like that policy will make it really hard for new (but potentially good) packages to gain traction because they won’t have any demo space allocated to them. I don’t think that each of the 10,000 packages will create a demo site, either. The hosting load would definitely be orders of magnitude lower than it is now.
@mitar just simultaneously mentioned the same concern.