 Welcome to the last last session of the day, I hope you've all had a good day. We're going to talk to you this afternoon about a project that we did called SpidersNet Infinity, which was about creating a site factory using Drupal and ADEAR. So I run a company called MIGGLE, we're based in Brighton in England. There are 11 of us, we work for the local national health service, New Zealand, Yahoo, NBCUniversal, a range of other clients. And today, myself, our lead developer Steve, one of our senior developers here, will be talking you through how we approach this project. And this project was something that we delivered for a classifieds business. We wanted to run a platform that would enable them to deliver a range of websites for automotive dealers, of which this is an example. So we have a hashtag which you can use for questions, comments or feedback. Any feedback would be greatly appreciated because this is only the second time we've done this presentation. So with everything, there will always be room for improvement, so we'd appreciate that. Or alternatively, you could just tweak the maintenance model of your first car. So that was my first car, a 1972 Red Vauxal Viva. It wasn't actually that one, my one looked in a slightly poorer shape than that one. But yeah, that's the hashtag for the presentation. And what we'll be covering, we'll look at the business objectives and how we matter about requirements gathering and replacing the existing solution. We'll cover systems architecture and specifically how we use Drupal and Agare, cover something on the platform code base, talk about how we collaborated with the client and how we then strive to kind of give them the independence to run that solution and how we manage change as part of that. And then what the kind of thing looks like going forward and in terms of how we've delivered that and try to allow the client to have a level of flexibility in that. And then at the end of it we'll take any questions that you have. So our client, a part of a larger classifieds group called the Friday Media Group, that group was founded in 1975. In an offline environment if you live in the UK, if you think about Loot Magazine it's very similar to that. Friday had predominantly kind of based south and southeast of England is where it's strongest. But the business as a whole has an international reach and it's got 75 dedicated, classifieds properties across a range of sectors. So all the obvious ones like jobs, property and motors but also some niche ones as well like guns, adults, horses, boats and forklift trucks. And they've kind of done that by acquiring a range of sector specialists as time has gone on. And one of those is one in the motor sector called Spider's Net. So this is an automotive online services company. It was founded by an ex-motor dealer who had a 20 years experience. It was started in 1997 and the Friday Media Group acquired it I believe in 2004. And they broadcast all of their classified listings to a range of other aggregators. So the obvious ones like Parker's, eBay and AutoTrader being kind of some of the largest ones in the UK. And then a range of other aggregators as well. So why did Spider's Net need a new platform? Well the structure of their existing platform wasn't manageable anymore. And its facility with that they found hiring in talent to run that platform and issue. There was no real sustainability, repeatability or standardisation. Although what they had in essence was a platform it had kind of got to a stage where pretty much each site was its own entity. And all of those sites were managed with zero level of version control. They also wanted to kind of get to a position where they could have more structured products that were better placed competitively. So to maybe have like an express offering, an advanced offering and an elite offering. I guess they also wanted to kind of replace the kind of death by a thousand cut syndrome and create instead an opportunity to innovate and grow their business. And also to be able to kind of provide more power to their car dealers. So give those car dealers tools that they could use to actually kind of manage the sites that they had bought. In terms of how we saw the project, we actually saw it as a really big piece of change management across the whole business. The project was going to represent substantial change both from a technical perspective but also from a sales and admin perspective as well. Top to bottom it was going to really change the way the whole business worked. And obviously while we were building that new platform, part of it would involve us having to kind of re-skill the existing team but that team would also have to kind of maintain kind of business as usual by running what they had in place already to be able to service all of their other clients. So we're going to use a bunch of kind of motoring analogies in this presentation. What we kind of said to them earlier on is that your use at the moment to be able to drive in a straight line kind of go as fast as you can. But obviously you can't kind of maintain that speed as you kind of go around corners or as you go around a steep learning curve. So you might find that you have to kind of slow down a little bit while you kind of consolidate all of the new learns that you have to kind of take into account. Also from our perspective as a business, Miggle believed that if you have tightly defined products that that really improves your ability to position yourself competitively. And as a result it could simplify the sales process and also simplify the development process. So compared to a scenario where there were none of those restrictions in place we kind of said to the existing team, that might feel like kind of putting a handbrake on where maybe in the kind of current scenario you don't actually have a handbrake on the car at all. So that in itself might feel, you know, a little bit odd going forward. In terms of actually defining what that change looked like we did a discovery phase in the first instance to determine product deliverables, to look at the existing capabilities of the platform, to clarify all of the business objectives, to look at what the technical requirements of the new platform would be and to also look at what the training requirements would be in terms of re-skilling the existing team. And ultimately the output of that was a product requirements document or a PRD. And in terms of building that PRD we wanted to kind of make that process as collaborative as possible. So we put the whole thing together using Google Docs, just created a folder in Google Docs. The main thing was a kind of document within that but there were various spreadsheets that would list things like content types, taxonomies, you know, so on and so forth. And kind of shared that with the client from a very early stage, from a kind of first draft stage, allowed them to use the kind of commenting functionality in Google Docs to actually kind of feedback on specific parts. And got that to a point where we had what we felt was a comprehensive document that outlined everything that we needed to do as part of that project. Once that had been signed off we then broke all those various tasks out into JIRA and used that as our means of managing development. So during that discovery phase we spent quite a lot of time actually sitting with the spiders net business. So you can imagine with this business as part of a larger classified group. You know, they've got an enormous floor with people sitting all around it. You've got the boats business in one corner, the horses business in another corner, the cars business in another corner. And then within an individual group you've got all of the sales and the admin and the developers all kind of sit together. So it's a fairly kind of close knit environment. And we sat and wrote a lot of the original kind of documentation with the team. So we were able to kind of see a lot about how the business ran and how the current technology was used. And what we saw was they were a very responsive customer focus business. They had a knowledgeable and helpful sales and admin team. The product team had a real can-do attitude and were very adept at finding clever solutions to facilitate the kind of things that dealers were asking for. And all around there was kind of generally good kind of processes and team spirit at least in terms of kind of managing client requests as they came in. However, that whole kind of can-do attitude and wanting to kind of keep the customer happy had had a very significant impact on the integrity of the existing platform and product. And I have that platform product in quotes because in reality when we looked at it we didn't really see it as a platform. We just saw it as like a bunch of code that was just used and copied. So all running off a Windows server, going to Windows file explorer, right click on the folder, copy it, move it into another folder, building your new site from the most relevant site that you kind of copied it from. So, you know, we didn't really see that as a platform. And for us when we kind of think about platform, there's a real sanctity to platforms. You know, platforms kind of do a certain thing and you don't deviate from that and you have very, very kind of strict rules around what a platform is and what a platform isn't. But then from the client perspective, all that they really wanted to do was put themselves into a position where their dealers were able to kind of sell more cars. So we had to kind of get that balance right between offering them flexibility while still maintaining platform control. And one of the questions that we were constantly asked through the whole discovery process is, you know, will flexibility be compromised? You know, so we had to be honest about that and say, well, yeah, in the short term, you know, that's inevitable that flexibility is going to be compromised and you have nothing boundary in what you can do at the moment. You know, if we're going to wrap boundaries around that, then that's going to create some level of kind of compromisation in the first instance. But in the longer term, that might not necessarily be the case. However, to best manage that flexibility, we really feel that the best way to do that is to have a much greater product knowledge and also a much greater kind of business knowledge and competitive positioning knowledge than what you might have in the first instance. And we think it's easier then to be flexible when you have, you know, established product variants, so you say this express feature or this express product, you know, just has these particular features, the advanced product has these features, the elite one has these features and so on, to have a roadmap that says this is how these product variants are going to kind of grow over time and ideally for that roadmap to be socialised, not just within the business, but potentially with clients as well. Obviously internally and particularly from a development perspective, for not just being able to kind of develop sites in Drupal, but actually having an all-round better knowledge of what Drupal could do and to be aware of that. And yeah, and generally to have more shared knowledge about their competitors and also the features most requested by clients across the sector. You know, so they don't necessarily try and get one product out to market just because you've got one dealer asking for it if none of your competitors or none of your other dealers are asking for anything remotely similar. So that was how we kind of approached product requirements gathering and discovery and thought that we had a pretty good handle on what was required. But what we ended up doing anyway is that we hopelessly underestimated the task at hand. And so obviously that had an impact. So what was the impact of that? Well, the initial delivery took longer. Spider's Net business priorities changed over the course of the discovery period. When we were first briefed, it was very much about the fact that we want a platform that enables us to basically throw these express sites out of the door in two to three hours. And we want to grow the number of express sites that we're selling and get those out of the door as easy as possible. But then over the period of us kind of going through the discovery process, they thought about it and said, actually, we don't really make much money on the express sites. It's more about us being able to kind of sell more elite and advanced sites which obviously require greater flexibility within the platform. So initially our heads are in this kind of realm of actually delivering like a real cookie cutter solution where, you know, which would have been really easy to do on a platform basis. Whereas actually we had to kind of think about how we could deliver something where potentially kind of sites could go off in kind of different directions and different variants would still be managed by the same kind of consistent feature-based code base. Obviously, as with all projects, the devil was in the detail and the PRD that we wrote really only had the time and opportunity to expose so much in terms of requirements. Client obviously didn't want an open checkbook or end date. And I think as a result of us finding that delivery took longer, you know, one of the things that we found is that, and I think to the client's frustration at times, is that at times we made time-based assumptions often as a result of having to kind of brief out so many tickets to so many developers just to keep on top of the timetable. You know, so as we started to slip behind with certain bits or with certain requirements kind of became broader, you know, regardless of whether we could buy that extra time or charge for that extra time or not, it was often the case of actually thinking about the same time, how do we onboard extra developers on to that, you know, explain to them what the project's about, you know, get them up to speed, you know, and to try and do that, making as few assumptions as possible. But despite all those challenges, collaborative working really kind of held it together. So on the right-hand side of this picture, you've got me sitting there saying, you know, I really need this product live, get it live. On the client side of it, you have Laura saying, I really need this live, get it live. And then at the kind of product level and the developer level, you know, you had the guys kind of working on it, really striving to kind of build the best possible solution that they could and really actually enjoying the experience of working and learning together. So in terms of what that journey and experience looked like, we're going to go over that now and then it's going to talk about the front-end bit first. Okay, so we wanted to keep the client involved with the front-end. So we wanted to be able to keep the client involved with the build stage as well. And as part of that, they decided they wanted to use these foundation framework. On top of this, we agreed as there was a country of Drepal theme available, and it had to be sponsored. It's closer to the mic. Okay. Okay, let me start again. So we wanted to keep the client involved in the project on the build stage, and for that, they chose the ZERB foundation theme. With the ZERB foundation theme, it's obviously a responsive grid system, and there's also a country of Drepal theme. It allowed the client to build the pattern portfolio, the style guides, and to find site structure. What this allowed was for us to concentrate on the core build and the actual platform. To do this, we used DisplaySuite, and the reason for using DisplaySuite is to me, there's three parts of DisplaySuite. You have the global benefits, which keeps the Drepal standards, and it only alters the node output and not the page structure. For the client side, it allows them to quickly create and manage view modes, manage field ordering from the UI, add dynamic fields to entities without coding. So as an example, creating dynamic fields, being able to embed views inside the node, and then add CSS classes using DisplaySuite extras, and also extra functionality with field groups to create containers and divs around items. On a developer point, we can build custom templates in code, and can be used within multiple places. An example of this is you can create display modes, which can be used within views and Apache Solar. They link up with features, so for verge of controlling and pushing between all the platforms, it's easier to manage. So joining everything together. So once again, we can create display modes, create custom templates, which can be used within views and Apache Solar. It allows the client to alter the templates of the search result output. It allows SpidesNet to actually use the UI to drag fields up and down, change the regions within the node, and... So this point is about theme inheritance. So one thing with the platform is we use the SerVoundationBase theme. We then created a parent theme, SpidesNet theme, which define the page structure, so sidebars, header, footer, content area. Then the actual whole platform uses an install profile, and one thing the client wanted to be able to do was install an express site using a dark or light theme. So we had those as a child items. And then on top of that, the client can then go in and create custom themes for the advanced and elite sites, which allowed them to actually override all the template files. And now over to Steve to explain how that's all joined. So once we had a good idea of the actual site build and how we were going to put together the front end, we started about putting together a distribution. So a key part of the distribution was to have an install profile which would enable us to take all of those parameters, put them together in those three different variants of sites. So we created out a custom install profile which would take in some specific parameters. So some of that key business data for them was to have a dealer ID and that was their internal piece of information which held everything together from a business perspective. We created it so that it was able to have different default configurations so that you could set the variant. So that was the express, advanced and elite packages. What came out with those was certain dependencies would be enabled on install. And then also to retain the flexibility we created some custom elements that would actually look through the code base to pull out certain features and those features could then be enabled directly on the install profile as well. This was also integrated into the AGR install and I'll cover that a little bit further down the line but we added into the install profile some custom elements that meant that you could pass those arguments directly from AGR through into the install profile. So the initial requirement was to replace our existing system. It was a 10-year-old classic ASP system. It had been built out over that period of time and highly customized towards a specific use case and eventually replaced that with something open source. I wanted to retain something open source for the whole stack, which made AGR an obvious choice. It had to be scalable as well. It had to be high performance. It had to be extremely repeatable and really robust in that we needed to avoid their existing scenario of copying solutions and actually go for something clean from each install. It had to be easy to manage for a small team. There was only two guys that we actually up-skilled initially. The team was expanded to include larger parts of the business now. But either way it had to be something which was going to be very easy for them to manage and a bunch of shared components which could be reused very easily. And then tied into the whole system was a rebrand and part of that was making the whole solution mobile responsive. And the final requirement for us was to write out a training schedule which would essentially define a roadmap for each of the new team members and basically take them on to the kind of Drupal ecosphere and show them all the different tools that they would need to work through that. So here I've listed a number of the platform features that we had to build out. This was some of the elements that we gathered through the PRD period of time. And all of these ended up as custom or features or contrary modules which we built out throughout the process of the build. So part of this was to define whether or not there was existing solutions for these of which there wasn't necessarily in most cases and in a lot of cases there was ways of just configuring stuff just directly using features or just creating certain entities for handling those things. One of the specific modules that we did create into a contrary module throughout this process was the live chat integration. They were using a specific live chat called contact at once so that was now available as a contrary module which we've created throughout the process of this. As I said, it had to be an open source stack so we chose A-gear. I'm sure most people in the room here know what A-gear is but if you don't, A-gear is the Nordic god of the sea but in this case, it's a Drupal 6 site but it has a great UI for creating and managing platforms, servers and site instances. There's a very active community around it and 40 plus contributed modules which handle different front-end, back-end tasks but ultimately it's just a Drupal site so we wanted to give the client something which meant that they had the options to customize it, configure it over time and essentially give them the abilities to manage that in-house. So A-gear refers to different node types of server, platform and sites but essentially gives you an interface for managing those really easy. So I've added a few credits down at the bottom here of the people that essentially are the key resources that I used as I was putting together this solution and without those guys we certainly wouldn't have been able to get as far as we did with this. Key part of retaining the performance aspect of their platform is to use the clustered functionality which in A-gear is called a pack. So in terms of the configuration we have at present and this is likely to change as the system scales we have essentially a load balancer in front of two web servers. One web server is essentially the master and the other web server is the slave. In this instance we have the database and the memcache server all on the master but over time we're going to distribute the solution over a number of other machines but there was an excellent walkthrough of just how to figure this cluster and I've put the link there of how to put that together step by step walkthrough exactly how to put that together. Before we did any development on the platform we had to essentially define some rules for how everyone was going to interact with the system. As it stands the project was nine, ten months and so over that time we created a lot of code, a lot of features and a lot of different content types modules, fields and so from the outset we defined a real strict naming convention for how we were going to put that together and so that was to use standard prefixes just general practice which I'm sure everyone uses anyway but in terms of kind of building out something which at some points we had up to nine, ten people working on it once it was very key for us to define that right from the outset and to have taken the approach of a contrary first which again is best practice anyway but to make sure that whatever we were doing as part of building the platform was to enforce all of that kind of good best practice stuff right from the outset and that included to document any patches that have been applied and make that part of the repo as well. So some of the key modules that we use as part of the platform build there's a very key search element to the platform so we use the Apache Solar module and FASAT API and we also use Apache Solar sorts and FASAT API select there was a key requirement to have drop down facets rather than standard checkbox or radio button facets so we use the sandbox module for that we also use the feeds module to a great deal one of the core requirements of the platform was to pull in feeds from their existing stock management system feeds an ex-path parser were really key on putting those parts together display suite as Ian covered it was a really useful way of us creating different display modes and then kind of exposing that to the client to manage that in a really usable way but one of the key modules for the whole platform essentially was entity form and this was essentially the first project that we actually used entity form on but in terms of the way it provided us the ability to just export different fields, export those those kind of key forms that made up the platform it was a really important step in putting together the platform most importantly because the key requirements of each site are essentially to drive customers through to those inquiry forms and of which there was about six or seven different types of forms and so it was really key that we had those in version control and easily editable so our objectives with the platform going forward as we progressed with the platform we essentially have now handed it over to the client but we have kept the ability to be able to add different update hooks and so moving from one version of the platform to the other is just a case of including our different changes within an update hook that we supply to the client but generally the migration tasks on A-gear handle all of those different changes from one version to the next for us we are studying closely the A-gear roadmap to see where this version of the platform lives within that roadmap and as I said we have contributed back a number of different things we have patches that we have contributed back as part of this and created a number of sandboxes and a couple of contrary modules throughout the journey we will also be doing this talk hopefully at Brighton Drupal camp so if you are in the UK around January we will be doing this talk there as well so we had to upskill the spiders net team that was certainly a steep learning curve to take a team from having absolutely no Drupal knowledge and limited PHP knowledge and to basically bring them into a world and show them essentially things which we probably take for granted as a community so one of the first things we did was to introduce them to a couple of websites so we sent them to Drupalize.me and BuildaModule.com and gave them the ability to essentially start the journey on their own whilst we went about creating the platform and then once we got to a certain point we moved that then on to one-to-one training part of that training was to introduce them to Drush we saw it as a key requirement for them to be able to set up their local environments and then be able to synchronize those local environments with their production environments so we worked out a way for them to create shared remote aliases and local aliases so that they could then move those databases and files between their local systems and the production systems we taught them a little extra things which maybe were specific to the platform around views and the space suite and context and a great deal of theme inheritance as Ian covered earlier there was a number of different levels in terms of theme inheritance so that was a key concept to get across at a very early stage and also to describe how to work on the platform how to use features how to essentially edit only the parts which needed to be versioned in code and separate out the parts which were essentially content and then finally we had to wrap it all up with version control and version control was something that they hadn't necessarily been using before and so it was a key key concept to to get across how to use gear how to use branching and how to essentially tag different versions of the platform and then push that out onto the server we actually managed the code base for the main platform and each individual site separately so that they could have one track of development specifically for the platform and then each of the individual sites could move at different places and finally we we looked to empower them through the open source community and through providing documentation for everything we did so we documented any custom steps we created that weren't covered by by drupal.org documentation and we created a quick reference handbook which essentially contained all those key functions and drush commands that they would need to basically interact with that platform on a daily basis and so that essentially was the way that we empowered them and handed things over Alex now going to talk you through the last parts of the talk I would say it was probably about three to four months something like that over a three to four month time period but probably about we probably did about ten one to one days with them which would involve Ian and Steve going there sitting down with them setting some objectives and actually starting to try and build sites at the earliest point if we could so that we were working on specific things and in the early days actually that's where a lot of the scope cream came in because as we were trying things it was like well actually we'd like it to do this so there was a lot of it earlier where the training kind of blended into trying to specify I wouldn't say so the guys were very enthusiastic and throughout having done the initial step of getting them to study up on Drupal on their own that meant that there was already a dialogue and they were already building sites of their own anyway so it was just basically taking them into how to use the platform rather than how to use Drupal and I think that was a really key step because I think if we had to show them how to use views from the ground up then it probably would have added a lot of extra time onto that actually when we started the one-to-one training that was made an assessment that that was the point where actually we were going to be starting to talk about the platform and not necessarily about like Drupal things, yeah so in terms of the clients objectives going forward they're now looking at kind of building out a hub in Drupal to kind of have that as a central resource for documentation to set up their own kind of internal procedures for reporting issues and bugs for managing feature requests that get driven internally or that get requested by clients they've started to kind of improve their kind of team structure so you know very much we kind of train the trainers and then the two guys that we trained have been responsible for taking it out to other members of the team and bringing them up to speed at the same time now that they've got a platform that you know is more reliable and solid they're in a position where they can actually start to kind of innovate in terms of what they offer as a deal solution so they're able to kind of apply more time and thought to that and less time kind of running around with the ball of string and the rear to sellotape you know patching things up and they're considering using Drupal in other areas as well there's another 8 year project that they have running to look at some of their other verticals like boats, horses and trucks and they're also kind of looking at some e-commerce projects as well just to kind of show you a couple of screenshots of some of the sites that have been kind of launched today and I just want to finish on by saying before we go into questions I'd like to dedicate this presentation to the memory of an ex-Migol employee who sadly passed away last month and he would have still wanted to be in a position where he would have been able to contribute and kind of give and our business would be in a lot poorer state without him so any questions at all? Thank you So how many, did you use one report to keep all of your teams your profiles of your code base in one place or how did you manage your code for? So I think I touched on it earlier we essentially had one repo which was for the main core and that was essentially the Drupal core the contrary modules the custom modules and the features the ones that basically made up the platform and then the principle was to have every site specific folder as it lived on A gear to be another Git repo and then essentially in that repo could then be another themes folder another modules folder which could then implement site specific versions of any of the modules that lived in the platform and so on an express site it was all actually configurable to the UI so there was in theory there's no need to actually have that child repo but as soon as it kind of moved to maybe the advanced and the elite packages the team would then have the ability to create that site specific folder and version it separately from the platform Just one more thing Did you have to hack anything into A gear system itself just making manual changes to the code the A gear platform No, we didn't have to hack anything into A gear we created a custom module that sat beside A gear I think I touched on it earlier that we created a custom module to essentially pass through arguments from the install profile screen so when you go to create a site in A gear essentially you get usually just the standard options which is to select the platform you're going to install on but we added additional parameters there that then got passed through to the install profile and then passed through to the actual site build How quickly do we react to security updates I mean in theory it should only take a few hours the platform itself now is kind of beyond our responsibility but I think if we were to handle those things just a case of committing in the new changes to the platform pushing that new version out like building the new platform on the A gear server and then migrating the sites across to it because we've done everything standard there's no kind of nothing that's sitting outside of that I mean it's as long as it takes to migrate all the sites to the new platform but essentially the aim is to have about 428 sites living on the platform so I guess that process could take a while that was out of the remit of what we were building I think looking back on it I would certainly want to put those things in place but certainly it was out of the remit of what we were building at the time we in the build process we essentially had an install profile which we maintained from the very outset of the project and so a successful install was essentially a successful test but then there was nothing necessary put in place to kind of handle regression testing the process was for them to essentially write an update that targets specific features so that you don't revert all features on a deployment or on a migration so not necessarily I think we discussed at one point kind of splitting out the features into kind of core features and like adjustable features but I think that was maybe the next phase and I'm pretty sure that they've discussed that internally and that's kind of part of their plan I think also with the features as well it's a we've kind of delivered it with a certain level of features and then depending on how granular they want to get with what those individual product variants look like I think they've already seen some things that they would want to take a feature and split that out into multiple features so in terms of the things that over the space of 10 months given that we've never done something like this when we started there are a whole stack of learns for us from how to spec this project, how to manage it how to kind of test it how to train a client how to get them to be able to more effectively deploy it I think that there are certain things that we're kind of impressing on them all the time things to kind of watch out for but at the same time we've handed over a product to a team in which the most experienced person in Drupal terms has been working with the platform or working with Drupal for less than a year so it's also about trying to kind of get things to a stage where they're comfortable being able to kind of move it forward and then establish to what extent they need support they can actually kind of run with it run with it themselves OK, so what's that buff called? Bopsite creation Bopsite creation OK, right All right, that'd be good, nice one, thank you Any more questions? You said at the start you did the discovery phase and you wrote a requirements document but it was more work than you expected it to be Were you working to like a fixed cost of a client or was it more flexible? Officially it was a fixed cost but then once we kind of got into the once we got into the kind of training part of it we um we had to kind of then start kind of charging additionally for the bits that started to come up and at that point it started to kind of go into a kind of more agile type approach where they would speck out a bunch of things that they needed done we would look at what availability we had over a period of a month and say OK this month we can give you like another 15 days and then get them to kind of prioritise just in kind of one, two, three priority order and then to kind of talk about how we would map that to the days sometimes those days would kind of depend on actually how much additional money they wanted to kind of spend on the to spend on the project so there was a point at which it started went from fixed to something that was a little more a little more open-ended and now we just have a kind of um rolling support contract where we commit to doing a certain amount of hours I think we commit to doing 8 hours a week we also put a days development in our schedule a week for them to be able to call on if they need it and again they just prioritise features against that Any other questions at all? If um you get a chance to a feedback on what you thought of the presentation that would be useful other than that Thank you very much for coming Enjoy the last day of Drupal Con tomorrow where you open up on the day of your sprinting on Friday Have a very nice time this evening Thanks a lot