 All right, okay All right Let's get started. So this panel is all about, you know, how virtual teams around the world collaborate and Contribute to an open stack or an open source ecosystem So we have an esteemed panel here. I'll shortly do an introduction, but before we do that, why are we here? And how many of you have actually been working with the open stack community? Okay, a lot of you are so you know what it is What it takes to contribute and work with the community? How many of you are remote or virtual? Yeah, about 50% of you and that's kind of the reality of you know, how things work in the community, right? So we have panel members today We're gonna talk about the challenges and how things work when you're dealing with people from different cultures from different countries The last statistic from open stack is we have more than what? 850 organizations 3,000 plus developers and contributors across 140 countries Speaking different languages in different time zones. How the heck do you get all this working together? That's what we're gonna talk about today and we have some great panel members who've had experience with this sort of thing For a long time. We have folks from Verizon from rack space From red hat and we'll do shortly an introduction just to give you logistics wise We'll do a little bit of an introduction first And then we'll go through some questions around our discussions and stories that these folks will share with you and We'll have about 10 minutes of Q&A towards the end. Okay with that Let me go ahead and let's start with introductions of the panel members You're starting with you Fred if you could do a very quick one minute no longer than a minute Who you are and you know, maybe a 30 second Elevator pitch of what you're gonna, you know, what challenges you see in this in this kind of an environment Okay. Yeah, my name is Fred Oliver. I work for Verizon. I'm located in Waltham, Massachusetts And I've been working on open stack for I think about three years at this point different implementations of stuff We're basically trying to transition Verizon from a kind of a legacy mode and to some more what dynamic New application styles development we have Development groups all over the world Probably our biggest one is in India right now from our remote location, but certainly we'll all scatter all around the the United States and I'm actually the only person that's involved them with my group. Everybody else is scattered around the United States. There are one biggest challenge you can point to before you hand over the mic. I Guess the biggest challenge is really just making sure that Kind of general communications and this is making sure that people are aware of what everybody else is doing there is Kind of we have a follow the Sun kind of methodology and Following that model requires big peaking and keeping people up to date. We don't want to wait 12 to 24 hours for the next communication metric part Karen Hi, I'm Karen Levenstein. I work at Rackspace. I am the US team lead for the Rackspace private cloud documentation team and our the documentation team is actually Spread across two continents half of us are based out of San Antonio and Austin the other half of us are based out in Australia and We support a dev team that covers the UK the US many parts of the US and also Australia so There's that and then I also am helping to coordinate work on the OpenStack installation guide and as the focus team on the guide We took a page basically from the networking guide team, which there's a presentation later this afternoon plug plug for one of my employees On a collaborative documentation, but anyway, that is what I do biggest challenge right time zones time zones and time zones and time zones Grant Shipley I work at Red Hat and I am a manager of OpenShift, right? So I'm responsible for You know the open-source project as well as you know managing and Maintaining integrations across different open-source projects like OpenStack. I've been remote for the last six years. I live about 10 minutes from the Red Hat headquarters, which is a skyscraper in downtown Raleigh, and I've been into the office about three times Everyone on my team is remote spread across the world and it was a big challenge You know initially doing that right and so a lot of insights there my biggest challenge is same time zones like Scheduling team meetings is impossibility sometimes Thank you My name is Beth Cohen and ironically Fred and I share an office Although not we didn't That's correct, right? That's a yeah So I also work for Verizon and I'm a product manager and I work with Nobody that's on my team is Located in Waltham. They're scattered all over the world We have people in Amia Latam Asia pack You know all over the United States Trying to schedule meetings when we cross six time zones is basically impossible And I also work with a lot of outside, so I do a lot of customer work And working with outside vendors. So, you know coordinating that stuff is near impossible I would say my biggest challenge is trust That the team will work together and produce something Terrific. Okay. My name is Kamesh. I'm Raju. I'm the moderator for the panel today. I work for Marantis I focus on partnerships within Marantis I've been involved with OpenStack. I guess ever since it started so I was with Dell prior to this and doing a lot of Contribution and on the marketing side on documentation Today at Marantis same way as the other panelists here. We have teams spread around the globe We have teams in Russia in Poland in the UK in France and you know all over the US Again same kind of challenges, you know, how do we work on that? So with that? Let's kind of get started with some interesting questions here. We talked about the challenges. So we'll start with you, Beth What would you consider is your most successful remote team? You know work or project you've been involved with and what made it successful? That's a good question. I don't even remember what I thought of So I'd say actually the the project that I'm working on now With secure cloud interconnect as a product that's on the product one of the product managers for it and Verizon is let's say it's a traditional telecom. So it's it's moving toward a mode of becoming more of a I wouldn't say startup because it's not a startup, but more agile And we were able to get this project out the door in about a year Which for by Verizon standards is amazingly fast And I think what really did it is very very good product project management. So we had a couple people who Really ran those meetings, you know drove to decisions You know road heard on the people to make sure that they were actually producing something And I think that applies to the oh actually I have another example Which is that I also was I was one of the people who wrote the open-stack design architecture design guide and That was a great experience and we were from every possible company Every possible, you know different languages, etc. And we came together and really was focused on the goal so one one question The biggest question is you know when when people get together Usually they are not people that have worked together in the past, right? I mean, these are not long-term colleagues that have been working together for a long time And when you had the successful, you know project that you're you're talking about where these people that are all new That came together for the first time and if so, how did that bonding occur and and what made it, you know Successful, that's a great question and in fact the the for the architecture book We had nobody had ever actually met in person. We were all coming from different companies We had never worked together as a team We will not again Unlikely although every time I meet any of them in the in the meet-up here I'm like oh long walks buddies, so I think I think the real key is is you really have to work on on bonding The team together, so there's there's some standard methods of you know, it's called Storming norm, you know form. I was it called forming Storming norming and performing and and I can't tell you that that really does work You really have to go through those stages and you have and you and and I think just Understanding that that is something that you need to do to get through to create a team is really important Just understanding that process So when you're busy yelling at each other because you know you didn't produce the thing that you promised You know Understand. Yeah, this too will will pass. Let's ask Grant because the interesting thing with Grant's work is he's not doing open Stack he's doing open shift, which is another open source project So interesting insights you want to share Grant when you have two different open source projects trying to collaborate with each other How does that work? It's It's basically the same, you know, I don't you know I think the key to being successful with any remote distributed team is even if people are in the office We treat everyone The same as a remote employee, right? And so even if there's a small cluster of people we never schedule conference rooms or anything like that Right. We have everyone use the same media all the time for communication Whether that's IRC or Google Hangouts or or Skype or whatever the case may be It's important that everyone working Uses the same media and so when we interact with other open source projects We use the the media communication vehicle that they use right and that's very key for us So You're you're working with the documentation right so how is I think you work with development teams as well Is that true? Yeah, our documentation team at Brackspace private cloud We work directly with the developers to build our so in your in your experience again successful project and how how is Documentation teams different from any other contribution like court contributions in your opinion I would argue that Documentation isn't that much different necessarily I think what the main the main success that we have as far as working with say development teams is ensuring that we have good ways of Asynchronous communication since not everybody can be there. Not everybody can be at every demo So some things that we've had real success with is For instance schedule recording demos So like video recording a demo if like the development team has some code They need to show off or a new feature that way the team on the other side of the planet can actually watch the demo as if they were there really being Really being committed to Arranging meeting times. I mean even though you can't have Even though eventually somebody is gonna be inconvenienced, you know Somebody's gonna have to put in a late night or somebody else is gonna have to put in an early morning You kind of have to accept that and just be committed to that to make sure that people get the face time and the talk Time that they need Really with documentation and in some ways There are certain ways that it lends itself to asynchronous development that like you can write the doc and then hand it off You know when you when you're going to bed for instance you you at the end or at the end of your day You're handing it off to the up to the other part of the team to continue to work on or to review And then when you come back the next day you can hand off it again But I don't know I don't necessarily see that as different from code. So what about language barriers? Documentation in particular is kind of interesting and I don't know if OpenStack has documentation different languages. Is that there is translation? I have not personally been involved in the translation effort. So I can't really speak to it But they I know that the documentation team for OpenStack has had to develop tools and tool chains to make sure that stuff gets translated And what about English barriers in other countries? How do you deal with that? Well, you know the one thing that we run into is that the Australians and the Americans spell things differently And you know sometimes and we you just kind of have to agree on what you're going to standardize on I mean we agree we Generally agree to standardize an American spelling which means that sometimes the Americans when we edit we have to take out some U's and change some SS disease But it's you just sort of have to find a standard and stick to it Okay, thanks. Let's get to Fred Same question successful projects and how do you specifically? I want to ask you more about cultural issues that you might have run into as you deal with global teams around the world Yeah, so I think there's been a I guess I think I think about the in detail the because our most successful project is we have a management addition we're adding to the OpenStack environment and from an orchestration perspective and Developing that in been interesting in the sense of Building up a new team and I think as you should describe it There's nobody really knows each other and what they're each other's capabilities are so there's a bit of a trust factor and we don't want to be in the mode of Kind of one person developing a you know a design specification handy it off. We were on a collaborative environment so there really is a At least I'm a mode of having to in some sense inconvenience everybody in scheduling meetings At offsetting times so that everybody has to be up at different times at some point But from a kind of a cultural perspective, I think they it kind of it what I've seen at least is Depend from some of the Indian Group we've been developing They're kind of a used to kind of Accepting a design document and then developing it from the design and not necessarily Questioning some of the design decisions that were made Where we want you know They're as intelligent as anybody else and have the experiences anybody else and we want to have feedback as to what we're doing so instilling the the ability for them to question what was proposed and Suggest alternatives is probably the thing we are trying to nurture more and and get them to do more in this project So that's a good segue. So I'm gonna throw this open to the panel anyone can answer this So typically if you're if you're dealing with these kinds of remote teams They are typically leaderless Right, there is no one single and tell me if I'm wrong But you're dealing with collaboration of teams and you know kind of designs emerge in some cases in some cases Somebody is driving the design So what's your opinion or recommendation? Do you recommend a? Single leader that kind of drives the whole agenda and kind of comes up with the blueprint and everybody follows Or do you recommend more of a hey? Let's collaborate and do things and kind of muddle through stuff Who wants to take that one? All these give an initial things. So I think there needs to be somebody with the kind of a vision of where this thing should go If you have a committee that's just completely open to making suggestions often doesn't reach a kind of a I guess a clear path very quickly And so I think there is you want somebody who can describe what The vision where they're going can also act as a moderator But I think the you know that person or kind of group small group people has to be wants to be very open and Solicit feedback for ideas and alternatives and work with that for a time I'd like to add to that so I'm I also teach at University of Phoenix, which is a completely online school and Every single one of the classes requires a group project and this is online So these people are all over the world etc. And it's all asynchronous So there's no they've never talked to each other And what I find is these are again leaderless teams and what I find is the most successful teams actually have Either somebody who naturally steps up or a wrote actually even better is a rotating leader So that everybody feels like that they can become a leader during during the pace of the course of the project So completely leaderless tends to kind of fall into you know sort of nothing Don't worry the the challenge with leaderless is it could just muddle through and nothing gets done in the end because everybody has Their agenda or things that they want to push So on that note, I think we should circle back to open stack because we've been talking in general terms So again, I'll throw this open to the to the panel. What is unique about? Open stack and and you've been working with open stack teams. I'm assuming how is that different from any other? Internal project you might be doing With distributed teams. What's your what are your thoughts on that? Who wants to take it? Well, I I'm not sure there's well I'll say there's a huge difference between when the way Verizon has done some things and in the path and past and how we're Kind of approaching the open stack environment in the sense. It's very in kind of legacy Verizon it's very much a waterfall model and you plan what you're gonna do a year from now and Six months from now you kind of re-establish that because you're not making any progress on that goal So I think the biggest change and that is to make a lot more short-term Milestones have Deliverables at those milestones that you can do that are short-term To a month or three months depending on what not kind of miles that you can do And then have kind of rapid turn as to what the requirements really are at that any one point and be able to adapt to the Change in circumstance over time. So I'll ask a grant You know because grant is doing open shift and you've been dealing with a couple of different open source teams one open shift and the other open stack What do you see different or unique or? Different about open stack as an open source community and open source project. Yeah, so I think All pure open-source projects are pretty similar, right? And the reason developers are attracted to them is because maybe they are not fortunate enough to be able to work on the open Stack or open shift during the day and so they you know love software development so they begin to do it in the evening and Regardless of the project that you decide you want to contribute to there's you know a couple of steps that you take One is establishing relationships and establishing your credibility, right to one day get commit access instead of just you know submitting You know pull requests or something like that and you know to come back to the leadership question I think in most open-source projects the leadership kind of for the most part except in very very large Open-source project works itself out through commit access, right? Once you gain the trust of the other developers on the project you're granted that role. What's different with? open-source projects with a lot of company interest behind it, which we see a lot is You know you may not be working on the Specific feature you want to you may be working on the feature that your boss is paying you to work on and so That's a little different as well. The political landscape in these you know huge open-source projects is vastly different as well in that you You know you're you're working with a lot of companies that may be your your enemy during the day But frenemy when you're working on open-stack, right? Because you're all trying to get the open-stack project to the to the next best state, right? And so you're working with with people that would love nothing more than to put your company out of business, right? But you're working on this feature together and collaborating and best of friends, right? And so it's really interesting I'd like to add to that that you do have to be very careful so the I'm I'm working on the on the telecom working committee and You know all of our rivals are on that committee and and so we have to be I mean I have to be careful about what I say and what I can't say and what I can share and what I can't share So and I'm sure that and I know that's true for all of these open-stack Projects and and as you mentioned, I I've also seen the Conflict between you know what what the company wants to put what the feature set that the company wants to promote and the feature Set that the community wants to promote is not always in in sync. So that's that's actually a big issue That that is a tension that that we in in private cloud deal with a lot it partly because for one thing Those of us who are writers on it I mean part of our job description is in fact you will work on private cloud docs and you'll work on open-stack docs You'll be a member of the open-stack community and also our Ansible deployment project which is now community began life as a rack space thing And so there's there's the tension between as you say like what the business wants you to do Versus what the what is what the community wants and I mean we really do have a foot in both camps I mean my my boss who is sitting over there. She she is also we are the open-stack docs PTL I mean that gives you an idea of just how much we you know, we walk the line there So it's it's it's always a juggling act. I find and you know And the good side of it though is that you always have something to do because when the internal project is maybe in a Slow planning period you can switch gears and work on open-stack for a while and it it keeps you know It keeps you fresh in both directions. I think I want to go back and touch on the leadership Question earlier. It's it's if you look at the open-stack community. It's not like there are no leaders There are PTLs for technical projects Over the last three or four years. There's been this whole question about where is open-stack heading? Right and and as a result of that and in the dynamics that some of the panel members have been talking about Which is companies trying to push their agendas, you know big companies having a cloud You know that we don't want that in the community, right? At the same time there was kind of no roadmap or no product management in the traditional sense that was going on in the community and now I think this summit. I believe right we started the product management enterprise committee, which is really all about You know determining what the future direction of open-stack is what are the features? We should prioritize on not what company X is or what what white company Y says, right? So that's so there is leadership. It's not like it's a little leader less community So with that, let's let's continue with a few other kind of tricky questions here So if not everybody is pulling their weight, right? So we're talking about a a community of folks that are working together There's some who want to really push their weight around some who don't contribute So how do you kind of deal with that kind of a dynamic? Let's start with Beth. You know if you could share some thoughts there. Yeah The so that's that's a huge issue So what I find with and this is applies to me, but applies to any and I think any team is that went first of all if you're not pulling your weight and you're just coasting through do not think that the other team members aren't aware of this and They will resent it very greatly and so my advice is You know if the if the team member is really not there cut them out, you know, that's that's their problem That's not your problem but sometimes it's a big problem because You know, they you know, they've committed to a key piece and they've let the team down and I find that When this happens, there's a huge sense of disappointment and resentment So, you know my advice is as a you know as a person who's joining a team Be sincere and you know commit to what you can commit to and deliver Because you will get a bad reputation in the community if you're not delivering Just to add to that. It's okay. If you you can't follow through mistakes happen Sometimes just let people know as soon as you know, right? That's the most important part in any project We expect failure and in fact, you know failures good the more you fail the better the next version is right? But just be honest and truthful about it and let people know Yeah, especially since you know OpenStack has a six month You know cycle of cadence if things don't come through then the project is not happening, right? I mean you you you get a half baked product. We've seen this happen with neutron How many of you use have been you know kind of following the neutron debacle over the last year? So it's going back and forth and I think finally in kilo it seems to have reached some level of maturity, but But it kind of yeah, it's arguable so I mean I think Neutron is a great example of where things can go off track and People kind of doing things on their own or pushing their own agendas and stuff But getting back to the point here, right? Let me kind of hear from other other panelists here People are not pulling their weight or not contributing Karen in documentation for example somebody supposed to do something they don't come through You know, it's a similar problem It's if you find that somebody has committed to you know work on a specific Chapter work on a specific document a specific feature or whatever and they they can't deliver You know as Beth says, I mean eventually you have to say look Fisher-cut bait here, you know and It's I mean really this is this is this also loops back to just communication really is you know Both whoever has taken the leadership role and also the people who are delivering have to set expectations It's one thing to say, you know to say yes, I will do the thing and then drop it without a word But it's another thing if you say yes, I will do the thing and then maybe a few weeks later You come back and go like okay. Look, I have gotten way overbooked here. I need to prioritize How can I reallocate this? I mean that's that's the kind of communication you want from people And if you don't get it you're they're not going to be a useful member of the team Interesting dynamic because you know in a traditional environment, it's your boss and doing a review of your performance It's not so in a community. You're kind of getting reviewed by everybody in the team, right? I mean if you don't pull your weight if you don't contribute if you don't do what you promise Then your karma points will catch up with you at some point and you'll be ejected like a virus, right? So I mean it kind of happens automatically, which is kind of interesting in one way Which also means that you have to be really honest about what you can and cannot do in a community Because word spreads very quickly and everybody says oh that guy don't deal with him anymore, right? Fred, what do you think? What have you seen in your experience again? I don't have much more to add to what the other people have said I think that's exactly right is that if Be honest about what you can contribute and if it changes over time that you can't contribute as much as you expected Just let people know and then it I think is very fair The community notices very quickly if you don't produce because you have a communications lines You know if they're open and everybody's communicating, but then there's also situations where somebody goes completely off track For whatever reason, you know, maybe they don't have the skills or you know, maybe they were told by their boss go do something else That that that does happen, right? so How do you deal with that? What are some examples that you guys might have seen? Can you point to some concrete examples from your experience of how you dealt with that? So I will tell the example. This was a team from hell It it started out as a five-person team and then three of them dropped and it's got down to two people and They were each calling me telling me that the other person was horrible And that they couldn't you know and and they had each one had like this totally different idea about what they wanted to do So in the end actually they handed in two pieces of work. I Would say that was the absolute nadir of teamwork It's hard I have four kids at home and Sometimes I look forward to going down to deal with them because their problems are more adult than some of the other problems You see in the community sometime and so, you know I think there's a lot of different personality types especially that's attracted to open-source projects and Honestly, it just takes time to get used to it and how to react to each one Specifically on a team because everyone's different right and it's a challenge. There's no magic bullet I mean shit happens no matter what what project you're on I will say in like a community-based open-source project If you're not pulling your way It may be a little bit longer than in a traditional office environment before someone notices But the reaction is typically much quicker and you can never repair the the trust issue that you've failed with Where's in a traditional office environment working on a product team? You know if you completely screw up chances are you're not going to get fired, right? It's not really the case in open-source projects Because so much relies on trust because you are distributed you don't you don't see them every day, right? And so people just expect you to deliver on on what you're committed to Okay, we're getting to Q&A time in a few minutes here But there's another question that comes to mind now We talk about communication keeping these lines open and having all these different media types where people want to communicate But some people by nature are not people that want to come out and talk or communicate in any any form, right? But they're great greatly skilled folks. They know they can do their job So the challenge here is these folks are somewhere remote on the other side of the world They don't want to get on you know Skype or whatever, you know Google hangouts and even if they do they'll probably say one word because of you know language barriers or what have you How do you how do you kind of call these folks out and keep the communication flowing? Have you encountered? People like that at least I have so I just want to hear your thoughts and on how how you have handled those those kinds of things Fred you want to take that you're saying I I'm not really sure you need to or want to call them out because they can produce some wonderful work but I think it requires you know At least some effort to try and get them to Minimal communication that might require some kind of a okay, just Write down a change log of what you did for the last week And then at least you could have go somebody else go back and look at what happened But I think it's if they are producing but not communicating It's kind of right on the edge as to whether it's useful or not But in certain circumstances it is still useful work. It's just have to somehow Convince them to do at least of a bit of communication right one other question So nowadays we have you know video that is so easy to get on to you know Whether it's Google hangouts or Skype or what have you has that made any difference in in in terms of better team work? Or do people use it? Well, I will say at Rackspace we have a video conferencing system that we use extensively and Honestly, I think it's made a huge difference especially because we are so distributed and I mean there's Our docs team every week we have a meeting that's last thing in the day for the US first thing in the day for Australia And that little half hour or so that we have to actually chat and see each other's faces is Really helpful. I mean it really it is a bonding moment if I can say that I mean and you know There's there's always like this sort of five-minute thing at the very end of the meeting after we've gotten through all the business Where everything kind of goes off the rails and we get silly and it's it's fun I mean and you need kind of that kind of interaction and like for our The development team for our private cloud they have regularly scheduled just video hangouts where it's like it's not a meeting It's just everybody plugs into their video client and they're all there on their headphones and whatnot And you can sort of sit and chat and it's like being in you know a room with a whole bunch of people You know you have casual conversations You can ask questions not just over IRC, but just like verbally and I think it makes a huge difference personally At least in my experience. It's been very beneficial. Yeah, what are the other other folks think here? There are some some folks who don't want to show their faces on video. Yeah, that's true So Ironically Verizon kind of flunks video We have we have a telepresence room which I have used and it's actually really wonderful But apparently it's like totally booked and I never see anybody in the room So mostly we use tele you know teleconference and I am and What I find is first of all people never Introduced themselves in the I am so you have to guess what they sound like And they're usually doing we're so we're talking, you know teleconference and frequently we do by consensus So there's like 15 or 20 people on these calls And probably half of them are busy doing something else And then and then there's these side conversations in I am going on so it can be very very confusing and And you know very challenging for people who you know can't multitask And and and this applies to the open stack the IRC's drive me totally bonkers. I actually have a hard time following them So I think um, you know, it wasn't that long ago Maybe a year ago I would come to a conference like this and meet someone introduced myself that introduced their selves turns out We've been working together on a daily basis, you know for years But we had never seen or known what each other look like And just recently we started using video conferencing for everything, right? And that has made a big difference. Sometimes we still chat on RC when we're on video conference. It's really weird It's it's a yeah, it's a steep learning curve But yeah, I would say it's harder for like if you're all at the same company employees at the same company is very easy But if you hop on a video conference with with a collaborator that works at a different company There's some challengers associated with that. And what are you going to use right? Is it Google Hangouts as a web? anybody from Microsoft But I would say it's made a huge difference, you know, come back to what she said it does make us feel You know more like a team because we're all remote We'll see something in the background of their office at home and we'll joke about it and laugh about it One time I showed up to a video conference last week wearing a full tuxedo, right? Just to just to be silly and stupid right and because we don't have this day-to-day Office face-to-face interaction we value those I think we need to get to questions here so one story I quickly want to share I have a colleague who works in North Carolina and Whenever I get on the video conference with him. He has his he has a cat sitting on his head Literally, I mean it's staring at me and I'm like I'm not looking at Nick anymore I'm looking at this cat is get that cat off of your head, right? I mean anyway, so we have a we have you know about three minutes five minutes Yeah, five minutes for questions. So if you could come up to the mic if you have any questions for the panelists That would be great. Thank you. Hi You touched on this at the beginning, but I would like you to go a little deeper if you can about the you know what happens when You're participating in a project the project is going in a certain direction But your company wants to have you push things in a certain way and then the dichotomy between having a project manager in the business world and The open source model where there is no one guy in charge of everything is really more Collaborative and we all decide together Can take that So I think a lot of it has to do with the company cultures that you're coming from too So as it so happens Verizon's a very collaborative culture So I think although we're kind of new to open source I'd say the the collaborative nature of the the way the company does business is actually very conducive to open source but that's not always true there's other companies that are very hierarchical and And that is it does become a clash definitely has been a problem I can I won't name names, but Definitely, yeah, okay one more question I wanted to ask about more like details how you organize the organize the communication during meetings because It looks like you sometimes need certain rules and do you have the onboarding process for this meeting? participants with specific set of rules you use into video conferencing or do you have a Moderator who tries to enforce these policies. How do you work with us? Always have an agenda always have a moderator It may not even be the same moderator every time But for the love of God have an agenda because there is nothing worse than a whole bunch of people getting on a video conference And all just kind of staring at each other or everybody just talking in no particular direction And there has to be a moderator because somebody has to keep things amen amen to that That's that's I think with this one takeaway from this whole discussion today have an agenda have a moderator That's the only way these things can work. We have to stop here Unfortunately, you can certainly talk to the panelists after we have about ten minute break now So thank you so much for the model for the panelists for joining us today, and thank you all for joining