 I'm Ben Cotton, I'm the Fedora Program Manager at Red Hat. I'm here to talk about managing changes in open source projects. So real quick, my Twitter handle if you want to say nice things, if you have not nice things to say, keep them to yourself. So what we're going to talk about here, I'm going to set some context for why I'm giving this talk and why you're ostensibly in the room. Then we're going to talk about what you want to consider as you're building up how you handle changes in your project. And then lastly I'll go through some time on Fedora's change process because it's a pretty good example of how a really big project handles changes fairly well. Some people may disagree with that, but that's what the Q&A is for at the end. So setting the context. So what is a change? So I realized after I wrote the description, I was putting this together, I was like, oh, change is kind of an overloaded term. So here we're very specifically talking about making technical changes to the features or the processes of the project. That might include having some organizational change and things like that, but that's really outside the scope of what I'm talking about today. But it's a really interesting subject and it was my favorite class in graduate school, so if you want to talk to me more about it later, I have opinions. So why do we want to have a change process to begin with, right? It's really all about communication. So you want people in your project to know what others are doing. You want them to get feedback on what they're doing. And then you want more communication. You want, for example, people to pick up on, you know, oh, this project is making a change, this change, let's write an article about it so people outside of your project see it. That's simple. So what do we want to consider when we're putting it together? This is the harder part, right? So first of all, as with any process, the process that you use in your project varies by the size of your project. And here when I say size, I'm really what I'm talking about is the number of contributors. So you want to make the weight of your process proportional to the size of your project. If it's a one-person project, you really don't need a whole lot of process. If it's a hundreds of people project, you have to have a little bit of bureaucracy in there. It's not fun, but that's how things work. And the reason we want to do this is because the number of communication channels you have is exponentially related to the number of people. So if it's just me, there's no communication channel because I'm not talking to myself. If it's me and one other person, we talk to each other. That's one. If I had another person, now each of us talks individually. That's two. And it goes up very quickly. So as an example, I'm going to talk about a command line, Perl Twitter client that I'm effectively maintained by myself. I'm the only contributor for all practical purposes. So I just kind of commit whatever. I go through the issues on GitHub and I say, this seems like a bug I could fix. I'll do that. Or I want to add this feature. Okay. Yeah, why not? Ooh, that's harder than I thought it would be. Never mind. I'll put it off till later. Sometimes I make branches in Git and then merge things in when I'm done. Sometimes I forget. Nobody cares because it's just me and I tag a release every once in a while. And then I'm like, oh, people are actually still using this. Wow. On the other end of the spectrum, we have a project like Fedora, where we have 200 plus people a week making contributions to Fedora itself. And that's not even the full scale because that's really what we're measuring there like package builds or changes to spec files or other generally sort of technical input. And that doesn't include the upstreams. You know, there are however many packages in Fedora that all have an upstream that could be, you know, the same person who's maintaining at Fedora is the only person working upstream or it could be something like the Linux kernel, which has a huge upstream. And all of these people feed into the process. So we have to have a defined process that has like rules and like decision making and stuff like that because it's big and it has to be coordinated. So you are somewhere in the middle probably. Fedora is a very large project. It's going to be the high end of the process. Mine is basically none. And this is a very scientific, you know, three minutes to make kind of chart. But you're somewhere in the middle. You figure out for yourself. So one of the things we want to talk about is who needs to review changes. And this isn't necessarily the decision process. So if you were in Rebecca's talk right before mine, she made the distinction of who gets a voice and who gets a vote. And this is really who gets a voice. Now there's some validation that might need to go into the change. And think of this as a linting process. So do you have a release engineering team who needs to say, yes, this change will allow us to continue producing our release. Or, oh, this change is going to break our release process. So we should probably accommodate that before we try and put the release out. Are there legal implications? Do you have a bringing in a new upstream package that has different license that needs to be reviewed? Are there changes to trademarks? Things like that. You might need some sort of sign off. Do you have somebody wrangling the changes? Do you have somebody who's sort of guiding each change through the process? Do they need to say, oh, yeah, you filled out all the forms. This is right. Or, wow, you completely forgot this very important step. Let's go back and do that before we move along. And then do you have the community weigh in? For the most part, I'm not here to offer you opinions. I'm sort of saying here's the framework you want to build. I will have a few opinions in a couple of ways, and you're always free to disagree because the process you come up with for your project needs to fit your project. So who approves the changes? Who has the vote? Somebody does. There, that's the answer. Somebody does it. Do you put it to a community vote? Does everybody who is a contributor or some other way that you define the boundaries of your community, do they get to give it a plus one or a minus one, and then you tally it up at the end and see where it goes? Do you have a technical steering body? You have some smaller group of people that says, we're going to evaluate these technical changes and make the decision. Do you have an individual leader? So, for example, in the kernel, you might have, Linus is the ultimate authority, and then he's sort of delegated to people different subsystems, and so within each smaller part of your project, do you have a person who is sort of the owner of that and they make the decision? Opinion time. Democracy is really messy. If you've paid attention to various elections in various parts of the world over the last few years, people make decisions, sometimes they're well-informed, sometimes they're not, sometimes they make a decision, and they go, whoa, this is what we did? Oops, and, you know, they're like, oh, well, how do we fix this now? In my opinion, the best way to do this for a project of any size more than a few people is to have some sort of elected technical body that approves the changes. In Fedora, that's the Fedora Engineering Steering Committee, or FESCO, that's a nine-person, completely elected by the community board. They rotate out every two releases, so it's always fresh. That's a smaller team that's sort of a representative democracy, let's say. And so with this model, you have a small group of people who can act fairly quickly, because you don't have to sit there and wait for 100 or 200 or 500 people to weigh in. Hopefully the people that get elected are well-represent the project in both the values and their knowledge of it. And if the community doesn't like the changes they make, they vote them out. So it's a nice balance between having the community involvement but also having some of that swiftness of speed, and you don't necessarily have all of the mob rule that can happen sometimes. Okay, so you need to think about how changes are enforced. Dirty little program management secret, you can't make people follow the process. You just break the process sometimes. In corporate environments, sometimes you can go to their manager and their manager can say, no, bad, and then they'll do it again because they want to keep getting paid. In community projects, you have volunteers and what are you going to do? They're going to either go away, which could be bad, or they're just going to keep not doing it. So you need to have a way to sort of have some sort of enforcement mechanism that works for your community. When I say enforce, what I mean is like, what happens if you have conflicting changes? So Alice and Bob both have changes. Turns out they break each other. Somebody has to mediate that. Do you reject them both? Do you pick whoever went first? Do you have them work it out in such a way that they become mutually agreeable? Sometimes you have incomplete changes. Somebody might say, yes, I'm going to do this thing and it gets approved and everyone's happy and then it's about time to do the release and they're like, oh, I'm not quite done with the thing yet. Somebody has to say, all right, well, you're close enough. We'll let you hurry up, but come on, hurry. Or, no, this is not going to happen. You're in the next release or just, you know, it's not going to happen. And then there are surprise changes. Somebody didn't follow the process and oh, we're getting ready to do the QA right before the release and oh, look, this thing is broken and it impacts any other things, oops. Does that change get pulled out? Do people just deal with it and try and get it fixed? How do you handle that? And again, the answer to how you handle all of this is very much a decision that you make for your community, for your project, based on the values of that project. But you have to think about this. If you think of it as a programming example, you don't just have your code do stuff and hope it works, right? There's no exception handling. So, you know, all this other stuff is the try, this is the accept. You need to think about how you wrangle the changes. The change process itself is an area of expertise that, you know, just like writing code is an area of expertise or designing artwork is an area of expertise. There's different things that have to happen because you have this process as you move things along the way and it's really helpful to have somebody who does that all the time. In Fedora, that's my job. I, you know, the people come up with the changes and then I help them through the process because, you know, if somebody is submitting a change once every couple of years, they're not going to remember the process. They're going to spend a lot of time going and looking up, how do I do this again? They might do it wrong and confuse people. It's easier if there's somebody to guide it. So, you might in your project that does that or you might have a couple of people or, you know, some small team that does that because, you know, if it's an all-volunteer, you can't count on people being available. But it's good to have this. And then, of course, like, you need some kind of tooling, right? Because you can't remember everything that's happening. You don't know the state of everything off the top of your head. You might use a Wiki page. That's what we're using for Fedora right now. You might use an issue tracker. You might use a fan board. You might use any number of things that you're tracking where changes are in the process so people can see what's going on. So, I'm going to talk about Fedora's process. And I'm going to start with some history. And I see Yaroslav is in the room, so he might jump up and correct me on this. But we had this process called the Features Process prior to Fedora 20. And it was really predicated on the idea of, is this a feature or is it an enhancement? And very broadly speaking, an enhancement was, let's do something we're already doing better. And a feature is, let's do this new thing. But it turns out people didn't like the Features Process very much. So, I'm relatively new in this role, but I was in the Fedora community for a long time as a volunteer before that. So I was kind of familiar with it. I was like, I want to look, I want to see what, you know, remind myself because I don't think I ever actually submitted any features. So I found from a long time Fedora contributor comment on a blog post that somebody else had written. And this is not a kind way to describe a process. And basically the gist of it is, try and avoid calling whatever you're doing a feature because it just adds a lot of pain that you don't want to deal with. It's a good sign that your process isn't really working. And so Fesco was looking at the process and they said, all right, well there's some issues with it. One, feature is a very ambiguous term and there were kind of two things that were happening. One is that, like that comment I just showed, people are like, I'm just not going to call this a feature because I don't want to deal with it. And so you lost all the benefit of the process. All of a sudden you didn't have that, you know, visibility and the tracking so people knew what was going on. Or the other end was people were like, well I'm not really sure if this is or not so I'm going to go ahead and do it anyway which added a lot of extra administrative overhead for things that really didn't need, excuse me, to go through that process. And like the Wiki page that people filled out had some duplicated requests for information which is like that's easy to fix but it's kind of annoying. But the process didn't account for different types or scopes of features. So, you know, adding a new shell that is basically it's a leaf package that people might be interested in and want to know about but it's not going to break everything is much different than, I don't know, switching to system D. That's a big change. You don't want to treat them the same because they're a very different scale of impact. This process didn't really care one way or another. And features weren't always visible to the community until after they were the proposed and approved which meant if somebody had an idea of like, oh, this is going to break me? Well, it's already been approved, now what? Now do we go back and have this fight? You lost, you didn't have the ability to get the early feedback. So in Fedora 20, we switched to the changes process which I'm sure makes Yaroslav feel very good about himself. I read a lot of your pager history in putting this together. So thank you for documenting that so well. So in reality, the changes process isn't that much different from the features process. It looks a lot of, pretty much the same in a lot of ways but it's better. One of the main distinctions we make is that we have system-wide changes and self-contained changes. So a system-wide change is like I'm changing a default on a big thing. It's going to impact everyone or a large chunk of people. Self-contained changes are more of a, hey, I'm doing this just to make sure it shouldn't really hurt anyone but I want you to know. And it's also important to note that changes aren't necessarily things that we ship, right? So a change could be we're changing the default flags for the C compiler in the build system or it could be some other sort of meta work on how we actually produce the bits that we ship. They're still very important to communicate that out to the community because if people's builds fail they would like to have known that it was coming, for example. So system-wide changes and self-contained changes are fairly similar but we have a little bit more for the system-wide changes because of their bigger impact. So those are required to have a contingency plan, a test plan, it lists the impact on the other developers and the impact on upgrades. So if a user is going from Fedora 28 to Fedora 29 will your change break them in some way? Will it do something that's incompatible where they can't revert back to a previous version or something like that? These are all things that are very important to know about and none of them, you know, it's not a, you can't do this because it has an impact but we need to know about it and plan for it and other people in the community need to be prepared. So the general flow, and I was gonna actually like make this into a diagram but it's still pretty big, this is two slides and we can animate it, but the point is there's a flow you go through and it starts out with the change owner drafting a proposal in the Wiki. They fill out this template that says, I'm doing this and that and here are the things that you asked for. All the changes need to have a check with the release engineering to make sure hey, we're not gonna accidentally break our release process by doing this, right? And I kinda go back and forth in my opinion on whether that's valuable because every time I've looked, release engineering has said no, we're good. So it is a little extra work for the change owner, it's a little extra work for release engineering but it's also mitigating a pretty big risk. So that's something to think about. If there's a trademark approval, the person goes to the Fedora council and says, hey, can I do this? It's usually like involving a new addition or something that you wanna call Fedora goat remix or something. If it involves changes to the packages, they go to the packaging committee, different other policies that may be involved, you do that. And then when they're all set, they mark the Wiki pages ready, they go into a category. I go in every day and click refresh and see if there's new pages in the category. If there are, I post them out to the community via email and I also include them in weekly blog posts I put out on Fridays that just sort of runs down all the stuff that's happened from a program management perspective. So there's really no excuse for not knowing that it happened because theoretically you're subscribed to the very important email list after a week. People have talked about it. They argue, they debate. It's kind of applying the open decision framework where we say this is our process. So once again, I thank Rebecca for tying that in so well to my talk. I take the change proposal as it stands and say, Fesco, here you go. What do you think? Fesco votes on the change. Their process is they have up to a week to vote and if it gets the desired number of votes after a week, then it's approved or they can say, let's go back to the person and ask them more questions first. But there's a defined process where things don't languish. If it gets approved, which they almost always do, it's either yes or yes if. So here's some feedback. Please make this change. The person gets a badge. Everyone likes the badges. To get that reward. And then the person goes and implements the change. Hooray. But then at the beta freeze, we look and see which changes are actually done. And then if there are ones that aren't yet finished, we look at their contingency plans and Fesco decides, all right, do we give you a little extra time to work on this? Do we grant you a freeze exception? Or do we say no? Sorry. Try again in the next release. Not too often. Usually people are done enough or they're so far from being done. Sorry, the question was how often is something rolled back? Usually either they're close enough that we just hurry up and get it done or it's so far from being done that nothing's really in yet. And so it's not really rolled back so much as just, yeah, I'll come back to it later. It's not too often that it lands in the middle. Can you be a little more specific? Okay, so the question is, this is a huge project. How do you structure it in terms of doing development and QA and all those things? So Fedora is a quick aside. We have different teams. So we have a QA team. Some Red Hat employees, some volunteers, they sort of lead the QA in testing process. Most of the development happens upstream. And so people, either their Fedora contributors working upstream and they do it there and they pull it in or they're just maintaining a package that an upstream provides and they build it for Fedora. So it's very disjoint. So there's people doing various activities at various times. Sometimes it's part of their day job, sometimes not. And that's part of the reason why we have a process like this is because it provides some of the communication and visibility for people who... Okay, real quick. The question is, how do you attract contributors? I think there's a talk later, either earlier today or later today. Okay, so I'll just give a very quick answer that is an anecdote for me. I started contributing to Fedora because I had been using it as my desktop and laptop OS. And I was like, man, I'm getting all this stuff for free. I feel like I should do something. So I started contributing to the documentation team and eventually started adding more and more and after nine years got hired by Red Hat. So... It's going to vary for each person but I'd say that's something where Fedora actually does need to do some improvement is going out and actively recruiting people because it's usually... the community decides they want to get involved. So real quick, look at the timeline because you want to have deadlines for when things happen. Basically, everything is kind of pinned off of the beta freeze. So we freeze the code and then it's like, alright, this is generated to release the beta. So code complete, testable code complete, which is like not quite all done but done enough that we can start testing it. We have a mass rebuild that usually happens and we have a deadline that's several weeks prior because we want the change to get announced fairly early. In fact, sometimes people submit changes for example, we had some Fedora 30 changes submitted before Fedora 29 was even released because they wanted to get it in as early as possible. So a quick example of... I guess I'll have a little more time than I thought but a quick example of using this process successfully happened actually it's still sort of in the works but Matthew Miller, the Fedora project leader wanted to improve the way we count the install base. We don't really have a good sense for how many machines are running Fedora. The way we do it right now is basically the number of IP addresses that hit the mirror manager and it turns out the DHCP and NAT are both things that exist in this world. So you don't know if that one IP is 100 machines or if that 100 IP is one machine and so really the numbers we get are just kind of like... So his idea was to say, all right, well let's have DNF insert a UUID that gets generated into the URL it uses to do repo queries and then we can just say, all right, well this is the number of different UUIDs that get generated. Theoretically there will be no collisions and so we have a really good count of the individual machines. He wrote that up before doing any of the work, submitted it, the community looked at that and said, no. So OpenSusa actually basically does exactly what we proposed but a lot of people in our community were kind of concerned that if you had the UUIDs and you got the logs from the mirror manager, you could potentially tie it back together and be like, oh, this is Bob. That's not a great thing. Some people raise concerns like, will this be GDPR compliant? There's a lot of arguing by people who aren't lawyers and so I just kind of ignored that part. But after a little bit of discussion and debate and some coverage in pharaonics where people were just flipping out about the same stuff, the community said, actually, you know what we could do instead is just have a bit that gets set in the oral. It says, count me. And once it sends that, it won't do it again for a week. So we have a little broader aggregate but we still get the same count but it's very much more anonymized. And so Matthew said, yeah, that'll work because I'm not going to anger half my community by doing this. And so he revised the plan and the process. That's a good example. We had feedback and it fixed things. And then sometimes, you remember I said people don't always follow the process and a key system package that I'm not going to name because I'm not here to shame them made some major unannounced changes and then, oh, that brought up a lot of blocker bugs that we didn't necessarily notice right away. Is that a QA failure in a sense? Yeah, probably. So when you get closer to the release, we're like, oh, this isn't working. And so they submitted some fixes but also had some new features and, oh, well, here's some more things that are problems. And there were some packages that were dependent on that package. And so at the end, it was sort of a hero effort from QA and the dependent package developers to try and get everything working so we could ship something approaching on time. What can you do? We sent them an email saying, guys, we're working hard, but it's really good that you at least just let us know that these changes are coming because that way people can be prepared when you have a change in your API. So the future of our process, it's evolving. In Fedora 30, we did add a new deadline for changes that require infrastructure changes and that's a really poorly worded thing. I couldn't think of a better way to call it but basically the change I'm submitting requires the infrastructure team to do something different than they're doing now. And we added this because the infrastructure team said, hey, we're really tired of getting all these things that need to be implemented in the next week because nobody told us about them ahead of time. So now, if you require an infrastructure change, you have to make sure you're in a lot earlier so you have time to plan that out. One of the things I'm working on right now is moving away from using wiki pages for tracking to pag your issues. It turns out that wikis are a great way to write free form text collaboratively. They're really bad if you want to like parse them and do things programmatically. If you don't want Ben to have to copy and paste things out of the wiki page into the email and hope he did it right, which is like a 75% success rate. And some of the things we have, we have some scripts that pull down the pages, scrape information out of them, create bugzilla issues out of them, then generate another wiki page that lists all the changes in their current status. Okay, so I wrote a make file around them that makes it a little simpler now, so that's nice. It's still kind of an ugly process. What if we just had like a cron job that could just pull the API and do half of that stuff automatically and just update the change page every day? So I have I put a proposal out to the community a couple of months ago and 31 hopefully will actually implement that and this is honestly mostly to make my life easier so I can spend time working on other things in the community. So to summarize all the things I've been saying and I think some slides disappeared or something, I don't know. So why have a process? Communication, communication, communication. You want communication of just status, hey, here's what I'm doing. You want the feedback communication of what you're doing is going to break this thing. Let's do it a different way. And you want the communication of somebody noticing hey, this project is implementing this new feature. I'm going to write about it and give them a little publicity. So to design your process think about the values and the work of your project because it's going to vary even if you have the same people from project to project, it could be a little different. But you want to take your deadlines and fit them into whatever sort of schedule you have assuming you're doing a schedule based release cycle. If you're sort of doing, yeah, we'll release whenever we feel like it's ready. I got nothing for you there, sorry. But you want to decide who reviews and approves the changes. Who gets a voice, who gets a vote. You want to decide what information you need. You want to decide who and how the changes will be wrangled. You want to write it all down and I can't stress this enough and this is something the Fedora Council is actively working on to try and make sure we're doing a better job of documenting some of our policies and procedures because even if you have a change wrangler the person who's submitting the change needs to know well enough to how to fill out the form or whatever you're doing. So you want it all to be very visible to your community. You don't want them to have to spend time figuring out the process. You want them to do the process. And of course, like anything else, you want to iterate on it because the first time you come up with a change process it will probably be terrible and you'll find all kinds of things you didn't anticipate and it turns out your community will hate it and you'll take all of that feedback and you'll make it better the next time and eventually you'll have something that works pretty well. So this slide should have been duplicated earlier but it's here now and that's the important thing. Here's sort of my suggestion for what you want to include when somebody's submitting a change. You want to name in a summary how do we refer to this change and what does it do at a very high level? I think it's important to include the benefit to the project especially if it's something that's kind of contentious or that could be argued about a lot. You want to make it clear I'm submitting this change because I think it will make the project better by doing blah. And that could be easier for the contributors to do things maybe it reduces some manual steps they have to do it could be better for the user community it could be better for whoever but somehow it should have some benefit if there's no benefit to the project then I question why you're doing it in the first place. You want to define the scope what does the change include and not include you want to know who owns it so even if it's a large team the Python sig actually I have no idea how large they are but it's a special interest group it could be tens or dozens or a hundred people but there should still be one person or maybe two people who are the owner of that change so that when somebody has a question they go to that person and they have the answer and they're the person who can speak on behalf of the rest of the people working on it. You generally want to have a test plan and I know we all whenever we're writing code we're always writing tests we never write anything without having a test so you want to include that you want to have dependencies and impacts and that kind of goes along with scope like who's going to be affected if I make this change other people have to change the work they do maybe it's changing something and how they build their packages for example and you want a contingency plan you at least think about what happens when this change goes horribly wrong and how do we get it back out it could be as simple as we just use the previous build instead or we just don't merge the change until it's really really ready but there has to be some way to handle it and just as a reminder as you're designing this the process is here to serve the community the community is not here to serve the process that's the only way you're going to have a successful change process or really any other process in an open source project is people have to see that there's value to it even if it's kind of a pain to go through a little bit they have to understand yes this is annoying but it's less annoying than not having it oh this is a PDF form so this is from Jeb Bush saying please clap so at that point questions and answer time we have any questions in the room you're going to let me off that easy we talked about both changes like technical changes and changes to process and have there been a lot of proposals for the way we're doing things I guess the did you submit a change proposal today as a clarification did I submit a change proposal for the way we're doing change proposals no I did not that is a change in the process and arguably it could go through that I did go through a a version of that process by coming up with a plan having a couple people sort of lint it and then sending it out to the community incorporating some feedback arguably it could go through the change process I guess it's one of the things you want to consider is sort of where's the boundary of changes to process going through the change process for us it's generally if it's not actually involving how things are built in some fashion it's sort of an exception is that the right way to do it maybe or maybe not that's a sort of the way we're doing it right now so to get to your first question I would say most of the change proposals tend to be I'm doing this thing that's going to change what we're shipping so it's a new version of GNOME or I'm adding this new package or doing something and then a smaller percentage are things of we're changing the compiler flags or some other sort of build system changes that aren't actually directly they might actually they affect the ones and zeros that go out but they aren't really affecting what we build so much as how we build it so the question is how I would in a hypothetical universe where I have supreme executive power drive from a woman throwing a sword at me how I would handle that the Fedora 29 release process are you talking specifically about the example I mentioned yeah so using the example I mentioned where somebody went through the change process and didn't I'm kind of petty and vindictive sometimes so I would have, I think my default instinct would have been like look you should have told people we should have known this was coming you didn't so it's not going in so in reality like Rebecca said if you want to avoid the circular debates don't work with humans if you want to avoid politics don't work with humans there's some political considerations just in terms of keeping people engaged in contributing in the future so you kind of have to balance the do you offend this entire group of people who did this work that I mean it turned out to be good work is just you know mistimed and not well communicated or do you offend the people who had to sit there and deal with the breakage and how do you balance that the reality is we delayed the release from our target GA date to our target number one GA date so it wasn't late we just switched to a different target partly for that there are other blocker bugs too so it's one of those things where this wasn't the only consideration and there were some discontent in the community that we didn't accept as blockers some things that maybe should have been maybe we should have delayed the release yet another week that I can only say that's a community driven process and it was open to a vote and that's how we people voted it's it's messy and you can never draw sharp lines as much as as nice it would be and I don't know if that really answers your question because I went on for a while but is that okay cool you're happy how many well that's a really good question it's good thing my manager is not here to ask me that the question is how many changes get wrangled through in a release so I'll quickly add a little bit of ignorance this is really my first full release where I've been on the job but I want to say 30 ish a release sounds about right as an average there are probably more that should go in that don't I would say there are probably 40 or 50 things one of the things that we try to do with the changes process is on the one hand we want to not send a whole lot of email to people and you know bother them but it is a communication mechanism and it's part of how we build our release notes which then is part of how we build the talking points for marketing and for the ambassadors to talk about what's cool in this new release of fedora and so from that extent really the more changes we have in there the better because that gives us more of a story to tell so even if people don't think that this is really justifies it we kind of want them to any last questions ok well thanks everyone for coming and thank you for your attention