Modelo de avaliação das atividades da Python Brasil

Depois de participar de algumas edições da Python Brasil como membro da organização, a mentalidade DRY (Don’t Repeat Yourself), reforçada por anos de programação, realça algumas tarefas recorrentes que geram muito trabalho e que poderiam ser, de alguma forma, melhoradas ou até mesmo automatizadas.

Na minha opinião, o que mais dá trabalho durante a organização do evento são as atividades relacionadas a escolha das atividades que serão apresentadas.

No final de 2019, após diversas conversas com pessoas experientes em organização de eventos, escrevi em conjunto com a Ana Dulce e com Gabriel Ferreira, um modelo de avaliação de atividades.

Esse texto tem como objetivo documentar e descrever uma alternativa de avaliação de palestras e atividades para quem organiza eventos de forma voluntária e, os resultados da primeira experiência, já na Python Brasil 2020, ficarão para um próximo texto.

Os problemas na escolha das atividades das últimas edições da Python Brasil

Escolher as atividades a serem apresentadas no evento, sejam elas palestras ou tutoriais, sempre foi uma tarefa muito custosa para a organização. Ele envolve desde a escolha da ferramenta que será utilizada para as submissões, e sua respectiva configuração, ao contato direto com palestrantes e toda a gerência de horários disponíveis para finalmente alocar todas essas pessoas na grade do evento, passando pelo tema deste texto, que é a avaliação das atividades submetidas.

Em discussões internas da comissão organizadora, chegou-se à conclusão de que submissões abertas, cuja avaliação era o voto público, levavam as poucas mesmas pessoas, muito conhecidas na comunidade, aos palcos da Python Brasil, por isso, de 2019 a 2021, foi desconsiderada essa opção. O objetivo era que houvesse mais renovação entre palestrantes e que mais pessoas tivessem a oportunidade de apresentar conteúdos na Python Brasil, e uma avaliação aberta não satisfazia essas condições.

A mudança na metodologia de avaliação para uma onde as avaliações fossem anônimas mostrou-se útil em relação ao objetivo de renovação, pois muitas pessoas novas chegaram à Python Brasil, contudo ainda não satisfazia uma crítica que aparece com certa frequência, em relação a qualidade das atividades apresentadas durante o evento. Por mais que essa crítica seja subjetiva, a ausência de feedbacks para quem submeteu atividades e de um processo oficial de mentoria pré e pós-submissão, não dá oportunidade para que as propostas e futuras apresentações sejam evoluídas.

Outro ponto complicado ao se tratar da Python Brasil é que, visto que cada time organizando o evento tem liberdade para idealizar o evento a seu modo, há um imenso retrabalho em todas as edições dos eventos para definir as regras de avaliação e escolher tais atividades, pois nem sempre os conhecimentos são transmitidos entre os anos, e frequentemente essa Organização comete erros conhecidos por times anteriores por falta de documentação.

Levando em consideração os problemas acima, o modelo proposto tem como objetivos:

• Criar um modelo de seleção de atividades que possa ser reusado nas edições da Python Brasil, diminuindo o retrabalho a cada ano entre os times da organização;
• Escalar o processo de revisão, já que a quantidade de submissões aumenta a cada edição, e isso onera muito o tempo dos voluntários da organização;
• Tornar o processo mais objetivo, menos sujeito a falhas e com possibilidade de evolução;
• Engajar a comunidade na seleção dos trabalhos a serem apresentados;
• Melhorar a qualidade dos trabalhos apresentados na conferência;
• Dar feedback para as pessoas que submeteram atividades.

Antes de começar

O objetivo desse modelo não é ser a única forma de avaliação e escolha das atividades, podendo ser combinado com outras etapas de avaliação. A organização poderia, por exemplo, definir uma quantidade mínima de palestrantes que nunca se apresentaram na Python Brasil que, combinado com o resultado das avaliações, seriam selecionados para palestrar no evento. Táticas parecidas poderiam ser usadas, por exemplo, para garantir maior diversidade de palestrantes no evento.

O Modelo

O modelo proposto pode ser resumido em uma regra: para cada submissão de palestra, a pessoa deverá avaliar três outras submissões. Em mais detalhes, o fluxo de avaliação é dividido em seis etapas:

Etapa 1: Submissão de palestras

Informações que precisam ser divulgadas ou coletadas na submissão:

• Detalhar a nova regra de avaliação;
• Informar a necessidade de avaliação de outras submissões por quem enviou propostas. Caso a pessoa não possa participar do processo de revisão, basta informar a organização;
• Informar sobre aplicação do Código de Conduta em todo processo.
• Importante: coletar dados necessários para outras etapas de avaliação. No exemplo de palestrantes de primeira viagem que descrevi acima, é preciso perguntar se a pessoa já palestrou em outras edições da Python Brasil para que seja possível identificá-las durante a avaliação final.

Etapa 2: Distribuição das submissões para revisão

Após encerramento das submissões, o time da organização ficará responsável por:

