Report mensal: Janeiro/2026 | Associação Python Brasil

[rougeth]

Olá pessoal, criando um tópico para comentários do novo texto no blog da APyB: https://blog.python.org.br/report-janeiro-2026.html

Sugestão para @apyb/diretoria: seria interessante vocês criarem um tópico aqui no /comunidade para cada texto no blog, e linkar esse tópico lá no texto, para que as pessoas possam comentar.

[rennerocha]

O marmite permite integrar com o Github Discussions usando o Giscus. As instruções estão na documentação do marmite e aparentemente não é complicado de se disponibilizar. Acho que ficaria até automático o processo. Se depender de criar o tópico aqui manualmente, com certeza em algum momento isso vai ser esquecido.

[tiidadavena]

Se for para criar o tópico com a issue para investigar o Giscus, seria abrir uma issue no repo do blog.

[rougeth]

Existe uma premissa que se comprovou ano após ano, gestão após gestão: a responsabilidade de manter e operar serviços hospedados pela APyB recai sobre uma única pessoa, geralmente quem ocupa o cargo de diretor(a) de tecnologia. Isso traz uma série de riscos que, na minha opinião, a APyB não está preparada para assumir.

Risco operacional

Um serviço crítico operado por uma única pessoa gera um ponto único de falha. Qualquer indisponibilidade do diretor(a) de tecnologia - férias, doença, sobrecarga, imprevistos pessoais — se traduz diretamente em risco para o serviço.

Risco de continuidade

A APyB tem uma rotatividade natural na gestão da APyB. O que significa que a próxima gestão pode não ter alguém com o mesmo perfil técnico ou disponibilidade, criando um risco em ter que manter algo que não se entende.

Dados pessoais

Uma plataforma de ingressos inevitavelmente armazena dados pessoais dos participantes: nomes, emails, histórico de participação e possivelmente dados sensíveis. Ao hospedar esse tipo de serviço, a APyB assume responsabilidade legal sobre esses dados. Isso implica obrigações de segurança, resposta a incidentes, retenção e exclusão de dados, etc.

Assimetria entre risco assumido e valor entregue

Hospedar serviços online não é trivial, e é comum que diversos riscos e custos sejam ignorados, como os citados acima. Eu vejo a relação risco × benefício nesse caso de forma desfavorável para a APyB, especialmente considerando que existem alternativas que transferem esses riscos para empresas cujo negócio principal é operar esses serviços.

[rougeth]

Primeiro, porque precisamos pensar no longo prazo institucional.

Esse é meu principal foco, eu não tenho dúvidas que vocês consigam fazer um trabalho legal agora.

O fato de gestões anteriores terem sido pouco ativas e confiáveis não pode nos condenar a aceitar o mínimo como padrão.

Eu não estou nem levando para esse lado, gestões pouco ativas e confiáveis. A minha experiência como parte da direção e conselhos é de que a demanda é sempre maior do que esperamos e o tempo curto para coisas novas.

Uma associação de tecnologia não pode achar aceitável eleger uma gestão sem capacidade mínima de manter serviços operando e, como já foi dito, o pretalx está rodando há anos sem intercorrências.

Aqui é a minha vez de discordar. A missão da APyB não é operar infraestrutura online, hospedar serviços, etc. E conhecimento para essas atividades são muito especificas. Uma pessoa que assume a diretoria de tecnologia consegue fazer o seu papel plenamente sem escrever nenhuma linha de código, sem nunca ter colocar um site online, ou sem mesmo trabalhar na área de tecnologia. O nosso estatuto permite isso. Se for para pensar no longo prazo, é preciso pensar em quem virá depois da gestão atual.

Art. 21º - Compete ao Diretor de Tecnologia administrar, executar e coordenar as atividades relacionadas aos recursos tecnológicos necessários para dar suporte às atividades da Associação Python Brasil;

https://github.com/apyb/estatuto?tab=readme-ov-file#cap%C3%ADtulo-v---da-diretoria

Enquanto organizadora de evento, penso que podemos e devemos solicitar soluções para que a APyB deixe de ser sinônimo de uso do CNPJ em troca de 10%.

Talvez a APyB poderia melhorar a comunicação com a comunidade e demonstrar o que significa o "CNPJ em troca de 10%", porque pode parecer pouco, mas eu achei difícil quando eu estava do outro lado 😅 .

[belisarenata]

O fato de gestões anteriores terem sido pouco ativas e confiáveis não pode nos condenar a aceitar o mínimo como padrão.

