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 batendo papo antes de ele ter que sair.
Ele me disse abertamente: os CFPs que havíamos enviado em 2024 não tinham sido bons.
Ele não estava sendo indelicado. Ele é um amigo, não apenas um organizador, e estava apenas me dizendo finalmente algo que eu já tinha passado um ano descobrindo sozinho.
Ser rejeitado já é um sinal, claro – uma pilha de nãos monta um cenário. Mas ouvir isso abertamente, de alguém que realmente lê essas propostas para viver, 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 final 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 chato
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 nomes a grupos.
A ideia por trás disso era simples: todo mundo tem uma mensagem para passar. Todo desenvolvedor já 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ão tínhamos estrutura alguma. 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 rejeitada. 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 que a qualidade. O objetivo era criar o hábito de enviar, não escrever propostas perfeitas. Fazer as coisas, e depois fazê-las do jeito certo.
Two different skills
No final de 2024, me tornei o DevRel da empresa (ainda part-time na época) e assumi o grupo. Uma em oito não era um número que eu pudesse continuar aceitando.
Então comecei a estudar. Não como dar palestras – mas como fazer com que fossem aceitas. Porque aqui está 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. O pessoal da Miners faz 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.
A CFP is a pitch, not a syllabus
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 grita a lista de ingredientes; eles gritam o que aquilo faz por você.
Agora olhe como os desenvolvedores escrevem CFPs. Vamos direto para as funcionalidades da palestra: "Vou abordar o modelo de ator, 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 usa para coletar propostas, tem um campo chamado literalmente "Pitch" – não "resumo," não "descrição." Pitch. Eles estão te 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 etapas, sempre nesta ordem.
1. Funcionalidades vs benefícios, 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 continua funcionando em 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 o público recebe. A maioria dos CFPs nunca sai da coluna da esquerda.
Nas primeiras vezes que você fizer isso, espere travar 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 surgirem, 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 se importaria
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 gestores 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 o público irá agradecer, então diga a eles exatamente com o que sairão de lá.
Pule qualquer um dos dois primeiros passos e esta 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: redigir a frase da "dor" de três formas diferentes, ajustar um parágrafo, 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.
Mas eu não entrego a ela a coluna de benefícios – pelo menos não na primeira passagem. Você tem que construir essa lista sozinho, recurso por recurso, porque o ato de construí-la é o que diz se existe mesmo uma palestra ali.
Se você deixar a IA preencher, ela preencherá. Ela sempre preencherá. A IA é ótima em gerar textos que parecem corretos, e ela lhe entregará uma coluna de benefícios plausíveis para uma palestra que não tem nada por baixo. Construir a lista à mão é a verificação: se você não consegue transformar seus recursos em benefícios nos quais você realmente acredita, você ainda não tem uma palestra – você tem um tópico.
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 marcada para 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ê descobrir 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.
Eis por que todas 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 submissões competindo por pouco mais de 100 vagas em 2024, uma taxa de aceitação de 6,6%. Seu comitê analisa as propostas três por vez, lado a lado, gastando cerca de 30 segundos por passagem.
Ninguém está lendo seu resumo detalhadamente. Eles o estão folheando da mesma forma que um participante folheia a programação, decidindo em segundos se continuam lendo ou passam adiante. 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 de frontend mais popular realmente funciona?
Nesta palestra, cobriremos 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 eu cobriria. Isso descreve uma palestra. Não a vende.
Aqui está a abertura do CFP que foi aceito na RubyConf 2026:
A concorrência no 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 que o Ruby estava tentando ser algo que não era.
O Ruby 4.0 mudou minha opinião.
Ele 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 definidos. Não há lista de ingredientes em lugar nenhum.
2025: o ciclo se fecha
Eu não dei nenhum workshop sobre isso no começo. Eu tentei 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 depois dessa aceitação, um de seus organizadores me disse que nossos CFPs antigos não tinham sido bons. A essa altura, eu já sabia. Eu tinha passado um ano reescrevendo a forma como eu 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 levou a palestra posteriormente 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 uma chama em mim. Enquanto assistia, me perguntei: eu conseguiria fazer isso funcionar em um app Hotwire Native? Depois da palestra, abri meu laptop 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 fomos aprovados: eu sobre Node.js DX, Talysson com duas palestras e João Vogler sobre resiliência de frontend. Resumimos tudo isso em nossa retrospectiva de 2025.
Cada aceitação 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 atentamente para o que estava diante de nós. Toda proposta aprovada é 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 da revisão de código: mais olhos em um rascunho antes do envio pegam o que uma pessoa sozinha deixaria passar. Uma pessoa estudando copywriting tornou-se 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 cada vez menor. 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 canalizados 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 caso isolado. A TDC aprovou oito de nossas palestras este ano em 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 podem ser corrigidas. 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 encaixa no ambiente. Uma proposta feita para a mistura de PMs e desenvolvedores da TDC pode fracassar em uma conferência que quer a parte técnica logo de cara, e o inverso também é verdade. Isso é responsabilidade nossa e é corrigível: reescreva a necessidade para o público ao qual você está realmente propondo, e a mesma palestra geralmente consegue entrar 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. Quando a Codeminer42 já tem 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 propostas por uma vaga que não existe.
E às vezes é apenas quem está pedindo. Algumas conferências dependem fortemente 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 é 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 significa 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, naquela conferência, foi onde ouvi a verdade sobre a nossa escrita. Este ano, ele foi direto comigo novamente – nossos CFPs estão bons agora. 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
