O dia começa com as pessoas se apresentando: "Eu sou Fulana, faço X coisa e participo de Y grupo/empresa/etc e estou interessado em aprender Z". A idéia é conseguir imaginar como o interesse se relaciona aos interesses sociais e profissionais da participante. As tutoras se apresentam no mesmo formato.
Pro: Todo mundo fala, todo mundo percebe que pode falar. Con: Demora muito. As atrasadas perdem a apresentação das primeiras.
Em seguida as afinidades técnicas se aproximam. Por exemplo, as que querem produzir scrapers, ou as que querem se iniciar em sistemas Web. É no contexto menor desses grupos que se constróem as propostas de projeto.
Essa é a parte mais difícil, na minha opinião. É difícil imaginar projetos sem experiência prévia na área. É comum ouvir "Quero fazer um aplicativo", como quem diz "Quero fazer um filme", mas sem conseguir imaginar sobre o quê. Eu costumo dar exemplos e torço pra que as participantes consigam abstrair o modelo e aplicar pra algo do interesse delas. É comum ouvir idéias geniais das participantes conforme elas vão compreendendo o que é possível de fazer.
Como toda atividade hacker, não existe votação. Desde que existam interessados em tocar o projeto, e um MVP possa ser executado no tempo da rodada, todos os projetos serão executados. Eu costumo agrupar pelo modelo, pois é comum ter projetos idênticos sobre assuntos diversos: "scraper de notícias de violência contra a mulher" e "scraper de notícias sobre hackers".
Os grupos de interesse já são pequenos (5~8), mas os grupos por modelo costumam ser menores. Grupos de uma pessoa só costumam andar bem devagar, porque as participantes se ajudam muito. É importante ter uma segundo tutora pro grupo, porque atenção é exatamente a expectativa das participantes, é o que as traz ao evento e é, provavelmente, o que nós temos de melhor pra oferecer. Caso a atenção seja dividida entre os projetos, é fundamental encontrar os pedaços em que se pode aprender junto, incentivar a polinização cruzada (idéias/técnicas de um projeto afetando/transformando o outro) e principalmente não deixar a participante se desanimar.
Em geral, eu proponho o próximo passo do desenvolvimento e nós aprendemos a tecnologia na medida que for suficiente pra poder realizar esse passo, algo que eu também associo ao "modo hacker de fazer as coisas". Perguntas sempre aparecem, mas elas surgem no contexto daquele passo do projeto, evitando explicações sobre algo que não vai ser utilizado naquele momento (mas pode ser estudado depois, na vida). O evento tem 12 horas, mas são SÓ 12 horas.
É importante publicar sempre. Isso motiva muito as participantes, e serve como documentação constante. Mas documentação especificamente falando é sempre bom, se alguma coisa leva tempo pra se acertar é importante levar um pouco mais de tempo pra se documentar também. As participantes são plenamente capazes de documentar seus desafios em uma linguagem que elas mesmas entendam — eu preciso aproveitar isso com maior atenção nas próximas rodadas.
Não costuma haver um encerramento. As horas acabam, o cérebro frita e, principalmente, a comida acaba. Comer é sempre um desvio breve, acontece em paralelo, não costuma ter "a pausa pro almoço" porque em geral ninguém quer parar. É importante, pro fim do dia, todos terem condição de rodar o projeto em suas máquinas ou em algum serviço acessível pela internet. A idéia é que as participantes possam mostrar seus resultados, seja para o público geral ou só pra um círculo mais íntimo de amigas. Esse orgulho/reconhecimento do que se é capaz é com certeza uma das metas da Rodada.
Depois que as participantes vão embora, as tutoras bebem/comem juntas, imediatamente. Isso é parte da Rodada, é nosso momento de feedback e é uma espécie de recompensa para as tutoras (cerveja, comida boa e mais trabalho). Seria legal se as tutoras documentassem suas experiências, mas programadoras que gostem de documentar são a raridade da raridade. Mas quem tem ânimo documenta (não na hora, eu estou documentando meses depois) e mostra pras outras pra dar aquela animada.
Não existe estrutura pro beber/comer/feedback. Depois de mais de 12 horas de tutoria e hackerismo, o assunto só pode ser esse mesmo. É só deixar rolar e perceber o que pode ser melhorado nas próximas.
*[MVP]: Minimal Viable Project