 Ladies and gentlemen, please welcome Chair of OpenStack Technical Committee, OpenStack Foundation, Thierry Carras. Hello, everyone. So I've been handling coordination and release management for the OpenStack project for the past three years, and I'm an editing member of the technical committee, and I would like to have this panel so that you can meet the members of the technical committee. The technical committee is in charge of the technical direction of the project, and so please welcome on stage the members of the technical committee. Maybe. It doesn't work. So that's 12, right? No, 11 members plus me. Great. Use the mic, dude. Why, Thierry, we're missing two members. Two members. Okay, so could you start by introducing yourself, everyone? I have to introduce everyone? No, you have to introduce yourself, and then pass the mic. Excellent. So my name is Monty Taylor. I'm from the TC. Gosh, I don't know what else to say in this context. I used to run some various projects in OpenStack, but I don't actually do that anymore, so now I'm just sort of dead weight. But I'm also on the board, which makes me even more dead weight, I guess. This is going to go bad really quickly, and I guess I've been requested to introduce the two missing members, Lifeless and Vish. They're not here. I'm James Blair. I work for the OpenStack Foundation, which is... I'm quite proud of that. I mean, I don't know what your feelings are on this subject, but I'm very happy about it. But anyway, I work for the OpenStack Foundation, which is actually largely incidental to what I'm about to say next. I'm the technical lead for the infrastructure team for the OpenStack project. So I'm part of the team that... Well, Monty said it this morning in his keynote, because he's part of the team too. So anyway, I've been working on the project for a couple years now, and I've always had a project-wide view and scope to my work, which is why I decided to run for the TC recently. Hi, I'm Michael Still. I work for Rackspace in Australia. I'm a Nova and Oslo core reviewer. I've been on the TC for about six months now. This is my second term. I think that's all you really need to know for now. I got two mics at once. Thanks, guys. Hi, I'm Anjan. I coordinate the documentation for OpenStack, and I work at Rackspace, completely all docs all the time. And I just got elected to a one-year position on the technical committee. So I love users. That's kind of my role here. And I guess I get to be the token woman too, right? So happy to be here. I'm Sean Degg. I work at IBM. I'm also the OpenStack QA program project lead. And you'll see me a lot also in the DevStack communities and doing some Nova things from time to time. And I just got elected for a one-year term, new to the group. Hi, I'm Barker McLaughlin, and I work for Red Hat. I work on the Nova and Oslo projects. Kind of like Jim, I try to have a cross-project focus as well. Yeah, that's me. I'm also on the board of directors with Monty. My name is Russell Bryant. I'm the PTL for the OpenStack Compute Project, or Nova. It's my third term on the TC. Since I work on Nova, I'm very interested in cross-project issues since Nova interacts with so many other projects. But even beyond Nova and the existing projects, I'm also very interested in the future of OpenStack and the growth that we've seen and that we're going to see in the near future. And my name is John Griffith. I am the PTL for the Block Storage Project, Cinder. I work for a company called SolidFire. My main focus is, of course, Cinder. And I try and also do quite a bit of work with drivers and vendors and stuff like that and helping them out. My name is Mark McClain. I work for Dream Hosts, and I'm the technical lead for the in-app working project, Neutron. My name is Doug Hellman. I'm the PTL for the Oslo project, and I was on the team that created the Solometer project as well. And I work at Dream Hosts as well. So I was mentioned before. My name is Thierry Carras, and I'm handling the release management for the project. And this should be a very open session, so we will have mics in the audience and you will be able to ask questions to the members of the technical committee during this session. There is some history behind the technical committee. It's one of the three bodies we have for our project governance. There is the board of directors. And there is the technical committee, which is elected by the contributors of the project to set the technical direction for the project. We are in charge of all the technical issues, all the technical decisions that have to be made at the top level of OpenStack. And it used to be the project policy board, which was the first instance we had. And one of the things we changed is when the foundation was established, we set up the technical committee as one of the pillars of our governance. And it's elected members representing the contributors of the project that are forming the technical committee. How would you describe the role of the technical committee? Anyone can take the question. It's inspiring. I'll give it a shot then. I really like your description of the technical committee being one of the pillars of our governance. People, when they look at OpenStack's governance, they look immediately to the board of directors as being, I guess, the top-level governance structure, our top-level body within our governance. But in fact, I think most of us see it as kind of peers in our governance structure. So the technical committee is really responsible for the technical governance of the project, so what new projects will be included in the releases, any cross-project policy issues we need to resolve. And we're really trying to work with the board of directors when that's needed. Yeah, I think actually the... When I tell people who don't really know a lot about OpenStack, oh, I'm on the board of directors and I'm on the technical committee, it makes it sound like it's a committee of the board of directors, which it's just really not. It's not that this is sort of a subcommittee or something like that. It's its own thing. And in that way, I think what Mark said is right on that a lot of what we're here for is sort of cross-project policy, in terms of a technical thing, which is the project policy board possibly a slightly better name indicating what the group of people does, although it's sort of a weird acronym and nobody really... I don't know. Saying I'm on the PPB didn't really sound all that great, especially when Terry said it. It's worth noting that even in the OpenStack Foundation bylaws, the technical committee is... it's established there and it's actually given... its remit is in the bylaws and it's actually given very clear, very wide-ranging authority over technical matters for the project. So when we started the project, we made it very clear that this is going to be a technical meritocracy. We want people who are actively participating in the project to be able to have a huge voice in the direction of the project. And so the technical committee is a continuation of that idea. And I think it's extremely important that an open-source project would get a control by its contributors rather than by people coming from elsewhere because there is always the risk that the contributors will take the project somewhere else if they are not happy with the governance of the project. And that's one of the major drivers behind the evolution we had with the representation of those contributors is to make sure that the contributors of a single project make the decisions on one project and then we are here to solve the rest of the technical issues like cost-project issues, inclusion of new project within the scope of what we concentrate on and focus on. And so it's really important that the technical committee is the elected meritocracy of the project and that's separate from the corporate influence or the sponsoring of the foundation itself. So we went through a number of changes during the Havana cycle, an important set of changes to the technical committee over the Havana cycle. One of them was to have this notion of integrated projects that is separate from the core projects. The board defines what the core projects are and which projects are allowed to use the open-stack trademarks because that's one of the board of directors' duties to protect the trademark. But the body of contributors is actually investing in new directions and what ended up being interesting is to separate the concepts of the project that the community works on from the project that the board thinks must be the open-stack trademark so we introduced the concept of integrated projects which is just the set of projects that we actually release altogether every six months. But then it was not enough and we introduced the concept of programs which is everything that's important for the project and that the contributors work on and that we want to recognize as part of the open-stack from a contributor's perspective. So we introduced the concept of programs so we have a QA program, we have a documentation program where the leaders are well represented here and infrastructure development infrastructure release management those are tasks that are essential to the success of the open-stack projects in general and we wanted to recognize that through the programs. And the last change we went through was changing the election model so we had the PTLs for the main projects had a reserved seat at the technical committee that did not scale so well especially with the new programs approach so we have like 20 programs so if we have like 20 members plus directly elected members that would like raise the numbers to very high so we made the decision to have all the members of the technical committee directly elected and that's the first fully directly elected set of members. How would you... What was your feedback on those changes? Were there good ideas? Anything we need to change during the ice-house cycle? I'm pleased with the result. What do you say? I'm pleased with the result. So I like the directly elected models to be honest especially as someone who isn't a PTL PTL is already a big ask for a lot of people right it's a lot of work especially for the bigger projects some of those PTLs don't necessarily want to spend a lot of time on technical governments outside their project as well so the assumption that they would want to was I thought a little bit weird so I prefer this model to be honest and you know if you're the PTL of a big project and you're interested you're probably going to get elected anyway so I think it's a move in the right direction. Let me add something a little less self-serving I'm even excluding myself I'm very happy with this group of people that's up here I think we've actually got a great representation from people who have a long history of caring about the project as a whole and I'm quite certain that all of these people will be deeply involved and useful and productive in the technical committee which I think is exactly the sort of thing that we were going for as a community when we decided to make that change. Yeah I was just going to say I think that the new model and the election model actually worked out really well and I have to kind of disagree with the comment about if a PTL wanted to be TC he would be most likely elected I think that what we actually ended up with was a really good diversity across the entire OpenStack community of some of the most active contributors and members not only in terms of code contributions but in terms of reviews, evangelism help with infrastructure everything across the board I think it really worked out extremely well And I think that the addition of a program lead really helped as far as documentation is concerned we had just a really big growth period in the Havana release we were able to release at the same time as code we haven't done that before I do feel like a mission statement kind of gels people together helps people understand we're all in this together so I really think the program technical lead was a huge help I'd like to see translation as the next program so hint hint yeah so that's all I was going to say I think the addition of a program technical lead really helped raise up the layers that cross projects Yeah I totally agree I think the big thing about programs the big change that programs has been about is recognizing that actually the most important thing is the groups of people working on the project so it's not just about specific code repositories it's about the groups of people and what they're collaborating on together and what their kind of common mission is so yeah we really love the programs concept and it was Monty's idea I had a good idea that's exciting we should take note of that more often I'm actually really pleased with how that worked out and I hadn't really thought about it in this particular context until Terry's introduction when we put it sort of opposite the board and the board's stuff and all the core and what's core and what's integrated and everything that the programs really wind up describing the set of things that are part of the technical project as part of a program you're part of who we are as a technical community and what we're doing in general is talking about being about the definition of the product output of the project and I think that's a really important I think it's a really important distinction that we've been able to capture without getting too without getting too legalistic about it which I think is pretty exciting so yeah I've that and like to echo everybody else I think we've got a great board of people and one thing also that I noticed so we have a whole bunch of like a whole bunch of arguments around the board of directors about company affiliation and you know we want to make sure that the big companies don't squash the little companies or whatever and we have no more than two representatives of any external company on the TC and A it doesn't matter because I don't think any of us are representing a particular company in our views here but at the same time it's really interesting to see that that sort of naturally we kind of have this spread across small companies and big companies and the foundation and representatives sort of across that board and I think that that we didn't have to dictate that that should happen it just kind of did which is great and the real sign that that has happened is when Monty said there's no more than two I think all of us looked up and down and tried to count quickly what our affiliations are and we don't think about each other's affiliations we really are here because we care about the OpenStack project and our affiliation is very much secondary so it's really great and like Jim said the group we have is really caring about the project first and not really pushing any personal agenda we probably agree on most things now and those are very well known and consensual candidates for the TC and from one personal note as a contributor to a recently integrated project I'm glad that the size constraint of the technical committee didn't lead to that not happening so changing the formulation of the technical committee allows the whole community to grow and bring in additional projects in the scope of the project yeah and I think just adding to that one of the things that becomes important as OpenStack grows the number of integrated projects which is going to happen over time is that having a viewpoint that's the collection of the whole strongly represented within the TC because you can sort of manage the complexity ad hoc when we were at five or seven projects but as we get up there seeing across the whole is actually really important I also think that the move to Directly Elected means that everybody here the active choice that it's a duty that they wanted to this duty is a duty they want to take on which I think potentially at least in my brain means that we can ask more of this set of people than potentially in the past you know when we look at things like you know projects up for there are more things we do other than just accept projects or not in theory but in looking at that thinking about the amount of technical sort of oversight or sort of us looking at architecture of things that are coming in and actually like actually digging in a little bit like hey so that's an interesting choice you made there why are you make is that really a thing that we want as a project and I think that that up until now there's been a little bit of like there's like thinking like oh gosh does the TC really have time well we all chose this so like I think that the idea of oh well that's too much to ask that we dig that far in is I don't think we can hide behind that at all at this point so it is the technical committee yeah it kind of is I think that's a really interesting idea too so Monty what do you think about providing more mentoring to recently incubated projects at the moment we say yeah you've met the bar come back in six months and we'll tell you if we like you or not maybe we should be more active at saying hey you know and we'll be involved in helping you get there I honestly think that's a I don't exactly know what how that works but I totally think because we get to things where I remember in the in the in the trove graduation discussion we're like oh hey and you didn't do this and and last night was like oh but you completely didn't ask me to do that and and we're like you're right we actually did not act like that's I get your point of view and that should be we should we should be asking things we should be looking into those things that level of the they'll before before it's up for graduation review there should be there should be some sort of wow that's a that's interesting the way you're doing that let's talk let's let's see what what a plan can be there and I think actually I really like this idea of mentoring other projects and I think and I think we should even be looking at trying to do some of that even before a project is incubated and sort of trying to approach that that graduation plan I think some of that has to happen even sooner so I think as a group we should all be looking out for projects as they're starting to pop up and they're like in their infancy because you know the earlier we can kind of redirect them the the cheaper that that redirection is as opposed to after they've done nine months of development or something so that's something that I try to do you know I look out for some of the projects and like one of the last few weeks that I that I'm personally starting to spend some time on is the solemn project so that one came up and I you know I have some interest in that so I'm trying to pay some close attention and and look at the decisions they're making early and I think I think we should all be doing that and looking out for projects that kind of strike structure interest that we can help mentor as early as possible yeah especially because kind of the point of OpenStack is a consistency of approach right so as people who've been there and done that a little bit you know we have some skills that we could help people with but that's a good segue to my next set of questions you mentioned the Doug mentioned that accepting new programs is part of our for our job and I mentioned that the this is mostly consensual and and probably agrees on most matter but I know that there are a few points where we actually differ opinions and one of them is the expansion of scope of OpenStack so could you could you give us a quick overview of your position in how many more project we need to we need to consider how what's the condition for them to be to be considered how do you regard the latest bunch of incubation requests that we recently received is it like too early is it too fast is it like should we just do infrastructure as a service pieces should we do like look at the state of the project rather than what the scope of the project actually is okay maybe I'll go first since I spent half an hour up here this morning talking about but you know my point of view is pretty simple it's we built this great place to collaborate it's a really natural place for people to come together and start working on problems outside of core infrastructure problems we need to make sure we encourage that we appreciate that collaboration so new projects come along under OpenStack and we encourage that but we also need to make sure we're not losing focus and I don't think we are losing focus on our core infrastructure but we need to keep reassuring people of that and keep reassuring people that as we add new projects we're actually doing this in a very careful, deliberate and measured way I think one of the things that people are they continue okay it's partially our fault because we do consider this one project it's OpenStack as a thing we are one thing except that when we get these new projects we also tend to get new developers that are working on them it's not like a new project means less developers working on them absolutely I can assure you that Nova is not suffering from a lack of people contributing to it despite the massive growth that we've seen in the community overall just as an example with the exception of so one thing I'd like to point out is Monty did actually a lot of really good work early on to help shepherd the Stackforge idea into production and so there is a place in our infrastructure in our community for new projects to sort of incubate to participate in this whole process without having to be part of the one OpenStack project and I think that's really great I think one of the things as a TC we need to do is to be very careful and very deliberate about how we grow the one OpenStack project I personally see no artificial bounds around that I my own personal opinion is I'm not interested in drawing a line at infrastructure as a service or anything else as a service or whatever I think we're actually doing a really good job of as Mark indicated this morning making that expansion in a sensible way but I think one of the things that that I intend to do on the TC is as a member of one of the cross project teams and I won't speak to any of the others but there are some others here is to help make sure that new projects don't put a drain on these cross project resources which doesn't necessarily mean saying no to new projects but this gets back to the idea of shepherding projects through the process and mentoring them and things like that so as we expand OpenStack and as we get new developers to projects in general we need to make sure that we get new resources to these cross project efforts as well. Yeah that's really interesting I think that's an even bigger view of a problem that we even face inside of individual projects as well sometimes where we have people from companies that have an interest in maybe some subset of the project a vendor for perhaps their hardware maybe but we have to have people investing in the common parts of the project and the core parts of it but I think that applies I think you made a really good point that that applies across all of OpenStack and the common stuff so I think we should do a better job of encouraging more of that contributing to this common I also think it's important that we encourage new projects to engage early we've had a couple of bad experiences in the past where things have popped up fully formed and they don't mesh well and there's a lot of technical debt and I'd much rather be talking to them earlier so that we end up with something that the whole community is happy with and the other thing is the bar for incubation is in my mind reasonably low we have integration later where we can say yes and this is now a thing incubation is giving people a chance to become a thing providing assistance and mentoring and stuff like that along the way I don't think that projects have to integrate it within six months or within a single release they can take longer than that if they need to and if some projects never make it then that's not terrible in my mind we've learned something interesting along the way I agree my position is we should raise the bar of what it takes to get integrated because we should learn from our past mistakes things we accepted that we're not like tested as much as we wanted and we should consider it normal if a project spends more than one cycle in incubation it's really a learning process and we we have two points of control we can trigger interest in that project basically saying everyone this is a project that's worth looking into it enters incubation and then there is a set of challenges that this project has to raise as to tackle before we would consider it integrated and it should not be seen as a failure for the project if it takes more than one cycle for them to reach I don't really expect Savannah to meet all the challenges that they will have to be fully integrated with OpenStack in six months because that would be like crazy activity to just meet everything we require from them they are crazy Russians though they are crazy so that point about engaging early is really good don't assume just because you have an idea that no one else is thinking about that problem maybe in a different way or maybe they would want to help you out so if you have some new project that you want to start up bring it up before you really get going maybe you'll find some contributors on the list you know one point to that I think is important to point out as well is there's a lot of people have thrown out words like control and let in and stuff like that but from my viewpoint I like to view the TC is more of some place to go for help when you want to start a new project especially as time has gone by even though we've started adding more projects it's becoming more common it's actually making it even more difficult because there's so many moving parts so to be able to have somebody to go to and get help in terms of what actually already exists what might be overlapping with what you're trying to do things like that I think it's really important involving the TC from that perspective you know I think is really really important I'm going to totally attempt to speak for lifeless who isn't sitting here but that's what you get for not coming you know when he first joined Opensack I remember having a conversation with him about code reviews and he was a little bit frustrated that he's like code reviews are great except that what they're not is they're not design reviews like they're not architectural design oversight in any way shape or form and that's a little bit tricky because we're so massive there's so many people there's so many moving parts to try and get like an overall sort of what's going on where should I sit and we've seen this just right now with Trove and Savannah and the conversation between Trove and Savannah I want to say there's like a fourth one that we really want to say hey you guys should sit down and maybe not duplicate stuff that seems like it's meshing in there and that's a place where I'm hoping that maybe we as a group can again start to help you know as John says help guide and shepherd some of those things and I don't know that we necessarily want to get all the way into the business of being an architectural design review committee but like but to point at things and to know what's going on so we can say hey you may not realize that you could that you know like it out Trove is using heat internally now we're supposed to to be spending up these resources so maybe you should too and maybe y'all should collaborate on what it means for an opensack service to use heat to get the resources it needs I don't know but like at least talk about it absolutely and what you said they're pointed things actually resonates a lot for so we're talking a lot here about adding new projects right but there are existing projects and we've got this across amongst us we've got this cross project scope right we can kind of see what's happening across the project and we can actually point at things in existing projects and go hey you guys in your silos and these different projects need to really talk to each other and really need to figure things out and come to some consensus on something so like a really simple example which Michael pointed out the other day is some projects use a library called SQL Alchemy Migrate for database migrations and other projects use a library called Alembic and this is something that just it doesn't help the project when we have this kind of divergence and the TC can really you know it really should take on the role now of identifying those kind of issues and not take on the role of trying to force an answer on people but get people to come together and discuss things and come to some some form of consensus and project can be completely successful outside of our group I mean if they apply for incubation it's because they want to be integrated with the other projects so they should be wanting to include new I mean adopt all the technologies we've been using for the other project and it's time for us to take questions from the crowd otherwise they will not have the opportunity to ask questions and it's like a unique opportunity it's really really difficult to have all those people at the same place at the same time and it's like a danger for the project because never knows could happen so if you want to ask questions to the technical committee now is your chance it's not completely technical but you're kind of representative of your communities we are in China there is no on the podium what can you do to actually try to improve the situation so I think that as far as improving the situation as you put it I think what it actually is it comes down to who's actually contributed and who wants the job so if it just so happens that there isn't somebody from the region that you're interested in that isn't on the technical committee it's most likely because there isn't somebody from the region that wants to be on the technical committee I think that's really what it comes down to that's the nice thing about an open election across the board for the entire committee it has nothing to do with regions or affiliations or anything else it's all based on the community it's a community vote you've also got to be in it to win it there was some data released earlier this week that said Beijing is the top contributor city now at this point I think it was Beijing but nobody from there ran so we should certainly be encouraging people we think are strong technical contributors to grow in the project and run but that takes time and I think a lot of these people are relatively new to the project so we'll get there my perspective on this and it's interesting Daniel is the guy who asked this question we used to work together on the GNOME project and we faced this issue there too we've got to face the fact that this is an English speaking project it is very difficult to contribute to the project we have a similar shared culture in terms of our understanding of our meritocracy being able to step forward and stage your opinions loudly and demand people listen to you that's not a culture shared by everyone we've seen this in open source projects before we like to talk about in my keynote this morning I had a bullet point but diversity I had to talk about our diversity of interests we don't have a massive amount of diversity for example Ann is the only woman up here and I think it's a goal that we should all in the project not just on the TC but we should all encourage it's not easy though but it's really recognizing where contributors are maybe not naturally going to grow and to be the leaders that could be and mentoring them and just being understanding of people who might face difficulties that not all of us face we also have we only have four people not from the US time zones on the thing we've got a person from Australia a person from New Zealand who was in here an Irishman and a French person and I don't know where he is but we also have a very American centric our meetings are pretty focused on American time zones and I think this is a thing that we should probably honestly attack a little bit stronger because we do have a whole bunch of folks in Beijing we're getting more and more in Australia in India we've got a bunch of folks in it's not just cultural I see your point with the cultural and the fact that we're placing meetings at the long times it's also that every region goes through a cycle where they first contribute tactical features things that are of interest for themselves and then that population matures and starts contributing strategic contributions and that's what gets you here that's when you care about the project you prove to care about the project then you get here so I think we will see more diversity coming when those people will start moving from that mindset where they are fixing their problems to the mindset where they are fixing everyone's problem and I think we'll take another question I just wanted to back up a tiny bit to something Mark said certainly we assume English in this project and I think as a project we can get better at not doing that so for example if we get a commit message from someone who's not a native English speaker as a project should get better at not nitpicking their English grammar and not helping them instead or maybe we can't expect English language documentation from a non-native speaker so we should accept it in their native language and run it through the translation cycle that sort of thing but we're already talking about that stuff so we're trying to improve so maybe next question you want to comment another question anyone so I have a question from users perspective so for enterprises who want to utilize OpenStack but do not want to have major updates every six months just like Ubuntu Jenkins so that's probably for me so we do releases every six months but it's actually not releases it's like we cut branches every six months where we backport a number of fixes and distributions can take that and package it and support it forever I mean if you want OpenStack LTS you can go with Ubuntu LTS and you would get the distribution supported version that will work for a given period of time on the other hand we have work on continuous delivery of OpenStack and I think that's where the future lies because upgrades will always be painful and the framework will always be evolving so those people should ask themselves at some point is am I making the right choice by sticking to an ancient version and should I not contemplate using continuous delivery to actually solve that so my answer would be your preferred distribution might just address that LTS need for you there are several number of distributions that have like a long term focus I mean I totally agree on the perspective that we want to get to a future where users can find it easy to kind of track to use continuous deployment to deploy OpenStack but just one thing you didn't point out there is we do actually maintain stable branches we do have a team that actually maintains a stable branch for six months after the release so it's not quite the length the life cycle of an LTS but that six months period is really just decided upon based on the interests of the stable branch maintainers so we're totally open to the possibilities of people who are interested in maintaining a stable branch for longer than six months to join the project and take on that role for themselves so like everything in OpenStack there really is scope for people to come in and just help make it happen I think also we get feedback from got feedback at least from one person over and over again on our mailing list that we should learn more from some of the other projects and not think that we're completely special and a new thing and I disagree with them most of the time because I like to think that we're special to no flake but we look at where Linus has gone with the kernel and Linus basically said I'm done, I'm not doing real releases anymore that's the distro's jobs we're going to work on the kernel we're going to release it when we release it and we're going to release it all the time we're going to release it when it's ready and we're going to do that and I think we're probably not quite to the level of maturity of the Linux kernel just yet but we're getting there and I think that's a place that I would like to see us be at so that we're not necessarily having to do extra things to enable the distros to do the thing that they do and then we're sort of letting that separation exist at the level that it needs to exist and our policy is actually modeled on the kernel one because we have like those releases and we do stable back ports and point releases only on the preview stable version which is what the kernel does and I actually think that's why the triple O story is such an important part of this because as a project our development effort is going into the master branch and so for us to have a good story about how to actually run that as a project is a great thing but even on the release side I mean not so much as an LTS perspective but the reason people want to hang on old stable code is that upgrades are painful and that is definitely in scope of they shouldn't be this should be something that we're really addressing the fact that upgrades are painless that you can move forward very efficiently and not hit issues along the way and that is has always been a place where we want to get as a project we're getting better at it but that's definitely another approach so we run out of time I hope this panel give you a good insight of how we actually do things within the technical committee which is very discussion based and so please engage with separate members if you're interested in further discussing with technical committee members and thank you everyone for coming and thank you for listening to us and bearing with us and my bad English thanks