bmogilefsky

It was all written at once, during the pre-production phase. We had daily meetings to brainstorm settings, characters, goals, puzzles, etc. The next day Peter Chan would come in with sketches or storyboards. Meanwhile I tinkered on making the engine work. Once the doc was done (and some locations/puzzles/characters were cut out to reduce the production cost estimate) and the engine was able to display one character walking around one temporary room, we went into production, where the team size ramped up and we churned through the document building locations, modeling, texturing, and animating characters, etc. This doc became foundational for anyone joining the team to learn what the game was supposed to be like.

I work at 18F. I have never been drug-tested. It's not a requirement for the job.

You listed two IaaS provider and one SaaS provider. cloud.gov is a PaaS provider. There is no FedRAMP PaaS available to agencies, and PaaS is the level of abstraction needed to accelerate delivery of services the government itself provides.

We also leverage the fact that AWS GovCloud already has FedRAMP status as an IaaS to accelerate our delivery of cloud.gov (which sits on top of it), so we're piggy-backing on the money and effort already spent and eliminating the millions we would otherwise spend by having the government run the IaaS layer.

In other words...

> The focus really needs to be on building a process to better integrate private cloud services and gov't applications.

...that's what we're doing!

Good eyes, will see if we can fix that.

We are using AWS GovCloud for our base IaaS layer, but we run a PaaS layer on top based on Cloud Foundry... That's the actual cloud.gov service being provided, the location on AWS GovCloud is just an implementation detail.

I said "through a special hiring authority" above but that's inaccurate, sorry for the mix-up... We use the normal GS scale.

You're right, everyone is on the hook for their own agency, and with such strict regulations they are very conservative about using each other's stuff, which is effectively delegating decisions and responsibility to others that may get them in trouble.

This is a major reason for cloud.gov going after the FedRAMP JAB P-ATO recognition. "JAB" is the Joint Authorization Board comprised of the CIOs of the Department of Defense, Department of Homeland Security, and the General Services Administration. Having a triple-sign-off from three CIOs under a consistently applied set of standards is the highest social proof you can get in government that will convince other agency CIOs that it is OK to use your stuff at their agency. Normally it's vendors that go through this program... We're among the few to do it for a government-developed-and-operated service, and the first to do it for something as generally useful as a PaaS.

The other aspect is making sure everything we do to deploy and document the platform's compliance is open source and subject to scrutiny, so they can check for themselves... and ideally contribute in areas they think it could be better, of course!

(And yes, sending a resume is how you get started.)

We can't control the decisions they make, and wouldn't want to... Each agency has their own CIO, and needs to be able to make decisions about stacks based their needs. Compliance requirements for running a service in public are so huge that agencies have conservatively stuck to ancient options, or farmed it all out to vendors. Our goal is to make the operations, deployment, and compliance aspects of service delivery trivial so they can put more of their resources (and those of the vendors they pay) into the improvement of the services they provide rather than sinking a huge portion of their budgets into redundantly addressing compliance and deployment concerns. And of course, use modern tech.

Google for "cloud to butt extension"

I LOL'd... I had the same extension installed, but had to uninstall it when I saw the word constantly as part of my job.

I'm the product lead on cloud.gov... Thanks for noticing us! There are other Cloud Foundry deployments, but what makes cloud.gov special is the focus on ensuring federal agencies are actually able to use it. Federal compliance for a cloud service provider is a tough bar to clear, and without it most agencies are simply unable to take advantage of capabilities the rest of the world now takes for granted. That in turn impedes improvements in the many services the government has to offer. We've just reached the "FedRAMP Ready" status, which is a signifier of confidence that cloud.gov will make it through the exhaustive auditing process to come. Best of all, everything were doing is open source, including all the compliance work, so others will be able to follow in our footsteps. AMA!