 For those of you who don't know me, my name is Alistair O'Neill, I'm Al for short, whatever works, it'll be fine. I'm the technical product owner of GapCMS. I've been with the program for two and a half years, give or take at this sort of point in time. I've previously been a customer, so I've actually sat on that other side, teams at Australia Finance and then joined, as you do in the pandemic, a new project, and do different things in the space. So that's a bit of a moment back there. Vaughn, I think you've also come from the customer side too, different journey, but... I'll try and yield it. My name's Vaughn, I've been in and around GapCMS for about five years, starting as Al on the customer side and then getting the opportunity to see how all the products work behind the scenes. GapCMS, that's actually quite exciting. I started in the on-boarding side, so actually, from the on-boarding to the project management side. Great. One thing you didn't mention about me is you've been the project manager previously for our A-to-9 collaboration and guess who's holding the keys again for 9-to-10? This one right here, brilliant. So, you know, there's a lot of people here who are familiar with GapCMS, but we always like to do this deal anyway, so if you're not familiar with GapCMS, I'm sure there's at least two people who probably aren't. Either that or I'm a broke American. About us, so as GapCMS is a program, it's a by-government, for-government hosting solution. So when we think about people who are actually sitting on our platform using our product, they sit in that government space. So most of our customers sit at that federal level. We've got a few state ones, got a couple of local ones as well. Or we've got entities that sit in that space that are on the vice-government ones. So ones that feel like they're a private entity, but probably actually aren't. And also, of course, we've got coverage across all of those three, but I'd say probably a big sort of fish are federal. We turned seven this year, so been around for a while. I'd like to think we're doing a good thing. Tell me otherwise, maybe not damn maybe later. Maybe your questions. So in that sort of space, it feels like we've been able to build from there from strength to strength. Going back to where I mentioned while I was a customer, we were very well on when I was at IP Australia, and we're now to our next slide. Number one, we're just about here 350 live websites. So it tells me we've got growth. We've always got quite a few in the pipeline. That number is always somewhere around 40 to 50. That can be upgrades. That can be transitions to new things. Something's always happening. It never stops. Good or bad. And of course, we've got 105 organizations signed up with us. Some of those will have a lot of projects. One of them some of them might only have one. And of course, that's normally circles. Apologies for the branding today. Moving from a Windows 10 PowerPoint to LibreOffice on the Mac to those circles to squares. Good to see we no longer have any of these technological challenges as we switch between platforms. But always do it the night before too, so that's how it works out really well. So when we think about our offerings at GoCMS, when we talk to customers and when they come to the front door and not, we usually ask myself, we've got two hosting solutions. The only thing I should miss is something. So we actually work with Solstice Digital and amazing who are both here, both sponsoring in our actual hosting solution. So we do a lot of work with the teams that are here today and some of the people who couldn't make it. So chat to them. If you don't know them, you don't want to have a chat to them. It's the smart people that we work with. Now, back to our hosting options. So when we think about our two offerings, we land in the space of software as a service and a platform as a service. Now, when we're talking about a managed service, we are very much going to land on the SaaS space here. We do have a slide at the end for powers. But if a bit of a break down there, 75% of those sites that we've got going back to those numbers land in that SaaS space. 25% sit on that other SaaS site. When we think about SaaS, we're looking at infrastructure. We're looking at the distribution. We're doing things around security. We derive updates to that distribution. We derive updates to our infrastructure. All of those things. It's all very much encompassed in that service. As is the intent. On the path side, we do still do that infrastructure. However, that's where things start to change. Talk to our side owners. They're the ones managing their distribution. They might be using those as astounding points. They might be extending on top of it. They might be rolling their arm. As long as it's turbulent, and they're doing it safely, fingers crossed. It's a good thing. For them as well. There's also that security land. So for them, the harness is all a thing to maintain and manage nice things. And when we think about those updates, we'll tell them again to drive those to turn them out as a product and as a solution. Assas is the main focus of this one. And we will have that touch point in the interface. Great. Sorry. Digging into Assas a bit more. Ah, there's another little font trick between the boxes. Love it. So we have fixed distribution for Assas. Sorry. It's a good thing. It's a bad thing. But it's designed to be out of the box. So for a lot of the information or websites that we host, all it is for feedback. It shouldn't meet a lot of needs. And if we reflect back to that number of 75%, it sounds like it does. There's always a referral for improvement. Now, what we obviously aim to do with our open source product is we want to give that back to the community, but we want people to be having to download, use it, extend it as they see fit, or look through to what we've got, figure out whether or not we're the right fit for them. Of course, we'll put that out of GitHub, we'll mess up our other products. And of course, we want suggestions, we want people to review those things. And we want feedback from our community or just more in broader general people who are interested in these sorts of things. Hello the room. And again, coming back, that vast majority of cases when we think about from a business perspective and customers who are looking to come to us, a lot of them are looking for stability, security, things that are otherwise managed for them. I'm not sure everyone's background in the room, but what we find is some teams aren't well funded. They don't have the capacity to do a lot of these things. A lot of teams are otherwise communication teams, so they've got a great focus for the material that they put at, what they need to get out to the public. But maybe there's a few other gaps in some of these other spots, such as security or keeping things up to date. So that's where a lot of that benefit ends up being realised for our customers. Within that space, our sign owners looking back to those communication roles, they sit in a space where they can maintain their content. They can do whatever they need there. They can roll whatever governance process they need around publishing. They can do their information architecture. For anyone who's been around for a long time, they're all very simple things to do but it's something that's back on that customer side. And of course the question that usually comes up again as well from an engagement side customers do ask about whether some sort of limitations are between SaaS and SaaS. Within SaaS, the big one for most of them is can we theme it? Can we make it look like how we want to? And that is an option. Maybe that's not clear in how we're putting that material out so possibly it wouldn't work for us to do there. But they can obviously control what that looks like, the branding experience, we give them strategies and of course the higher ups making sure that they get what they want with their reason. I hope. So with a few of those things, there's obviously quite a few positives in that space. So again, security patching, the courtesy of the product, that's on us. That's us as GovCMS. That's not necessarily the two of us here but a couple of men or other from what he was here from GovCMS is part of their job. There's also a few more talks on that as the same as well. Check the calendar. And of course when we think SaaS, that's the price that we advertise on the site. The number that we have listed there is the number you hate to do those things in SaaS. So it's not a secret, it's not a surprise. Hopefully a good thing especially for those working with financials and the budgets. Again, infrastructure and application layers are covered. One less thing to worry about. It's all once again part of that price that's part of our offering. We just do it. And of course we've got some alignment there because of course as a government agency we're trying to fit government needs. So of course we have a minor application and of course a big one as well for information in public sites or partly public sites. Classification level info those who are really excited. That's up to official sensitive. It means we can grab a fair bit of information. Not a lot of those secret things. Probably a good thing too for public facing sites. And of course that other sort of level then as well. Trust and alliance in your product. So we have up time. We have availability. We're the ones solving those problems. Now, hopefully a good thing. Now of course the offset of that is there will break things for customers hooray. That doesn't make a lot of work for us though. So that's the offset. But that's what we've been paying for. So of course when we think about at least some of the things that we're doing. We're of course monitoring for things like security advisories. Obviously a lot of that's coming downstream from Drupal. But we also have a security team who's looking at not only just the Drupal layer but also those other aspects of our infrastructure and other supporting tools that we have in space. So we're the ones that are reviewing our stack. We're the ones that are identifying what those problems are, risk assessing them. And then of course if there's an application one, getting to the point of actually resolving those things. Of course, regular patching. All the time. We're doing those updates. We're looking at those model updates. We're looking at patches that are basically fixed in our stack. Problems or issues at the application layer. We're doing those core averages. We're doing those security advisories we're expansion. And of course we've got a pretty frequent rally schedule. For those of you tracking along from our status page, we've actually started doing the deployment this morning as of 5am. So that's rolling through our performance we speak. Fingers crossed that'll be done at least for our live sites sometime this afternoon. We've got 2 am already. Of course a big one as well is living up to our ethos. So of course if we're going to say we're in the source and doing things like that, we obviously want to get back. Not only in the things that we're making, but obviously we want to help the community as well. And of course we have to be on top and in front of a lot of these things. It means a lot of work. It means a lot of chasing. But again, tying back to that security and security for our customers. That's part of the gig. Whether we like it or not. That's what we've signed ourselves up for. And that's how we sell ourselves. And that's a really important thing. Now, into a form. I just wasn't sure. So yeah, so the eight to nine that was when So the overall project from automating the eight to nine upgrades for our own internal websites consisted of two very large streams of work. That was the entire technical aspect of creating the distribution and what and how the automations were. And overall, our approach of automating the South's websites was broken down into a nice three-year set process. Build foundations, do the security assessment, and then we launch the websites. But equally as massive was the stakeholder engagement of the entire chain management management process over the two to three year program period. I officially joined the Denon project in September 20. But the initial planning implementation of the project started at least 18 months, two years prior with Nathan and team socializing with customers. The idea that triple nine is coming and get ready. So in some respects, there were a lot of particularly time and in others, it didn't feel that way. But the many fun stuff didn't start until it wrapped up around June, July, 2020, once D9 was released. And when I came on board, the GUM CMS service ops and DevOps teams were well underway starting the D9 foundations. Toward the end of 2020, we had our first D9 candidate release and the final requirements and hand testing to do other security and other security assessments took place in February to April. We plan to launch the distro at the end of April. We had a bit of a false start and we launched two weeks later on the 11th of May. We worked through the automation process with agencies over a four month period. And we aimed a target date of 30 August to have all our D8 sites in D9. Giving ourselves a nice two month buffer, which we ended up using to get some of those stragglers across the line. We worked through the automation process with agencies which we ended up using to get some of those stragglers across the line. And then we retired the D8 distro in November. Throughout the whole project, the team needed to maintain as Al said, the distro. There was a lot of BAU core critical updates going on at the same time for such a small team. The first priority for the upgrade was to D9 and buy our D8 distro. So that once we made that final leap in the automations, there was such a minimal gap that there was less room for things to break. It also meant on average that at that point we were updating the distro at fortnightly, which was a lot, quite intensive time. So we can put in the security patches and all the queries. Part of D9 buying and was reviewing the D8 module usage, analyzing where they still needed and what were we going to do if there wasn't a D9 path. What were some of the changes that we made? Well, we deliberately made D9 as vanilla as possible. Only security and changes. Minox, Adelbox, we made D9 as vanilla as possible. This was to help our reporting so that we could actually get a good view and landscape of what modules were being used on the platform. We made TFA mandatory, in line with the essential eight of us, security essential eight. We deliberately made configuration management out of the box disabled. So remembering that most of our sites were set and began. And we only advised that this was enabled during active development. It suits the large majority of our program. And then on the technical standpoint, we consolidated the distribution. The distribution scaffold and the burn repositories in GitHub so it's nice and easy to find. So a little bit about the automation process. That was applied when we D9-ified the idea. The CR pipelines were used to emulate the upgrade process. So we had to re-run and re-run again until all our partners were green. Using the iterative automated resolutions approach that DevOps did, they started with the more easy solutions and progressively worked up to the more complex. For example, some of those issues range from simple method name-changers through to changing Tweet-contained and new configuration. But still at the end of it, we needed some custom resolutions for a few fetch cases. So what did the on-platform implementation look like? With the great foundational work that the ServiceOps and DevOps team had done, by the time we got to the finish line to complete the final upgrade we had D9-ified 90% of our website. Processing for agencies was all done using the feature branch from within their project. This helped the customer's focus, but it also helped us. Because of the technical stuff that DevOps needed to do, we created that branch for customers. The agencies were given the opportunity to identify and fix any issues from within that branch. We provided a simple checklist for business owners remembering that most websites were set with the event. They had developers. We knew that the agencies themselves would be the best place to spot the things that were wrong with their websites. And then once a customer or an agency had confirmed that they were all finished and they put their content freeze in place, they handed the keys back to us because of some more technical stuff needed to do, we switched their site life. All that, it was actually a very nice minimal impact to the customer on that end with up to a one-day content freeze. And it was done. So visually, this is how my time frame was. Full start of our launch meant that we cut out group one and smooshed them into group two. But all nice, it was nice, it was waterfall and a natural bridge. We even got a little break in between June and July. To us and us. But with group one and two, not surprising, it didn't actually have an impact because we had not too many people volunteer, but one of them was in the room for group one. And us. But other than that, the rest of our teams, it didn't impact anymore. As I mentioned before, we scheduled over a four-month period. Each agency was given two months, two weeks to do their UAT and kick it off in a round robin as we went through the whole process. For the most part, agencies stuck to their two weeks, some slipped and some were earlier all evened out. On average it was a planned 107 groups, 170 projects in eight groups, which is about 20 per group, 20 projects. When we switched it down to seven, it's about 25 in a group. And agencies, lastly, evened themselves out. They picked which group they went into, so that meant that they picked the timeframe that has suited them around their other BAU priorities. As I mentioned earlier, the project was two massive projects. We had a lot of... Sorry, we had every two months information and QA sessions. As anyone may working live, volumes of customers, validating contacts, the changing faces, it's a constant, I will say that now. We had to work with their competing priorities and timeframes. A lot of what I had to do was aligning our priorities with their customer with those, and what was that capacity for the customers to do this? What was their technical ability to do this in most of them didn't have developers? It was a great challenge and I'm excited to do it again. There were many more challenges throughout the project. So once I just said the capacity availability of the agencies to deliver the customer knowledge and capabilities and it's ranges from the very, very less technical where their websites are five minutes a day for a whole month, that's all they spend to the very technical there are standing on board. The timeframes themselves were at the time didn't feel too pressured. There were definitely some squish points. One of the biggest challenges we found and we'll find again is what actually did the customers build? How are we going to automate it? So, lastly, here's my nice proposal for each developer distribution. We invited the developers to test the D9 distribution. We iterated the distribution. We invited the D7 owners to move to D8 to join our process to get them across the line. We did a security assessment and we were going to launch the D9 district and that was a very nice plan that I had at the beginning. Oh, but this is how it goes. There were some ups, there were some downs, there were some squeals, there were some backwards and forwards, but that is the most accurate reflection of the 2020 plan. So, as an end result, what happened? We had some very big wins. All of our D8 sites became D9 before end of line. We had very limited issues on very limited sites, so most of the automation still care of the vast majority and even those limited issues on limited sites were D9 by 9% of their sites, so they only had a tiny little bit to get it across the line. We managed the process within the existing projects which meant not increasing projects, not dual publication, not large content freezers, we just D9ed their website in the background. At the end of it, Gaussian has got down to two distributions to maintain 7 and 9, so we reduced our tech people there. More opportunities for targeted fractures and premium environments. So, based on this D8 to D9 process we implemented our premium environments, so that we could give agencies the opportunity to test the PHP upgrades which we did 7.4, 8.1 and then a month or two later we did the preview fractures when we moved 9.3 to 9.7.4. And customer developers were more involved around the process, so there were so many things to celebrate. Sorry, there's some really good positive about that. It gets me a bit excited. Tom Reims, I think we're both still a bit worried about it, but we've done it before, we can do it again. Sorry, what do you think about some of those lessons to learn? On our left here we've got our Word Lessons. We've built it on the platform. We're already working there, let's keep working there. Let's not have to shift them to some point when they're on. Yes, we recommend we're working in the same existing projects as if one just touched on top of obviously, we don't have to dual publish, we don't have to have access again. It's all there ready to go. Customer, if they're familiar, can already jump to it very quickly. Thankfully when we were then expanding to those who maybe weren't so technical or maybe needed to get a sort of leg up, it wasn't too hard to then educate. Most of them had the access. They just didn't jump into those little spaces more than we would have liked. So again, one less hurdle in the way. Automation where possible. Run, run, run again. Oh, we could have run forever. And we probably should. Those small little things that we had left over in the scheme of things, it's great to be able to throw some resources at that, share it out. Among others. And of course, the big one, communication. And that ties back to a couple of things that I want to think about. Improvements against these good things. Build earlier, build often. One of the challenges we've obviously got with things upstream and downstream, but we should at least be starting. We should be trying if we can overcome hurdles now, but there are not things we're going to worry about later. Very important in my mind. Automate more. I felt like we had a really good run. I think it went quite well. I think we could have gone a couple of extra steps in those sort of spaces. Again, wouldn't be talking about capacity even our own resources, not alone our customers. If it's anything from deploying those branches of that sort of date, having them available, to, hey, let's make sure it's our mail service so we can then just give a button. We don't have to surface up an email list. All of those different fronts of the process. Purifying the scope. This one was when we talk about, again, a managed service, we're almost talking about everything. Everything is a lot. So for some of those things, it didn't necessarily become apparent until we got later in the piece or when a customer came from a customer. Again, having clearer pegs in the ground. Target of communication. As we've already touched on already, there's some kills here. We have a mix of audits. We've got people who are full-time developers that breathe in code and everything around them is like the matrix. We've got other people, like who might go in there and publish a newsletter, but they're the web manager. So again, people's experiences, people background, all of those sorts of things mean we need to have a better idea of who we're working with, how they need to be communicated to, what they need from us. So again, it's always going to be a challenge. Those changing faces time frames don't help, but we need to be more progressive about it. Not so good or bad. Timing. Timing is never great. We're dependent on others. Others are dependent on us. We have all the work going on. There's never a perfect time for it. You have to start. You have to accept that you have to start. Contingencies. As we saw the journey as we went squiggly, we didn't necessarily have some of those contingencies in place to counteract those or consider. Again, we have a lot of smart people who work on our platform and another product. But the reality of some of these things is we didn't see that as something that's coming. We didn't have a resource to potentially help the submersed spaces. We need to be able to consider those things and hopefully be in front of them. Capacity. Time to that as well. Do we have enough people to do these things? Do we have the right skill sets ourselves? Ignoring our customers, we've got that same thing internally. Again, we have some great partners. Who does what? Where is the line? Can we throw another body out with frameworks? Do we need to upskill? What is it? Lots of questions around those sorts of things. And the big one there as well is do we have to drop other work? And I know people don't like that and I know our customers have expectations from us for other things as well. Some of these things we're just going to have to drop. If it is not critical or it doesn't align to our sort of end of life or it becomes a security problem, we're very good on our security ones. They go to the top of the list. Some of these other things we probably need to put a hold on. Education. Again, going back to that customer point there's a need for improvement or how can they work through these things or what is their expectation? How can they feel more comfortable if their side isn't going to break? So when we think about improvements against those things plan, plan, plan some more engage more both up and downstream. So when we think downstream from us we're talking our customers. We're talking their stakeholders. They want to make sure that their things aren't falling over and they're working or they can release their corporate strategy or whatever it happens to be they still have their work and our own regardless of what we're doing. When we think upstream we use an open source product. We have a strong community in Drifl we have passionate people that are here in this room, in this building and around the world. We need to be better with them spend time with them and see that we can do any support in that sort of way and give back ourselves. Those are variable things because that then can help against our timing or our contingencies or giving back capacity. Plan for the worst, aim for the best always a good one regardless of what the project you're doing and helping customers help themselves. I think I've already touched on that but again giving them some confidence making them feel comfortable about what we're doing we're not obviously going to run a boot camp on how to do tweaking or anything like that but of course we need to set them in the right direction make them feel comfortable about what they need to go and do. Other considerations oh good upstream changes with core motors again that's a constant it's something we already work with we need to keep that in the back of our mind again it depends on whether it lands on our BAU business as usual side or that it lands on our build project does one influence the other do these other things need to happen in terms of security again model compatibility stability, security same sort of thing again and we need to consider that for the current state and of course the future's there security advisories those recurring updates are just generally a big one which everyone will talk to theme and compatibility this is a big one for 9 to 10 alright again we've got it in the life of Drupal 9 thankfully not going to be time soon but it's on the horizon again customer time frames they're up to their skills sets I think about our immediate time we don't have to go to probably Drupal 9.5 before we think about 10 again part of that's compatibility part of that's stability with these things part of that's where is the community and of course my new favourite one we make CJA editor and there's questions about whether or not there's an impact for our customers so we're thinking the content editing component and of course if there's an impact for our we'll do that as well and then the balancing act it's all of these things it's the things we've already talked about how do we how do we prioritise how do we organise all of those lovely things that's very long to manage so when we think about some of these hands on we've talked obviously about what we did last time with that hands on for the agency well it probably has to change a bit this time around I don't want to be the bearer of bad news but this is probably going to be the return we can automate upgrades we can apply features of tests we can't have complete coverage I think that's unrealistic for anyone trying to do anything regardless of whether it's us or the restricting or whether it's anything some of these issues are just going to manifest themselves as we help them out so again in those contingencies but on for saying unexpected issues again we're not trying to name names we're not trying to blame anyone but potentially sometimes it's the approach and we're trying to write a new feature whether that's the side owner whether that's the development partner hey it might have even been a decision that we made in how people are using our product so we could all potentially deal to them the old classic things just don't work what could that be and of course the big one for us is we can do all of these things at a current level for us, for our side, hey that model is enabled, this thing is on actually working well we can suggest a lot of those things but I don't own that content I don't know what people are looking at can I have coverage across 350 near websites no I guess people in those sort of scenarios are going to be those side owners those are the responsible for it sorry, in all aspects of any of this we've all got a part to play go team this time we're probably going to need one sorry and this is something that will be communicated to our community this is a ballpoint that we had really early on side owners retain ownership and management of their content information architect chat and can theme their sites I'm hoping that pink comes up alright more if I can theme their sites there, apologies if it's not as it aligns with their business needs brand new strategy, stakeholder preferences sorry a lot of our renovation last time the theme was pretty straightforward or even worse about what the issues were most of them manifested themselves as is it compatible or durable can it, doesn't have the right class there's all of these sorts of things there's a lot of that in for Dripper 10 but there's a lot of deprecation as well oh my goodness and apologies having said this back in the room earlier this will be very hard to say I will describe those smart people working on our platform specifically in this whole sort of moment we've actually now got a job in our pipeline which is running it's not part of the current real process so if you are a customer and you've got access to that project space you might see a fail thankfully it's only a fail against D10 compatibility the first screenshot up the top here is our D10 capability task as we have across the top and right so it's tests and that's marked with 18 jumping into this we can actually see what those errors are from a deprecation standpoint on a project right now for any project between our platform that does at least this Dripper 9 Dripper 7 are saying bye bye so we're not focusing on time there but when we think about this we're actually now already serving information to our customers about what their challenges are they're probably going to have to go back into their laps with their site developer partners or themselves depending on what those relationships are some of the dosers we've got here we're all probably familiar with the scenario if you come from a theme in the second there's quite a few changes here again we've got information here that says what is the problem when it was deprecated where it was now we've got time alright that's a more detailed one of those I won't hold on to that let's hit some really quick points here to get ourselves over the line good build challenges Dripper 9 compatibility this chart on the right-hand side talks about our growth of modules that are already DQ10 compatible 42% in our distro already have a path 30% of the modules have already been upgraded to DQ10 we just keep growing and growing we're relying on what's available that ties into what's still available what's nameable ah, here's the right form, everyone these are the modules that we're looking at that don't fit that model at the moment a group from a security or a group from a functionality so these are the ones that are currently going to prevent us from moving to 10 or are still entrenched in that sort of space these are the ones that we want to contribute back and if you've got anything to contribute there as well you can do that too we'd love to hear from you thanks Roach so we're going to use the same approach it worked last time it will work again we will build the DQ10 foundations we will do the security assessment and we will launch our websites we will take all the things that worked well and make them better and we'll take all the things that didn't work so well and make them better and more cyclic foundations, DevOps preparation insights will inform our district and our district informs our insights and so it will go until we launch our distribution just before we will do the security assessment launch the distribution and then proceed to upgrading our websites a time drain looks something like this, twice the effort and half the time at best now, from this point we've got seven months left to finish developing the distro and to launch it we've given ourselves a month to do the security assessment by the last time we did three and we've given ourselves three months to do the automation by the last time we did a little bit of a buffer in the end which I know we'll need but we've got to get the majority at the beginning of in our launch timeframe leaving the buffer for Australia and then we will retire the district the timeframe will look like this remember eight and how nice and spaced and we had a break and it was great this is twice the effort in half the amount of time when we're kicking off weekly we will still give the agencies two weeks to do the UAT and they will still be able to pick which timeframe they want but we won't have the luxury of a foreign after financial year and we are very much constrained by the end of life with UAT which we'll get the next slide for me so again I talked about this earlier it's very much a side ownership perspective those who are owners at one time or two already should already be familiar with it if they're not okay it appears we're running out of time the 7.4 update it where I'm coming screen at you in the nicest possible way again those side updates it's on them we're trying to keep them a little reformed about it help them help themselves we want them to connect with their security teams so they're doing the right thing if they're not on top of stuff they need potential resources or help and of course they need to get in touch with us if I'm not already mining them this slide is questions we won't ask questions if I run out of time I hope it was informative for you hopefully there's still some morning tea floating around please come and chat to us we have a booth we're around looking for the tall guard melting for the shorter one with the up-seam shirt thank you for your time everyone