 De novo, se alguém tiver algum problema com slack, dúvidas no GitHub, dúvidas durante as apresentações, pode chamar qualquer um de nós, pode mandar no chat, então enquanto se você não estiver apresentando, o outro vai estar monitorando chat, a gente vai ter um dia aí, uma parte de dia, né, bem intensa de evento, não fiquem com dúvidas, o que mais que eu ia falar, bacana, o Jorge conseguiu a social contributor da SCEP Limit, a gente vai ter aí, ao final do evento, sorteio de alguns ingressos aí para o Comicon Virtual, mas para participar, vão ter algumas, vocês vão precisar participar, então vai precisar aí fazer o reisom, interagir com a gente, sei lá, não preparei nada para falar, então vou ficar falando aleatoriamente aqui, eu sou bom para investir aleatoriamente, acho que é isso, vou falar mais alguma coisa, a gente vai comentar aí durante o começo do evento, mas lembrar que o Código de Conduta aí, ele é aplicado a esse evento também para ser um evento oficial da CNCF, basicamente o Código de Conduta seja excelente ou não seja um idiota, não vamos aceitar racismo, sexismo, qualquer coisa aí que realmente enfira o bom andamento do evento, a boa convivência entre todos nós, e aí qual que é a pessoa aí que por algum motivo quiser reportar algo em relação ao Código de Conduta durante o período, pode me mandar uma mensagem em particular, mandar para o Carlos em particular aqui no chat, se eu me engano no chat permite isso, e se for alguma coisa relacionada a nós, a qualquer uma dos apresentadores, a qualquer uma das pessoas que vai palestrar, pode entrar em contato direto com a CNCF, a gente vai deixar o e-mail aí também, beleza? E já está até gravando esse evento vai ser gravado, se alguém por algum motivo não conseguir, se dá sair, não conseguir participar, a gente vai subir ali de post para o YouTube e aí isso não fica fazer spoiler não, as 10 horas a gente começa. Bora Carlos. Estava te escrevendo lá, vamos começar, beleza. Vamos entrar então, tá? Ou tu quer falar alguma coisa antes Ricardo? Eu não. Tá bom. Bom pessoal, vamos começar o pré-evento do KCD Brasil, hoje a gente vai ser um evento sobre o Kubernetes como contribuir para o Kubernetes, mais para a comunidade em si, então a gente vai dar, vai explicar como é que funciona algumas coisas dentro da comunidade, dentro do GitHub e tudo mais, deixou, me perdi aqui nos slides. Ok, vamos lá. Então muito bem-vindo a todos que estão aí, esse evento está sendo gravado e acho que vai ser disponível no YouTube mais para a frente depois. Antes de a gente começar, só lembrando como o Ricardo falou agora pouco, que esse é um código da CNCF e do Kubernetes em si, a gente tem um código de conduta da CNCF e um código de conduta do Kubernetes que são praticamente o mesmo, que segue o código de conduta da CNCF e ele é aplicado neste evento aqui também. Então vocês podem ler o código de conduta no site, mas resumindo é só ser legal com todo mundo e isso basta. Agora um pouquinho só a apresentação para todos, aqui para todo mundo nos conhecer um pouco, acho que podemos começar. Iago, pode ser o primeiro? Boa senhora. Raffidão, eu sou Iago. Eu contribuei como maneira que faz a um tempo, mas não siga que continue cycle, que é a responsável pelo QBDM. Hoje eu trabalho como maneira da Loft, acho que é isso. Obrigado, Iago. Edson, pode ser o próximo? Sim, acho que sim. E aí galera, sou Edson. Eu contribuo mais com o SigDocs na parte de localização para português. Deve fazer quase um ano aí, foi o Cates que me trouxe para o bonde. E hoje só devou ver a Nacocos, Portugal. E acho que é isso. Vai lá Ricardo. Acho que nem minha mãe me chama de Ricardo. Agora sim, eu sou Ricardo Cates, eu trabalho na VMware, sou staff engineer na VMware. Contribuo com o Cates desde 2017, na verdade, eu comecei com o Ingress, fazendo parte da comunidade, mesmo contribuindo de verdade desde 2019, que me puxou, foi o Iago, que me recomendou, vai lá no contributor Summit quando você for no Cubicom, a empresa na época tinha apagado, eu fui. Atualmente eu sou um dos mantenedores do Ingress em Jinex. E também estou de vez em quando aí, Sig CLI na parte do Cubicetl e do Sig Network. E sou embaixador da CNCF também. Então, se algum dia a gente tiver alguma coisa em relação a CNCF e quiser conversar, eu estou por lá também, mas eu quase não exerço isso, deixo muito a desejar. E aí eu vou passar para o Panato, o Panato é a nossa pessoa de destaque. Então, se dá oito, mas tudo bom. Bom pessoal, meu nome é Carlos. Trabalho na Mattermost, como staff engineer. E na comunidade Kubernetes, o seu trabalho tem contribuído bastante na Sig Relize, Sig Cluster Life Cycle. E na Sig Cluster Life Cycle eu sou tech lead de release e subproject owner do release engineer também. E no Life Cycle eu sou o mantenedor de alguns projetos de cluster API, como por exemplo cluster API Digital Ocean e cluster API DCP. E contribuo para o Azure e AWS também para cluster Life Cycle, para cluster API upstream. Eu ajudo um pouquinho às vezes o Ricardo no NGinex ingresso também e também trabalho e contribuo para outros projetos como Realm, como Falco, um outro que não tem nada a ver com a CNCF, que é o Sig Store. E alguns outros projetos de open source também. Acho que é isso. Se tiverem dúvidas, só perguntar no chat aí o que o Ricardo e o Edson e a Agu vão dando enquanto eu vou falando, o pessoal vai catando as perguntas. Bom, vamos começar. O que as pessoas tem que saber, basicamente, na comunidade Kubernetes? Ela é organizada em grupos de interesse, que é o que a gente chama de Sig. E dentro da Sig ela pode ou não ter subprojetos, como a gente vai ver mais por frente depois. Outros grupos que tem também se chama de Working Groups, das famosas Vegas, que é um pouco diferente da Sig e ainda tem comitês e grupos de usuários. Os usuários seriam mais os grupos de Made in List, algumas outras coisas fora, Meetups, outras coisas fora que não tem a ver muito com o GitHub ou código em si. Uma estrutura aqui para a gente poder entender um pouquinho melhor. Então, por exemplo, os comitês são grupos de usuários que levam a caminho junto com o projeto. Por exemplo, tem o steering comitê, tem o comitê de segurança de resposta de segurança, security response e o Code of Conduct. Eu faço parte do comitê de Code of Conduct e eu participei das eleições do steering. Esses três ou a gente vai ele é por convite ou é por eleição, certo? Então, esses três caminham ao longo do projeto e ao longo do tempo ele vai se reciclando as pessoas, vai entrando e saindo outros membros. A Sig em si, a Sig também é um grupo que se caminha ao longo do projeto, então ele é junto com o projeto da comunidade em si e é dividido em foco, tem uma área de foco para atuar. Por exemplo, a Sig Release, que é onde o trabalho atua exclusivamente na parte de manter e gerenciar o processo de release, tem ferramentas necessárias para que tenha um processo de release que seja fácil e privatizado e que seja fácil de reproduzir e reduzir o trabalho manual. Então, em gerencia, tem várias ferramentas que cuidam desse ponto. Por exemplo, a Sig de ALF, de autenticação, é focada só na parte de autenticação do Kubernetes em si, seja ela autenticação de Nordro, de Controplane ou de aplicações externas. Então, cada Sig tem uma responsabilidade, um escopro fechado de features. Claro que tem algumas features que existem no Kubernetes que passam várias Sigs. Por exemplo, pode pegar o API Machineer e concie lá e instrumentation, então esses grupos vão trabalhar juntos em si. E em cima de tudo isso, tem a parte de a Sig Release e a Sig Testing, que trabalham com todas as Sigs. A Sig Testing, por exemplo, é focada em manter a infraestrutura de teste rodando e os testes em si. Então, tem toda uma infra de teste grid para saber se os testes dos pull requests ou até mesmo os periódicos que rodam toda hora apontando para a MainBrand está tudo passando e tudo rodando. O Ricardo quer romper, assim que sempre que tiver um comentário para adicionar mais, tá? Então, por aqui. Por exemplo, tem o próximo seria o Working Group. O Working Group é um grupo que tem um período de existência. Então, ele começa e termina em algum ponto do projeto. Ele não vai ficar se estendendo ao longo do projeto em si. Enquanto o projeto estiver vivo, esse Working Group vai estar vivo. Não é bem verdade. Então, ele tem início, meio e fim. Como, por exemplo, o Structured Logging, ele é um Working Group que está focado em mover e ajustar todo o login da aplicação para ser estruturado. Então, isso vai ter um início, meio e fim. E esse Working Group, ele vai provavelmente passar por todas as Sigs, né? Porque todo mundo tem alguma coisa para alugar. A gente teve um exemplo que era o Kates Infra, que era um Working Group no início e se viu a necessidade de manter esse projeto, esse grupo rodando e mais perfeito. Então, ele virou uma Sig. Teve todo um processo de eleição, de escopo, de coisas para se definir essa conversão de Working Group para a Sig. E aí, agora tem todos os papéis lá. Ele foi visto. No início, ele foi criado um Working Group para ver como se ia se trabalhar nessa parte. E depois que ele se encerrou todo, o que tinha que ser feito, ele sentiu a necessidade de manter o trabalho rodando e continuando. Então, ele virou uma Sig, porque agora ela corre ao longo do projeto. Só para dar um contexto, o Kates Infra, ele cuida da infraestrutura do Kates Infra. Isso quer dizer, o site que roda o Kubernetes do ATI-O é essa infra que cuida toda a parte de acontas, AWS, DCP e Regio e toda tem essa parte que esse time é responsável. Então, da automação interna de, por exemplo, eu preciso fazer um setup de um teste novo. Esse setup de um setup novo vai precisar ter um service account no DCP específico e então vai ter que ser coordenado para ser criado essas coisas lá. Posso só fazer um adenho desse grupo aí? Esse grupo aí, ele é o exemplo, pessoal. Na verdade, de que contribuir para o Kubernetes não é necessariamente codificar. Quando esse grupo ele foi montado, foi bem interessante que assim, qual que era o problema? O Kubernetes foi criado no Google. Então, muitas das coisas que o Kubernetes utilizava, a infraestrutura de automação, o Docker Registry de onde vocês vão lá e baixam o Kinein, ah, preciso, fiz uma instalação via Cubidm, e aí ele baixa Cubiproxy, Scheduler e por aí vai. E eles ficavam no Docker Registry que era do Google e que ficava na conta do Google. E aí num dado momento o Google vira e fala assim, olha, não dá para a gente manter isso, porque só funcionários do Google que tem acesso a essa infraestrutura. Então eles doaram para a CNCF um valor lá anual, que eu não lembro se foi de 1 ou 2 milhões de dólares, e falaram assim, CNCF, monte a infraestrutura para sustentar o Kubernetes aqui no no no no no GCP, onde vocês quiserem, mas está aqui uma doação só que que a comunidade mantenha e não que o Google mantenha. Então, por isso que ele começou como um working group, e ele foi um working group que tentou mudar, por exemplo, aquele monte de conteúdo que existia para terraform e que começou a fazer coisas, por exemplo, assim, discussões de CDN, de distribuição de conteúdo para os usuários que estão na China, por exemplo. Então ele é uma parada que ele saiu muito do nível de código e foi muito pro nível assim, que muitas das pessoas estão também no dia a dia, que é um nível de SRE, né? Então tem um time que fica em non-call desse, desse working group, por aí vai. E aí foi o que o Carlos falou, eles viraram necessidade de falar assim, tal, a gente já trabalhou, fez o que a gente queria fazer na sua maioria, que foi tirar da infraestrutura do Google e levar para a infraestrutura da CNCF, só que agora a gente precisa manter. E para a gente manter, a gente precisa de um SIG para isso, beleza? Isso aí, por exemplo, tem uma discussão que está sendo feita com o Kates Infra e com a SIG Release, que é a questão toda de como que a gente vai distribuir as imagens dos imagens que são gerados por Kubernetes, tanto como o Ricardo falou para como é que vai ser distribuído na China e a gente agora está vendo como fazer isso, porque hoje todas as imagens estão num bucket, um registro e dá do GCP. O que a gente está trabalhando agora é para ter essas imagens também disponíveis num registro e da AWS, num registro e da Azure em outros lugares também, que tem uma cópia de cada coisa. Porque também um dos problemas que a gente tem é o custo de data transfer disso tudo. Então isso é um dos maiores custos que a gente tem dentro da comunidade. Então a gente tem, por um lado muito bom, os cloud provides dando um apoio financeiro e botando grana nisso, mas ao mesmo tempo eles ajudam nessa data transfer, mas ao mesmo tempo eles estão cobrando da gente, tem esse data transfer aqui, como é que a gente vai resolver isso no longo termo. Então a gente está trabalhando em conjunto com a SIG Release, SIG Testing, SIG Cates e Infra para a gente resolver esse problema e junto com o Sterecomite também, porque envolve outras coisas também. Acho que era isso, vamos lá. Então só entrando no vídeo de novo, uma SIG é como se fosse uma pequena comunidade, né? E se a gente tivesse só um projeto, só uma comunidade, só um tipo de, um guarda-chuva que atrasse tudo, ia ser uma comunidade de mais de 2 mil pessoas. Então é difícil de saber quem está trabalhando no que, como gerenciar as Tescas, como gerenciar as Ixos. Então por isso que foi quebrado em SIGs. Cada SIG tem um papel, tem o seu, o seu escopo fechado e aí dentro da SIGs a gente tem alguns outros papéis de, para organizar a casa, né? Deixa eu ver se tem isso que a gente vai falar mais por frente. Não, vou falar aqui. Dentro de cada SIG a gente tem o que a gente chama de chair e os tech leads, né? Então o chair é uma pessoa que é convidada a participar, ela que não tem, um dizer assim, a visão do, do time dessa SIG, qual será o roadmap e todas as coisas que vai ser trabalhado ao longo de um tempo X e essa pessoa fica o tempo que ela achar necessária, né? Mas a gente sempre estimula que vai sempre ir rotacionando a cada período de tempo. Esse período de tempo pode ser seis meses, um ano, dois anos ou, ou mais, não tem muito fechado, ela rotaciona as pessoas. E junto com isso também tem a parte dos tech leads, então pode ter um ou mais e aí esse grupo de pessoas são pessoas que trabalham mais no um dizer assim, na visão do roadmap e o que fazer, como criar as issues, acertar e traquear todas as coisas que tá sendo e óbvio também a fazer, quando a gente abre algumas issues, ninguém vai lá e pega para trabalhar, a gente vai lá e faz elas também. Então tem todo um um um trabalho que não é visto, né? pelas por fora, mas que a gente trabalha bastante, às vezes muito tempo offline e a maioria desses dessas pessoas que trabalham no como chair, como tech lead, é trabalho sem ter um esponso ou alguém pagando por trás, né? Então seria um trabalho mais voluntário, sim. Então algumas pessoas dentro da comunidade são pagas pelas empresas que trabalham para trabalhar no Combenets, mas isso não é um caso de de uma grande maioria das pessoas que trabalham na comunidade. Isso não é um caso de nenhum de nós aqui, inclusive. É, não é um caso de nenhum de nós aqui. Essas são os tipos de sigas que tem, né? Então teria de trabalhar em features, de plumbing lá de conectar as coisas, fazer as coisas funcionar, a de meta, de documentação e até mantemos as de cloud providers, né? Então tem um tem grupos específicos que fazem o Kubernetes funcionar um pouquinho para a AWS, para a DCP, para outros cloud providers também. Oracle Cloud, Alibaba e assim vai, né? Porque quando tu pede para, por exemplo, criar um service que é um tipo load balancer e aquilo cria um load balancer no teu cloud providers, como parecendo uma mágica, tem muita coisa por trás ali para conversar com a API do cloud provider em cima. Então alguns exemplos que existem antes no slide lá, mas essas são algumas sigas que existem, existem várias sigas, né? Então tem algumas que são bem quebradas, por exemplo, a Sig Apps cuida praticamente de como rodar as aplicações de, por exemplo, integrações de aplicações como Realm e outras que custam mais. Tem o Assignode que pensa e trabalha exclusivamente no node do ensino, crublet e assim para fazer aquilo tudo está rodando direitinho. Por exemplo, essas de Plumbing, que seria a API Machinery, Cluster Life Cycle Instrumentation, elas que conectam as coisas para dar um suporte. Por exemplo, no Cluster Life Cycle, algumas ferramentas que existem, algumas serviços que a gente trabalha é o Cluster API, tem o QBADM e todas essas partes que gerem o Cluster em si, desde a criação até o upgrade, o refresh de nodes e até o face-out, até a total teardown do teu Cluster. Então esse Cluster vai se focar muito no caso de como é que vai ser o dia a dia do teu Cluster, desde a criação até a deletar o Cluster em si, às vezes me foge as palavras em português. Por exemplo, essa de Meta, a Sig Release é um, a gente não contribui código direto para o repositório de Kubernetes, Kubernetes para o código de codebase, mas a gente tem todo um código em volta que gerencia e cuida das coisas do Kubernetes. Por exemplo, uma das coisas que a gente faz é quando tem alguma atualização de dependência ou de, por exemplo, de atualização da versão do Go, isso é um serviço que a gente faz e a gente tem imagens, tem todo um processo que é feito e aí a gente contribui código e autorizações no Kubernetes que a gente vai chamar de KK. Não sei se eu estou indo muito rápido. Acho que não, mas qualquer coisa eu vou te interromper. Eu mandei ali no chat, eu não lembro se você tinha na apresentação, então eu mandei ali no chat o Sig List e um pouquinho mais sobre o que é cada um dos sigs. Aí tem o Charter que eles chamam, mais ou menos o que ele faz, por aí vai e aí um detalhe a gente vai chegar depois na parte de como participar de um Sig, mas é interessante dar uma lida para vocês verem o que vocês se identificam mais. Eu entrei no Sig Network, foi o primeiro Sig, porque eu sempre gostei muito de rede, mas eu nunca soube programar até hoje, eu não sei programar direito. Mas era interessante ver os problemas de redes do Kubernetes. Então o pessoal falando de, sei lá, de contract, de tabela de roteamento, como funciona por dentro, então dê uma olhadinha lá e já vai vendo assim, acho que é até uma tarefa que depois a gente tem mais para frente que é vocês falarem qual um qual Sig você se identificaram mais dentro do Kubernetes. Eu não lembro se tinha essa tarefa, se tinha eu fiz spoiler, desculpa, se não tinha eu estou dando essa tarefa agora, mas vamos fazendo aqui e aí depois durante o intervalo e tal a gente dá uma olhadinha desses charters aí. Vamos lá. Deixa eu só atualizar aqui no meu lado. Bom, essas são as Sigs mais focadas em documentação no website e depois o Edson vai falar um pouco sobre os Sig Docs também. Então tem Sigs que também não é uns assim, que o foco não é código mas o foco é documentação e o website em si também. Então tem pessoas que trabalham apenas focando e dando sua contribuição em documentação, que é uma coisa que sempre está precisando, em falta. Cada lado do Provider tem um subprojeto dentro de uma Sig da Sig e aí é focada em cada Cloud Provider. Então tem AWS, Jury, IBM, Cloud e por aí vai. Então tem times que trabalham exclusivamente. Normalmente, na maioria das vezes as pessoas que trabalham aqui são pessoas que trabalham para esses Cloud Providers também, mas isso não é verdadeiramente 100% a verdade, por exemplo. Eu não trabalho nenhum desse Cloud Provider e eu mantenho o cluster API para digital ocean e para dissipir. Então, porque é uma coisa que eu gosto de fazer e gosto de eu trabalho junto com outras pessoas que trabalham nesses Cloud Providers em si. E aí a gente entra no Working Groups e subprojetos. Então o Working Group é um esforço entre Sigs, como a gente viu antes lá, de Structured Logging. Então é um grupo que se forma com um grupo de várias Sigs que tem um objetivo em comum para atacar. E os subprojetos são áreas de focos de uma Sig. Então, como a gente viu antes do Cloud Provider, a área de foco de um Cloud Provider, então, seria AWS, Azure e outros Cloud Providers. Como por exemplo lá, um subprojeto do Cube CTL, que é um subprojeto da Sig CLI e que trabalha exclusivamente focado em adicionar e corrigir features do Cube CTL. O Working Group, por exemplo, já teve no passado, seria o de Code Cleanup. Eu tive um time trabalhando para dar uma melhoria no corte e manter limpo. E aí tem algumas áreas que se formam também para se trabalhar, por exemplo, machine learning, que você cria um grupo para saber como melhorar a parte de machine learning, como fazer o deploy, como o que você precisa de ecossistema em volta disso tudo. E eu esqueci de passar os slides, passei no meu aqui e não passei no outro. Ok, vamos pro próximo. Isso que dá para ficar usando dois monitores, tá vendo? Por exemplo, um grupo, exemplos de Working Groups que existem e já existiram. Então, como a gente comentou lá do login, tem uma parte que trabalha agora a VGDaming, que é toda a parte de como dá nome às coisas. Então, a gente está trabalhando também em outras partes. Se quem me vê que a gente está mudando alguns, o nome do Brent, do Brent Default, de cada repositorio de VGD, Master, a gente está mudando isso para mim. Então, tem todo um esforço, não só nisso, mas também toda a parte de como chamar algumas coisas, como trocar. Então, não é simplesmente trocar, tem uma variável que se chama, um nome lá que se chama Master e Slaves. Não tem que só ir lá e trocar no código que tem ver, estudar o impacto disso tudo para saber o que mais tem que ser trocado. Então, já tem um grupo estudando isso e algumas coisas já aconteceram, já foram trocadas de nomes. Então, mas algumas vezes trocar isso pode dar algum problema, pode quebrar alguma coisa. Então, se faz toda uma transição nisso, nesse ponto. Não sei se tem perguntas. Vamos para o próximo. O chat travou aqui. E só recapitulando subprojetos, por exemplo, a gente vai vir mais para frente, mas dentro da Kubernetes 6, dentro da organização do GitHub chamado Kubernetes 6, a gente tem outros onde fica normalmente o subprojetos, como por exemplo, o Customize, Qubespray, Cluster API e assim por diante. A gente vai dar uma navegada neles antes e depois. O grupo de usuários, o User Groups, normalmente não tem ownership de nenhum código. Então, normalmente são tópicos de interesse, que são compartilhados. Então, as pessoas se juntam e começam a discutir dados, por exemplo, de Big Data ou grupos de usuários que usam via Moer para saber quais são as melhores práticas, o que fazer, como trocar as coisas, como trabalhar em conjunto com essas coisas todas. E, por último, a parte dos comitês. Então, hoje a gente tem três comitês, o Steering, o Security Response e o Code of Conduct. O Steering é um grupo de pessoas, é um comitê que foca e trabalha em todo como manter a comunidade saudável, o que a comunidade está precisando, quais são as coisas necessárias para fazer não só a comunidade, mas o projeto em si rodar. Então, eles cuidam toda a questão de administração do GitHub. Então, tem uns subgrupos de pessoas lá que são o GitHub Admin, que cuidam. E se alguém escreve alguma coisa que fere o Código de Conduta, tem algumas pessoas que vão lá e apagam e fazem um follow-up com o Código de Conduta, com o comitê, para a gente saber quais asções são necessárias. E isso vale também para o Slack e para outras plataformas, em fórum e em si. Mas esse grupo é focado em manter a saúde da comunidade sempre saudável. O grupo de Security Response cuida na parte de segurança em si, por exemplo, ah, saiu um CVE. Então, esse grupo trabalha junto com a CIC Release e outras CICs para responder essa eixo de segurança na forma correta, aplicar os pets necessários e a gente fazer a release necessária e dar o disclosure assim que possível quando chegar a hora. E o último comitê, o Code of Conduct, é o comitê que gerencia isso tudo de código de conduta, verifica se o código precisa ser atualizado, a gente recebe, a gente pode receber, vocês podem fazer denúncias anônimas ou pessoais, a gente vai conversar com essas pessoas, vai fazer o que for necessário para endereçar esse comportamento que foi divulgado, foi reportado para nós. Agora, quando... Posso te roubar um minutinho? Desculpa, só um detalhe lá no slide anterior. Esses comitês é muito importante tanto a parte de resposta-segurança em relação à responsabilidade. Então, quando você acha uma vulnerabilidade e acha assim, software, eu no Ingress já tive, sei lá, só esse ano foram dois ou três CVS e a gente vai achando. Então, o reporte responsável, porque isso pode impactar financeiramente em empresas. Então, são empresas que estão utilizando software, são empresas que não têm um tempo hábil para, por exemplo, para dar uma resposta necessária ou até para os próprios contribuidores. Então, eu uma vez recebi um reporte de uma vulnerabilidade no Ingress sexta-feira à noite, só que não foi pelo comitê de segurança. Foi um tweet que alguém mandou, falando assim, oh, achei essa vulnerabilidade aqui. Então, assim, você acaba prejudicando outras pessoas quando você acha um zero-day e não faz o reporte responsável. Então, é muito importante. E o comitê do Código de Conduta, eu acho que ele, na minha opinião, ele é uma das partes mais importantes do Cover, porque a gente consiga manter essa comunidade de uma forma não tóxica. Então, vocês vão ver, a partir do momento que vocês entrem e começam a contribuir, que vocês vão estar lidando, assim, com pessoas que fundaram o Covernet, ou pessoas que tenham uma visibilidade dentro da comunidade de tecnologia, que você vê e fala assim, oh, eu nunca pensei que eu fosse estar interagindo com uma pessoa desse porte, desse nível. E é importante, dentro do Código de Conduta, porque todo mundo tem que se comportar igual. Não é uma comunidade em que, vamos dizer assim, vou dar um exemplo. A gente sabe que existem alguns projetos aí que o cara é o dono do projeto e ele te responde da forma como ele quer. E isso acaba fastando contribuidores, isso acaba fazendo com que a comunidade se torne tóxica. O Covernet se ele preza muito pela não-toxidade da comunidade, para que todo mundo se respeite, para que, independente se você é um contribuidor novo ou se você é uma pessoa que contribui desde a fundação do projeto, você seja escutado, você tenha o seu papel, você tenha o seu lugar e, principalmente, você seja respeitado. Então, é muito importante vocês terem isso simplesmente quando vocês estiverem contribuindo. A gente até brinca às vezes que é review de PR sem sentimento. Então, quando eu for fazer um review de um PR seu, por mais que eu vá com a sua cara, o que acontece? Às vezes também somos seres humanos, mas eu tenho que te dar um review responsável, eu tenho que te dar um review educado e um review que seja construtivo. Então, é muito importante esse tipo de comportamento dentro da comunidade. A gente vai continuar presando e vocês vão ver que essa é uma das coisas que mais se bate dentro do Covernet, que, no final, todo mundo até brinca. É uma família, uma família de duas, três mil pessoas, mas que as pessoas elas têm que se respeitar. É importante mesmo porque, no momento que você se sente ofendido ou que você acha que feriu o código de conduta, você pode fazer um report sem problema nenhum, que as pessoas vão analisar, conversar com a pessoa que fez o report e vai ver o que aconteceu e a gente sempre tem uma resposta para dar. Nunca fica, ah, mandei, fiz um report e nunca me respondeu. Isso não acontece. O que pode acontecer é demorar um pouquinho mais. Porque, de novo, as pessoas que trabalham nos comitês e, por exemplo, no código de conduta, que eu trabalho também, é no meu voluntário, no meu tempo livre. Muitas vezes, às vezes, eu não tenho o tempo para olhar no dia, mas eu olho no quanto der no próximo dia ou à noite. Outro detalhe é... Foi até bom o cara dar uma parada, porque agora lembrei de outra coisa que eu tinha que falar. O steering e o code of conduct são grupos, são comitês que, para ser parte dele, é por votação. Então, as pessoas, todo mundo que é da comunidade tem... Para poder votar e poder participar das eleições, tem alguma série de regras. Então, você tem que ser um contribuidor ativo no último ano. Você tem que ter o ativo que... Tem umas regras no site, tudo explicado, mas não é só por requestos, a abertura de por requestos, mas também é isso mais o quanto é ativo na comunidade. Então, esses dois são por eleições. E o security response, se não me engano, tem uma parte de eleição, mas a maioria é parte por convite. São pessoas que já trabalham normalmente na área de segurança, especialmente na área de resposta à segurança. Então, essas pessoas aqui também contribuem nesse projeto. Mais uma coisa, Ricardo? Não, eu estava só digitando que, como você falou, esse lance do steering e do code of conduct, o pessoal, na verdade, a métrica básica é código, mas se você ajuda em ICHI, que às vezes é uma coisa que é muito importante. Eu estou ajudando a fazer triagem de ICHI, ajudando a fazer... Acho que no Stack Overflow, que tem um descanso lá da vida, o pessoal fala assim, mas eu ajudei bastante aqui e num conta como métrica. Então, na verdade, existe um processo para que você entre e tenha esse privilégio de votação sim. É que o código é fácil de metrificar, entre aspas, mas não é só código. É muita coisa, sim, realmente. É só uma parte do Cuberance. Tanto que, quando chega o período de eleições, é enviado um e-mail para a lista. Normalmente, toda parte que acontece no GitHub, seja comentários, requests, essas coisas todas, que acontece dentro do GitHub, é fácil de metrificar. Então, a gente consegue tirar as métricas e ver quem pode votar ou não. Mas ele também tem a parte que... Se o teu nome não está na lista, você pode... Eu ajudo a responder questões no Slack, no Stack Overflow e em outros lugares. Então, você vai aplicar para eles olharem e aí eles vão olhar essas outras métricas também. Normalmente, a pessoa ganha o poder de voto também, para aquela eleição. Sim. O Iago fez uma pergunta aqui em relação a security response, se tem pré-requisito. Você respondeu, estou dando uma olhadinha aqui no documento e eu vou te mandar pelo chat. Mas, assim, se eu não me engano o security response, você tem que ser de algum grupo específico de resposta de incidente de um desses grandes cloud providers ou ser chair do SIG Security, alguma coisa da CNCF. Mas eu vou dar uma olhadinha aqui e eu já te respondo, tá? Yes. O Hugo perguntou o seguinte, quando a gente conta adicionando informação, você vê um IX e colabora com resultados no IX e diz que eu acho que é um para dar mais peso sobre o assunto. Sim. Esse é um processo, na verdade, que muitos dos SIGs eles têm e faz parte, que é o seguinte, quando a gente recebe uma IX e, por exemplo, no SIG Network, cada SIG tem a sua forma de aplicar isso. Mas quando a gente recebe, por exemplo, uma IX no SIG Network, muitas das vezes o pessoal faz um pré-processo de uma triagem. Então, o que é triagem? É ver se aquela IX é válida ou não. Às vezes a pessoa tá reclamando assim, eu tô fazendo alguma coisa e tá caindo e tá trocando um pacote, tá perdendo um pacote ou não tá funcionando tal coisa ou vamos lá no CLI, lá no CUB-CTL. Dêi tal comando no CUB-CTL e o resultado não foi o que tá documentado. Então, esse processo de você falar que essa IX e ela é válida ou não, é chamado de triagem e ajuda bastante, na verdade, pra você separar. O que é um pedido de suporte ou o que é alguma coisa que é só num ambiente específico da pessoa ou o que a pessoa tá usando uma versão muito antiga do CUB-CTL que não é mais suportada de uma IX que é válida. Então, sim, ele conta e ele conta inclusive quando você quiser pedir, por exemplo, a gente vai explicar depois o que é o CUB-CTL, tá? Então, se eu quiser ganhar o membership, aquele convitezinho que te dá alguns privilégios a mais em relação ao BOT e por aí vai, tá? Mas sim, conta. Pode seguir, Carlos. Então, quando decidirem começar eu quero começar a contribuir para o Kubernetes. Como é que eu faço? Normalmente, foi até como você tem que escolher alguma SIG, né? Normalmente, você procura a área que mais tem afinidade ou que quer se desenvolver profissionalmente ou que gostaria de trabalhar mesmo, né? Então, você tem que lá e olhar quais são as SIGs que existem quais áreas que elas atuam e ver qual qual você tem mais interesse ao ser naquela ou uma ou mais, né? Normalmente, as pessoas se focam em uma, porque já é bastante coisa para aprender numa zona. E aí, quais são os passos? Então, procura elas, vê as que te interessa mais. Não tem muita... Ah, eu gosto de trabalhar em tal área, mas eu ainda não achei qual SIG que é. Então, normalmente as pessoas podem perguntar também no Slack, no canal de SIG Contribacks que é uma SIG que trabalha exclusivamente para dar um... Quer pôr a palavra? O... Uma ajuda? É, uma ajuda. Mantenha o... Trazer o possível para um contribuidor ter o máximo de resposta e se sentir bem-vindo e conseguir todas as respostas que ele precisa. Então, essa SIG Contribacks ela trabalha para ajudar o contribuidor a tirar o melhor da comunidade e para ele também. Então, para que ela possa... Acho que é na experiência do contribuidor. Isso, experiência do contribuidor. Tem a experiência do cliente ser a melhor possível. Então, essa SIG é bem focada nisso. Normalmente, essa SIG que faz esses tipos de treinamento que a gente está fazendo agora na Cubicom, que sempre tem os pré-eventos, tem um que é o Contributor Summit, que é dividido. O que a gente está fazendo hoje aqui é um... um agrupado de dois eventos que existem na Cubicom, na conferência que tem um ponto que se fala mais introduitório e depois tem um outro curso, um outro workshop que é mais avançado. A gente está fazendo um mix desses dois e num só hoje. Então, essa SIG é o que foca nisso. Acho... Acho que é essa SIG que eu vou querer ir. Então, tu entras no Slack, no canal da SIG no Slack. Cada SIG tem um canal de Slack e tu pode se juntar no Slack na lista de emails, que é o conselho, porque muita coisa acontece... Muitas coisas acontecem mais no e-mail e não tanto no Slack. Tem outros que acontecem nos dois lados. Tem outros que acontecem mais no Slack. Por exemplo, a SIG Release acontecem muita coisa no Slack. A gente não manda tanto e-mail. Então, depende. É bom se juntar nos dois. Se juntando na lista de emails, tu já automaticamente recebe também a... o convite para atender as reuniões da SIGs. E feito isso, já é parte de uma SIG. Então, tu já é parte daquela SIG é claro que você não vai ser um chefe no primeiro dia. Mas, se você já faz parte dela e aí a única coisa que tem que começar a fazer é se envolver e começar a entender mais o que está acontecendo, às vezes como uma experiência minha mesmo quando eu entrei na SIG Release eu entrei no Slack, entrei na mailing list e passei um tempo lendo as mensagens do Slack para saber o que estava acontecendo lá comecei a participar das reuniões mais comum ao 20 para entender para saber o que estava fazendo e muitas vezes acontece nas reuniões que temos esses trabalhos quem está querendo trabalhar. Se pergunta isso, muitas vezes nas reuniões. Então, quando se pergunta as pessoas que levantam a mão gostaria de trabalhar nessa SIG de cara já tem algumas coisas para fazer. Às vezes é bem complicado achar uma ischo, a gente vai ver mais para frente como achar ischos mas um jeito fácil mais tranquilo é começar a participar e entender o que está acontecendo nessa SIG. Eu vou mandar para o pessoal no chat existem duas mailing list que são que você busca quando quiser participar de uma SIG então a gente tem o Cabernet Traço Dev que é uma mailing list geral então todos os desenvolvedores de todas as SIGs quando eu digo desenvolvedores toda a comunidade fica nessa mailing list mais abrangentes vão para lá a gente está discutindo a política de depreciação de uma API porque geralmente vamos dizer que pode vai precisar ser renomeado de pod para superpod as discussões começam lá e é interessante você ler e ver como a galera das antigas e a galera das novas interagindo em relação a essas discussões entra na mailing list específica de cada SIG que você escolher foi o que o Carlos falou então quero começar a participar de uma SIG vai você vai receber os convites dos eventos e qualquer pessoa pode entrar realmente nesses eventos no zoom e se você tiver alguma coisa para falar você pode realmente era do mundo e falar eu queria falar ou botar esses itens da agenda eu demorei 3 ou 4 meses para falar na minha primeira reunião de SIG porque você vai tentando entender como é que é dinâmica você ler os documentos você entende os problemas e você fala assim isso é uma coisa que eu posso fazer isso é uma ischo e que eu posso pegar é algo que eu quero tratar então mesmo na parte de triagem de ischo isso é uma coisa bacana quero ajudar na triagem dessa ischo vou lá e boto no chapéu eu vou mandar aqui para vocês no chat a lista do Kubernetes DEV uma atualização a lista, o mailing list da Kubernetes DEV antes era Kubernetes Traço DEV, Arroba Google Groups.com agora mudou para DEV Arroba Kubernetes.io teve essa mudança provavelmente as outras mailing list vão ser emigradas também mas essa era a maior e já foi feita agora essa é a única que foi sempre sendo migrada agora para dentro do subdomen do Kubernetes DEV isso foi um trabalho que tanto da SIG Controbex fez junto com o pessoal da VG Infra da SIG Infra então eu ia falar outra coisa eu já pouco me lembro aqui é só uma referência rápida se quiserem dar uma olhada então tem toda a lista de projetos como funciona a governância e tem o SIGS.yaml um arquivo de configuração de todas as SIGS qual o nome da SIG, quem é quais as reuniões tem toda a informação lá e agora a gente podia fazer uns 5 minutos de break o que vocês acham? 5 minutos, até 3 pegar uma água no banheiro tome água pessoal tá quente aqui no Brasil sabe que tá quente pra caramba deixa eu ver a caração a gente volta às 10h50 10h50 fechou voltamos aos 10h50 fiquem aí se a gente estiver nesses intervalos quem quiser ir dando uma olhada nos charters que eu mandei o link ali em cima e fala assim eu me identifico mais com esse vai colando aí acho que é ser legal a gente saber quem que tá mais indo pra um lado ou pra outro, quem tiver alguma dúvida em relação a algum SIG pode fazer perguntas já voltei também hoje é o acho que é o primeiro dia depois de algumas semanas que tá fazendo sol aqui onde eu moro até estranho ver o sol foi rapidinho esses 2 minutos 40° se fizer 40° aqui em Berlim vou pra finland agora tá bom deixa eu ver quantos quilatas tá na rua 4 bom vamos continuar aqui a parte de comunicação continuando a parte da SIG como manter o contato marcando de novo fazendo um reforço tem 3 meios de manter contato então é a parte da mailing list da lista dos meios SLEC e as reuniões no Zoom eu diria que o SLEC é o canal no SLEC toda a comunidade no SLEC é bem pesado e às vezes eu duro e acordo tem uns ilhão de mensagens mais da SIG release então mas é lá onde normalmente todas as discussões acontecem tem várias discussões que acontecem que começam, por exemplo no SLEC que fala de alguma issue que tem no GitHub e às vezes se faz o cross o pessoal tá conversando no SLEC agora vamos sair daqui e vamos voltar pro GitHub normalmente vai ter essa conversa para ter mais contês alguma coisa tá no link do SLEC então se copia e cola o link da conversa da thread no SLEC lá no GitHub e é ao contrário também várias vezes as discussões acontecem isso aí as reuniões no Zoom normalmente é definir o que está sendo feito por exemplo a gente pode falar um pouco da experiência dele no NG mas na parte de release a gente tem uma reunião por semana e a gente alterna entre a parte de release engineer e da parte do release team que são duas coisas o release engineer são as pessoas que... vamos explicar um pouquinho mais para frente mas dando um quick e discute quais são as coisas que a gente precisa fazer o andamento do trabalho atual que a gente tá fazendo o que que tá bloqueando o que que tá sendo o que que precisa de ajuda e na outra subsequente reunião da outra semana que a gente troca por time de release o que tá acontecendo na release atual né por exemplo no final do ano passado a gente fez a release 1.24 então essas reuniões era para saber um status de cada área a gente vai ver mais para frente como é que tá a cada área tá trabalhando como é que tá a parte de documentação como é que tá a parte de release nodes se os testes estão passando no brand e assim por diante então cada lead de cada área da sua status e vê o que precisa ser feito em cada se precisa ter alguma ação por parte do time de release ou por parte de alguma outra SIG que tá impactando na release você quer que eu fale dos outros? você falou de mim é pode falar da tua experiência um pouco é o SIG Network é uma vez a cada duas semanas né mas o SIG Network tem muito subprojetos esses subprojetos são legais de entrar porque não é uma coisa tão vamos dizer assim séria quanto as reuniões do SIG Network então SIG Network é toda outra quinta-feira e aí toda segunda-feira toda outra segunda-feira tem reunião ou da pessoal que cuida da parte de Network Policy da BA de Network Policy e é legal agora eles estão discutindo por exemplo Cluster Network Policy então é uma coisa que todo mundo sempre pediu muito no Kubernetes que é uma Network Policy que ela é aplicada pelo administrador e não pelo usuário então essa discussão tá rolando é tem toda outra segunda-feira se não me engano reunião do Gateway API que vai ser a evolução do Ingress são discussões que vocês podem participar e ajudar inclusive a dar a forma para como essa funcionalidade vai ser dentro do Kubernetes tem também toda sexta-feira a reunião da evolução do KubiProxy e essas reuniões também são bem legais já o SIG CLI eu gosto muito do SIG CLI porque ele é muito receptivo ele é um SIG que é muito bacana que é muito receptivo toda reunião eles perguntam se tem alguém novo se apresenta, fala o que você veio fazer aqui porque você tá aqui eu vim aqui só porque eu ouvi que o Katz falou que o SIG CLI é legal porque eu realmente gosto do Kubi CL e o pessoal não bota muito muito valor no SIG CLI mas vocês tem que lembrar que na verdade o primeiro contato que você tem com o Kubernetes é o Kubi CLI ou o outro chamam de Kubi enfim, você chama como você quiser até essa discussão tem no SIG brincando mas ele é um SIG bem legal e ele também toda outra quarta-feira aí tá na agenda lá tem reunião do SIG CLI e aí quando não tem a reunião do SIG CLI eles fazem o que chamam de bug scrub é aquilo que eu comentei com vocês como tem muita eixo do Kubi CTL vamos fazer uma reunião aqui uma vez por mês e que a gente vai passar por todos os ischos e vai realmente tratar online esses ischos esse problema ele existe vamos ver como é a correção alguém pode pegar essa correção pra fazer então eu recomendo fortemente o SIG CLI para quem tiver um pouquinho de conhecimento de Goal e quiser começar a dar uma olhada como é que essa reunião é bem bacana e aí pra quem gosta mais da partida infraestrutura de terraform de cloud providers toda outra quarta-feira tem o SIG infra então o SIG infra ele ocorre o pessoal também discute assim essas soluções de CDN como é que vai ser o CDN distribuição de imagens e é bem dinâmico e é muito receptivo também então assim o SIG Network ele é um pouquinho mais sério porque são pessoas que já são mais antigas de Kubernetes que tem aquela visão a pessoa de redes e tal mas o SIG CLI e o SIG infra são muito receptivos e essa é a dinâmica também é muito bacana vamos lá no início de cada reunião independente da SIG acho que em quase todas as SIGs as pessoas se introduzem e falarem e tal e se pergunta se tem alguém novo para se apresentar então todo mundo começa quando se apresenta as pessoas já te conhecem então a gente já está dentro da SIG eu acabei de cometer uma gaffe gigante que o Guilherme levantou aqui porque eu falei no SIG Network de todos os projetos e não falei do Ingress né enfim o Ingress como é um subprojeto do SIG Network a gente tem reuniões a cada duas semanas também de terça-feira acho que é as duas horário do Brasil por sinal a próxima é amanhã só que eu não vou participar porque vou estar no KCD eu já visei o pessoal mas sim a gente tem e a gente também tem canal no Slack e eu até peço para todo mundo que quiser entender mais do Ingress eu sou muito ruim de e-mail eu esqueço de ler notificação, aí eu abro meus e-mails marco como não lida, aquele negócio assim eu vou marcar como não lida para ler depois eu não leio nunca mais então me chama no Slack a gente tem um canal dos desenvolvedores assim como a gente tem um canal de contribuição de documentação em português tem um canal do Brasil, a gente tem um canal de contribuição do Ingress em Jainex pode me chamar no Slack eu sou bem mais responsivo no Slack e aí eu explico melhor também e chamo a gente tem até um anúncio periódico de quando vão ter as reuniões então é só dar um pinguilá obrigado por me lembrar Guilherme da minha gáfia espero que os meus colegas do Ingress não saibam dessa gáfia que eu dei já escutei tem algum tipo nem todas os subprojetos e tem reuniões recorrentes por exemplo, a gente tinha uma reunião da Plasterepia e Digital Ocean que acontecia uma vez por mês só que basicamente era eu e mais um outro colega na reunião e a gente decidiu cancelar a reunião e não ter mais ela porque era só nós que aparecia na reunião e a gente decidiu fazer isso via Slack então a gente discute no canal Digital Ocean as coisas que tem que ser feitas a mesma coisa para Plasterepia e DCP também era só eu que aparecia então a gente cancelou e virou Slack uma das coisas que estão sendo trabalhadas também é para ter reuniões mais acíncronas porque qual o maior impecível dessas reuniões normalmente elas acontecem no time zone de quem participa mais então se no meu caso eu moro aqui na Europa então a reunião seria num horário que facilitaria a minha presença e a presença de outras pessoas que estavam mais envolvidas ativamente mas isso é ruim para outras pessoas que estão fora desse time zone o que a gente faz quando tem bastante interesse e o que já aconteceu uma vez também foi na parte do subprojeto de Torque Policies que eu queria participar e tinha outras pessoas também querendo participar foi aberta um dudo lá para pesquisar qual o melhor horário então se tenta fazer isso outras coisas que estão sendo trabalhadas para ter reuniões mais acíncronas então não tem o zoom e ser feito por Slack ou algumas outras coisas e por exemplo na SIG release quando é o período de uma nova release a gente faz duas reuniões a mesma reunião em dois horários em dois time zones diferentes um que fica melhor para o pessoal da APEC, o pessoal da Asia e todo mais e o outro pessoal mais para o pessoal da América então consegue a mesma reunião ter para os dois essas reuniões também são basicamente quase todas gravadas então pode assistir no Youtube a gravação mas não é a mesma coisa que está lá e participar o meu tempo o que a gente tenta mesmo é manter as reuniões mais acíncronas e discussões mais no Slack e lista de emails todo mundo pode participar uma coisa de ficar em mente normalmente todas as discussões no Slack e lista de emails são acíncronas então eu não vou responder se for madrugada para mim eu não vou responder provavelmente no próximo dia útil e não se espera que tu responda tem algumas mítias que são bem descontraídas e engraçadas acho que essa é um screenshot de uma SIG Contribacks eu acho não me lembro direito mas basicamente se segue uma agenda as pessoas discutem os tópicos da agenda a gente vai fazer uma pequena atura para os nobes do repositório a gente não vai abrir GitHub mas vocês podem abrir no computador de vocês enquanto a gente vai falando aqui sobre o que é mais ou menos cada repositório dentro do Kubernetes antes de a gente começar só dar um alias aqui todo o que começar com car significa que é o repositório GitHub.com barra Kubernetes qualquer coisa quando a gente fala KK normalmente é Kubernetes barra Kubernetes quando a gente fala K Steering é Kubernetes barra Steering tem um outro repositório que é o K-6 a gente vai ver mais pra frente que aí é a todos os projetos subprojetos e tem alguns outros da comunidade de Kubernetes no GitHub a gente tem essas duas organizações são as maiores então é a Organização Kubernetes e a Organização Kubernetes Trasus X mas tem outras organizações que fazem parte organizações do GitHub que fazem parte da comunidade do Kubernetes também por exemplo a gente tem uma que se chama Kubernetes Nightly onde roda toda a implementos que vai rodar e fazer o build da release toda noite por lá então fica um projeto um grupo de repositórios mais isolado desses outros aqui então dentro do repositório GitHub.com Kubernetes barra community é onde está toda a parte da comunidade então vai ter documentação sobre a comunidade a experiência do contribuidor e tudo que relaciona com essa parte o key enhancements a gente vai ver mais para frente é onde está toda os design docs feature enhancements toda parte de o que vai ser feito de melhorias no Kubernetes o repositório steering toda parte do steering comitê em si então vocês vão ver lá toda parte que o pessoal está discutindo a saúde do projeto de repositórios e outras coisas em si o repositório test infra se vocês abrirem e derem uma olhada é toda a definição de tudo que acontece no GitHub e nos projetos nos testes em si lá tem definição de test config quando eu abrir um pull request quais testes vão rodar nesse repositório é tudo definido lá como roda, quando roda e por que que roda e por exemplo de perf testes é todo um projeto um repositório que trata de descabilidade e teste de performance do Kubernetes em si tem alguma dúvida? ok parte de developer tools então tem todo eu quero começar a desenvolver para Kubernetes onde eu começo a olhar exemplos e como criar um controller como funciona um API server como gerar código em si porque tem bastante coisa que é gerada automaticamente e tem um um projeto de template de um projeto do Kubernetes quando a gente precisa dar o bootstrap de um novo projeto, um novo repositório se usar esse por exemplo essa é toda a parte de staging acho que o Ricardo pode dar um comentário nessa aqui acho que conhece mais que eu a área de staging na verdade você está sem abrir o GitHub aí né na sua janela né Carlos você consegue que aí eu vou mostrar, mas o que acontece é o seguinte o Kubernetes ele é um grande monorapp então o Kubernetes ele é um exemplo, eu acho engraçado porque o pessoal sempre associa na verdade micro serviço e o Kubernetes, se você olhar o código do Kubernetes ele é um grande monolito e um grande monorapp né o que acontece? Existem determinadas áreas do Kubernetes que são que elas impactam diretamente em outras partes do código então vamos dizer por exemplo API, o panato está mostrando API esse Kubernetes ele é uma biblioteca que você pode importar ela dentro dos seus programas em Google então você pode importar para ver como é que é API do, sei lá de um pod ou API do Ingress então vai lá no networking lá em cima Carlos por exemplo networking networking está passando networking vê um Type.go então aqui a gente tem como é que a definição de uma network pode ser de uma Ingress o que acontece? A gente precisa ter uma forma de importar essa biblioteca que não seja importando o repositório inteiro do Kubernetes porque o repositório inteiro do Kubernetes que é o K barra K, ele é gigantesco imagina que você queira usar só uma parte só uma pequena parte dessa biblioteca então uma versão específica lá do Ingress você tem que importar 900 mega lá de código não é bacana para sua aplicação segundo ponto é o seguinte, essas APIs elas estão sempre em movimento então se você aumenta a fonte aí então se você pega e importa direto do código do Kubernetes não existe um vamos dizer assim um compromisso né um contrato de compatibilidade porque aquele código ele tem constante movimento aquele código é o main aquele código é o que eu fiz API assim, vai precisar mudar então se você pega e importa aquele código você está suscetível a realmente assim, aquele código em algum momento deixar de existir e quebrar sua aplicação então o que o pessoal do Kubernetes fez? eles criaram um repositório que chama staging que é onde todo o desenvolvimento ocorre aquele staging ele é utilizado pelo código main e no momento que você precisa fazer um corte de uma release que se faz uma release nova aquele código ele é sincronizado com o repositório principal então está dentro do pkg bar staging você consegue mostrar o Kubernetes pkg staging qualquer coisa lá? você consegue abrir o Kubernetes bar staging lá só para a gente mostrar vamos lá enquanto ele abre aí então todo o desenvolvimento dessa parte de API por aí vai, pode ser um pouquinho o pkg, a staging ali é isso então todo o desenvolvimento tem ali por exemplo o API que está ali em cima a gente faz e aí na hora que se corta uma release que se faz uma release nova esse código ele é sincronizado a release dele é sincronizada para o código principal então garante-se na verdade que a versão 1.23.2 que está lá no no código da API é a versão 1.23.2 que existia quando essa release ela foi cortada e aí você não quebra a compatibilidade então vocês vão ver assim que por exemplo existe, ah eu quero desenvolver uma funcionalidade nova, aí você foi lá e fez um pr para o Kubernetes bar cub CTL e aí você vai ver e fala assim, não, não esse repositório ele é read-only você tem que ir lá, staging, search kates.io bar cub CTL faz o pr lá e aí quando for feito uma release esse código vai ser copiado para o Kubernetes bar cub CTL isso tem um outro projeto que se chama publishing bot que cuida exatamente disso então tem toda uma série de definições que ele sabe, ó para essa release aqui quais são os staging repositórios que eu tenho que puxar de qual brente que eu tenho que puxar e aí ele vai criar isso automático um cron de hobby que roda lá eventualmente acho que todo dia e sincroniza essas coisas então é um pouquinho complexo às vezes mano, ainda que eu estou com o contributor Summit estar fechado de novo pessoal, se vocês souberem desse tipo de coisa me avisa aí que eu sou meio ruim isso do beve aí eu tentei abrir e botar mais o evento mas ficou fechado ainda vocês podem me dar um ping tá acho que é isso aí vou voltar lá para o outro beleza tem algumas sigs tem os seus próprios repositórios por exemplo a sig release tem um repositório chamado release e a sigs também tem um outro que cada sig tem o seu próprio repositório chamado sig traço o nome da sig in C então se vocês entraram no github também entraram em Kubernetes barra sig de traço release ali tem toda a documentação quem faz parte da sig release e assim quem entrar de sig networking também vai ter as coisas de tudo o que é necessário aqui são por exemplo o que a gente comentou no passado lá no início do ccloud providers então esses são os repositórios de cada cloud provider e tem outros a mais, só alguns exemplos e aí tem todos os produtos de ferramentas tem o index ingress, minicube, dashboard compose por exemplo esse aqui seria um website em si e tem outras coisas que definem a infraestrutura toda do projeto então tem alguns lugares que a gente está tentando consolidar aqui dentro tudo que faz parte do kates.io outras coisas em outros lugares por exemplo as mailing list é feita na community quando você vai ser membro da recebeu e convite para ser membro do Kubernetes tem que abrir um por request para a automação poder te adicionar depois no futuro e esse por exemplo o que a gente viu antes era todos os das github.com barra Kubernetes esse aqui é um outro organização que é a Kubernetes Dash 6 que tem todos os subprojetos dentro dele por exemplo kubbuilder cluster API provider todos estão aqui dentro eles se comunicam dessa forma então aqui tem toda uma configuração que é praticamente igual a do Kubernetes mas fica mais isolado o que tem se trabalhado e tem sido discutido há um tempo é o nosso parte eu contribuo bastante para o kubbuilder então aí você vai receber o convite para fazer parte do Kubernetes da organização do Kubernetes mas ao mesmo tempo você faz parte da comunidade de Kubernetes então quem aplica para receber o convite para Kubernetes vai automaticamente receber também para o Kubernetes a organização maior então essas são as duas coisas que vai acontecer também agora acho que o Edson é o Edson agora um pouco para falar você consegue me ver direitinho sim não aguento mais a voz do panato agora é hora de evangelizar sobre as docs e aí galera a gente já comentou no início sobre a importância das docs então vou falar um pouquinho sobre o kwebsite e falar um pouquinho sobre o time de localização em português português e Brasil na nossa casa e como vocês podem contribuir também vou tentar ser rápido mas no princípio já deixo meu contato aberto lá no slack e vou deixar o link também e isso basicamente o kwebsite se vocês deram uma olhada no repositório do github a gente vai ter toda a documentação o blog que já deu uma olhada no blog do Kubernetes sempre tem uns anúncios bem bacanas lá a referência dos iglaçários a gente tem um iglaçário bem bacana também lá pode passar por favor panato obrigado então basicamente a estrutura da documentação que a gente mantém hoje ela é tudo em markdown para quem está nessa vibe de devops a gente é basicamente markdown e yaml então são coisas que está bem dentro do dia a dia aí e o deploy, a farmata que a gente usa para renderizar lá o site é ugo para quem já brinca um pouquinho com gol também, já deve ter que falar de ugo e é bem interessante pode passar então basicamente essa carinha é o nosso Kubernetes docs que todo mundo já deve ter pingado lá seja para estudar, para a certificação ou para tirar aquela dúvida marota aquela referência marota em alguma em alguma coisa pode passar pronto, falando de localização a gente tem a documentação a a linguagem principal em inglês mas a gente sabe que cada cada idioma cada país tem suas particularidades então a gente sabe que a gente tem que aprender inglês e que faz parte do dia a dia mas a gente tem muitas vantagens se a gente tiver o nosso idioma e aí quem já vai falar um pouquinho sobre localização eu deixei até definição porque não sinceramente é só tradução então por localização a gente diz adaptar para o nosso contexto então não é aquela tradução by google translate por exemplo então a gente tenta trazer o mais próximo possível do nosso contexto e aí a gente tem discussões por exemplo do que traduzir do que não traduzir lá no início quando o Carlos me chamou por exemplo a gente a blue green deployment a gente traduz um service mas é o nome de um recurso do Kubernetes mas no português a gente tem serviço então a gente tem esses cenários que pode ajudar ou pode atrapalhar na documentação então é importante para caramba a gente se atentar nos detalhes quem der uma olhada lá no repositório a gente vai ver que tem todos esses idiomas de documentação e a gente tem o nosso querido português ali no meio pode passar como que eu posso contribuir né então a gente tem anyformas acho que a documentação ela tá sempre o tempo inteiro de portas abertas esperando contribuição a documentação ela não é escrita em pedra ela evolui a gente tem releases a gente tem coisas que estão sempre em frente à evolução então a gente pode melhorar o que já tem lá a gente pode criar conteúdo novo lá no inglês a gente pode traduzir ou localizar e toda essa questão de que eu falei de que a documentação ela se atualiza de acordo com as releases eu coloquei essa fotinha para vocês verem a comparação de quantidade de páginas por idioma então esse que é bem recente acho que é do último PR é do PR do Iago que ele até me encobrou então por exemplo a gente tem o coreano por exemplo com 530 páginas e o português a gente tem 174 páginas então assim trabalho para a documentação não falta isso definitivamente não falta e a gente tem bastante coisa para fazer pode passar por favor então por onde que eu começo para contribuir com a documentação que eu diria que é extremamente fácil de entrar nesse sentido de a gente tem documentações sobre documentações então a primeira coisa seria um pouco do que o panado falou de que quando a gente vai contribuir com algum sig a gente seria interessante estar uma lida no histórico do slack e entender como é que o projeto funciona então a gente tem o idim do projeto lá no K website em português então é interessante entender como o projeto está organizado como o Hugo funciona como o diretório como é a organização de diretórios como é que a gente gerencia esses arquivos como é que a gente faz build entender como o todo funciona para a gente poder ficar mais tranquilo e realmente ter dúvidas acho que as dúvidas aparecem no momento que a gente está dando essa olhada pode passar um pouquinho o outro aspecto é o slack todas as comunicações acontecem via slack lá no slack do Kubernetes a gente tem um canal específico para falar em português acaba sendo um pouco mais confortável para tirar suas dúvidas e por dúvidas a gente fala toda e qualquer dúvida independente você pode achar que é uma besteira mas não é de forma alguma é uma besteira então dúvida é sempre dúvida e é importante trazer principalmente quando a gente fala de documentação então um processo que é construído por quem está ali nesse processo um termo para mim não necessariamente é a mesma coisa para o Katis isso acontece bastante em revisão de PR todas as pessoas tem sempre alguma coisa que pode contribuir tem uma perspectiva que pode dar uma ajuda então a primeira recomendação é entrar lá no canal do slack tudo acontece por lá a gente não necessariamente pode responder na mesma hora mas a gente vai responder tem algumas pessoas bem ativas então a gente sempre tenta responder à medida do possível pode te passar por favor outra coisa que é relativamente essa iniciativa de localização ela já tem alguns anos mas ela foi meio que revivida pelo Katis foi uma discussão que surgiu lá no grupo do Telegram do Kubernetes e aí a gente acabou fazendo uma força tarefa para renovar o processo de tradução localização e aí a gente tem uma planilha todo mundo provavelmente assina em Excel então a gente tem uma planilha que a gente faz o rastreio dos trabalhos porque basicamente para você não fazer retrabalho para duas pessoas não trabalhar na mesma página por exemplo então a gente tem esse rastreio e tem uma planilha todos os links provavelmente o pessoal vai deixar mais lá no canal a gente deixou fixado nessa planilha a gente também tem um glossário porque um glossário porque tem termos que que quando você for traduzir a gente já consegue usar algo que foi definido em consenso entre as pessoas contribuidores então a gente já tem um glossário com palavras bem comuns que a gente que a gente já encontra bastante pela documentação então o segundo passo seria entrar no slack vou olhar na planilha mais ou menos o que eu tenho interesse e aí já vou dar uma sign lá, vou colocar meu nome e vou começar a trabalhar pode passar por favor pode voltar um então quando você considerar que aquele seu trabalho está pronto ou que você já quer alguma revisão você abre o request provavelmente vão falar talvez seja um pouco de spoiler mas o bot vai automatizar boa parte do trabalho então quando você abrir o PR fica tranquilo que alguém vai vai ser atribuído como revisou e aí aquele processo de revisão ele vai acontecer bem naturalmente e assim não fiquem com medo se tiver muitas comentários, muitas coisas para arrumar o processo de revisão ele é um processo que acontece e eu aprendo de mais em revisão de PR quanto mais review mais legal alguém parou, olhou todos os detalhes fiquem tranquilo que é extremamente comum, meu primeiro PR teve 50 comentários é assim que a gente gera uma documentação bacana pode passar e é isso, eu tentei ser o mais rápido possível e assim fica à vontade a documentação do curvo não sei lá o universo pode muito bem ter uma documentação de uma definição de deployment que você acha que é um pouco mais complexo para você começar, mas a gente tem por exemplo uma sessão de tasks são how to use, como fazer bem simples que é uma forma de começar eu recomendaria você começar por algo que está no seu dia a dia ou que você quer aprender a gente tem tasks menores, documentações menores a gente tem documentação para todos os gostos tem documentação que você vai levar dois meses para chegar no final da página e tem documentação que você pode chegar ali mais mais rapidamente e terminar então começa por aquilo que você sente mais agradável eu uso muita documentação para manter atualizada e para aprender então ajuda bastante e eu acho que é isso eu estou super disponível para quem quiser trocar ideia lá em Mislec e ver por onde é que vai começar só chamar e é isso pessoal estamos de portas abertas para quem quiser contribuir com a DOC teve uma pergunta do Luís aqui em relação se a gente tem reuniões recorrentes eu não entendi ser no SIG ou sem relação à localização PT por Português e Brasil se quiser responda essa da linha tranquilo, no SIG a gente tem quase o horário sempre choca é exatamente o que o Planado falou a questão do timezone é meio complicado é o horário normalmente choca às vezes o horário de almoço aqui mas o SIG tem feito a sincronovia em Slec então normalmente o pessoal tem colocado as pautas e o pessoal vai trocando ideia na thread no português a gente até teve algumas mas agora no momento a gente não está tendo as questões de a gente não tem não chegou um consenso de quantas pessoas a gente tem que se disponibilizar para reunião e tal e tudo o que a gente precisa a gente resolve Slec então a gente acaba que não teve essa necessidade ainda mas é também super aberto eu às vezes faço call com alguém que tem dúvida e prefere falando então isso é bem aberto o SIG DOCS mesmo a gente fala SIG DOCS mas agora eles estavam fazendo testando a sincrona então tem um canal do SIG DOCS e tem um canal do Kubernetes do PTBR acho que eu respondi isso aí até o senhor Jefferson mandou aqui que documentação é super importante o melhor caminho para aprender algo e é realmente assim eu vou falar por experiência própria eu estava achando com o Kubernetes desde 2016 2017 e aí eu pegava umas páginas para traduzir e tinha a funcionalidade que eu não tinha nem ideia de que existia então e assim, coisa básica coisa dentro de secrets ou coisa dentro de pods realmente assim são dois lados o SIG DOCS a partir de tradução para português a gente está precisando quando a gente formou eu fica muito feliz que o Edison viu isso aí porque eu realmente não consigo mais acompanhar tanto mas o Edison o Diego todos fazem um trabalho muito bacana lá e é uma via de duas mãos porque você acaba aprendendo você acaba contribuindo, você acaba ajudando pessoas que no futuro vão precisar disso também seja alguma referência ou seja para prova e por aí vai então é bem bem bacana e que é isso alguém tem mais alguma dúvida pessoal em relação a DOCS? localização? eu falando aqui no Mudo a documentação é um negócio que sempre tem pouca gente que trabalha porque todo mundo acha que é mais importante o código mas isso não é verdade eu acho que um código sem documentação não vai ajudar muito também então no caso do Kubernetes e vários outros projetos qualquer outro projeto é uma coisa que vai mudando tem que ser sempre tem alguém que vai lá ler isso aqui está errado, isso aqui está desatualizado e tem que ter para atualizar as coisas é uma coisa importante e ao mesmo tempo lendo e vendo que tem que ser alterado e atualizado facilita e se aprende mais bastante aqui nem é um livro e reforçando o que o Edison falou também isso vale para o Kubernetes como todo não existe pergunta imbecil não existe dúvida besta não existe esse negócio posso fazer uma pergunta que ela é meio idiota não existe isso qualquer dúvida é dúvida qualquer questionamento é questionamento e a sua dúvida besta pode ser realmente alguma coisa complexa para qualquer outra pessoa então tragam as dúvidas perguntem não tenham vergonha que nem a gente falou no começo vocês vão ver que no final o que a gente preza muito dentro da comunidade é que todo mundo se sinta confortável que todo mundo se sinta realmente a vontade para contribuir e a questão de dúvida é sempre tem qualquer dúvida faça a pergunta eu sempre digo para o pessoal que entra no meu time para os novos new hires eu sempre digo assim que tu me faça um monte de pergunta esse é o meu o que eu espero de ti nos primeiros dias nos primeiros meses que tu me pergunte tudo que tu queira danhas da coisa mais simples até a coisa mais complexa pode ser um negócio que seja banal que pergunta não faz muito sentido sempre ela faz sentido na cabeça da pessoa que está com aquela dúvida então em coragem a todos a perguntarem em coragem a todos a perguntarem aqui também se tem alguma dúvida, quer saber de alguma outra coisa não entendeu tal assunto que a gente está falando aqui pergunta posso continuar? por mim pode ok deixa eu só olhar aqui, olha o que é aí no brasil então acho que a gente pode fazer mais uma sessão, mais uma parte depois a gente faz o break do almoço agora o que a gente vai falar aqui a gente falou de cycles, falamos de um monte de coisa falamos até um pouco de por request e adicionar feature como é que funciona um processo de ah eu quero adicionar uma feature a gente vai falar mais de feature algumas coisas não se aplicam para bug fix e algumas outras coisas mas eu quero adicionar um novo secret uma nova funcionalidade para o meu net work policy uma nova funcionalidade para o meu nodo e assim vai como é que funciona esse processo todo normalmente a gente acha que se cria um maixo no GitHub lá dizendo ah eu quero adicionar alguma coisa nesse no produto e depois disso abre um por request e pronto não é bem assim normalmente nas empresas que a gente trabalha antes de sair implementando a goal horse lá vai a gente senta e faz um design doc e conversa sobre isso se tem uma ideia uma feature nova que vai entrar as pessoas sentam o converso e discutem e fazem brand talk usam a técnica que quiser mas se senta e se discute e se escreve um documento dizendo o que vai acontecer o que vai ter nessa feature e no Kubernetes a gente chama ela de cap que seria a Kubernetes em resse muito propônso nada mais que em outros lugares se chama RFC ou se chama design doc eu não sei qualquer coisa parecida assim o goal horse eu chamo de dor dor e desespero a gente é que o processo de escrita de cap ele é bem chato acho que não tem, não sei se existe uma palavra melhor pra isso mas ele é bem estrito tem que prever todas as situações tem que prever toda a parte de métricas e toda a parte de impacto e wholeback então é um processo assim e o Carlos também que não é goal horse eu falo assim a minha vida inteira no lado srs admite muita coisa que era o goal horse planta e vambora e aí muda aí vai lá, explica aí é, por que que se tem, por que que é o como o Katz falou é complicado, é chato porque Kubernetes é um projeto enorme, gigantesco e se entrar qualquer coisa que não seja bem documentada ou não seja bem feita ou um código redondo que é um teste de conforme vai quebrar e aí quebrando imagina se tu instalou tu usa o Kubernetes da tua empresa e ela é o principal ponto de entrada de tudo, tudo acontece lá e se tu faz um upgrade quebra o teu cluster acho que vai dar algum problema na empresa vai dar algum problema que vai dar mas essas coisas tem que ser muito bem estudadas e bem planejadas então, tem algumas caps que estão aí alguns ciclos de release abertas e ainda não foram pra frente porque ainda não se chegaram num acordo de como que vai ser feita todo o processo de depreciação das versões anteriores para as versões futuras de como que vai ser testado e como é que vai ser feito o upgrade de uma versão X pra uma versão Y e assim vai então tudo é discutido e tem um processo essa cap tem um processo, tem todo um arquivo que tem que ser escrito tem toda uma documentação em si, não é só um arquivo, tem várias outras coisas que podem ser anexadas a isso e por exemplo, um mais simples que parece simples mas não é que é uma cap que a gente tá trabalhando que é trocar o nome do Brent do Github do KK pra Dimaster, pra Main tem uma cap falando sobre isso e que a gente tá tentando descobrir quais são os problemas porque não é só a gente renomear é alguns outros repositórios dentro do Kubernetes, é só vai lá e renomeia, troca os jobs apontando pro Main e funciona, mas no Kubernetes não é bem assim, no KK não é bem assim porque tem outros downstream, outras pessoas que consomem os dados que estão ali então é uma discussão que vai, vai e aí o que vai quais são os possíveis impactos disso o Github faz um redirect de uma vez, tá, o que ele faz mas se as pessoas estão usando apontando pro master ele vai conseguir fazer o redirect sem as pessoas trocarem como isso tudo funciona os testes, tem um monte de coisa que tem que ser pensada e ver quais são os impactos e como resolver cada coisa por exemplo, uma parte inicial dessa, desse renome que a gente vai tá planejando fazer, já foi alguns jobs já foram adicionados o nome do Brent do Main pra ele poder já, quando aparecer aquele Brent ele já poder continuar testando sem quebrar nada tem um monte de coisa pra fazer por exemplo esse que o KK botou aí um novo camp na IPI, tem um exemplo do network policy, então não é um negócio, ah, eu vou adicionar aqui e funciona, né as vezes não é bem assim e aí como é que funciona, essa feature vai entrar qual é o processo de test dela, quando é que ela qual é o planejamento de qual release que ela vai entrar aí naquela, quando chegar perto e ela está, a feature está pronta pra entrar, ela tá já tá toda desmovida, tá faltando algum pedaço, como é que ela vai entrar, vai precisar de feature flag vai precisar de gateway ligado, desligado, então tem todo um esquema que você tem que se pensar tem pessoas que trabalham exclusivamente nisso que ajudam as outras pessoas que estão escrevendo as caps pra pra escrever uma cap correta e que faça sentido e bem inteira e o que, quando você deve criar uma cap não é pra qualquer coisa, né então é quando tem mudanças significativas né, que envolve grupos e áreas que tem uma mudança não importante no código, não é só ah, vou trocar um comentário no código, não precisa uma cap pra isso, né, e mudanças que impactam o x lá, então você vai mudar um nome de campo agora, ao invés de criar um secreto de um jeito você cria de outro, muda todo um impacto a todo o x, então tem que ver o que mais precisa ser feito tem que ter documentação, tem que atualizar os treinamentos, tem que atualizar os blogs, tem que atualizar todas as coisas, tem que ser tudo mapiado e o que que não entra, né então, toda parte correção de teste não entra, refatoração de código não vai mudar a funcionalidade, não entra, adicionar logs, adicionar eventos, todas essas coisas que não, assim, não impacta se não impacta no x ou não é uma coisa que vai impactar no codebase em geral não entra, não precisa de uma cap aí isso só basta uma isha no GitHub, a discussão ocorre lá e se queria um request pra isso ah, um passeio aqui ah, vocês tu quer dar uma navegada aí cátiz posso, posso começar posso, podemos passear se quiser dar uma passeada, não, sei se você sabe pode ser, é que eu compartilho aqui ou eu compartilho do teu lado aí acho que eu consigo compartilhar, o meu share screen tá desabilitado, aqui eu não sei se é porque o seu tá habilitado eu vou desabilitar aqui, meu teu... habilitou deixa eu abrir aqui, deixa eu só abrir o chat compartilhar nenhuma jornada errada aqui vocês não vêem os segredos do trabalho eu vou, enquanto isso eu vou botar aqui no chat um um link de uma coisa que ajuda bastante enquanto quer procurar coisas nos repositórios de Kubernetes é o cs.kates.io ele é tipo um search só que bem melhor do que o search da internet hub pode procurar o digital ele vai te dar todos os repositórios para que menciona aquela tua procura eu vou, eu como eu não estou vendo mais minha tela qualquer coisa você me avisa da card se alguém manda alguma pergunta alguma coisa assim então assim esse é o repositório principal ele é onde fica todo o código principal o código principal ele é aqui dentro então o primeiro que a gente já passou é aquele staging que eu comentei com vocês que na verdade são partes do código que depois são reutilizadas e que vão gerar alguma biblioteca alguma coisa assim e vão depois ser migradas para o código principal então um exemplo aqui o Ctl vamos pegar um comando de create se eu ver aqui então package.comand.create eu quero ver como funciona o comando de create de um config map deixa eu ver algum básico aqui um cron job então quando eu dou aquele Ctl.create.cronjob eu caio dentro seria esse programing em gol aqui então ele tem a descrição aqui eu vou fazer uma demonstração para vocês aqui de como altera e como se compila um código no Kubernetes porque geralmente essa é uma parte as vezes que a pessoa fala eu quero fazer um pr mas eu não sei nem por onde começa a compilar um Ctl novo e aí tem toda a estrutura dele aqui de run complete, validate, run e aí o run no final é quando roda o próprio comando mesmo e por aí vai isso aqui dentro do staging outro diretório que a gente pega bastante é o command que vamos assim é o diretório onde fica o código principal na verdade de entrada então quando você chama Ctl esse é o código principal aqui a copyright é 2014, a gente está velho então foi criado em 2014 e ele basicamente ele vai chamar o Ctl porque ele é o programa principal tem um diretório que ajuda a auxiliar no processo de build aqui então são muito mais na verdade shell scripts make files do que o o código zingol mesmo por isso que assim se você é uma pessoa que sabe bastante de testes, de CICD CIG testing está precisando de gente que conheça de shell script de CICD para dar manutenção aqui, você vai acabar aprendendo um pouco de gol também, como é que funciona o bot de CICD por aí vai algumas coisas do API, do Open API, Swagger da vida, códigos gerados os clusters utilizados aí para aquele local cluster up e down algumas documentações aqui o dox até foi movido, ele tem aqui mas não tem mais nada aqui, ele foi movido para a partir do website que o Edison lançou ou dependente de cada parte para o repostório de community por aí vai um diretório de REC que tem um monte de shell script programinhas em gol necessários para manter, vamos dizer assim fazer a azeladoria que chama do código, então às vezes você modifica alguma API e aí você precisa gerar um monte de código que é autogerado, mas você precisa rodar ou você precisa fazer a validação para ver se tem tab de espaço, se o nome das variáveis estão no lugar certo, então todos esses hacks aqui são os códigos que são gerados até a verificação de spelling, de gramática faz dentro do código e ficam dentro desses shell scripts aqui do hack e por exemplo, quando tem que fazer alguma atualização de dependência, tem um script que se diz qual a dependência que tem que ser autorada, qual a versão e ele atualiza todos os golmódios que tem dentro do projeto. Como é que é? Dependendência, esse aqui né, aí tem um de sharepeak, às vezes você achou um bug e aí você fez, se corrigiu esse bug no main e alguém vai falar assim, ah beleza agora faz um sharepeak desse bug que é pegar o commit e mover para a versão 1.23, 1.22 para essa correção ser aplicada também dentro das releases que ainda são suportadas, então existem alguns script aqui que fazem tudo isso automaticamente para você, aí rodar torcer para não ter nenhum conflito no git, se não tem que ficar gerenciando o conflito depois ser feliz ali com PR aberto por um sharepeak. Aí aqui tem uma parte de logo que foi quando foi feito o logo mesmo do Kubernetes, foi criado essa parte de package que são, vamos dizer assim, todo código do Kubernetes, lembra que eu comentei lá no comecinho, que tem códigos que você precisa versionar no bibliotec e tal, então via de regra, quando o Kubernetes começou a ser desenvolvido tudo era jogado dentro desse cpkg e aí viram por exemplo assim, sei lá o Cobi Proxy, Cobi Proxy tem partes do código em específico que o Calico precisa usar ou que o Silion precisa usar ou que o Flanel precisa usar, o OneTree precisa usar e hoje se eles precisam reutilizar esse código, como esse código não foi emigrado ainda para o staging esses senais têm que puxar o código inteiro do Kubernetes e não tem inclusive esse contrato de compatibilidade alguém pode vir aqui mudar, que nem mudaram aqui no proxser.go a 26 dias atrás e pode quebrar alguma coisa dentro desses senais o que mais, o que mais, o que mais eu não sei, que tem algumas coisas, eu não sei o que é esse plug-in aqui, tenho nem ideia é plug-in, Admission e Alph foi criado, são aqueles plug-ins que foram criados para como webhook, mas dentro do próprio código do Kubernetes, para não deixar rodar como root, algumas coisas de segurança o pod security nem sei onde é que está, aquele pod security alguma coisa que substituir o pod security policy e por aí vai tem coisas que eu também não sei, o repostório é gigante tem coisas que eu não tenho nem ideia do que faz tem coisas que, não tem como saber tudo acho que é bem difícil achar que poucas pessoas conhecem todo é, essas essas pessoas aqui que são top contributors, elas provavelmente conhecem de cabo a rabo, tá então você tem o Brandon Burns, que é um dos caras que fundou o Kubernetes o Daniel Smith, que é um dos caras que conhece mais de API Jordan Lee, Tim Hawking o Mike o Stefan, que escreveu um livro sensacional inclusive de API e desenvolvimento pro Kubernetes fora essas pessoas aqui o Clayton, né é muito difícil alguém que conheça tudo acho que é isso do repostório do Kubernetes e a gente tem também o website que o Edson falou, que acho que vale a pena então a parte de contribuição do código para português mesmo ela fica aqui em Contente BTBR e aí por aqui tudo que depois é auto-generado com o Hugo mas ah, eu tenho curiosidade de ver na verdade como é que funciona essa geração automática ou eu posso adicionar por exemplo uma verificação de spellcheck, né então tem também scripts de geração conteúdos estáticos e por aí vai acho que isso foi um passeio como é que a gente tá de perguntas aqui nenhuma pergunta beleza acho que é isso então eu vou parar de compartilhar aqui são 11 e 48 quanto mais que a gente tem aqui Carlos parou no 52, né isso, né vamos fazer o seguinte pessoal para não ficar corrido dentro do deixa eu dar um stop sharing aqui para não ficar corrido no próximo assunto que ele é de muita importância na verdade porque é como achar sua primeira ische e como começar a contribuir a gente tinha falado do almoço C-15 vamos puxar ele para agora o Carlos ele tinha sugerido isso também, pode ser Carlos eu vou deixar aberto aqui, eu vou só fechar o webcam e o microfone, mas eu vou ficar por aqui se vocês quiserem puderem e façam isso também e aí meio dia aí, meia pode ser? 40 minutinhos mandem um joinha sim ou não no chat aí também pessoal, tá ruim, tá bom quiserem voltar antes ou quiserem preciso voltar depois porque a segunda parte a gente vai começar realmente a fazer uma parte mais prática agora a gente só ficou falando falando falando, na segunda parte agora vai ser vamos procurar mais ische nova, vamos fazer uma contribuição vamos brincar com os bots e aí vamos assim então a gente precisa que você esteja até mais felizes aí, mais atentos e é realmente o que vai também ajudar e a gerar a gente, a gerar massa aí para a gente conseguir fazer aquele sorteio dos ingressos para o Cubicom virtual beleza? A gente só tem mais um alguns slides que a gente vai falar como achar ische e aí depois a gente vai falar um pouquinho do bot em si, bem rapidinho e aí a gente vai por hands-on todo mundo vai poder brincar um pouco aí isso aí pessoal, então bora para o almoço obrigado para quem chegou até aqui eu sei que a gente fala pra caramba o Hugo falou que ele já tá super feliz então eu fico feliz, se você tá feliz eu tá feliz, tá valendo a pena vamos almoçar meio dia e meia a gente volta obrigado para quem chegou até aqui e qualquer coisa tá aberta aqui também eu vou ali comer alguma coisa rapidinho de avorto eu vou fazer uma pausa de uns 5 minutos mas eu vou estar aqui de volta quando eu abri a câmera de novo vocês podem fazer perguntas e qualquer coisa se tiverem dúvidas vão mandando aí eu também vou alesquentar comida valeu pessoal eu tô por aqui pessoal, se alguém tiver alguma dúvida ou quiser perguntar qualquer coisa eu vou aproveitar enquanto ninguém me voltou ainda depois eu faço o comentário de novo Panato mas eu ouvi dizer aí que o KCD da India lá teve 1.500 pessoas e que se a gente conseguir bater 1.500 pessoas a CNCF cogita o Kubikom Brasil isso aí é verdade tá gravado tá gravado a gente já tem 40 metros falta bem pouco tô só jogando a ideia vai ser publicado assim a gente ainda não sabe quando e mas assim que sair provavelmente vai ser no youtube no canal da CNCF a gente perguntou pra eles né? se é P99 o tempo todo não sei acho que 1.500 se fosse 1.500 P99 já seria a maneira seria bem legal a gente vai ser mais do que esse assim deixa eu até dar uma olhada aqui vou conversar com o Bil pra não cometer os erros que a gente cometeu hoje e deixar os ingressos todos abertos deixar tudo certinho aqui deixa eu ver o Contributor Summit a gente agora tá sem problema aqui com o ingresso né tem 282 disponíveis KCD Brasil os KCD Brasil já tem 900 pessoas registradas e aí será que a gente chega 1.500 da manhã olha, estava só em 1.000 tickets vou aumentar para 2.500 pronto pronto o Jefferson aceitou o desafio 2.500 só que eu acho que a gente vai ter que fazer alguma posta eu não vou tatuar nada não, deixa eu pensar o que eu posso fazer, as caras querendo fazer tatuagem de logo de empresa concorrente deixa a minha barba crescer durante 1 ano eu não posso fazer isso também não você tentava deixar a barba crescer durante 1 ano, eu acho que eu sou banido aqui em casa rapaz eu preciso fazer alguma posta que ela seja viável assim que eu não seja pensar eu tinha falado do cabelo de crust eu posso deixar o cabelo com o cabelo do crust durante a chance aí lá mas o reaction da manhã pode fazer pode ser o que você está comendo aí Carlos você está comendo aí você está comendo aí gordíssimo umas malinhas de de caramelo nossa mano, quero gosto é caramelo para mim as as filetes de açúcar queimaram mas aquela que você me mandou estava muito melhor já acabou os caras estão falando que não tem um bigode foda igual seu o John não perguntou se você está comendo X se você estiver comendo qualquer outra coisa vai ficar desapontado você está deixando as pessoas desapontadas comendo caramelo em vez de estar comendo X aqui não tem X, eu tenho que fazer o meu próprio X tenho que fazer o pão tenho que fazer tudo bom meio de meia, bora avortar deixa eu descompartilhar aqui e voltar para você um aqui que eu me perdi muita tecnologia muita tecnologia esse negócio de tecnologia é complicado é complicado quebábe vale depende do quebábe não é quebábe, não é X é bom que horas são aí? meio dia 31 mais 10 minutos então não porra, meio dia e meia a gente já falou de meio dia e meia ah é? estou torto aqui então vou começar não, não tem quanto atual presidência estiver correndo aí, não tem planos de ir no Brasil pois eu não me prendo aí estou ferrado fica aí, fica aí onde você está, que está melhor vamos continuar então pessoal espero que tenha dado tempo eu vou mostrar aí ao menos comer um um sanduíche aqui a gente vai falar um pouquinho de como achar primeiro aixo mas isso também depende muito da pessoa em si isso normalmente também pode se aplicar para outros projetos que não seja só o Kubernetes para qualquer outro projeto da CNCF ou até mesmo outros projetos open source que tem por aí porque eu digo que você aplica a todo mundo porque tem muita gente porque muita gente pode começar a participar da CIG, atender nos reuniões e ela eventualmente aparecer alguma coisa para fazer e aí estou de candidato para fazer e vai e tu não precisa procurar um aixo mas às vezes eu às vezes não toda semana mas alguma eventualmente uma vez, duas vezes um mês de chegada nessas itis para ver como é que andam as coisas e ver se o pessoal das partes do que eu faço que eu atuo mais para ver como é que está indo se está parada muito tempo se tem algum aixo que está com muita discussão e não está andando para frente então a gente tem que ficar olhando também como achar a primeira aixo eu vou copiar esse link ou Ricardo não, eu já achei aqui e me perdi de novo copiar essa está no está na apresentação né já copiou copiou esse link abre direto na página do GitHub que mostra todas as itis tem um label no Kubernetes, na comunidade no GitHub que é o esse GoodForce Itis essas itis são focadas para as pessoas que é a primeira vez que estão trabalhando naquele parte do código naquela SIG ou naquele pedaço do projeto ou naquele repositório é focada mais para isso quando a SIG está criando às vezes tem alguma SIG senta numa reunião e começa a criar itis e delegar coisas como a gente faz no nosso trabalho normal que o SIG senta numa planning e começa a criar um monte de Ticket e botar no Backlog o que vai ser feito aqui também acontece a mesma coisa você cria itis e aí se define isso aqui é uma aixo que é boa para quem nunca mexeu no código aqui ou nessa parte do do sistema e aí se vai catalogando assim então essa query que vocês têm é uma boa para quem quer iniciar em alguma área tem que dar uma procurada, tem que dar uma navegada procure alguma coisa que chama atenção para vocês e entrem nas itis um ponto a esclarecer vocês podem olhar que as itis vai ter vários comentários você não quer dizer que alguém já está trabalhando naquela iti então pode ser só pessoas comentando para esclarecer ou tirar dúvida ou deixar a iti mais clara para poder continuar o trabalho se vocês se interessarem em alguma iti acho que aquela já está suficiente pergunta escreve um comentário na iti dizendo se até alguém trabalhando se não tivesse você pode receber aquela iti para trabalhar um detalhe que eu considero eu sempre falo com as pessoas que me pergunto em como começar a contribuir uma vez que pegou uma iti para trabalhar tenta e tu passou alguma estimativa vou levar tanto tempo tenta em atualizar essas itis está demorando mais tempo do que tu esperava volta lá na iti comenta o que está tendo problema ou que vai demorar mais porque isso avisa o pessoal lá e entende pode ter alguma outra pessoa que queira trabalhar mas se você já está trabalhando naquela iti outras pessoas não vão passar por cima sempre tenta manter um status das coisas se demorar mais quando você vê lá não vou conseguir fazer a iti volta lá e diz não consigo mais não tenho mais tempo ou qualquer outra justificativa para liberar aquela iti para alguma outra pessoa que possa trabalhar tem um ponto na good first issue você me permite Carlos é assim eu acho que é o lado humano da coisa é muito uma good first issue no Kubernets não é porque não tem é muito disputado no sentido de todo mundo quer falar que fez um PR que fez alguma coisa para o código e por aí vai quando eu digo para o Kubernets para o K barra K a gente já teve algumas situações chatas e eu acho que vale a pena falar para vocês por isso vocês não fazem isso também que é assim alguém vir e fala assim eu quero trabalhar nessa issue eu acho que posso trabalhar e será que eu posso me associar a ela e tal e uma outra pessoa e fala assim eu já fiz o PR e está aqui e já preparei eu via de regra nos projetos que eu mantenho quando eu vejo que alguém pediu para ajudar e a outra pessoa vai e passa por cima mas eu não aceito o PR dela e ajuda a pessoa que quer fazer trabalhar cada caso é um caso cada mantenedor aborda de um jeito diferente mas isso pode acontecer e eu acho que é válido vocês saberem que isso pode acontecer então tenham paciência não achem que vai ser super simples ou super fácil pegar uma good first issue no Kubernets é realmente disputado tem empresas simplesmente que usam determinados PRs em repositórios como métrica de contratação ou não então assim, não fiquem frustrados procurem eu, procurem o Carlos eu sempre tento mandar para o pessoal nos canais que eu estou Telegram ou até no Slack good first issues que eu abro que eu abro e falo assim eu vou abrir uma good first issue se alguém tiver de boa e quiser começar a olhar isso daqui está aqui e aí a gente vai passar por alguns comandos do bot e se você tiver certeza que você quer trabalhar numa issue fala assim ah, tem uma good first issue eu acabei de ver ela, que eu tenho certeza que eu quero trabalhar nela a gente vai ensinar vocês também a como marcar aquela issue para você então assim, ninguém comentou, ninguém fez nada você pode ir lá e falar assim eu quero que essa issue seja minha mas aí se alguém for lá e falar assim a gente é deixado para outra pessoa vamos tentar sempre pensar em ser bons cidadãos cidadãs de contribuição e entender assim a dinâmica dessas good first issues beleza? e também não peguem good first issues por pegar nem entender o contexto que eu fui lá e peguei porque você só vai acabar se prejudicando e se queimando entende? fala assim, legal um negócio aqui que vai cuidar de um memory leak um panic que é um erro que não está retornando eu sei fazer isso aqui então eu vou lá e a gente vai chegar lá nessa parte de se associar um outro detalhe muitas vezes algumas pessoas veem 15 issues vou assar todas as 15 e cada 15 e cada uma é uma coisa nada a ver com a outra então tenta em pegar as issues que vocês vão realmente trabalhar e botar um tempo porque eu vou lá dizer que vai trabalhar depois, 2 dias depois 3 dias depois dizer não posso mais não sei o que porque tu pegou 15, 30 não é muito bom também não existe problema se tu quer sentar hoje a minha semana contribuição senta, pega as 15 lá e começa trabalhar em sequência, não tem problema nenhum eu já fiz uma loucura décima vez, sentei comecei numa semana terminando a sexta tinha, sei lá, 30, 40 piadas abertas não sei se vale muito a pena bom vamos pôr no caminho do feliz peguei minha primeira issue teoricamente a miagudo force issue já foi para aquele codebase para aquele repositório teoricamente tu já não teria mais não precisaria mais pegar force issues mas isso não é bem verdade pode procurar outro repositório outra em outra parte do code que te ajuda mas, para isso que vem após a primeira issue tenho link no chat essa é independente não é tão focada para quem não conhece é para quem já tem um conhecimento ok ou básico mas já conhece o código sabe o que tem que fazer são ajudas esse é um uma comunidade open source e a maioria das pessoas não recebem nada para trabalhar, não são dedicadas 100% do tempo nisso então falta mão de obra falta pessoas para trabalharem nas issues, nas coisas que terem que ser feitas se abre esse help wanted quanto não está faltando pessoas para trabalhar as vezes as pessoas perguntam mas ali só tem coisa meio difícil, muito difícil que vai levar tempo as vezes tem coisas mais fáceis tem coisas mais difíceis mas uma issue pode levar o que eu dei exemplo há algum tempo atrás quando a gente falou das caps a de renomear o brent de master para mim, eu estou trabalhando nela desde a metade do ano passado é um negócio que vai levar um tempo a gente está planejando para fazer tudo isso para o meio do ano desse ano se tudo é certo então é uma coisa que leva um tempo tem outras coisas que eu estou trabalhando e eu estou a mais de 2, 3 meses trabalhando e a gente faz um pedaço descobre que tem outras coisas para abrir e quebra isso em outras issues mas a help wanted quer dizer que precisamos de ajuda aqui então pode ir lá procurar tirar dúvidas e assiná-las para vocês também aqui só algumas coisas do team do team Sankler que é falando de como contribuir também, não é só novas features, tem toda uma parte de refactor de code para deixar mais claro tem toda parte de documentação do código em si, não documentação de tutorials ou outras coisas que vai para o site de test, tem correção de test ou como o projeto anda muito rápido tem muita atualização às vezes alguns testes quebram ou estão flake, não estão rodando de jeito que deveria rodar então tem toda uma parte de entender como aquele teste funciona e reescrever o teste ou corrigir o teste para melhorar ele então não é só novas features e tudo mais tem todo um vamos dizer assim que não é ainda para ser resolvido também e de novo, batendo na tecla, não é só código como o Edson falou antes eu vou botar o link aqui também tem toda a parte de documentação e coisas que precisam ser atualizadas precisam ser criadas, precisam ser pensadas nessa parte toda lembrando, qualquer um pode participar, pode contribuir não é só código, tem parte e contribuir não é só também no github tem toda a parte de responder dúvidas nos canais do slack ou no Stack Overflow ou no forum ou e até mesmo em meetups e coisas, isso também faz parte de contribuições moderação de slack, moderação do youtube também, um monte de coisa um monte de área que falta a gente para fazer mesmo é aqui parafraziando a Paris tem toda a parte de gerência de projeto de comunicação, de suporte tem um monte de gente que trabalha como youtube admin, slack admin tem toda essa parte que também tem que ser feita, não é só tem gente que tem que cuidar do youtube para subir os vídeos e catalogar ele corretamente tem a parte do slack que pessoal acerta é um cara que conferiu o código de condota, tem que remover o comentário tem toda uma parte de administrativa por exemplo toda vez que as pessoas mandam um e-mail para a lista do Kubernetes o deve, arroba kubernetes.io tem um grupo de pessoas por trás que recebe aquela mensagem e a mensagem tem que ser aprovada se vai entrar ou não, eu sou uma dessas pessoas para o meu timezone aqui então eu olho isso e quando vem uma mensagem a gente olha ver se não está tudo certo e aprova a mensagem ou nega a mensagem tem todo esse tipo de trabalho para ser feito também e um pouquinho da como funciona a escada de responsabilidades dentro da comunidade, a gente já falou de várias coisas até agora então começa eu não sou um membro, não contribuo nada eu começo a contribuir então eu fico como eu sou conhecido como contribuidor ainda não faço parte da organização não sou parte da org do github eu sou só contribuidor, pode ser até esporádico, fiz um piada aqui fiz outro lá, daqui a um ano eu fiz um outro então são contribuidores esporádicos mas a escada vai crescendo então assim que você fizeram algum por request acho que é dois não, acho que é bem mais são contribuições significativas pode ser um piada só mas foi bem uma coisa complexa ou pode ser 20 piadas menores acho que nem precisa ser piar mas tem que ser contribuição que seja realmente significativa também em outras coisas é o que a gente comentou é correto, mas pode ser qualquer outra coisa em si, tem vários outros contribuidores que nunca fizeram nenhum piar no código e são membros da organização também então tu vira abre o maícho no github de comunidade dizendo que tu gostaria de ser membro do github org e tem que achar duas pessoas que te façam o sponsor que deu o mais um lá no no comentário feito isso foi aprovado, recebeu o invite do bot para entrar na org todo mundo é membro então tu é um membro do Kubernetes tem só um detalhe aí que você tem que ser patrocinado para alguém que seja reviewer então não adianta tipo alguém que é membro, outra pessoa que é membro, o cara acabou de virar e todo mundo vira membro aí você vai chegar na parte de reviewer aí esqueci de ter esse detalhe membro não dá exponso para membro tem que ter no mínimo os reviewers para ser um reviewer tem que ter contribuído para aquela parte do código do código a gente até pode mostrar um pouquinho depois a gente pode mostrar algumas partes do código tem um arquivo chamado onersfile e aquilo vale para aquela parte do diretório tem o root quem é o oner do root é o oner de todos pra dentro mas tem específicos oners em específicas partes do código como a gente viu lá do K&K lá de staging, tem a parte de API de network as vezes quem é oner do API não é oner do network quem é oner de uma parte específica é o que tem conhecimento daquela parte e já fez não só por request não só trabalhou lá mas como também ajudou a revisar por request, ajudou a revisar coisas responder dúvidas fechar issues e fazer toda essa parte depois de um tempo pode se candidatar a ser reviewer e aí entra na lista de onersfiles depois disso entra na parte de approval no processo de revisão de um pull request são dois dois steps dois estágios um é o luxo gutu mi lgtm e o bar approver para o pull request ser mergiado entrar no c ganhar o merge ele tem que ter esses dois pelo menos tem que ter alguém que faça a parte da lista do oner de approval para dar o approval e tem um outro lado de reviewer para dar o luxo gutu mi depois disso a approval pode ser virar oner de um subprojeto ou de um específico do repositório então aí já é a parte que entra vira tech lead ou vira subprojeto oner de algum projeto esse é o grau máximo de um projeto tem algum comentário? vamos pular para o próximo existe também programas de mentoria dentro da comunidade dentro do slack tem um meteor contributor tem todo um acho que tem vídeos no youtube as pessoas que contra backs fazem vídeos apresentando os contribuidores dando background deles como começaram a contribuir tem o google summer of cold também agora vai começar as inscrições para um novo ciclo e também tem mentorias de grupos isso seria mais ad rock o ricardo fez um grupo de telegram para ajudar as pessoas acho que já fez isso as pessoas se auto ajudam não é uma coisa muito oficial e o LFX é da linux foundation esse ano eu mentorei duas pessoas, dois estudantes que fizeram parte do LFX e aí a gente deu um projeto para eles a gente vai acompanhando ao longo de seis meses e eles trabalham nas coisas que a gente vai passando para eles então existe formas de entrar em grupos de mentoria e a comunidade sentei várias pessoas que são bem abertas a receberem pessoas para ter um um pattern tipo de mentoria se alguém quiser tem algumas pessoas que eu não faço tanto como eu gostaria mas eu ajudo um pouco do que eu sei a gente conversa, senta, conversa via zoom e aí a gente vai passando algumas coisas para as pessoas aprenderam esse aqui o programa release shadow é bem focado na sig release que acho que é uma das únicas sigs que como vai variando, vai trocando ao longo da cadência de releases vai trocando um time de release então a gente tem esse programa de release shadow e como funciona tem uma nova versão a cada três, quatro meses é liberada então nesse período desse intervalo tem um time que se forma para gerenciar a release por exemplo agora a release 1.24 tem um time que foi formado que tem todos esses papéis dentro da release do time de release a gente tem um release lead tem o harassment lead, cias signal lead que é o cara que vai cuidar da parte de cias e os sinais de cias estão vindo certos que tem algum erro de testes test flake, tem um teste que está falhando tem o pessoal de bug triage que vai verificar todos os bugs que estão sendo abertos e ver quais devem tem que ser corrigidos que podem passar para frente ou não tem a parte de documentação dox lead release nodes lead de comunicação tem toda essa parte que tem que ser todos esses papéis são trabalhados ao longo para que no final desse período a release por exemplo 1.24 seja liberada com todas as informações atualizadas por exemplo, release nodes atualizada, documentação atualizada toda a parte de comunicação com a CNCF que vai ser divulgado, material de marketing todas essas coisas tem que ser tudo planejado e executado e com isso a gente tem um pessoal que a gente chama de shadows que são as pessoas que ficam junto com os leads trabalhando em conjunto então o lead já participou de outras releases virou o lead e agora ele está ensinando outras pessoas que num próximo ciclo vão ser leads então assim vai se passando o conhecimento e as pessoas vão aprender e vão crescendo junto eu não sei se você chegou a falar isso aí mas que é bem fixo na comunidade que uma das melhores formas de você entrar na contribuição do Kubernetes é sendo Shadow que você acaba tendo que conhecer tudo pessoa, sig, código como funciona e é bem receptivo também pelo menos era, eu lembro que era um negócio que até todo mundo pedia bastante contribuição então o Shadow é bem bacana quando eu comecei a trabalhar na sig eu fui lá atendendo e aí quando chegou a hora e trabalhando em algumas coisas quando chegou a hora de se inscrever eu me inscrevi para duas áreas uma eu não passei a outra também não passei na primeira vez aí no próximo ciclo eu me inscrevi novamente e aí passei para uma área mas naquele período que eu não tinha passado me perguntaram se eu queria só ficar junto para entender alguma coisa eu disse claro também quero ficar então eu comecei a trabalhar numa área de siar e sigo e entender o que se faz lá dentro e começar a ajudar em algumas coisas e no próximo ciclo eu entrei qual é a ideia do release Shadow é aprender fazendo então se trabalha, se discute o que tem que ser feito naquele papel em si por exemplo se há e sigo e começa a ver o que existe o documentação hoje como é que se realiza esse tipo de trabalho e aí tu vai lá e faz e vê tá faltando uma coisa essa documentação tá errada o jeito, o processo que se faz pode ser melhorado então as pessoas trabalham na parte de melhorar esse processo entender como é que funciona e quais são as melhorias e o próximo time do próximo ciclo consiga fazer o trabalho melhor e mais rápido então aí aquele próximo time vai pegar o que se passou na release passada aplicar e ver agora dá para a gente ampliar essa outra área para melhorar essa outra parte e assim vai melhorando a cada ciclo e ajuda por um lado se tu pode entrar numa área que tu não conhece muito e aprender daquela área por exemplo a parte de comunicação ou da parte de release notice pode participar daquilo como Shadow e aprender um pouco daquela área para entender melhor e aí o bom dessas coisas de Shadow que não se aplica só para o Kubernetes Ensina em todos os projetos tem os projetos que a gente trabalha na empresa eles tem que fazer uma release em certa altura do desenvolvimento do projeto você pode usar o que se aprendeu aqui na parte do trabalho como é que pode participar do release Shadow a cada final de ciclo por exemplo vai ser enviado um e-mail para a lista o devearroba.co.io dizendo que o processo para aplicar para o programa de Shadow está aberto então fiquem de olho no e-mail quando abrir o e-mail a gente divulga também no Twitter e em outros lugares vão lá e preencham o formulário é um formulário simples de preencher mas tem algumas partes que tem que ser bem pensado porque você vai te perguntar o porquê você quer aplicar as coisas que gostaria de aprender e tudo mais é baseado nisso e se também é um pouco baseado se já tem uma certa experiência se não tem e aí explicar as coisas direitinho o que tem que ser feito antes de aplicar tem que entender o que cada papel se faz vou aplicar para como aí chega para entender uma coisa que você não tem interesse ou é muito fora do seu escopo que não gostaria de trabalhar então não vale a pena então a ideia é leia o livro de Handbook de cada papel e entenda o que cada papel faz tem dúvidas? vai no Slack do Sig Release no canal do Sig Release e pergunta lá também o pessoal sempre responde sempre tenta deixar o mais claro possível entender o qual a rol que quer para ele formular e espera para a lista de anunciados caso não dê não tem problema acho que a gente teve bastante pessoas aplicando então é um processo que leva um tempo até para nós verificar e selecionar as pessoas então não deu nesse nesse ciclo tenta no próximo mas a minha dica é ah não deu no ciclo vira as costas e vai embora e tenta aplicar no próximo talvez não dê porque também tem que mostrar uma exposição mostrar interesse das pessoas então você só aplicar e nunca participou de uma reunião ou nunca falou nada no chat é um fico um pouco difícil das pessoas te conhecerem então às vezes tem que aparecer um pouco também esse aqui acho que a gente já falou antes de começar o evento para todo mundo participar e poder submeter contribuições seja lá ela qual for tem que ser assinado um CLE que esse CLE pode ser tanto individual ou corporativo se você estiver trabalhando numa empresa que ela vai te te dedicar um tempo do teu trabalho da empresa para contribuir para a comunidade tem que verificar na tua empresa o CLE corporativo o individual o acesso se tu não quiser assinar o CLE a tua teu direito também mas nenhum piar o request vai ser mediado porque esse CLE é obrigatório na ser assinado se for alguma coisa muito específica tem que conversar com o pessoal do steering committee para saber por que disso e aí entra de caso a caso é onde eu sei o CLE é bem simples de ser assinado e não tem muitos problemas rapidinho agora um pouco mais agora focando no github e a automação do Kubernetes a gente tem alguns labels que quando se abre por request ou quando se abre issues alguns são automaticamente colocados e outros são adicionados manualmente via automação por exemplo se tu não tiver o CLE assinado o CLE quando abriu por request ele vai dizer que não tem o CLE não está assinado então ele avisa um label lá se tu não é membro da comunidade da organização para qualquer por request vai aparecer esse label aqui nidsoketo test que significa que nenhum teste nenhum job vai ser rodado para aquele request ou seja que alguém vá lá e diga ok esse por request pode ser testado pode ser ok por que disso por que alguma pessoa com mais intenção pode submeter algum código que faça alguma outra coisa que não é desejado e rode na infraestrutura que tem e pode dar algum problema de segurança por isso que existe isso esse nidsoketo test some do momento que tu ganha tu entra para a organização do github alguns outros labels aqui o approved looks good to me esses são os labels que são necessários para quando vai ser o merge feito tem que estar, tem que existir alguns labels no por request tem esse short cut aqui issues.kates.io ele abre todas as issues do Kubernetes para ti e aí pode ser filtrado por tipo de de kind o tipo daquela issue se é um bug, se é uma feature uma melhoria, um clean up se é documentação e aí pode ver labels necessário para criação quando tem a criação de um por request tem que ter no mínimo esses dois labels que é o da sig qual sig pertence a aquele por request e qual é o kind que tipo é aquela issue é uma issue de correção de bug é uma issue de atualização de documentação essa sig esse por request é da networking normalmente essas coisas podem ser entram automaticamente porque o bot identifica em qual parte do código que tudo mexeu com as arquivos e ele às vezes atualiza se não atualizar pode ser colocado via automação para ser adicionado depois por exemplo priority qual a importância dessa issue é importante para agora é crítico é urgente para dar prioridade para as pessoas poderem revisar por exemplo um label de sig um sig off sig test para adicionar uma sig manualmente um label da sig faz um comentário no github slash sig off vai adicionar a label sig off por exemplo esse sig contribui a experiência vai adicionar essa sig no label de quest ou da issue esses são alguns exemplos de tipo do kind label as cores são até corretas também quando é bug failing test pode ser um teste que está falhando esse é um tipo de failing test tem kind flake que é um teste que está falhando que falha eventualmente todos esses que a gente comentou para adicionar o exemplo é o slash kind e o tipo desse label por exemplo slash kind feature vai adicionar o label kind feature o mesmo pra prioridade como eu falei antes então esses são alguns então o crítico urgente é o mais urgente a gente tem que revisar o mais rápido possível então alguns outros também vale isso aqui tanto para request como para issues tem algumas issues que se cria isso aqui é backlog ou isso aqui é importante no long term mais pra frente mas a gente não está tentando trabalhar nele agora mas num futuro próximo esses são alguns labels que são adicionados pela pela automação e às vezes tipo esse cherry pick approved em alguns estágios de release esse é adicionado manualmente pelo pessoal de release management que quando tem alguma coisa que tem que ser back port para os brentes anteriores os owners dos arquivos verificam aprovam e dão looks go to me mas o time de release management vai lá também dar uma olhada se aquela é uma correção de bug porque normalmente a gente não faz cherry pick de features para não ter problema cherry pick para os brentes que já foram feitos a release só de correção de bug ou clean up melhorar alguma coisa no sentido um log que está feito sendo feito estar com a palavra errada alguma coisa assim mas nunca sem explicação quase sempre a gente não aceita melhoria features implementações novas a não ser que seja muito bem explicado mas isso aí tem uma discussão toda em volta disso mais um link aqui piars.kates.io mostra todos os os requests que estão abertos no brentes e aí de novo esses são os labels que aparecem nas issues para good for se issue para help wanted normalmente o help wanted baixa barreira de entrada, uma tarefa normalmente fácil não quer dizer que vai ser sempre fácil e o good for se issue é focado em novos contribuidores o pessoal reserva um tempo para dar suporte e orientação nessa issue também esse é como aparece quando o pessoal vai procurar o GitHub e vai aparecer desse jeito tem mais a gente tem o kates.io robot se vocês vão ver que ele vai estar para vai aparecer em tudo que é lugar ele que faz as automações rodarem que isso aqui contribuição né esse é o processo de contribuição é bem, acho que é bem um padrão do GitHub né então faz um fork do repositório que você vai trabalhar trabalha nele, puxa o teu brent e depois abre um por request então ele depois você pode fazer um fetch, um rebase para sincronizar o seu fork repositório bom aí aqui só um flowzinho bem simples né a gente abre um por request a gente adiciona os labels necessários e notas né tem todo um template quando tu abre um por request ele vai te dar um template vai te dar um certo um guia lá para o que que tu tem que preencher qual esse cheque que tu tem que dar aí o bot valida e comenta nos por request por exemplo se tu adiciona um release note ele adiciona um label de release note ele adiciona se tu fez o CLE ou não se tu é membro ou não você pode fazer outras coisas então aí tu resolve os comentários as pessoas os reviewers adicionam outros labels ou notas os oners daquele parte do arquivo do código faz o review e a prova outros contribuidores podem dar o luxo go to me também quando o aprov tem que vim pelo oner daquele parte do código da comunidade dentro da organização pode dar o luxo go to me se os testes estão passando está tudo ok o tide que é um um serviço ele faz o merge no pia e com esse link aqui vocês podem abrir e vai estar todos os possíveis comandos que o bot entende e que pode ser aplicados por request ou num maícho nesse link também vai dizer eu vou dar o que dessa automação tem alguns comandos que é só pra quem é membro tem alguns comandos que só rodam que só funcionam pra quem é oner daquele específico código base e tem alguns outros comandos que é pra qualquer pessoa por exemplo a barra sign a rouba o GitHub username vai associar aquele ixo, aquele pull request é um usuário de pull request está os testes falhando se você der um barra re-test re-executar todos os testes que falharam se tu quiser fechar aquele ixo, o barra close fecha o pull request quer comentar pra algum usuário pra revisão, barra cc é o nome do usuário e assim vai por exemplo aqui volta um lá esse lance do a sign se vocês lembrarem quando eu falei de good first ixo se vocês lembrarem em PRs e ixos pra vocês mesmos então mesmo você não sendo membro se você ver um a good first ixo e você quiser tratar e falar assim, eu tenho certeza e não tem ninguém se você digitar só um barra sign sem nada o bot vai falar, vai associar você como dono daquela ixo e daquele PR tá é isso aí eu vou dar uma aceleradinha aqui acho que tem mais dois slides pra gente fazer um hand zone porque agora que eu vi um horário eu tinha chamado a mensagem de slack agora que eu vi a mensagem também bom esse vai ser uma mensagem típica do bot dizendo que o pull request não tá aprovado ainda pra dar uma sign na pessoa x por exemplo, isso aqui é random ele pega pelo arquivo e aí aqui diz quem esse link aqui onde tem oners no details aqui se vocês abrirem esse link ele vai direcionar pro arquivo de oners daquela parte que tu tá mexendo no pull request esse oners aqui pode ser uma lista pode ser um ou pode ser vários dependendo de quanto tu mexeu no código tem que ter um approval da o barra approval das pessoas que estão dentro dessa lista e um looks good to me de qualquer outro contribuidor agora as vezes tu abre um pull request e o pull request fica lá pra sempre né aberto e ninguém olha né então as vezes acontece isso de novo as pessoas trabalham aqui voluntariamente as vezes tu não esquece de olhar as notificações ou passa ou simplesmente não teve tempo de olhar ou apagou os e-mails os lados de notificação do GitHub nem viu então tem que adicionar a barra sig no label vai dizer qual sig que é se não tá no teu pull request se tu tem algum mentor fale com ele pra ele poder te ajudar quem procurar entre em contato com alguém da sig pelo via slack e-mail ou até o pull request tá aberto lá um tempão entra na reunião do zoom se tiver e diz que tem uma pergunta o pull request lá pra alguém dar uma olhada ou entra direto em contato com o pessoal que tá descrito no onerfire também as vezes é um pouco complicado as vezes a gente tem por exemplo quando tem que dar o cherry pick a prove pra fazer backport mas ainda tá pendente de alguém dar um a prove tem que ir catando as pessoas certas pra fazer um merge pra dar o ok pra gente poder fazer um merge as vezes isso leva um dia já teve caso de um pull request que levou quase dois meses pra alguém lá dar uma olhada e dar um a prove as vezes pode ser interesse da pessoa se não é tão importante pra agora pode deixar aqui maturando mais um pouco as vezes as pessoas são muito ocupadas mesmo por exemplo quando tem algum erro de teste também o bot responde e diz o teste por exemplo nesse caso cobernets entwen gci falhou aqui ele te mostra o link pro teste grid pros logs pra te dar uma olhada nos logs e qual commit que falhou então dá pra te retestar se for algum flake alguma coisa e aí tu consegue ter mais informações do teu teste também só pra responder tem que responder as questões tem que resolver as coisas tem que resolver se tiver alguma falha no teste tem que o pessoal vai passar feedback no código tem que ir lá e discutir ou corrigir e atualizar e as mensagens do bot também tem que ser resolvidas tudo isso ok as pessoas vão dar o barra provo no xcut mi e o teu PR vai entrar no código agora hands on Ricardo beleza eu mudei um evento aqui eu consegui mudar até as três pra gente não deixar também tão corrido mas eu acho que até umas duas duas e meia a gente acaba tá só pra fazer com calma também se libera o share screen aí pra mim deixa eu compartilhar minha tela aqui eu vou compartilhar a minha tela inteira aí aí panata você vai ver aí os comentários o pessoal tá pedindo pra aumentar ou diminuir a fonte porque meu monitor ele é meio grandão às vezes eu perco beleza pessoal então vamos lá eu vou dividir essa demo em duas partes a primeira parte eu vou mostrar como é que é mais ou menos o ciclo básico de alteração do código do cavernets então assim a gente precisa alterar eu quero alterar alguma coisa como é que eu compilo como é que eu faço o teste e tal um hands on mais rápido na parte de gol a ciclo da plata compartilhou até ali entrou num buraco negro aqui pronto melhor deixa eu fechar esse negócio aqui pronto melhor né a segunda parte que ela também vai ser importante pra pra vocês acharem até mais legal esse playground aqui então o que a gente vai fazer aqui tá pessoal nesse exercício aqui vocês que estão aqui vocês vão abrir por request então eu vou fazer um primeiro vou mostrar mais ou menos como é que seria o fluxo do por request depois a gente vai mostrar como é que é esse ciclo de de autorização né então a gente tem aqui é o que que é esse diretório aí a gente tem aqui um um arquivo de owners que diz quem são as pessoas que podem aprovar que no caso sou eu e o panato vocês vão ver vocês vão ver vão poder interagir com o bot é então eu vou tentar passar mais rápido pela parte de compilação do código só pra né então eu vou fazer assim porque eu quero mudar alguma coisa em tal e a gente vem aqui pra essa parte do playground mesmo que ela é mais legal e ela é mais interativa tá então vamos lá então a primeira coisa eu vou vir aqui no eu tenho o código do culvernet esclonado aqui tá é deixa eu aumentar aqui a janela acho que tá bom né tá bom panato beleza vamos dizer assim que eu por algum motivo eu quero adicionar uma flag nova no cubi proxy tá então eu quero adicionar um cubi proxy lá né e eu quero adicionar alguma flag nova é sei lá porque eu achei bonito não precisa ter um caso do cavernet para tomar justificativa mas aqui pra vocês não precisa tomar justificativa então eu vim aqui no código do cubi proxy não é aqui é aqui e aí eu vi que eu quero por exemplo adicionar eu quero mudar a descrição de uma flag aqui falando que por exemplo vamos procurar umas flags aqui flags flags eu já não lembro mais estou ficando velho cadê server go cadê panato aqui server go quero pegar e mudar uma flag aqui que hoje ela representa por exemplo sei lá eu tenho aqui esse config e a descrição desse cara aqui tá como config depeft configuration file eu quero botar qualquer coisa aqui então vamos ver como é que ele tava antes meu meu viagem ele tá tendo um tempo ruim aqui calma aí porque viagem né é porque é porque ficava mais fácil de compartilhar a janela né vamos lá eu vou então a primeira coisa que eu vou fazer antes de alterar eu vou mostrar pra vocês como é que ele tava então eu mudei um componente mudei o cubi proxy mudei o cubi ctl se eu vier aqui na vez e fizer um make cubi proxy ele vai compilar o cubi proxy pra mim o computador vai a loucura aqui né vai esquentar o quarto todo é pra vocês que estão na europa é fazer compilação de qualquer coisa no cuban é um ótimo jeito de você esquentar a sua casa tá é a gente espera ele fazer aqui deixa eu ver se ele tá rodando teoricamente tá ele tá tendo o tempo dele aqui eu podia ter feito isso antes né animal só pelo menos pra cachaar é desculpa viu gente vamos lá enquanto ele faz aqui ele tá construindo aqui agora ele vai fazer toda a parte de compilação do código né por aí vai coisas que poderíamos estar cachaadas e este esta besta que vos fala esqueceu de fazer isso perdões pelo vacilo enquanto ele faz aqui eu vou fazer uma modificação do código eu vou brincando de fazer aquela modificação do código então eu quero vir aqui cmd cubi proxy app aí é aqui interessante né se eu mudasse o cubi proxy o oner desse cara fala que se eu vier esse aqui mudasse qualquer coisa alguém sig network reviewer teria que autorizar revisar né quando eu abrir seu pr e alguém de sig network approve vai então aquilo que o panato comentou no comecinho a partir do momento que eu abri um pr alguém desse grupo aqui vai ser marcado no pr para revisar e alguém desse grupo aqui tem que necessariamente falar que o pr foi aceito e quem são essas pessoas por exemplo então vamos ver aqui a oneralias sig network approvers então approvers a gente tem o andrew antonio boa e o casey da windshield e reviewers também mas o grupo de reviewers e o grupo de approvers pode ser diferente então eu posso ter um grupo de pessoas que faz só revisão que vai ser marcado só pra revisar e um grupo de pessoas que vai aprovar e isso inclusive que nem o panato falou faz parte da escada de carreira dentro do cubi você pode ser só uma pessoa que vai revisar e você pode ser uma pessoa que vai aprovar então por exemplo se eu vier e procurar eu por exemplo eu sou uma das pessoas dentro e se ela é que eu reviso mas eu não aprovo né as únicas pessoas que podem aprovar são essas daqui que estão dentro desse maintainers aqui beleza bom o cubi proxy está acabando de construir ali ele realmente assina a primeira vez que você faz o build de alguma coisa no cabinet se ele demora porque ele vai construir todas as coisas auxiliares que precisa aqui agora ele já está construindo então ele está no final e aí eu posso mostrar pra vocês como é que a flag estava tá quanto isso vamos fazer o seguinte vamos abrir aqui o acabou então beleza se eu vier aqui agora e executar output bin cubi proxy menos menos help ele vai rodar o cubi proxy aqui e aí vamos pegar aquela flag de config lá que é que eu quero mexer tá ela está aqui em cima então rapaz foi pegar bem aqui tá eu tenho a config aqui e a descrição dela é depeft configuration file aí vamos dizer que eu sei lá não gostei da palavra configuration e eu quero mudar pra config né depeft o config file então deixa eu fechar e deixar grandão aqui um dia eu queria ter ter a capacidade da elin nessa parte assim de mexer com temux viai fiquei impressionado quando eu vi a apresentação dela no no vídeo do jefferson lá fazendo coisa no viai foi assim caralho eu queria ser desse nível então se eu vier aqui apagar e deixar pronto, mudei pra config né vim aqui o viai mudeia esqueci que esse viai está super carregado preciso tirar esse monte de plugin dele aqui ai desgraça beleza aí se eu vier aqui dá um git de file e fala oh beleza tá diferente aqui um bake cubi proxy agora vai ser bem mais rápido que ele já fez o cache de tudo vai dar certo eu tenho um habito meio ruim de quando eu preciso esperar alguma coisa acontecer é eu cantar tá gente então se eu começar a cantar aqui vocês por favor fiquem não vão embora faz parte meu gosto de musical ele é completamente duvidoso mas faz parte também feito então cubi proxy menos menos help aqui se eu vier aqui em cima no config agora cadê o config pronto config file fizemos a nossa primeira modificação para que serviu pra nada serviu na verdade pra mostrar pra vocês o processo de compilação com o bake cubi proxy bake cubi CTL e o processo de edição e como ele é um pouquinho demorado no começo beleza agora vou fazer o seguinte tem alguma dúvida até aqui e para nada o pessoal mandou aí chat um speck mínima de memória para fazer o build rapaz sabe que eu não tenho a menor ideia a última vez eu não me lembro se eu li em algum lugar mas eu acho que é no mínimo 8 giga mas aí tu vai dar uma sofrida né eu diria 16 giga de memória estava suficiente mas isso é para o make release né se você for lá e dá um make release o make release é demorado na minha máquina porque eu acho que assim de 4 8 giga dá para compilar porque no final esse é um programa goal e tal ele demora um pouco mais nesse comecinho que ele tem que compilar todos os generators todos aqueles arquivos lá mas depois vai embora o nosso job que roda a release é uma máquina com 32 giga de memória é já achou já achou massa então vamos lá agora vamos brincar um pouco no play ground deixa eu ver aqui se alguém já não foi aqui e fez alguma coisa então beleza vou colocar o link aqui no chat boa a ideia é que você faça um fork desse projeto e vai ter uma pasta lá um diretor chamado Brasil lá dentro como é que a gente pode fazer lá dentro você vai criar um arquivo com o teu nome de markdown Ricardo ponto md e você bota o meu primeiro piar qualquer coisa ali dentro bota a nome sobre o nome para não dar conflito a gente não tem que ficar fazendo rebase esse conflito então assim é isso que o Carlos falou eu vou fazer o meu aqui e aí eu vou demonstrando mas vocês fiquem à vontade tá então eu vim aqui já fiz o meu fork então ele fala você já fez o fork beleza então eu vou vim aqui e vou clonar o meu forkzinho aqui então então eu tenho aqui o meu fork ele tá demorando uma vida aqui também mas ele vai fazer então entrei aqui no contributor playground esse é meu fork eu quero vim aqui e adicionar uma coisa nova então e aí eu vou colocar alguma coisa assim olá para o contributor summit vou adicionar vou comitar mudar o brente né criar uma brente é verdade eu já master desculpa gente eu vou colocar para master o problema depois eu vou ter que fazer um rebase myfirstcontrib tá aqui e vou mandá-la gitpush origin myfirstcontrib mandei na hora que eu fiz isso o GitHub vai falar assim beleza você fez deixa só eu voltar quando o panato fala assim de puxar para sua brente então o comando que eu esqueci foi esse git checkout-b minha brente eu não vou entrar nos internals de como é que faz um crion brente, descrion brente e tal do git eu acho que é um pouco mais de gestão aprender um pouquinho mais de git apesar de que eu tenho para mim de que nunca não existe isso de aprender git demais o que eu sei fazer no git geralmente é apadar meu diretor e clonar de novo quando eu vou fazer alguma coisa errada é bom aprender então eu fiz o checkout com a brente novo já a versão podia criar um descomplicando o git esse ia ser massa e aí eu fiz o push origin myfirstcontrib e ele mandou aqui e falou se você quiser abrir um purr quest você abre esse linkzinho aqui então eu vou vir aqui vou abrir o meu pr aqui ele tem umas instruções o que você quer fazer quer dar no bot ele já vem com um template pronto para você preencher as informações aqui vamos fazer isso aqui então eu vou chegar aqui vou apagar esse monte de comentário que é desnecessário o meu pr ele é um sei lá ele é do tipo clean up vou apagar todos os outros aí porque esse pr ele está aqui porque eu preciso disso ele fecha alguma ische se fechar a gente pode botar aqui fixes o número da ische ele não fecha nada então a gente não precisa colocar nada aqui tem alguma nota para o seu revisor você quer que a pessoa tenha alguma tensão especial no nosso caso não release note se eu colocar um release note aqui o pr sei lá o pr e aí alguma informação adicional se tem algum cap, alguma coisa assim, não tem nada então na hora que eu vier aqui e criar o pr request, olha que bacana o que vai começar a acontecer o bot vai começar a rodar então a primeira coisa que ele fez foi ver que eu assinei o cl por isso que a gente falou para vocês lá no comecinho e foi falando, assinei o cl ele não deixa que está aprovado porque eu estou naquele arquivo de áuners então ele tem um aprovio automático ele adicionou uma label com o tamanho desse pr por que? porque isso aqui facilita para quem está fazendo a revisão saber qual pr está maior, qual pr está menor e uma coisa que vale a pena comentar é que não é porque um pr ele é pequeno que ele não tem impacto às vezes você tem um pr que é de uma, duas linhas e o impacto dele pode ser gigantesco então é só mais assim, mais fácil, mais difícil de revisar aí o que eu vou querer agora é o seguinte o panato foi lá e ele pega pega pra você dá uma sign pra você, aí revisa pra mim o meu pr por favor beleza então o panato foi lá, deu uma sign nele o bot foi lá e falou que o panato agora é o dono desse pr então aqui ele é o assinei e aí se ele estiver satisfeito com esse meu pr ele pode dar um barro LGTM e esse cara aqui vai ser mergiado ele pode só dar um barro LGTM porque no meu caso ele já tá aprovado porque eu tô no arquivo de Albers então vou deixar contigo aí ou ele pode pedir pra mudar alguma coisa também tá fazendo aí sim sim tá revisando tem uns revior que são chatos viu gente, o cara para, lê mesmo tipo o panato leio no meu pr deu deu tem um outro comando que a gente pode ir vai lá que pode ser rodado, que eu vou rodar aqui que é aprova ou cancel porque pode ser que eu não queira que seja aprovado de cara porque seja uma mudança muito grande e aí qualquer pessoa pode ir lá dar um luxo e entra no mar de direto tem um outro comando que a gente pode fazer aqui um hold que ele bota um label que vai bloquear, ninguém vai conseguir fazer merge no PR mesmo que ele seja com luxo gutumi e tudo mais eu vou dar o luxo gutumi aqui e Ricardo pode alquerar o o texto? é, o texto, só pra gente ver que vai ver o luxo gutumi e depois aqui porque teve uma quando se tem o luxo gutumi e tu faz uma mudança no código e puxa de volta o código pro puro request o luxo gutumi vai sair porque teve uma mudança então isso quer dizer que a pessoa que deu luxo gutumi deu praquela e comite específico mas se tu trocou o comite pra alguma outra coisa aquele luxo gutumi sai em porque necessita uma nova revisão pra evitar problemas de de ah, o cara botou um código malicioso lá e depois de ter sido aprovado estou colocando aqui, então obrigado pelo review chat dd menos a, kit comite menos m um thank you a kit puxa origin my first contribute baby ai na hora que eu mandar ele aqui o bot veio aqui e removeu o lgtm aqui porque ele detectou que eu fiz mudança no pr que nem o panado falou ele faz uma nova revisão agora tá todos o piar tá aprovado não to compartilhando o tempo o piar tá aprovado e aí foi aprovado por quem diz os usuários que foram aprovados ali o status check ele é para baixo um pouquinho ele não vai ser feito merge ele tá dizendo pending porque tem que tirar o hold isso quer dizer que tem aquele label de hold segura aí, não vai pra frente você pode tirar o hold posso hold cancel acho que unhold funciona também unhold também pronto agora o bot vai dar um outro peço no pur request esse pending do tide vai sumir e ele vai fazer um merge a gente espera aqui também de novo nossa ele demora um pouquinho porque aí vai passar a controle de novo ele fica na fila bom enquanto ele faz aqui, quer já lançar o desafio pessoal aí panato vamos lançar então beleza então para quem chegou até aqui tá a gente tem 10 convites do cubicon virtual para sortear um cubicon da europa guareciano isso isso então o que que eu queria que vocês fizessem para você ser elegível ao sorteio eu queria que vocês abrissem esse processo que eu fiz então faz um fork dentro desse contributor playground faz um pr com algum arquivo de texto com seu nome e sobrenome com o que vocês quiserem ou falando o que achou ou falando se apresentando ou só dando um olá o que vocês quiserem e aí a gente vai pegar todos os pr de todo mundo que mandou pr que foi feito aqui sozinho quem fez o merge foi o bot eu posso deletar a gente vai fazer um review não um review de faça isso, faça aquilo mas a gente vai vendo os pr que foram mandados e vai colocar em uma planilha para sorteio então todo mundo que mandar o pr vai estar participando e aí 10 pessoas porque foram os ingressos que a gente conseguiu com a CNSF também e a RQ que caíram lá no sorteio vão ganhar o código para o ingresso se alguém teve alguma dúvida até aqui se alguém não estiver conseguindo fazer eu vou dar uns 20 minutinhos então até há umas 50 para todo mundo mandar os pr e aí a gente já vai fazendo os reviews imediatos, os approved o panato se alguém tiver alguma dúvida vai perguntando aí aí umas 50 a gente encerra ver todo mundo que mandou, joga os rendlers lá na planilha dos pr que foram mergiados que tiveram o merge aceito e aí a gente faz esse sorteio encerra beleza eu vou fazer o seguinte eu estou vendo aqui, já tem esse monte de pr eu estou vendo aqui os de 7 minutos para cá eu vou fazer o seguinte, eu preciso agora dar uma pausa porque eu estou velho, preciso ir no banheiro mas vou mandando os pr e aí o panato a gente vai revisando então deixa eu dar um stop sharing aqui por enquanto e aí eu vou deixar compartilhado só a aba do review do meu review aqui mas aí eu acho que o panato também vai fazendo o review dele lá e aí eu vou lendo aqui o chat também, tirando dúvidas esse tipo de coisa, eu só preciso desses 3 minutinhos aqui, beleza eu também beleza, mas vamos fazendo aí povo se tiver alguma dúvida, só perguntarem também como é que a gente tá aí, vamos ver o chat dúvidas como é que Ricardo, como é que tu vai querer botar os na lista lá para fazer o sorteio como que eu vou querer, como assim eu vou, os que forem mergiados a gente bota depois no google sheets da vida ali ou usa algum aplicativo desses de online, o que você acha? eu tava procurando um aqui agora beleza deixa eu ir dando o review aqui enquanto isso vamos lá temos aqui, oi, temos 3 só? cadê pessoal? evite só o 3 até agora beleza, Bernardo Comentation, a gente dentro daquele negócio que a gente fala acho que o triagem não tá habilitado aqui nos sigs, ah tá sim mas quando a gente comentou eu posso entrar e só fazer a triagem de um maícho, né, então o que se espera é que por exemplo, alguém vem aqui depois e dê um barratria jackseptice falando, ah, aquele aquela ische foi aceita ou aquela ische tem problema aquela ische precisa de mais informações e por aí vai então vamos ver aqui beleza tem um que eu dei só a provo para te mudar o luxo GoTome para mostrar como é que funciona beleza, eu estou dando uma provo e um luxo GoTome em um aqui só para mostrar que eu consigo fazer isso com os dois também então esse aqui beleza, o bot aceitou vamos mudar para o próximo qual foi o que você mandou aqui esse My First PR aqui do Maurício beleza eu vi que tinha falhado esse PR aqui eu acho que o bot ficou louco o bot ficou doidão como o Maurício trabalha comigo eu tenho que olhar aqui para ver se ele tá me xingando tá, deixa eu ver aqui dá, beleza eu comentei em português tem um caso aqui interessante se tu for no próximo PR ali vamos lá, deixa eu ver se ele vai o LGBT vai pegar aqui no próximo PR, qual deles? o último ali do João esse aí o bot disse que não foi feito o CLN então tem que a gente pode dar o luxo GoTome o luxo GoTome, o aprovo mas ele não vai ser feito o money porque tá faltando a assinatura do CLN João, você tá aí, você consegue assinar o CLN manda no chat aí se você consegue assinar o CLN porque assim, a gente não consegue aprovar PR sem o CLN assinado, entendeu? mesmo que a gente queira mesmo que a gente tenha algum jeito de forçar não consegue ele não entra você deu a parte, vamos te mandar o link de novo aqui você pode seguir as instruções aqui que tem nesse link aqui e ele é bem simples bem tranquilo como a gente tem aí nossa, já são 1 e 47 vamos segurar até 1 e 55 eu botei o evento pra até as 3 então a gente consegue dar uma seguradinha tenta assinar o CLN isso aí é coisa de 1, 2 minutos assinei, checa de novo beleza deixa eu ver aqui como é que era da git pontukates tá aí hoje a CLN acho que tá dando o que que é isso aqui vamos ver ele tá batendo o isi selay também ah, o isi selay a gente consegue dar esquipa isso até é outra coisa pessoal, como o isi selay ele tá dando not covered o pessoal tá migrando o selay do modelo antigo pro novo só que vocês podem ver que assim o isi selay ele não tá com um negocinho de required aqui no lado então como ele tá aqui com o selay yes e o purporter aqui eu não sei quem que é, deixa eu ver o nome o window, como o window ele não assinou isso aqui e ainda assim a gente consegue aceitar agora acho que dia 8 de fevereiro o covernet só é mudar desse selay antigo pra esse selay novo aqui tá mas agora no momento a gente consegue aceitar o que a gente não consegue aceitar é um PR que não esteja com o selay antigo assinado isso aí então esses dois aqui esses dois 932 e 931 eles tem o selay assinado mas o novo não tá assinado então ele tá falhado por causa disso mas agora isso não é um problema aqui eu já atualizou acho que tá dando problema no selay mesmo ah tá, o window disse que assinou aqui beleza, ele já pegou lá perfeito vamos embora você vai fazer uns aí eu vou fazer no outros tem mais um selay como o new aqui pessoal esses daqui vocês precisam assinar e aí vai avisando tá a gente pode fazer assim também tem várias formas de aprovar então aqui já temos dois autorizados quem já for assinando aí dá um toque aqui a gente mostra como reverificar o selay tá também dá pra vocês conseguem fazer por conta própria aí tem um comando que é o cheque selay ele acha que é um comando deixa eu ver aqui opa, qual que é a tela que tá compartilhada dessa daqui né eu tava dando a prova ou na janela errada tá vendo vocês nem me falando nada pronto tá aqui ó, a janela acerta a gente tá dando a prova e junto nos códigos acho que deu aí aí que bacana o tide quando ele tem muito pr já passou, mas ele ia mostrar ali que tava, como é que fala? Cadê? estou abrindo pra ver o cheque show all checks aqui tem merge pool significa que ele tá na fila pra ser mergiado que ele não faz o merge imediatamente no caso do cumbernets por exemplo quando tem muitos prs ao mesmo tempo o que ele vai fazer? ele vai pegar, sei lá, 10 prs e vai tentar testar todos eles juntos ao mesmo tempo antes de fazer um merge como um todo aí eu não lembro qual que é a aleatoriedade disso, como funciona eu lembro que ele vai fazer um grupo de pool requests e cria um brante temporário e faz o merge desses todos nesse brante temporário e testa se todos passarem todos aqueles piadas vão ser um merge feito se um falhar ele vai retirando cada piada daquela lista e vai retestando até sobrar um único piada que passe aí ele faz o merge daquele li e aí pega um outro batch como estúdio novo complexo o Luiz se esquecinou e às vezes demora um tempo para o sistema se sincronizar então não é 100% real time ele tá aqui assim comit missing it hub user que acontece é o seguinte quando você vai fazer o seu comit você tem que botar o o user name e o e-mail então seria você teria que fazer, vou colocar aqui tem que configurar o git config config-user.email aí tem que dizer se é global ou local normalmente você está no global sim git config-dash-global dash-dash 7 acho que não não tem nada é só dash-dash-global ou dash-dash-local tira o 7 e aí é user.name e e o