Antes de seguir, quero esclarecer esse ponto. Não acho, nem por um segundo, que alguém que tenha passado pela APyB tenha agido com má-fé ou falta de capacidade. Apesar de eu estar sendo crítica às gestões anteriores, entendo que tudo isso é trabalho voluntário e que existe um limite real para o quanto cada pessoa pode contribuir e esse limite pode mudar entre o início e o fim de uma gestão.

De verdade, acredito que quem assume esse tipo de dor de cabeça voluntariamente o faz com o bem da comunidade em mente. Pesei a mão na frase, e ela não reflete o que penso sobre as gestões como um todo; peço desculpas.

Também quero deixar claro que não enxergo a APyB como um CNPJ que cobra 10% de forma alguma, acredito que ela é essencial para a manutenção da comunidade vibrante que temos hoje (senão eu não tava nem nessa thread ahhaha). Mas infelizmente tem quem veja e eu entendo a origem do pensamento, apesar de não concordar.

[belisarenata]

Art. 21º - Compete ao Diretor de Tecnologia administrar, executar e coordenar as atividades relacionadas aos recursos tecnológicos necessários para dar suporte às atividades da Associação Python Brasil;

Entendo que o pretix se enquadra em “recursos tecnológicos necessários para dar suporte às atividades da Associação Python Brasil”, já que uma das principais finalidades da associação é a organização de eventos. Ainda que ele não seja estritamente necessário, o pretalx também não é mas faz uma diferença enorme na vida de quem organiza. Concordo que o Diretor ou Diretora de Tecnologia não precisa codar para ter feito um bom trabalho, mas acredito que essa pessoa precisa, sim, ser capaz de gerenciar essa infraestrutura, seja diretamente, seja articulando apoio da comunidade e de organizações parceiras.

Como coloquei anteriormente, acredito que o pretix é estratégico para a APyB, e também reconheço que não é impossível que ele venha a ser descontinuado no futuro. Não acho, porém, que isso justifique não tentarmos. Podemos formalizar um GT para o pretix, que garanta tanto o funcionamento adequado quanto, se necessário, um desligamento responsável ao final do ano, caso o projeto se mostre insustentável.

[rougeth]

Também quero deixar claro que não enxergo a APyB como um CNPJ que cobra 10% de forma alguma, acredito que ela é essencial para a manutenção da comunidade vibrante que temos hoje (senão não tava nem nessa thread ahhaha)

<3

seja articulando apoio da comunidade e de organizações parceiras.

Na minha opinião esse é o modelo ideal para qualquer iniciativa da APyB que vá além da parte financeira/cnpj.

Não acho, porém, que isso justifique não tentarmos. Podemos formalizar um GT para o pretix, que garanta tanto o funcionamento adequado quanto, se necessário, um desligamento responsável ao final do ano, caso o projeto se mostre insustentável.

Acho que nem pensamos tão diferente @belisarenata. Não sou contra nenhum teste ou experimento, minha maior preocupação é o acúmulo de tarefas para a diretoria. No caso do Pretalx, até onde eu sei, o Renan que está responsável por liderar e manter o projeto (mas não tenho certeza, não encontrei nada documentado além da proposta inicial do projeto). Teremos alguém liderando o Pretix que não seja o @zsinx6?

[naanadr]

Oi pessoal, brotando aqui 🪴 para esclarecer alguns pontos sobre o Pretalx, porque foi falado muito dele como sendo responsabilidade da diretoria de tecnologia, mas não foi isso que aconteceu.

Como foi discutido no GT, e também entre todas as pessoas que estavam envolvidas na época, a APyB entrou e sempre foi um apoio e nunca foi a responsável principal. Porque naquele momento, eu, como então Diretora de Tecnologia, e o resto da diretoria, vimos que a energia necessária para manter a base do funcionamento da APyB em pé não permitia abraçar um projeto tão grande quanto hospedar e dar manutenção a uma instância do Pretalx.

O problema não era falta de conhecimento, mas sim que era muita responsabilidade para uma única pessoa (Diretoria de Tecnologia), e o GT já estava com um estudo avançado sobre a ferramenta e eram mais pessoas envolvidas. Imagina que caos seria ter todo o sistema dependente de uma única pessoa e algo acontecer com ela, enquanto o sistema estava sendo utilizado por 5 eventos ao mesmo tempo? Por isso, sempre estive disponível para auxiliar o pessoal com o reembolso dos custos de infraestrutura e outros pontos que foram aparecendo em que a APyB poderia auxiliar.

O fato de gestões anteriores terem sido pouco ativas e confiáveis não pode nos condenar a aceitar o mínimo como padrão.

Aproveitando essa colocação, para deixar claro que se no parágrafo anterior falei que "manter a base do funcionamento da APyB em pé não permitia abraçar um projeto tão grande", quis dizer que cada pessoa precisa saber o que ela consegue entregar durante um trabalho totalmente voluntário, e o que ela não consegue, para assim não deixar ninguém na mão.

