 So a quick show of hands just so I can gauge a bit of a reaction and gauge sort of what, you know, who's here and who's attending. Who's heard of GovCMS? I should bet a question. Who hasn't heard of GovCMS? Great. Okay. Well, I'll be going from like a little bit of, actually, Glenn over here will be going a little bit about what is GovCMS. Glenn's from the Department of Finance who are partnering with Acquia to make GovCMS a reality. And then I'll be going into a little bit of the technical detail about what we're doing to drive it, how we're managing patches, the code workflow, the tools, all the really juicy stuff that's under the hood. So I'll stand out of the way so you can see who I am. So I'm Adam Malone. I'm acting as a technical architect of GovCMS on behalf of Acquia for this project. So about me in sort of four bullet points. I'm with the professional services team at Acquia. We do a bunch of different stuff. Wherever any of our other teams don't really cover it, professional services bridge the gaps. So we do big site builds, we do consultations, engagements, everything like that. I'm almost this age in Drupal years, according to my Drupal.org profile. So I started about four years ago and have been going relatively strongly ever since then. Most places online, I created this alias for it. What I didn't know at the time when I thought I invented that word is that Typhonias is a species of toad. So if you look me up online, remember that these are me and those are not me. It's just a really important clarification to set who I am and who I am, definitely not. So really quick slide about Acquia because we have to. Fanded in 2007. Product services, training, certification, all that good stuff. There's lots of Acquia people in the audience here. So you can probably poke one with it about arm's reach if you want to know any more information. We just hit over 600 employees globally. So that's Asia Pacific, US, Europe, everywhere around the world. And we're now at about 20 employees, a little over in Asia Pacific. I did a nice little graph there to show where we all are around the world. We're hiring. So if you're keen on joining this organization and get our number up to 700, 800 and more, contact one of us and there's plenty of stuff going on. So in the beginning, I'm going to hand over to Glen now to give us a little bit of the GovCMS intro, where Department of Finance fits into this and tell us the story. Great. Thanks Adam. So I'm Glen Martin and believe it or not, I am a public servant as opposed to this guy who looks like a public servant. So work that one out. From Chris O'Neill's presentation, which I was seeing just before, describing as one of these glue people, a lot of developer, a lot of designer. But I know enough about just about everything to be really dangerous that I do bridge that gap from, I guess, a real front end market and help people along the way and back end technical. So if we talk about GovCMS real quick and I acknowledge it started a bit late. So GovCMS, there's a service and there's a distribution. So GovCMS service is going to be a whole of government website hosting based on Drupal. That's going to be primarily with Acrea in the cloud and site factory. And you'll see that instead of going out and getting Drupal for building in all our modules to bring it up to a point where it's going to be acceptable for government, we actually found previous and next and their agut distribution, I've already done that. So we took that and then we working with previous and next, we enhanced the Drupal. And when I say enhance, it's more for where we get down to really stringent government requirements around security in particular, meaning the ISM and other obligations. In also doing that, we built in options. So we don't want agencies to feel like they're locked into one particular bit of search. So I mean, there's Drupal search. A lot of agencies are using funnel banks, so we didn't want to carve out funnel bank. But Acrea's also got solar in there, so we didn't want to not be able to leverage that either. So we've been building options in the GUT CMS. And it's available for use by all the federal, state, local. It doesn't matter. It's not mandatory. So I've been hearing this a little bit today. Ah, the GUT CMS is going to be mandated or agencies must use it. No, it's not being mandated. No, I didn't say that. I'm with the government. I'm doing it. All right. So why don't we do it? Mainly because since 2009 onwards, I guess there's been a lot of government policy about open source, using cloud, getting away from the old systems that we used to have. So there's links at the end of this slide, which I won't bore you with now. But the prime ones, the digital economy, our open source software policy, where we have to consider open source now, whereas in the past, the open, all right, the cloud computing policy. And it follows the best practice service design around the digital service standard or the DSS, which you may or may not have been hearing about. TVA, their site hasn't launched yet, the service, the standard is not finalized. But where you start hearing about websites having to adhere to certain standards, such as we're used to with the national transition strategy and accessibility, you're going to be seeing that soon. So the distribution, the private distribution is available now. And this is the one where we have agencies coming into the government service. So it's private because we built things into it. So it works with the site that, let's go a long way around, Acre, Cloud, Sol, Factory, Hawkins. But there's also going to be a public distribution, it's not available yet, it will be soon. So anyone can use it, not just government, but you can stand up and host it. And both the private and public will be regularly updated. Both security and feature enhancements. And the big one is around government reuse. So in the keynote today, we heard about sort of financial contributions to Drupal. So we're not doing that directly. What we're doing sort of indirectly, anything that we government build into GovCMS, ultimately it's going to become available on Drupal.org and GitHub through the distributions. You all know that making these enhancements doesn't come without cost. And when we're dealing with government, it's often significant cost. So all of this is going to be passed back into the community. As well as an agency stands up some functionality, which we think, hey, this is what some public government use will build it in. And so we'll extend that out to all agencies and anybody that uses GovCMS, basically. And the other big one is the jubilee, which is on the phone, to be sure of. So normally when you're going to stand up and you sign, you've got all the security stuff. You have to go through the procurement, the panels and all the rest of it. So basically that's been done. We've done that due diligence already. So you can get yourself up and running faster and you're going to seem to be supporting all of the governments. And this is the last one and I'll hand back to Adam. So how agencies actually get on to GovCMS, it will depend on where you are now and what ability you have. So I'm kind of talking to a room full of devs and maybe not me for the service, only one kind of going to hand up there. But where sites are existing on Drupal already, it'll be easier to bring them across to GovCMS. If we're on punky bespoke systems, okay, it's going to be a little longer. And depending on whether there's Drupal skill in-house, be it basic as content, right up to developers, that'll impact how quickly they can get on to GovCMS. But we'll have professional services available. So if agencies want to do a full redesign of their site, take an opportunity to move platforms and basically come kicking and screaming into 2015 and actually use a site, use a platform so it gives not only the agency options of how they work, the content of how they engage with online citizens. We can have discovery workshops and read the signs and user testing and write down to all of those things that will be made available. And at this point, I'll hand it back to you. Thanks for having me. Thank you, Glenn. So as Glenn sort of alluded to, there's going to be a problem that has to be solved for our solution to be implemented. I had a little text message with June edition and I asked her to name which three problematic things that GovCMS could not solve, which she responded with the allergies for cash, calendar, I guess, time, and a big stack of papers for paperwork. So she was, she'd do a lot of money there. So these might seem like really, really leading questions. And they kind of aren't, actually, because I'm kind of driving to a point. Who here has used a government website to follow taxes, to download form, to look at immigration status, anything? I'd imagine everyone, everyone has used a government website in some sort of way, shape, or form. Who enjoyed using it? Is it the public? Of course you do. So it's generally not a very enjoyable experience. And the reasons that I've heard for them not being enjoyable is, you know, some are disparate. They're just, you know, there's no sort of information architecture behind it. It's just, you know, sometimes it's just some flat HTML and sometimes it's something like really snazzy. There's no sort of one theme behind all of these websites, which allows people to feel comfortable when they're using them. Now we already kind of covered this earlier and we've got one. There's probably other people out here who are sort of shy with their hands up. So I'll ask you, how happy are you with the development, the content, authoring, workflow of the government site? This kind of could be extended to everyone about using the sites as well. If it's not an enjoyable experience, if it's not something that you enjoy doing, or find ease in doing, then it's not going to be something that you want to do. I'm glad you didn't sort of contradict me about that. I wouldn't be doing it. So when we think of government and open source, there's two definite examples, which certainly spring to my mind and will probably spring to your mind here. One of them is from the US. It's posted in public cloud. It uses Drupal. It's one of the flagship sites that people who have promoted Drupal use when they're speaking to people who want to use Drupal. It's whitehouse.gov. The whole suite of White House sites uses Drupal. They're very open about it. It's all public on GitHub. It's a really great example, a really great precedent. The other site is gov.uk. So kind of a similar thing with GovCMS is sort of looking to do, whether there's one sort of web portal for all your government needs. Again, open source, things written in Ruby, all on GitHub, and unavailable for people at their pleasure. The thing that GovCMS is looking to do, though, is to leap from that. It's to take a look at these two examples and then to set the new precedent, to be the new site, the new kind of platform that people look at when they're going open source, government, who do we look to emulate? We look to emulate GovCMS. So taking definite sort of hints from these two sites, and mainly, I mean, Glenn really summed it up earlier, to provide a platform that any agency, be they federal, state, or local level, can use to drive their website and give everyone a really good experience online with government. So how do you do that? How do you make a platform that is applicable to a really wise way of agencies? And this is a John Sheridan solution, TM. So it's the pattern solution. For those of you who attended Drupal Guard 2014, John Sheridan did a really, just to sort of introduce who John Sheridan is. He's the Australian government CTO. So he's sort of one of the people, or the person probably who is behind a lot of the driving force of GovCMS. The whole idea of patterns is that any government website in relation to GovCMS will fall into one of these different patterns. Pattern one is GovCMS. I will fit into that mold. Anything that's on GovCMS currently, I need on my site, I can speed my site up immediately. Pattern two, 90% of things that are in GovCMS are in my site. GovCMS will have to evolve a bit to become what I need to run my site on it. And then there's pattern three, which is completely custom. And I drew this little diagram earlier. And this really kind of explains where the patterns fit in to the GovCMS development workflow. Pattern one can go straight into GovCMS today. 100% match of requirements. Pattern two has a little bit of evolution. Maybe we need GovCMS v1.1 and then it's a 100% match. Pattern three can use GovCMS but needs a few other things. And eventually the hope is that we'll come back into GovCMS in some version at some point in the future. So now the technical bits from the really professional technical people. How do you fit all of these departments? Be they state level, be they local level, federal level, into the one platform. What we needed to do is we needed to grab a lot of requirements from everyone. We needed to look at what kind of users are going to be logging in, what kind of content types are going to be available, what each individual agency interacts with the citizens and residents that they're dealing with. So one thing that we did is we took a look at, say, content types. And we realized that most departments are actually going to be using really similar content types. Events, policy. There's going to be maybe blogs, consultations, media. But really there's not going to be huge amounts of, you know, custom requirements for each individual agency. And you can actually do this. If you go on any kind of government website now and you look at it, you look on a few pages, what it boils down to is not a huge amount of different requirements. They all kind of do, if you sort of, you know, take away the URL and any of the marketing language behind it. Mostly similar things. So where does Acreified Site Factory work for all of this? How many people in here have heard of Drupal Multisite? So a good amount of people. This is essentially Drupal Multisite, but done in a way that can handle thousands of individual Drupal sites in a way that is sustainable for the platform. So all of these sort of little dot points here kind of explain it a little bit. And I'll go into a couple of these. So what we do is we have a dashboard for the entire site factory. Individual permissions and user permissions can be delegated to a number of sites, to groups of sites. So if we think about Department of Finance, for example, any kind of site that falls under the purview of the Department of Finance can be grouped over here on this other administrative dashboard to only Department of Finance users. This then allows us to have a bit more of a granular perspective for security and site management. It's still one code base under it all. There's still only one code base and a multiple number of sites, as is standard with Drupal and Multisite as we know it. So we do have to care for the code base and the platform as a whole. But it just allows a better amount of reliability when spawning new sites, creating different sites from clones, cloning different sites from sort of original sites and so on. So the tooling that we use when we build GovCMS, we try to keep it as open source as we possibly can. We try to use all the kind of tools that would be used in a modern development environment. Drupal, obviously, we use that for the site itself. Drushmake, we keep the code base really small, really thin a make file and that pulls in all requirements and builds the whole project from there. Thing we use is our sort of build instructions that fires off Drushmake, fires off all the testing and things. Composer for our dependencies, PHPCS which I think Nick mentioned in his previous session. So we run code SNFs, again, Strupal Coding Standards for any new code that hits the site to make sure that again, our platform is kept healthy because that code itself isn't necessarily indicative. Badly written code isn't indicative of something that's unhealthy for the platform but it doesn't help especially if we're passing this on to new developers, releasing it to the community and allowing other people to contribute. Git, everything is in version control because we're going to put things on GitHub, we're going to want people to contribute, we're going to want other agencies to contribute. Behap, which I'll cover a little bit later for our behavioral testing and Travis CI which is really kind of awesome for automated testing to make sure that whenever anyone does submit a pull request, whenever anyone wants to contribute some more code, contribute anything to GovCMS, we don't have to manually go through line by line and make sure that everything is correct. We just fire it off to Travis, it goes, it does all the syntax checking, it makes sure that all the tests pass and make sure there's no regressions and then we can manually look at it and make sure that it passes our muster as well. So, kind of the meat about what this session is about, the architecture of GovCMS, how it was built up, what we're using as some of our bases and all the things that we're sort of adding on that we'll look under the bonnet. So, the platform itself is really formed of these sort of fairly key components. So, the base is sort of the infrastructure layer with Aquacline Site Factory, which itself is built on Aquacline Enterprises. Another sort of abstraction layer that allows that multi-site to take place. On top of that, we've got Drupal using the AGOV distribution as our base and then on top of that we've got Contributed Modules that the GovCMS distribution adds and any GovCMS modules as well. So, a lot of websites will have their own tweaks modules and specific modules just for specific functions. We're kind of having a whole of GovCMS tweaks module, if you will. So, anything which is going to be relevant to the whole platform, that's something that we would want to be added into the platform rather than sort of, you know, a department of finance dot module. It's really going to be a whole of government kind of platform. So, this is sort of a little bit of how the code workflow goes and this is a little bit of sort of the piping and electrical conduit underneath the bonnet. What we do is using AGOV as our base and AGOV obviously pulls in Drupal Core and Contributed Modules. We then use our DrushMate file to pull in that dependency and then any other dependencies that are needed specifically for GovCMS. So, that all gets made using DrushMate and then from there we can distribute that out to GovCMS on running on Site Factory. So, the code base is actually running on the Site Factory platform. We can distribute it out to any other site that wants to use it. We can pull the latest copy of GovCMS because it's going to be open source. Anyone can use it if they want. Anyone can use that distribution and of course distribute it to anywhere that we have a source. So, GitHub, Drupal.org and so on. So, really everything sort of funnels into GovCMS pulling in all those dependencies and then from there it's sort of Blunderbust Act to every weather that's used. Everything is pulling into this main center is one of the requirements from the government was that they owned the code base. So, they're the ones who there's no sort of vendor lock-in there's no sort of questions about do we have this dependency from this web service from this other person? It all has to come in to this central GovCMS repository and that's under the ownership and GitHub of the government. So, taking an example of today I look at my email at 7 o'clock in the morning at the time I woke up and I see that, oh great we've got some Drupal vulnerabilities in here. What have we got? Not relevant web form. So, web form this morning had a vulnerability. I'm quite glad that it happened actually because it's relevant to this. How do we take that vulnerability and patch it to make sure that GovCMS isn't vulnerable from now on? So, this one would fall under the prepared for hot fixes so we're ready for a hot fix in this case it's going to be web form. So, much like the other diagram here's our kind of patch workflow. This one will fall into the agov ballpark. So, agov is one of, agov is our GovCMS dependency that itself has a dependency on web form. So, what needs to happen here after the Drupal contract web form update has happened is agov will need to get patched. We then pull in the latest version of agov that has that patch gets through our government operations sort of review which for security issues is a very sort of thin layer because it needs to get deployed fairly quickly and then from there we deploy it to Site Factory, we deploy it to anywhere else that's storing that code, be that GitHub, be that Drupal.org in the form of a new release. We're going to work on regularly scheduled releases as well. So, the general way that new code gets released is going to happen in conjunction with Drupal core security releases. So, much in the same way that on the I think fourth Thursday or third Thursday of every month there's different security releases for Drupal core. We'll be doing to make sure, I think it's third Wednesday but we're at time zone ahead or something we're going to be doing a very similar thing and what we'll do there is we'll create release for all new security issues so they're fixed immediately and then any other scheduled issues that come from the continual development and continual work in GovCMS from partners and from different agencies. This allows us to give all of the agencies who are using GovCMS a timeline for when to expect their new code to go out. We can do load testing, we can have regular deployments and we can make sure that any kind of patches that come in go through this workflow and they get scheduled to get released on time and sort of to schedule for whenever the agency is expected. So, this is a really common saying in the Drupal community there's a module for that. Let's say I'm an agency who needs to change the color of their node titles to red on a Wednesday. So, firstly over my dead body that that requirement goes into GovCMS, but aside, aside, my too. How do we make sure that any modules coming into GovCMS are going to be good for the platform. They're going to help the platform and they're going to keep the platform healthy. What we need to do is we need to ensure that anything coming in, any requirement coming in goes through a proper review of Finance, Acquia and our partner network to make sure that this module is going to be good for the health of GovCMS as a whole. Quite often what that requires us doing is find out what they really want to do and this is something that I see day in, day out with the job that I do to help it. What are they really asking for? Is it that they're only wanting node titles to be red on a Thursday because of a number of other different requirements. Quite often that's the case and you can boil things down to something very simple that requires, say, the rules module, something that the whole of government would probably benefit from. What we have to do always, always, for every single decision, for any module, for any different piece of functionality that goes into GovCMS is consider the platform. While it's very easy to add modules and, you know, there is a module for literally anything, well it is very easy to add modules to any other standard site and I'm sure, you know, I've definitely done it. I've got a dev module with, I think, three different downloads on my personal site because it does one specific thing. We can't really do that for GovCMS because one, two, three, four years down the line, we're then going to have to maintain that module in the context of 200, 300, 400, however many sites. So everything that goes into GovCMS, every module, every tweak, every, you know, different feature or hook, it needs to make sense for the entire platform because if it doesn't and if it only makes sense for one different site then we need to work on their requirements to make sure that their site is going to be good for the platform. That really kind of dovetails into the next point about keeping this server-based lean, not adding additional cruft with modules that aren't needed anymore or modules which only serve one very specific purpose. One of the aims that we have when we went into this process was that we'd look at more API modules. We look at, you know, modules which weren't doing one specific thing but could let you do one specific thing through, say, the UI. An example of that, I'll go back to Google for example. Rules module, yeah, sure, you can make it do one very specific thing. You can make it send an email to someone whenever anyone comments. But you wouldn't write a module just to do that. You want this module that acts more like a framework to let you choose the actions and the events that happen. That's really what we'd like in GovCMS to make sure that we're having the least amount of modules but they're able to do lots of things because they're able to do lots of things that are going to be more relevant to a whole number of different government agencies. The other thing that we're doing for keeping things lean is having our DrushMate file and having this as our way to create and build our code base. By doing that, we're keeping the amount of maintenance that we have for the site really low. We look at our code base, we look at our unmade downloaded code base and it's about that big. It's a make file, it's some documentation, it's a few tests. Obviously when you build it it becomes that big. But by keeping things small they're easy to, we can easily see what's changed. Going back to our Webform vulnerability today, how do we change that? What is the difference between yesterday's version of GovCMS and today's? In our repo it's one line. We change our requirement from Webform 7.4 something to 7.4.4 the latest version of Webform. On a normal site which doesn't get built with DrushMate, you've got an entire module's worth of differences that you have to go through and check and make sure that you have an accent that you've committed at a .gignore somewhere. Why we do this is because we need to make sure that each individual agency isn't going to end up spiraling out like a massive tree of code. The GovCMS itself isn't going to get massive and crazy and like binds and tangled words. We need to make sure that we're keeping a real strong hold on what brought us here, what got us to this position and that we don't get that moved again. We need to make sure that GovCMS is maintained and watered and cared for and tended so it doesn't turn into a tangled massive bind. I'll flip back to testing. This is a little bit covered by what we spoke about earlier with some of the tooling that we use. We run both code tests and behavioral tests. I'll talk a little bit about behavioral testing in the next slide, just a quick slide. With any code, with any pull request that comes into the platform, we need to make sure that it's syntactically correct. We need to make sure that if that just goes out without us even reviewing it, which it won't, but if it does, it's not just going to crash the whole system, white screen the whole, there are any sites using the module because there's a syntax error. Someone accidentally forgot to include a semicolon. I've done it. Very quick test, covered by automated testing. We need to make sure that it's covered by Drupal coding standards because you can have beautiful code all written on one line and it's not going to help anyone. It needs to be written in the coding standards expected by partners, developers, agencies, individual citizens and residents who are going to be working on and forking and contributing to GoCMS. Psychometric complexity. We need to make sure that anything added in isn't ridiculously crazy and has several thousand different if statements within one function. We need to make sure that the code itself is the same and that it's fairly, fairly simple from a code complexity standpoint. And then we need to run a bunch of tests using the behavioral tests to make sure we're not dealing with any regressions at some point later down the line. The really cool thing about the hat is that anyone can write these tests. Hands up who hasn't heard of the hat. So what the hat allows you to do is write tests in regular language. So rather than any kind of particular code language, it's more of a as long as I say this in the right way it'll test this. So a really simple example and one that appears in GoCMS is we need to make sure that we get the right Google analytics addition in there. If you and I go to the home page then the response should contain that particular code. Anyone can write that and that's really what we want to do. We want to lower the barrier of entry to anyone who wants to commit for request, contribute a test using the hat. It's really simple to do. So that should actually help us do that. So benefits of GoCMS asked Julie again what GoCMS made her feel like she responded with hearts in her eyes. There's a number of different benefits for people in the community. So benefits to agencies. As Glenn mentioned earlier it's going to really reduce cost to different agencies. It's going to reduce time for public procurement time for evaluating different options and it's going to allow agencies to get spun up on GoCMS a lot faster than they could if they decided to do it alone. Also there's going to be the whole support aspect that comes with GoCMS hosted on AcrePlyas site factory. Benefits to Australian residents. Now I purposefully wrote residents here instead of citizens because I'm not technically a citizen and I hope to benefit from it in the same way that anyone in this country be their resident citizen whatever. Benefits from hitting a government site and learning any of the information on there. So let's say I go to gov.au and I want to learn about citizenship. If that site ends up on GoCMS using all of our standards using all the things that we've learned then I'm going to be benefiting from that myself. There's going to be a familiarity across the breadth of government sites. Any site should be built with the same kind of focus and the same sort of feeling in mind. So I go to one site or another site and it's one government and it's one GoCMS. Benefits to government employees. So all of these things here are probably things which, if you take the reverse of them are frustrating factors for people working in development, working for the government. Not being able to do a public contribution because everything has to remain behind the government firewall. Not being able to see your name in light on Drupal.org for a Git commit that you wanted to and not being able to contribute a patch. Using modern tools, agile processes, making sure that all these things that you're learning about in the news, hearing on different IRC or blog posts are able to actually be used when you develop these things. So we're kind of looking to bring the development of GoCMS in line with any modern Drupal project. Benefits to the Drupal community. So going back to one of my very first slides. This is going to be a flagship Drupal platform. It's going to be up there if not surpassing the likes of the White House site and of Gov.uk. Having an entire platform for all of the Australian government agencies to use if they would like is a really great example to use for open source and government. So there's also a mandate to contribute enhancements. Anything that goes into Gov.CMS any kind of enhancement or tweak or module, there's a mandate to contribute that back to the community. So it's not just leveraging the community and bringing in code, bringing in modules. There's also going to be modules developed. There's already been a number of patches to contribute to modules from Gov.CMS back into the community. So it's definitely a two-way thing and increasing skills in Australia. So with the Australian Drupal community what we're looking to do is skill up anyone who wants to contribute to Gov.CMS. Whether that's partners whether that's people who are engaging with agencies themselves or developers and publishers or authors at agencies increasing the skill of everyone increasing everyone's Drupal skill across the board is going to be beneficial to anyone. When they are looking to transfer between departments when they're looking to gain a job in the government then having the knowledge of Drupal that every single agency will use is going to be advantageous to them. So how to contribute how everyone in here can contribute to Gov.CMS is community and partners. So if there's any agency or any sort of departmental employee in here who wants to contribute to Gov.CMS the best way is to get their site onto Gov.CMS to learn about how Gov.CMS is going to be used for all of the different sites. Community, just by learning about Drupal by being here by being in the Australian Drupal community or the Australian New Zealand Drupal community allows you to learn more about Gov.CMS skill yourselves up and in turn pass that on back into the community or towards Gov.CMS and partners. So we have a really great partner team who are going to be working with different agencies to to push forward Gov.CMS so any kind of work that an agency is going to be engaging Acquire to do our partners will help us to push that site up and into Gov.CMS I've got a couple of links here that aren't quite live but are sort of lying. So as Glen mentioned earlier the code is there but it's not there. So these are the places that the code will eventually be when things are published when Gov.CMS is released to the wild. We've got a project page on Drupal.org called Gov.CMS. Luckily no one took that name space and also the one on GitHub as well so this is where things will eventually live. These are where we encourage people to take the code, to fork the code if on GitHub, to submit pull requests, create patches write new tests learn about how Gov.CMS is built learn about the architecture underneath it if you need to and suggest solutions there's really not a limit on how people can contribute we're definitely going to be taking any suggestion that people make, if it's a great one then that could well be in the one point whatever of Gov.CMS definitely looking to engage a lot within the community. So here are the resources that Glen mentioned earlier and don't bother biting these down I'll keep these on the presentation and it'll all be online with the resources in there and this is me and any questions? Turns out I have three questions can you go back to the previous slide just for a second? I think so I don't know how to use this there you go so one question and one comment to go the question is you indicated you seem to indicate there would be a standard look and feel across government properties how does that work? So it's not so much the look and feel itself because obviously each agency will be able to contribute their own theme that's one of the advantages of site factory itself any site can kind of look different it's more about the architecture underneath it so making sure that if we have say a taxonomy and different tags in a taxonomy then they're going to be something different agencies it's also things like making sure that one site doesn't use say one content type with one different field and another one use seven so having a really strong baseline information architecture of course people can go and create 100,000 different content types after it's released on their particular site but having that good base we're kind of hoping that people will think that that is sufficient and if that's the same across all government departments then that's something which will keep that same feel without extending the architecture too drastically The government digital standard in the UK is also really heavy on a very fine example of mandating a lot of aspects of UI and best practices so that there's actually quite a consistent look and feel across all of the government UK portals and units so that's sort of the origin of my question So what is the Australian DSS which is modeled after the UK version quite strongly as it becomes stronger and clearer we'll be building facets of that into GodCMS as well so there's sort of that ongoing iterative improvement when we get our own DSS and the one comment I wanted to make is of course it's I like that you say well it's not mandated everyone can use their own system but if you look at the number of carrots here that are on offer I'm not sure that you need any sticks at some point in terms of cost efficiency and what have you So to be absolutely clear with my funny little joke earlier it's not currently mandated that agencies have to use GodCMS it's just going to be a pretty good idea and that's going to be pretty much on the site tomorrow At the moment what's the between GodCMS and AGOV apart from maybe some ADI stuff which is the growing interest So I need to get back to you on all the specifics because I don't know the default on my head but we're using AGOV as a base and then anything in extension of AGOV as it currently is AGOV in the current release is in sort of different custom, well custom modules currently but hopefully contributed modules for GodCMS So I need to That's entirely possible That is entirely possible So it's just the case that there's different things being developed in different areas So a lot of the contributions currently are going directly into AGOV There are a few contributions that are into GodCMS the platform There are a few other contributions which may not really be relevant to a non-GodCMS website So maybe a government website, but not a GodCMS website for example So anything like that is currently sitting in the GodCMS repo but not in AGOV That works You're just wondering regarding security and sitting on a scaling group It's on a number of web nodes So it's like a Drupal multi-site where there's one code base across a number of different high availability webs So what was the sort of question about attack vectors and things So DDoS prevention is probably a Glenn question It was on a very high level that we've got both CDN and DDoS services sitting in front of it all So the intent is that should not happen In the back Around the partner involvement You mentioned earlier a few of us here We have some more questions So you mentioned partners who assist after we are released through the agencies So for example from a partner How am I going to be first of all be aligned with the agency and how are we assisting Acquira So that's probably a question that I'll delegate to one of my colleagues who are in the room right now who know more about the partnering site that Acquira are doing with different partners and different agencies in APAC and that's the same for any person who has sort of a similar question I can throw in there that through the agreement that finance is built with Acquira we've got options so one option is for agencies to procure services basically through finance through it's not quite a panel per se but Acquira and their partners it does not preclude an agency if for whatever reason they've gone out and procure their own services and they've grown that whole process it's not as though we'll say hey you weren't of Acquira's you're not coming in the requirement though will be that any work must be done on a gut seamless distribution you can't just be out on Drupal plus X and then expect that to shunt in a gut seamless So just following up on that answer to that I know at this time to Preston you mentioned John Sheridan's three different types of website the first one is the one that fits perfectly in the gut seamless and then you had versions 2 and versions 3 both of which would require gut seamless to develop somehow in the future I can say it's going to be quite difficult to handle version 3 and then maybe even version 2 in the future so how do you expect where we're able to say hey we've got a customer requirement obviously you've got site factory you've got departments you've got a foundation to provide a customer solution is that going to be possible? So version 3 is really for those sites with crazy ass requirements like I've got to hook into this service and this service and I've got to do this and I've got to have all this flash here it's something which going back to one of the early sites it wouldn't be good for the health of the platform there's very very few of those sites when we actually look at it pattern 2 sites which is those that gut seamless kind of has to evolve to meet that's actually a fair number of sites and really by evaluating requirements and running discoveries with those clients we find out that the gap is not massive the gap is not massive between where gut seamless is at some point in time and then the jumps to add in those requirements to facilitate a pattern 2 site the aim is that all pattern 2 sites will eventually become pattern 1 because as gut seamless evolves suddenly those requirements will meet one to one so for the really crazy pattern 3 sites generally maybe they're running on Java and they need crazy stuff maybe gut seamless isn't a good fit but for some pattern 3 sites they can eventually come in at some point down the road and any pattern 2 site will follow the overall evolution of pattern of gut seamless is this a follow on? I'll allow it talking with John last August the initial conception of type 3 sites was massive custom development so please start with gut seamless and keep the base the same so that we still have security Tara? this is a question from the outside as I'm not government I'm SDS but there seems to be a lot of different contact points how will something say a year and a half 3 years down the road go say a new version of gut seamless and other sites how would that get rolled back down to all these other sites they've finished, they've got obviously things like content types aren't going to be future content types maybe they're not going to be if they aren't rolled into any kind of feature because they do follow the general evolution of gut seamless that can be something that can be turned on or turned off for different sites for any kind of custom functionality the general rule will be that it's there, you gain advantage of this should you need to use it but it's not going to sort of affect people and just turn on magically and affect sites which have been running happily that's the question so it's mostly I'll also chuck in the DSS mention it yet again the digital service standards it's going to be encouraging government more than ever to continuously improve this idea of build the sites and now we're done hopefully it's going to be something of the past because I think every government agency website from brochure where right after transactional services can benefit from continuous improvement so that's going to be a massive culture change for government to do that but they should be on their path I'm so going to super quick because I know we're well prototyping once a week but since Dan's fantastic talk at Google South going to last year quite a lot of support and gathered for developing a lot where we're still adhering to his QE Go I'm curious to know how we can use that existing resource and energy in New Zealand to create the distribution do you imagine that we would take government CMS as sort of a base distribution in format or how would you imagine it would be? it's open source that would actually be a beautiful outcome for us we're another country we're going to take this idea and concept and the distribution and then hopefully make it their own definitely it's part of the plan and imagine a future where we've got multiple countries contributing back could be something really really special for government and citizen engagement do you think your nature is going forward? is it too soon? any last questions? with the way it's organized can different sites turn on and off can they have their own custom module? if the site desires a custom module that will only be useful to the site then it's probably not going to be overall healthy towards the entire platform if it can be abstracted in such a way that most of GovCMS most of the sites on GovCMS will benefit from it and also that there's a requirement that most of these sites that they're going to use this module then that itself can at some point in future start to become a part of GovCMS the whole aim of things is not to have all of these sites spirally off and adding all of these different custom modules that's sort of one of the reasons that we're trying to pull GovCMS into the way that we're developing it just to end that what we're also building into it is white listed modules where agencies can do a bit of self service and there'll be a suite of modules in there that they can choose to activate or not depending on if they're going to use it we spin up a module about say citizen engagement to comment on government policy turn it on if you're going to be doing that but if you're not running citizen engagement in that fashion have the thing turned off pick your search engine pick your analytics so there will be a level of that you just can't jam your own stuff the back just want to follow on from that so all of the 5.3 sites then Gov actually sit within that I'm guessing because they will have their own complete custom modules yeah if as Gov said they've got all of these requirements and have lots and lots of different integration points with other things that require a lot of custom tweaking that nobody else in the government will benefit from it wouldn't be of good use to the platform it wouldn't make the platform sort of a happy thing so yeah the custom ones are sort of free to sort of it will be a bit different in an agency that does that it's not going to you'd have to do it for darn good reasons and if you give their support elements which in a way disappears on the site factory ones we look after the security we look after the module updates and all the support lines where you're at in that pattern 3 sort of space you're managing yourself and that adds a whole layer of complexity to an agency depending on your own skill it's the carrots again we are like we are way up so far let's head out and then if there are any further questions we can just hang out outside and just