1. Anonimizar as submissões, de tal forma que a pessoa revisando não consiga identificar quem submeteu a palestra;
2. Distribuir as submissões, de forma aleatória, para revisores. É preciso garantir que todas as palestras sejam revisadas por três pessoas diferentes;
3. Garantir que ninguém revisará a própria palestra.

As pessoas envolvidas na anonimização, idealmente, não podem participar da avaliação.

Etapa 3: Revisão

Cada revisão consiste no preenchimento do formulário abaixo por parte da pessoa revisora. O número no início da alternativa indica o valor da nota atribuída à questão.

Pergunta 1: Familiaridade - A familiaridade da pessoa revisando com o assunto

• 1: Fora de minha área de conhecimento
• 2: Pouco conhecimento neste assunto
• 3: Sou familiar com este assunto
• 4: Esta área de conhecimento faz parte do meu trabalho
• 5: Atuo diretamente com este tópico

Pergunta 2: Apresentação - Avaliação da qualidade do trabalho

• 1: Não condizente ou ilegível
• 2: Necessita de alterações consideráveis
• 3: Poucas alterações são necessárias
• 4: Passível de melhorias, mas sem necessidade de alterações
• 5: Muito bem escrito e desenvolvido

Pergunta 3: Relevância - Quão relevante este trabalho é para o evento

• 1: Não tem relação com o evento
• 2: Baixa importância para o evento
• 3: Relevante
• 4: Boa relevância
• 5: Totalmente alinhado aos objetivos do evento

Pergunta 4: Qualidade técnica - Grau de confiabilidade técnica do trabalho

• 1: Trabalho questionável, com diversas falhas
• 2: Contribuição marginal e com falhas
• 3: Com falhas, mas de fácil correção
• 4: Poucas correções necessárias
• 5: Excelente

Pergunta 5: Contribuição - A originalidade do trabalho e a contribuição para a área de conhecimento

• 1: Trabalho e contribuição questionáveis, faltam ideias novas
• 2: Trabalho marginal, pouca contribuição
• 3: Variação de um conceito consolidado
• 4: Evolução de um conceito consolidado
• 5: Trabalho sólido e original

Pergunta 6: Pontos fortes (Campo aberto)

Pergunta 7: Pontos fracos (Campo aberto)

Pergunta 8: Comentários (Campo aberto)

Recomendação - Sugestão de aceitação/rejeição do trabalho

1. Forte rejeição
2. Baixa rejeição
3. Aceitável se houver vaga
4. Aceitável
5. Forte aceitação
6. Trabalho candidato ao prêmio de destaque

Etapa 4: Cálculo das notas

Após recolher as revisões, a organização calcula as notas de cada submissão por meio de média ponderada, utilizando como peso a resposta para pergunta 1. Ou seja, quanto maior a familiaridade da pessoa revisando com o assunto da submissão, maior será o peso da nota dada por ela.

Etapa 5: Escolha das atividades

A organização analisará as notas das atividades e avaliará a grade completa, podendo aplicar novas etapas de avaliação ou filtros, como por exemplo:

• Caso uma pessoa tenha mais de uma palestra selecionada, a de maior nota será escolhida.
• Caso tenhamos submissões muito semelhantes, a de maior nota será escolhida.

Importante que a organização analise a grade como um todo e avalie se ela de fato representa a comunidade Python brasileira, fazendo ajustes necessários para que os objetivos do evento sejam alcançados.

Etapa 6: Envio dos resultados e revisões

Após o término de toda avaliação, todas as pessoas que enviaram palestras receberão os feedbacks coletados. As notas finais não serão divulgadas.

As pessoas que tiveram as palestras escolhidas serão informadas, e será reforçada a importância das correções apresentadas nos feedbacks.

Código de Conduta

O Código de Conduta da Associação Python Brasil se aplicará em todas as etapas do processo. As pessoas que enviarem ou revisarem as palestras, deverão concordar previamente com o mesmo.

Perguntas e respostas

As três perguntas mais frequentes que surgiram na proposta do modelo:

A pessoa que submeteu atividade é obrigada a revisar as palestras?

A escolha fica por conta da organização de cada edição. Além da obrigatoriedade, a organização pode optar por pontuar quem revisou as palestras. Caso não seja obrigatório, será necessário que outras pessoas, do time da organização ou da comunidade, revisem as atividades remanescentes.

Qual ferramenta será usada para submissão e revisão das palestras?

A escolha das ferramentas fica a critério da organização da edição do evento, recomendamos apenas atenção ao método que possibilite coletar todas as informações necessárias. Google Forms se mostrou útil e com diversas possibilidades de automações.

E se houver uma infração ao código de conduta na submissão ou revisão de uma palestra?

Time de Resposta do Código de Conduta deverá ser acionado para tomar as devidas providências.

Referências

Esse modelo de avaliação foi baseado na forma como o IEEE (O Instituto de Engenheiros Eletricistas e Eletrônicos) avalia seus trabalhos.

Agradecimentos pela revisão do texto: Ana Dulce e Gabriel Ferreira.

\o/