Por isso, durante todo o período em que estive na diretoria, eu sempre prezei em saber qual era o meu limite como pessoa com deficiência, e precisando sustentar uma casa. Dessa forma, vejo que nunca abandonei quem esteve precisando da DT e, durante esses dois últimos anos, sempre fui transparente e fiz entregas visando desafogar cada vez mais as pessoas.

Sei que @belisarenata já se desculpou pela péssima colocação. Mas, para deixar claro, não generalize a péssima experiência que você teve com uma única pessoa durante um período, como se tivesse sido o comportamento dela durante toda a gestão e como se fosse o comportamento de todo mundo da diretoria 🤗 .

[tiidadavena]

Olá pessoal, criando um tópico para comentários do novo texto no blog da APyB: https://blog.python.org.br/report-janeiro-2026.html

Sugestão para @apyb/diretoria: seria interessante vocês criarem um tópico aqui no /comunidade para cada texto no blog, e linkar esse tópico lá no texto, para que as pessoas possam comentar.

Exatamente! O canal oficial de comunicação da Diretoria com a comunidade é no Github Discussions. Ainda não ficou claro para mim a real necessidade por um blog próprio: SEO? Encontrar conteúdos indexados? Acessibilidade?

Apesar da infra ser da Diretoria de Tecnologia, a pessoa Diretora de Comunicação tem que realizar curadoria, pesquisa, redação e revisão do conteúdo: e acho que o problema não seria a carga em si, mas a real demanda da audiênci i.e., a comunidade.

[rennerocha]

Inclusive é possível continuar usando o Github Discussions, como comentei a pouco.

[belisarenata]

Concordo plenamente, Renne. Estamos indo no mesmo caminho na python brasil 2026, para retirar a dependência de redes sociais proprietárias nas nossas divulgações. Penso em trazer algo como rss, pra galera poder escolher como vai receber as comunicações, mas ainda não conseguimos dar vazão pra essas ideias. Acho excelente a APyB ter trazido blog de volta.

[tiidadavena]

