Como “Seus CFPs Não São Bons” Se Tornou Cinco Aprovações na RubyConf
Table of Contents
Em abril de 2025, a Tropical on Rails, a conferência de Rails em São Paulo, aceitou uma de nossas palestras pela primeira vez. Alguns meses depois, um de seus organizadores e eu acabamos conversando informalmente – nada oficial, apenas duas pessoas colocando o papo em dia antes de ele precisar ir.
Ele foi direto comigo: os CFPs que tínhamos enviado em 2024 não tinham sido bons.
Ele não estava sendo rude. Ele é um amigo, não apenas um organizador, e estava apenas me dizendo finalmente algo que eu já tinha passado um ano descobrindo por conta própria.
Ser rejeitado já é um sinal, claro – uma pilha de nãos pinta um quadro. Mas ouvir isso abertamente, de alguém que realmente lê essas propostas profissionalmente, bate diferente. É real e não deixa mais você refletindo. É objetivo.
Eu lidero um pequeno grupo na Codeminer42 focado em produção de conteúdo. Palestras são o fim desse pipeline – e os CFPs são o portão que você não atravessa sem escrever bem. Este é o guia que compartilho com o grupo para essa parte, e é a mesma coisa que eu diria a você.
Um grupo com um nome entediante
Em janeiro de 2024, começamos um grupo interno na Codeminer42 chamado producao-de-conteudo – "content production". Eu sei. Somos melhores em escrever software do que em dar nome a grupos.
A ideia por trás disso era simples: todo mundo tem uma mensagem para passar. Todo desenvolvedor passou por algo que vale a pena compartilhar – um bug que lhe ensinou humildade, um padrão que salvou um projeto. Conferências são um dos melhores meios para essas mensagens. O grupo existia para que pudéssemos apoiar uns aos outros no envio delas.
Nós não tínhamos estrutura nenhuma. Escolhemos algumas conferências de Ruby e JavaScript e começamos a nos candidatar. Acompanhávamos tudo em um repo Git compartilhado onde cada pessoa tinha uma pasta e jogava suas submissões – commit direto na main, sem merge, rebase sempre. O README prometia que "se todo mundo fizer certo, nunca haverá conflito". Bem-vindos ao trunk-based development.
Naquele ano, enviamos cerca de 40 propostas. A maioria foi recusada. Algumas foram aceitas: duas no TDC Floripa, uma na Nerdearla (a minha), Talysson na RailsConf 2024 em Detroit, e Sammy na RubyConf 2024 em Chicago.
Aproximadamente uma aceitação para cada oito propostas. Isso parece ruim, e era. Mas, no começo, o incentivo importava mais do que a qualidade. O objetivo era criar o hábito de enviar, não escrever propostas perfeitas. Fazer as coisas, depois fazê-las do jeito certo.
Duas habilidades diferentes
No final de 2024, me tornei o DevRel da empresa (ainda em tempo parcial na época) e assumi o grupo. Uma em oito não era um número que eu poderia continuar aceitando.
Então comecei a estudar. Não como dar palestras – mas como fazê-las ser aceitas. Porque eis a coisa que eu ainda não tinha entendido:
Escrever um bom CFP e dar uma boa palestra são duas habilidades diferentes.
Nós já sabíamos apresentar. Mineradores fazem brown bags e apresentações internas o tempo todo; colocar alguém na frente de um público nunca foi nosso gargalo. Mas nada dessa habilidade de palco aparece em um resumo de 300 palavras lido por um comitê que nunca viu você falar – e, em conferências como a RubyConf, nem sequer vê seu nome na primeira rodada.
Um CFP é uma proposta de ideia, não um programa de estudos
O material que mais me ajudou não era sobre conferências. Era sobre copywriting.
Copywriters sabem há um século que as pessoas não compram funcionalidades, elas compram benefícios. Ninguém em uma feira de rua grita a lista de ingredientes; eles gritam o que aquilo faz por você.
Agora veja como os desenvolvedores escrevem CFPs. Nós vamos direto para as funcionalidades da palestra: "Vou cobrir o modelo de atores, Erlang, Elixir e passagem de mensagens." Isso é uma lista de ingredientes. O comitê lê centenas dessas, e nenhuma delas responde à única pergunta que importa: por que o público se importaria?
Algumas conferências nem escondem isso. O Sessionize, a ferramenta que a maioria delas usa para coletar propostas, tem um campo literalmente chamado "Pitch" – não "resumo," não "descrição." Pitch. Eles estão dizendo abertamente para que serve o formulário.
O framework
Em fevereiro de 2025, transformei essa percepção em um processo real e o compartilhei com o grupo. Três passos, sempre nesta ordem.
1. Features vs benefits, lado a lado
Escreva duas colunas. Lado esquerdo, cada funcionalidade da palestra. Lado direito, force-se a responder: o que isso realmente faz pela pessoa que está assistindo? Você não tem permissão para deixar a coluna da direita vazia e dizer que o CFP está pronto.
Aqui está a tabela que montei para minha palestra de PWA:
| — | ||||
|---|---|---|---|---|
| Apenas Rails e um pouco de JavaScript | Você já tem todas as ferramentas de que precisa | |||
| Páginas com capacidade offline | O app ainda funciona com uma conexão ruim, ou sem conexão nenhuma | |||
| Notificações push | Você alcança o usuário novamente depois que ele fechou o app | |||
| Sem App Store, sem Play Store | Envie uma correção hoje, não depois de uma fila de revisão |
A coluna da esquerda é o que eu sei. A coluna da direita é o que a sala recebe. A maioria dos CFPs nunca sai da coluna da esquerda.
Nas primeiras vezes que fizer isso, espere ficar travado no lado direito. Isso é normal – discuta com outra pessoa do grupo. Dizer a funcionalidade em voz alta para outra pessoa geralmente é o suficiente para encontrar o benefício escondido por trás dela.
Mas se você discutir e os benefícios ainda não aparecerem, leve isso a sério. Não é o exercício falhando com você. É o exercício te dizendo a verdade: você ainda não tem uma palestra.
2. A necessidade: quem está na sala e por que eles se importariam
Uma lista de benefícios ainda assume que o público já quer o que você está vendendo. O trabalho real é nomear quem está naquela cadeira e o que os incomoda antes mesmo de ouvirem uma palavra da sua palestra.
Para a palestra de PWA, a necessidade era concreta: publicar na App Store da Apple é penoso, e a maioria dos desenvolvedores Rails não precisa de um app nativo – eles apenas ainda não sabem disso. Essa dor é o gancho. O tópico é apenas o mecanismo de entrega.
A sala muda a necessidade. O TDC no Brasil atrai PMs e gerentes junto com desenvolvedores, então a necessidade tem formato de negócio: entregar mais rápido, gastar menos com manutenção nativa. Em uma conferência apenas de Ruby, a necessidade é técnica: parar de comprometer a concorrência. Mesma tabela de benefícios, frase diferente sobre por que qualquer pessoa naquela sala específica deveria se importar.
3. Satisfazendo a necessidade
O último passo é escrever a frase que fecha o ciclo que você acabou de abrir. Não "você aprenderá sobre Ractors" – isso é cobertura. "Você escreverá Ruby concorrente sem medo de race conditions" responde à necessidade diretamente. Comitês escolhem palestras pelas quais seu público irá agradecê-los, então diga a eles exatamente com o que sairão de lá.
Pule qualquer um dos dois primeiros passos e essa frase desmorona. Você não pode satisfazer uma necessidade que nunca nomeou, e não pode transformar uma funcionalidade em um resultado que você ainda não traduziu em um benefício.
Onde a IA se encaixa
Eu a uso para a parte mecânica: transformar aquela coluna de funcionalidades em frases de benefícios candidatos, redigir a frase da dor de três formas diferentes, reduzir um resumo ao limite de caracteres que um campo de proposta impõe sem perder o ponto. Esse trabalho é real, e recusar-se a tocar nas ferramentas disponíveis para você é um tipo de arrogância.
Eu não a uso para nomear a necessidade real. Einar Høst, que faz parte do comitê de agenda do NDC Oslo, chamou as ferramentas de IA de máquinas de mediocridade: competentes, plausíveis, feitas para produzir a média do que já existe por aí. Um comitê que faz leituras rápidas torna-se muito bom em detectar a média, porque a média é o que eles leem quinhentas vezes seguidas.
Há uma frase que ele citou de Matthias Freis, que organiza o DDD Europe, que ficou gravada em mim:
Escrever é pensar. Se você terceiriza seu pensamento para uma máquina, não estou interessado em ouvir o que você tem a dizer.
Nomear a necessidade é você entender por que esta palestra, para este público, agora. Essa parte não se terceiriza. Pule isso, e isso transparece – não na gramática, na mediocridade.
Aqui está por que as três etapas importam mais do que parece. Um comitê não consegue ler com atenção. Høst trouxe números reais sobre isso: o NDC Oslo recebeu aproximadamente 1.700 propostas competindo por pouco mais de 100 vagas em 2024, uma taxa de aceitação de 6,6%. O comitê dele revisa as propostas três por vez, lado a lado, gastando cerca de 30 segundos por leitura.
Ninguém está lendo seu resumo atentamente. Eles estão folheando da mesma forma que um participante folheia a programação, decidindo em segundos se continuam lendo ou seguem em frente. Se a necessidade e o benefício não estiverem nas primeiras linhas, a tabela que você construiu nunca será lida.
Antes e depois
A diferença é mais fácil de mostrar do que de explicar. Aqui está a abertura de um CFP que enviei para o TDC em 2024:
Já se perguntou como a biblioteca frontend mais popular realmente funciona?
Nesta palestra, abordaremos os internos do React e, acredite ou não, entraremos nos conceitos mais básicos de programação funcional.
Uma pergunta retórica, depois uma lista do que seria abordado. Isso descreve uma palestra. Não tenta vendê-la.
Aqui está a abertura do CFP que foi aceito na RubyConf 2026:
A concorrência em Ruby sempre foi um compromisso. Threads são propensas a erros. Fibers são complexas. O GVL limita o paralelismo real. Aceitamos que o Ruby concorrente é difícil.
Eu vim do Erlang e do Elixir, onde a concorrência é o padrão. […] Quando o Ruby introduziu Ractors no 3.0, eu estava cético. A API era desajeitada. As limitações eram severas. Parecia o Ruby tentando ser algo que não era.
O Ruby 4.0 mudou minha opinião.
Começa com uma dor que todo Rubyista conhece, assume uma posição pessoal e deixa você querendo descobrir o que mudou minha opinião. Depois, cinco resultados concretos e um esboço com tempos. Não há lista de ingredientes em lugar nenhum.
2025: o ciclo se fecha
Eu não ministrei um workshop sobre nada disso a princípio. Testei nos meus próprios CFPs, porque conselhos que você não testou você mesmo são apenas opiniões.
2025 foi o ano em que começou a funcionar. Fui aceito no Tropical on Rails em São Paulo – minha primeira grande conferência. É também a conversa com a qual abri este post: alguns meses após aquela aceitação, um de seus organizadores me disse que nossos CFPs antigos não tinham sido bons. Naquela altura, eu já sabia. Eu tinha passado um ano reescrevendo a forma como os escrevia. O comentário dele não era mais um aviso. Era uma confirmação.
A palestra que me colocou lá foi a proposta de PWA que mostrei acima. Essa mesma proposta depois levou a palestra para a RailsConf 2025 na Filadélfia, a última RailsConf de todas.
E a palestra cumpriu a promessa que o CFP fez. Joe Masilotti, o criador do Hotwire Native, estava na sala:
A palestra do Edy Silva acendeu algo em mim. Enquanto assistia, me perguntei: eu conseguiria fazer isso funcionar em um app Hotwire Native? Depois da palestra, abri meu notebook e, duas horas depois, tinha o acesso offline funcionando nativamente.
Então deixou de ser apenas a minha técnica. Talysson subiu ao palco no Rails World com o "Problema XY" na era da IA, e espalhou DDD por três países – Nerdearla na Argentina, Explore DDD nos EUA e DDD Brasil. No TDC, três de nós foram aprovados: eu sobre Node.js DX, Talysson com duas palestras e João Vogler sobre resiliência de frontend. Encerramos tudo isso em nossa revisão do ano de 2025.
Cada aceite fez algo que o estudo sozinho não conseguia: aumentou a confiança de todo o grupo. Estávamos compartilhando CFPs desde o início – o repo do git garantia isso – mas agora havia um motivo para olhar de perto o que estava diante de nós. Cada proposta bem-sucedida é discutida, analisada detalhadamente e transformada em uma lição para a próxima; revisamos os rascunhos uns dos outros antes de serem enviados. É o mesmo princípio do code review: mais olhos em um rascunho antes do envio pegam o que uma pessoa sozinha deixaria passar. Uma pessoa estudando copywriting se tornou um grupo que escreve propostas juntos.
Essa é a parte que eu roubaria se fosse você. Não os livros de copywriting – o ritual.
RubyConf 2026
No final de 2025, enviamos nossas propostas em uma janela que estava diminuindo. A RubyConf 2026 é a primeira RubyConf em 20 meses e, com a aposentadoria da RailsConf, é agora o único evento principal da Ruby Central – todos que teriam enviado para qualquer uma das conferências foram funilados para um único CFP. A programação encolheu para cerca de 30 sessões, contra 70 em 2024, diante de centenas de submissões. A primeira rodada de revisão é anônima: apenas título e resumo, sem nomes, sem empresa. Não tínhamos ninguém no comitê de programação.
Quatro Miners entraram direto: Gabriel Quaresma sobre por que um algoritmo de machine learning dos anos 1990 destrói LLMs na previsão de preços de casas, Miguel Marcondes com um workshop prático construindo um motor de jogo de IA com Ruby e algoritmos genéticos, Antônio Paulino sobre tribologia – a física do atrito – aplicada a sistemas Rails, e eu sobre Ractors no Ruby 4.0. Uma quinta proposta ficou na lista de espera, e a chamada chegou.
Cinco aprovações. Mais do que qualquer outra empresa conseguiu, passando por um filtro anônimo, na RubyConf mais competitiva em anos.
Nem todos conseguirão ir para Las Vegas – a vida interfere nas agendas de conferências. Mas este post é sobre a escrita, e a escrita cumpriu seu papel.
A RubyConf também não é um pico isolado. O TDC aprovou oito de nossas palestras este ano com quatro Miners. Também conseguimos mais vagas no Node Congress, incluindo um palestrante de primeira viagem liderando um workshop.
Nem todo CFP serve para toda palestra
Quero ser honesto sobre algo: não esperamos uma taxa de aceitação de 100%, e nunca esperaremos. Algumas rejeições são culpa nossa e corrigíveis. A maioria delas não tem nada a ver com a escrita – têm a ver com a forma como as conferências são organizadas.
Às vezes, a proposta simplesmente não se ajusta ao ambiente. Uma proposta feita para a mistura de PMs e desenvolvedores do TDC pode fracassar em uma conferência que quer a parte técnica logo de cara, e o inverso é igualmente verdadeiro. Esta parte é conosco, e é corrigível: reescreva a necessidade para o ambiente para o qual você está realmente propondo, e a mesma palestra frequentemente entra em outro lugar.
Às vezes é uma cota, não a proposta. A maioria das conferências limita quantas palestras aceitará de uma única empresa, não importa quão boa seja a escrita. Uma vez que a Codeminer42 já tenha duas ou três vagas em um evento, um quarto CFP forte nosso não está mais competindo com o resto do mundo. Está competindo com nossas próprias outras propostas por um assento que não existe.
E às vezes depende apenas de quem está perguntando. Algumas conferências dependem muito de palestrantes convidados ou conhecidos e aceitam pouquíssimos nomes da chamada aberta, não importa o que a proposta diga. Um comitê preenchendo a programação sob um prazo busca nomes em que já confia. Uma boa escrita faz você entrar na pilha que será lida. Ela não garante a vaga depois que você chega lá.
Temos sinais agora de que nossos CFPs são bons. Isso não significa que cada um deles pertença a cada conferência, ou que cada conferência tenha espaço para eles.
O que é parte do motivo pelo qual o número que mais importa para mim não é o da RubyConf. No final de 2025, também enviamos propostas para o Tropical on Rails 2026 – a mesma conferência, o mesmo amigo que certa vez me disse que nossos CFPs não eram bons. Duas aprovações e uma lista de espera.
Dois anos atrás, aquela conferência foi onde ouvi a verdade sobre nossa escrita. Este ano, ele me disse a real novamente – nossos CFPs agora são bons. Mesmo cara, mesma franqueza, veredito oposto.
Se você estiver na RubyConf, venha dar um oi.
Obrigado por ler!
We want to work with you. Check out our Services page!
Share
Edy Silva Let's build a scalable frontend that grows with your business.
Contact Us
