 Então, boa tarde. Eu vou apresentar aqui como é a vida de um OpenStack fora da Cerno. Primeiro, eu gostaria de introduzir quem somos. Eu sou o Henrique, eu sou o Raíudo. Estamos bothos da Universidade Federal de Campina Grande, no Brasil, onde estamos trabalhando com OpenStack por 2,5 anos, e estamos bothos, neste momento, engenheiros de software. Então, eu gostaria de te destacar o que você expecta de ver no talk. Primeiro, vamos contar uma história sobre os primeiros OpenStack contributores de upstream na América do Sul. Essa é a nossa equipe. E depois, vamos tentar mostrar como você pode evitar our mistakes no início e speed up a nossa contribuição e a adaptação na comunidade. E depois, nós finalizamos de mostrar como você pode ser um melhor membro da comunidade, como você pode contribuir para OpenStack de um melhor maneira. Então, eu vou te emphasize aqui. Você não vai ver neste talk nada relacionado com o coding, e nós não tentamos mostrar para vocês como se tornar um membro da comunidade, porque isso é muito fácil, você só precisa fazer as melhores reviews, as melhores patches. Então, é muito fácil para você conseguir um review de cores. E depois, nós gostaríamos de definir o que nós consideramos, não o kernel. Então, como você pode ver aqui, desta data, da última investigação, nós temos cerca de 46% de delays de não trabalhar na América do Sul. E você pode ver 24% na Europa e outro 24% na Aérea. E nós consideramos que o não kernel é exatamente o complemento de isso, que é esta parte aqui. E nós também consideramos a área como não kernel, por causa de alguns factores econômicos, como você pode saber. Então, justificando aqui, é onde estamos, estamos vivendo Campina Grande, que é a Universidade Federal de Campina Grande. Então, a Norte do Brasil. E depois, eu gostaria de contar esta história sobre o LSD, que... oh, desculpe, isso não é o LSD que eu queria. E o LSD está para Laboratórios Temos Distribuídos, em Português, que é o LSD Distribuído Systems Lab, em inglês. Então, uma breve história aqui sobre o LSD. Em 1996, alguns professores começaram a estudar, distribuídos de sistemas. Eles têm um pequeno rumo com alguns computadores. E depois, em 2000, nós tínhamos um grande rumo com mais professores, mais engenheiros e mais computadores. Então, nós evoluímos isso. E depois, em 2004, nós construímos nossa própria construção, onde agora nós hostamos cerca de 60 membros, que incluem professores, desenvolvedores, estudantes, e nós estudamos muito sobre distribuídos de sistemas como um todo. E, apenas falando de como começamos a trabalhar com o OpenStack aqui, nós começamos em 2013, onde nós tínhamos uma forte front na computação de cloud. Então, nós decidimos ter um novo projecto de R&D para trabalhar com o OpenStack. E neste momento, nós temos mais que 10 contribuídos activos de OpenStack, que funcionam daily, a maioria deles é full-time, um bit of them, part-time. E nós temos, no nosso labo, mais de 30 membros que usam o OpenStack daily, sendo para o desenvolvimento, para a equipe de CZ, e para a equipe de Dev, e finalmente, há também um CI, os usuários do OpenStack aqui. E, neste dia de horas, nós começamos novamente, com simples problemas, criando DevStack, desde agora, um ponto em que nós temos 3 cloud de produção de OpenStack, que servem todos, um grande número de labs na nossa universidade. E neste ano, nós até este ano, nós estávamos convidados a usar o SuperUser Award, como você pode ter visto no Keynote, este dia. Então, isso sempre começou no cycle de release de Isohouse, onde você vai explicar agora, como foi o começo da nossa jornada. Obrigado, Henrique. Então, nosso projeto começou no meio do release de Isohouse, e todos os usuários da equipe nunca tinham trabalhado com OpenStack antes. Então, nós tentamos entender o que é OpenStack. E, para entender isso, nós tentamos entender os principais, e os principais componentes da OpenStack, e nós usamos o DevStack para isso. Então, nós usamos DevStack para pegar os usuários básicos no Horizon, no CLI Clients e no API. E, depois disso, nós notamos que o DevStack não é suficiente quando você precisa de um deploy mais complexo. Então, nós deployamos na Avanah Cloud, na nossa universidade. E, outra coisa que nós notamos no início, é como interagir com a comunidade, e como ser Linnis. Linnis, desculpe, Liss Tannin. Então, quando nós começamos as contribuições, nós temos muitas perguntas e dúvidas, e você está esperando as respostas para essas perguntas. Então, você precisa entender. Você precisa usar os principais termos de OpenStack relacionados com o OpenStack. Por exemplo, se você está indo para a comunidade de Keystone para perguntar algo, você precisa usar o projeto, o grupo de usuários, os termos de OpenStack relacionados a esses serviços. Se você está indo para Nova, você tem que aprender o OpenStack, os termos novos para as coisas dentro de Nova. Isso vai fazer que a gente consiga as respostas que você está esperando. E nós temos alguns problemas sobre esse primeiro release. Primeiro de tudo, nós tínhamos alguns patchs mesmos, fazendo algumas das operas, tipo, nós não falamos os estilos de codos em Python, nós nos enviamos patchs com bad comment measures, então essas coisas fazemos que os patchs estivessem mesmos. E outra coisa foi, nós tentamos entender, nós notamos que o grande peixe no OpenStack é muito grande. Então, é difícil, quando começamos a contribuir no OpenStack, entender sobre Nova, Keystone, Neutron, Glass. É um monte de coisas. E no nosso caso, nós vimos que temos um efeito de documentações portuguesas sobre OpenStack. E nós vimos que você pode ter o mesmo problema em todos os países que estão fora do kernel. Se você está em Inglaterra, em China, provavelmente você vai ter esse problema. E no nosso caso, nós não tínhamos reputação na comunidade. Nós estamos só começando. E as algumas contribuições que nós sentimos, são muito difíceis para ter esses patchs mesmos e ter algo dentro da comunidade do OpenStack. Então, o que nós aprendemos? Nós aprendemos que você precisa perguntar sobre outra coisa na comunidade. Então, você tem os channels da RSC, você tem o menu list, você tem o Ask.OpenStack. Então, provavelmente alguém tem o mesmo problema que nós temos agora. E você pode encontrar essa resposta, ou você pode encontrar alguém na comunidade que vai ajudar você. Mas você precisa ser proactivo. Você precisa ir à comunidade e perguntar para os caras. Há muita gente lá que vai ajudar você. E se você é mais devestado, um ponto de contribuição boa é se fixar em boas bugs. É um tipo de bug que todo projeto tem uma lista de bugs que são simples bugs que você fixa em 1 ou 2 horas. E você aprende o processo de funcionamento para fazer essa contribuição, a real contribuição dentro do OpenStack. E outra coisa é o sumido. Esse é o principal evento relacionado com o OpenStack. Então, nós pensamos que aprendemos mais sobre o sumido. Um dos membros do nosso time foi apresentado na samba de Hong Kong, a samba do Ice House. E nós tentamos fazer uma conferência com ele para ter mais informação para entender mais sobre o sumido. Mas nós só tentamos. Porque nós não podíamos entender e não vimos como é um evento. Então, nós precisamos irmos para o sumido. E na reação de Jona, foi o nosso primeiro evento quando nós ficamos em samba. Eu e outro engenheiro aqui viermos para Atlanta e nós percebemos como é grande o OpenStack. Nós vimos isso. E outra coisa é que é muito importante fazer a rede social. A rede social é muito útil no OpenStack. Você precisa gostar desse evento para encontrar os carares que você sabe que estão relacionados com os features que você está interessando ou os carares que estão mais experimentados com algo. Então, no nosso caso, nós fomos interessados em multitenácia. E nós usamos esse network para ter um caso de implementação que foi o Haricomutenácia em Keystone. Então, nós voltamos para o Brasil e poderíamos explicar melhor para a nossa equipe o que foi o OpenStack e nós tivemos esse novo feature para implementar. Então, quando voltamos para o Brasil, o primeiro desafio que nós tínhamos foi discutir esse feature de Keystone nas reuniões da equipe. Alguns membros da equipe, como eu, não tinham a fluência do inglês. Então, nós tivemos tantos problemas relacionados com as perguntas e recebemos as respostas que estamos esperando. Nós tivemos tantos problemas durante esse processo de reunião. Então, isso é um problema quando você está fora da equipe e nós estamos escrevendo um speck complexo. Então, nosso primeiro trabalho foi um speck complexo que fez isso mais difícil. E nós não tínhamos influência para ter esse feature aprovado. Então, neste momento, nós aprovamos nosso código e nosso estilo, mas nós sentimos mais de 100 setes, que criamos um delay no nosso plano. E esse feature que nós implementamos, que foi fechado pelo Feature Freeze, desde que nós perdemos um par de discussões de mid-cycle. Então, agora esse feature nós não poderíamos marcar esse feature no Juno, e foi disposto de 2kg. Então, o que nós aprendemos no Juno Release? Nós aprendemos que precisamos preparar nossas discussões para esses 10 anos. Quando você tem algo para discutir, escreva em avanço, pelo menos os primeiros centros que você começar as discussões, faça discussões internas com sua equipe para falar sobre as mudanças, ou se essa reunião é de esta forma, o que você faz, ou se a discussão é de outra forma, o que você faz. Mas você precisa, mais do que isso, você precisa unify em sua equipe, em seu Feature. E, depois disso, você pode perguntar para as revisões para esses meninos. E, provavelmente, ele vai revisar o seu patch, o seu spec. Mas outra coisa é, nós aprendemos que é muito importante ter os patches de data-on-guerrit. Então, quando algum membro revive seu patch, faça rápido e responda os comentários e envia um novo patch set. Faça que os patches faça data-on-guerrit. E, agora, nós vemos, finalmente, que nós só temos, nós só perguntamos para Feature Free's Excepção, se não há muito tempo para fazer. Nós perguntamos, nós temos um lote de coisas para fazer, e isso é um problema, porque Feature Free's Excepção vai ser apenas alguns dias para terminar o seu Feature. E você tem que ver se alguém da comunidade, alguma equipe, interessa este Feature. E, finalmente, no Releas Killer, nós percebemos que nós somos mais expertos e, agora, nós temos passado o processo de romp-up no OpenStack e nós temos o sentimento que podemos contribuir mais com o OpenStack. Então, nós começamos a trabalhar novos serviços no futuro e o primeiro problema que temos é a mudança do time zone. Nós tivemos uma reunião com as pessoas da América, da Europa, na Índia, e é quase impossível ter o time zone perfeito para todos. Então, alguns cara, provavelmente os cara que foi fora do cerno, nós recebemos essas reuniões na noite. Neste caso, os cara na Índia recebem reuniões como 3h00 a.m. e, cada semana, ele recebe essas reuniões. De outro jeito, na Keystone, nós recebemos o primeiro feature que foi o Tenacity e nós tivemos a sensação de que agora nós temos as reuniões para nós e recebemos muitos complementos e nós tivemos a sensação de que nós estamos procurando tudo que nos enviamos agora e nós somos os melhores cara na comunidade. Como vocês podem ver aqui, o nosso feature foi o número 1 na Keystone, um novo feature para a Keystone. Então, nós tivemos essa sensação e os próximos passos para o Harkomotennis, que foi implementado na resselha. A resselha foi uma extensão de esse primeiro feature que nós fizemos e esse feature foi aprovido para o Kilo e nós implementamos em Kilo, sim, mas não foi mudado e o problema que nós vimos foi uma boa discursão sobre o processo de spec. O feature foi muito grande e era imutável. Quando nós começamos a fazer a implementação, você estava procurando um lote de bugs e nós vimos que nós não discutimos esses bugs sobre o processo de spec. Então, é um problema você precisa ter certeza que o processo de spec, a documentação e o design são muito importantes no OpenStack. Então, você precisa ter certeza sobre isso. Então, o que nós aprendemos? Nós aprendemos que no time zone shift, podemos fazer algo como a nova equipe está fazendo que alterna as reuniões weekly. Por exemplo, a nova equipe fez algumas reuniões na semana em 2h00 e em outra semana, eles fizeram as reuniões em 9h00. Então, todos os serviços estão fazendo o que está acontecendo com esses serviços. E você precisa ser mais prático. Nós notamos que é muito importante aparecer na comunidade. Então, você precisa ser visto por membros da comunidade. Quando você está fora do coronel, isso é mais difícil de fazer. Então, nós decidimos que precisamos focar nos resultados. Você precisa cometer mais, você precisa fazer mais code review, você precisa participar mais da discussão do OpenStack. Então, isso é muito importante. Você precisa ser prático. E sobre o reseller, nós notamos que você precisa planinar, você precisa pensar, discutir e designer mais. Você precisa designer melhor. Você precisa ser precisado do que você está dizendo. Essa parte é muito importante do processo. Há muitas pessoas na comunidade que só querem ter o SPEC aprovido as vezes possível para desenvolver o futuro porque a companhia quer isso no reelejo. E isso não é o trabalho do OpenStack. O OpenStack, você precisa ser precisado. Você precisa designer melhor. E agora, Henrique, vamos falar sobre o Summits. Então, como Hélio disse, no Reelejo Quilo, nós discutimos mais detalhes sobre nossos futuros apanheiros. Nós temos mais nosso primeiro feature e nós também temos este Summits, que é o que eu gostaria de falar sobre agora. Em Paris, nós tínhamos quatro membros da nossa equipe, mais ou menos as vezes que tínhamos em Juno, o Summits de Juno. E o que eu gostaria de destacar aqui é que este foi o nosso primeiro Summits usando o programa de apanheiros do OpenStack. O programa de apanheiros de apanheiros é um programa que te ajuda a chegar para o Summits. Então, em todo o Reelejo há dois ou três meses antes, eles transmitem a forma que você aplica o programa de apanheiros de apanheiros. E aí, o Programa de apanheiros de apanheiros vai evaluar se você é um dos melhores candidatos para fazer isso para o Summits. Então, o programa de apanheiros de apanheiros de apanheiros tem sido extremamente importante para a nossa gestão, na nossa jornada de apanheiros de apanheiros de apanheiros de apanheiros. E isso já foi ganhado mais de 10 suportes para membros do nosso projeto. Então, a maioria das features que estamos desenvolvendo aqui acontece porque o funcional de apanheiros de apanheiros é muito expensivo para nós. Por exemplo, um membro de apanheiros de apanheiros de apanheiros é sobre como um estudante de apanheiros de apanheiros por todo o ano. Então, isso não é tão fácil para nós no Brasil. E eu gostaria de dizer que, há um mês, você pode aplicar, sentir a forma e dizer por que você acha que você precisa ir para o Summits. Há alguns tips sobre como você se acertar para o Summits que, primeiro de tudo, você precisa ser claro sobre o que você realmente intenta fazer em um Summits e coisas que você pode fazer melhor em uma pessoa que o que você vai fazer com a comunicação usual, por exemplo, como eu disse, a social network em as faces, é muito importante e você pode ter coisas feitas muito mais rápido do que discutir com o mailing list e no IRC. E outra coisa que você precisa ser muito específico é sobre as suas contribuições. Então, você pode dizer frases boas frases como, eu tenho implementado um novo blu-print que faz algo, eu tenho implementado outro peixe crítico que fixa um bug crítico. Então, é muito específico sobre como você contribui para o OpenStack. Não diga frases como, por exemplo, eu gostaria de saber o horizonte. Eu gostaria de saber a glença e não diga, por exemplo, que eu gostaria de conhecer o Leonel Messi ou o Neymar. Então, essas frases não são boas que você pode dizer ser muito específico sobre as suas contribuições no OpenStack. E outra coisa muito importante é que você pode mostrar como importante você estar localmente em nossa comunidade. Eu vejo aqui alguns membros da comunidade do OpenStack Brasil que é o que você nega a parte de nós. Então, por exemplo, nós temos as frases da comunidade do OpenStack Brasil onde nós falamos da identidade sobre monitorar o OpenStack. Então, se você tem feito algo importante na sua comunidade local, apenas diga que é muito importante que o Programa de Trabalhoso quer saber o que você está fazendo no seu país localmente. E, finalmente, ser muito específico e mostrar o valor da comunidade do OpenStack e se concentrar no que você pode achar, como esse sumido pode melhorar o sumido com sua presença, apenas diga o porquê o sumido não pode acontecer se você não ir. Show como importante você realmente é. E este é um gráfico que mostra a nossa tendência em summits. Nós começamos sem membros. Então, em junho e em Kilo, onde primeiro usamos o Programa de Trabalhoso nós temos crescido quase exponencialmente. Então, aqui em Austin temos 13 ou 15 membros da nossa equipe. Então, eu gostaria de agradecer o Programa de Trabalhoso para a suporta que está nos dando em Kilo. E, só indo para o que o HAYO começou com o ciclo de relíquias, o relíquias da liberdade e com isso, outros problemas que nós tentamos resolver. E, sobretudo, o primeiro foi que nós tentamos explicar o nosso esforço em um par de outros serviços que foram a prioridade Então, isso foi muito difícil no início. E, de novo, HAYO disse que nós fomos responsáveis para o recelar de implementos e que foi atingido para marcar aqui depois que foi transponente em Kilo. Então, nós pensamos que as repensas eram muito grandes e que a matura estava pronta para marcar mas, porém, elas não eram tão bonitas como nós pensamos. Eles eram muito grandes, muito difícil de revelar. Então, isso foi um problema que nós tínhamos aqui na liberdade. Nós tínhamos visto que os esplítios quando você tem um time muito experiente não pode ser um jeito muito bom Então, nós tínhamos novos membros que não tínhamos experimentado e começamos algumas novas frases que não tínhamos resultados bons no início. Então, tentamos ter alguma espacialidade no início se você cresceria o tamanho da sua equipe. E depois de voltar para o recelar como eu disse, nós não tínhamos feito o melhor planejamento de tudo para o recelar e em cada single review temos discussões de cada vez mais que foi feito principalmente porque as patas estavam fazendo muito coisas Então, as patas não devem fazer muitas coisas, você precisa fazer essas patas precisáveis e ser muito específicos em algumas partes das features. E na liberdade tínhamos muito esforço para refletir as patas para fazer o maior e o mais fácil para o review Então, isso foi um grande sobreviver que tínhamos em relação ao planejamento do início E isso é quando nós aprendemos como podemos identificar e reportar riscos e, mais importante, precisamos ser mais realísticos nas expectativas, porque nós tínhamos pensado que esse feature estaria disponível no próximo release de novo. Nós tínhamos ido a cada segundo Então, isso não é um planejamento uma expectativa muito boa E finalmente, nós vimos que na comunidade precisamos ser mais altos Nós tínhamos sido meio selfishamente na comunidade, então tínhamos todo o tempo Hey, por favor, minha pata é boa, review-a Hey, review-a Então, isso não é algo que você deve fazer e você precisa fazer a sua parte Então, review o call to walk at the pace you desire You need to review a call to help the community to work to walk and not expect that only from the core members And now coming the Mitaka release which we have more problems to solve and then starting with 3 members of our team has left 3 spirit members to other open stack players such as HP and Red Hat and also a partnership change which made our contributions have a little bit of redirection and we had a new focus on our project with was not that easy at the beginning so this all look good however, we had a bad side main bad side on this change of focus, we still had 2 big blow print spending the biggest of them was reseller and with the change of focus it was not a priority anymore so what are we going to do to finish this work and even though we kept focused on Keystone at this new direction of us we had again spread our work to other jobs but this was a more specialized job in the other services we were still doing authentication stuff which was our specialty and at this journey we had to work with services that we didn't have any counter some we didn't even know what they are for and that wasn't that good at the beginning however, we have also again lessons learned in Mitaka and we try to align our new priorities with the old ones so that work at the beginning but we had again lots of work to do on reseller again due to our bad plan at the beginning we had to do some part of this work at home for example as we are at the project in the university we have some bureaucracy that has some very fixed limited budgets so we do not have the concept of extra time here and we needed to do part of this work at home by ourselves so we made it, we kind of made it and this pending feature here we could make part of it merge in Mitaka so the work was split and we had about 80% merged and I think 20% we are going to discuss here at this summit so that's the biggest example we have of bad planning of bad expectations so we thought that we could make this feature in just one release we have gone to a third and it wasn't even merged entirely so again be realistic plan, design, discuss be very thorough and you seem to have a lot of sex more than we did at the beginning and also as I said we started to make other changes in other services last major which was not easy at the beginning but it was extremely worthy work since we had faster results on those last major projects within we had at the beginning because those last major projects those newer open stack projects tend to go at a faster pace they want contributors, they want features they have lots of bugs that you need to solve so if you intend to start your open stack journey maybe the last major projects may be a good start point as it worked for us even as we were being very major and first I'd like to finish here just highlighting that our new com members were able to contribute as a pro much and much faster than what we did at the beginning, we had experience we had two years of open stack and we were able to pass our experience our expertise to these members and they were immersed in the community in a much less painful way than Hayudo and other members of the project made at the beginning so Hayudo now will finish this saying what we expect for this summit for Newton so we are not here just to give this talk we have a lot of things to do first of all me and Eric will be leading a design session tomorrow we will be a cross project workshop so Kishon deprecated the V2 API and now they are moving to the V3 API so we want to discuss that Kishon have a lot of features on V3 so it is amazing and we will discuss this tomorrow on Wednesday me and Eric will be on the Kishon new features when we will discuss these reseller things and other features that we have like project tree operations and finally we will be on Wednesday on the Kishon stabilization when we will be discuss about Fernet tokens it's a new feature on open stack and it's a great thing so we just made here our result our final results so here we have an image with our members on the team we started with 7 people which was 2 undergrad students 3 engineers and 2 PID students and if you saw on Kilo and Liberty release our team increased a lot and on Liberty release was our biggest team and some guys left our project and now we have 10 members working with open stack and if you look here we have the average commit number the blue line is the average commit numbers from our anniversary the red line is from the whole open stack and the green line is from the top 10 communities on open stack so we can see that on the Kilo release as I said we had the feeling that we are more experienced guys and we learned how to contribute so we could be closer to the whole open stack average commits and the other thing is after the guys left our project after Liberty we still have the same average commit numbers so we could pass this experience for these new members and we stay with the same average commits and if you look on the review numbers we can see that no Kilo release we were really closer to the whole open stack and on the Liberty release we passed this number so we are learning how to contribute how to review this code not just in numbers but on the quality too and when we noticed that on the Mitaka release we couldn't pass this experience for code to review to these new members so this is something that we are aware and we need to work more with our team and finally no code average we can see that on the Kilo release on Liberty we were working as everyone on open stack so we had the feeling that independent where you are you can contribute like everyone, like the core so open stack are prepared to be globally to everyone on the world work with open stack so just a couple of general tips we have a great reception we got this great reception from the community but you need to be kind polite and receptive this is really important be a good member from the community it's really important to attend to the summit and meet the cycles, discussions it's hard to get something done we thought be here everything is decided here the design summit is really important for the dev team you need to write complete and concise specs these are a real important phase of the developed process so you need to be aware of that and keys, keep it short and simple write clear commit methods write simple paths and you make your life easier and for the code review tool and provide use case hey, my company wants this inside open stack and I'm doing you need to explain why this is important why this need to be inside open stack and as we shown before it is possible to have good results working outside the kernel so what is the open stack community doing for the outside kernel contributors right now there is some and meet cycle transmissions this talk will be on youtube later you can see it outside the kernel guys can see this later and some services like nova and kason make the meet cycle transmissions so they create a google hangouts and you can be part of this meet cycles and so on the travel support program as Higgs said it's really important to us the open stack metering some guys from our team are participate of the open stack metering so it's important thing for new guys that are start contributing now the open stack day some countries are organizing that it's a kind of tiny sum when you can see a couple of talks and your own language and understand more about open stack and improve the docs and tutorials right now the Brazil translation team I'm a core member of the Brazil translation team for portugues so it's really important to have these docs on your own language you speed up the ramp up process for these new users and you are contributing of your local community so finally I want to thank you the guys from the university that we could have made these without him the kason team who we works and they help a lot of moments and thank you everyone so if you have some question can you there's a microphone please so it can be recorded so we have a the open stack infrastructure team has a developer manual that we published it kind of works through how to use garret and get review I don't think we're translating it today is that something that we should try to be working on and publish do you think that would be useful usually the every servers use the IATN library to the translators so every message or every doc that you have that are using that going to a tool there is an data and the translator use these two to translate you have a list of all these messages and you can translate for your own language so basically if you are using that the translator guy can have access for your docs you don't need to be aware you just say hey please translate that for every language that the open stack supports I had another one but I don't remember now you can talk later guess we have time gank on back another thing that the community has been looking at doing is virtual sprints using IRC and asterisk or google hangouts and setting up a specific day or several days to work on a specific feature or bugs do you think that's useful I know we tried it once and one of the things that became hard for us was the time zone difference everyone in North America would be active for like this 6 hours and then kind of doing the handoff and back like that can be difficult, I don't know have you tried any of those things I saw that there is the bug smash day there is made on metaca it was by countries some countries organized physical meetings but we noticed that these works a lot a lot of bugs was fixed and they could explain for new members about OpenStack and I think that we can do some similar virtual meetings like that it's important be aware which guys you want to be part of this meeting if you are looking for new members so you need to prepare a little talk to explain about OpenStack and how to contribute but we made our OpenStack Hangouts on Brazil now it's more focused on Brazil but I believe that we can do the same thing around the world you need just to be focused who will be part of that so I think that is the important thing maybe if we do as we did in Nova and alternate the schedule of that that might also work on some Asian countries so of course it is very good for the outside contributors too Just a thing to make a note the whole mid-cycle meeting of the Iron Community was done through audio conference with a tool that is maintained by the OpenStack community and it was very important for our team in Brazil because we naturally couldn't do it so to submit to the 70 and to the mid-cycle and we could follow the discussions and participate Simva was there with the guys even in the in the late night meetings and since it's kind of scheduled meeting in a week and we could follow it even when they are very early in the morning