Concordo 1000% com feed do RSS para o blog! E dá mais uma razão de existir para ele: acho que transferir as seções dos premiados DTJF, história da associação e uma seção de eventos apoiados, bem como o CdC e o Fundo para Inclusão possam ajudar a agregar mais valor (além do relativo baixo custo operacional pois os conteúdos já existem e já estão em formato Markdown.

[tiidadavena]

Eu acho que a existência de um blog com a comunicação oficial da APyB uma iniciativa excelente. Apesar das discussões se manterem no Github Discussions (como as que estão ocorrendo aqui), ter um canal oficial com controle total da Associação um passo importante e sinalização política sobre importância da soberania e controle dos nossos dados.

Não parece adequado dependermos do Github para dar publicidade às ações da APyB (apesar de podermos continuar utilizando ele), sendo que manter um blog estático não é mais um desafio técnico.

Não sei se o termo foi discutido no momento da criação do blog, mas se enquadra bem na filosofia de POSSE (Post (on) Own Site Syndicate Elsewhere). Nada impede que as publicações sejam postadas automaticamente no Github, Mastodon, Linkedin ou outras plataformas, mas a fonte original da informação é de controle total da APyB.

Sim, a ideia das redes sociais é ser proxy de informação e acelerar a entrega de conteúdo - o Discussions seria a "fonte da verdade" i.e. a pessoa dir. de Comunicação posta primeiro lá e depois replica nas outras redes.

[tiidadavena]

Concordo plenamente, Renne. Estamos indo no mesmo caminho na python brasil 2026, para retirar a dependência de redes sociais proprietárias nas nossas divulgações. Penso em trazer algo como rss, pra galera poder escolher como vai receber as comunicações, mas ainda não conseguimos dar vazão pra essas ideias. Acho excelente a APyB ter trazido blog de volta.

Acho que triggando o RSS a partir da criação da issue seria 10/10 - não sei se é factível

[julianaklulo]

Agradecemos por todos os pontos levantados. Reconhecemos que na comunicação inicial focamos na entrega técnica e faltou transparência sobre a gestão de riscos com os associados, dado que o levantamento foi feito em conjunto com os Kahunas.

Toda essa discussão sobre os riscos legais e a responsabilidade de manter dados sensíveis é muito importante, portanto gostaríamos de detalhar a nossa estratégia, cobrindo a soberania, a segurança jurídica (LGPD) e, principalmente, esclarecer os riscos reais comparando o cenário atual com o uso de terceiros.

O Blog

A criação do blog não implica que iremos aposentar o Discussions. Aqui continua sendo o canal de comunicação da comunidade e ele sempre estará aberto a todos.

A decisão de manter o blog e infraestrutura próprios é uma questão de soberania. Redes sociais e plataformas como o GitHub são excelentes canais de distribuição, mas não podem ser os detentores primários da nossa história.
Precisamos defender o blog como o solo da própria APyB.

Regras de plataformas mudam, algoritmos limitam alcance e serviços deixam de existir. Ter nosso conteúdo centralizado garante que a APyB não fique refém de terceiros.

Além disso, a proposta do blog é ter um registro da trajetória da Diretoria em um local publicamente acessível e curado por nós, sem dependência de plataformas externas e redes sociais, e que seja de fácil divulgação.

Problemas com as plataformas de ingresso pagas

Entende-se que contratar o Eventbrite/Sympla terceiriza o risco legal, porém isso não é verdade perante a LGPD.
É importante explicitar os riscos jurídicos reais de usar uma plataforma externa:

• Responsabilidade Solidária: Pela lei, a APyB é a Controladora dos dados (quem decide a finalidade) e a plataforma é a Operadora. Se a plataforma vazar dados, a APyB responde solidariamente. O associado vai processar a APyB, não a plataforma gringa. Nós teríamos que pagar a indenização e depois gastar anos e fortuna com advogados tentando uma ação de regresso contra a plataforma.
• Falta de Auditoria: Em plataformas proprietárias, não sabemos como os dados são tratados, quem acessou, ou se foram vendidos para terceiros (marketing, treinamento de LLM, etc). Se houver um vazamento lá, ficamos sabendo pela imprensa, sem capacidade de resposta imediata.
• Contratos de Adesão: Ao usar terceiros, ficamos reféns dos termos deles. Se eles decidirem usar os dados dos nossos participantes para treinar IA ou vender mailing, muitas vezes não temos como impedir sem parar de usar o serviço.

No modelo Self-Hosted, nós trazemos o risco para dentro de casa, mas ganhamos o poder de mitigação, que é impossível ter fora.

pretix: por que estamos assumindo o risco?

Além da soberania, há a eficiência. Plataformas terceiras cobram taxas de 6% a 10% por ingresso. Em eventos do tamanho da Python Brasil e regionais, isso é muito dinheiro da comunidade indo para aluguel de software.

Ao assumirmos a infraestrutura (que custa uma fração disso na AWS), esse dinheiro fica na comunidade. Ele vira coffee-break melhor, fundo de inclusão e infraestrutura para os eventos menores.

O risco existe? Sim. Mas decidimos gerenciá-lo com responsabilidade para maximizar o retorno para a comunidade. O pretix é uma ferramenta bem consolidada, com constantes atualizações de segurança e com quase 10 anos de existência.

Fizemos um benchmark, em conjunto com os Kahunas de 2026, onde avaliamos as plataformas Event3, Sympla e pretix, e a decisão pelo pretix foi tomada em conjunto.

Automação e auditoria

Para garantir a segurança jurídica e técnica, contaremos com processos automatizados:

• Ciclo de vida automático: Scripts automáticos farão a anonimização dos dados pessoais (exclusão de dados de identificação) X dias após o evento. Por exemplo, se formos auditados alguns meses após o evento, o banco estará limpo de dados sensíveis. Isso reduz drasticamente nosso passivo jurídico.
• Logs de auditoria: Estamos implementando logs persistentes. Diferente de uma plataforma externa, aqui sabemos exatamente quem, quando e o que foi acessado. Isso é vital para defesa em caso de incidentes.
• Termos de uso: Ninguém comprará ingresso sem um aceite explícito. Teremos um Termo de Uso onde o participante concorda com nossa política de processamento, protegendo a APyB ao alinhar a expectativa do usuário com nossa operação de exclusão de dados.

Sustentabilidade e documentação

O objetivo é que a próxima gestão não precise ser especialista em segurança para manter isso rodando.

Infraestrutura:

• Docker em EC2 + RDS (banco gerenciado)
• Updates de segurança e backups são automáticos.
• Legado: Toda a arquitetura está sendo documentada passo a passo. Estamos criando uma documentação operacional para que a manutenção seja simples posteriormente.

Próximos passos

Acatando a sugestão do debate, vamos formalizar esses pontos relativos ao pretix em um outro tópico do Discussions em breve, para dar tranquilidade e transparência aos associados.

[julianaklulo]

Renomeei essa discussão para que ela fique linkada com o post de Janeiro.

Seguindo a sugestão do @rennerocha, integrei os comentários com o Giscus.