Após ter avaliado todas as palestras do FISL 2006, acho que estou um tanto
cansado de ver letrinhas e descrições de papers e pra ser bastante franco
não me recordo de tudo o que passou durante todo o mês disponível pra avaliarmos
as palestras (era meio no escuro, não dava pra saber quantos estavam fazendo isso
paralelamente e/ou em quais trilhas de tema), mas anotei algumas coisas em
vários post-it colados no meu monitor e resolvi escrever sobre cada uma, abaixo:

Alguns pontos desse texto tem relação direta com o Papers criado pelo pessoal
do FISL (http://papers.softwarelivre.org/) mas alguns são genéricos o
suficiente pra valer a pena lembrar deles em alguma outra organização de
evento, IMHO. Possivelmente alguns comentários são devidos a features ou bugs
do sistema de Papers também, mas como eu não consegui identificar direito
tudo, fica o alerta de que determinadas críticas não são diretamente pra
proposta de ninguém e vice-versa.

O que botei abaixo também não serve como "relatório", nem "análise" nem
"recomendações aos proponentes". Isso tudo já é feito pelo pessoal do FISL, mais
especificamente por quem cuida do Temário, e se escrevi tudo isso é porque achei
que valeria a pena cada um dos avaliadores comentar sobre todo o processo. Enfim,
depois de ajudar por três anos o pessoal da forma como dá, sempre se acaba tendo
o que falar. Imagine quem está nisso desde o primeiro fórum de Porto Alegre.
Digamos que escrevi isso também como guia pro próximo ano, pra mim mesmo caso
tenha alguma idéia de paper pra mandar. Se não me falha a memória, foram 353
palestras avaliadas este ano, um pouco mais do que no ano passado. Do primeiro
ano que ajudei eu não lembro o número de propostas, mas avaliei todas também, IIRC
(tudo corrigível pelo pessoal do FISL).

E antes que eu me esqueca, aqui está o documento oficial do Temário sobre isso:
http://twiki.softwarelivre.org/bin/view/Fisl6/RecomendaçõesAosProponentes

Isso por sua vez me lembra sobre avaliadores que submetem palestras para análise
do Temário. Apesar de ter regras pra isso não dar problemas mais na frente ou não
desbalancear os rankings, acho que não fica bem um avaliador submeter palestra em
qualquer uma das trilhas do FISL. Então é por isso que nunca mandei nada (para quem
ficou curioso sobre isso, mesmo não sendo relevante agora) e não pretendo avaliar
nada ano que vem... bom, aos pontos aleatórios e sem sentido heheh:

[pausa para uma palavrinha dos nossos patrocinadores: o tom negativo dos comentários
não representa todas as avaliações e somente as que deram um trabalho extra...
papers bem feitos e palestrantes com currículo bom e conteúdo interessante não
se encaixam no que está escrito abaixo, provavelmente]

Evitar blocos grandes de texto é uma boa idéia e cansa menos a avaliação. Foi
bem comum pegar um único parágrafo com 15 ou até 20 linhas e sentenças longas.
Isso acaba cheirando a blábláblá e não é brincadeira, cansa mesmo de ler.
Grandes blocos de texto foram criados quase que automaticamente por
alguns... como nas propostas de palestras que copiaram e colaram no campo de
descrição o manifesto inteiro do projeto relacionado (sim, aconteceu isso).

A sugestão que fica sobre isso então é: por favor, escreva parágrafos curtos (3
à 5 linhas), sobre assuntos específicos em cada um e, se possível, com
keywords que facilitem a pesquisa sobre o tema no Google ou Wikipedia.
Entretanto, de nada adianta uma descrição curta, como sugerido agora, se elas são
curtas demais, ao extremo e em geral com conteúdo porco. Desculpas aos proponentes
que se sentiram ofendidos com isso. Ano que vem poderão se vingar :-)

Foi comum pegar descrições cheias de nonsense e coisas não
relacionadas ao evento ou software livre (até mesmo uma sobre a bíblia
católica, se me lembro bem). Uma descrição objetiva, sucinta e curta não
significa uma descrição pobre em detalhes, de 3 ou 4 linhas no total ou dando
a impressão que foi digitada em 5 minutos, no intervalo pra um café no
trabalho (tive essa sensação ao ver várias propostas).

Isso leva ao problema do conteúdo das descrições. O pior caso sem dúvida foi na
trilha de desenvolvimento. O conteúdo quando não era cópia de páginas
"about.html" do site do projeto em questão, era um resumo das features de
algum software, praticamente uma mera apresentação "o que é foobar". Nada ou pouco
técnico, quero dizer. Em uma trilha de desenvolvimento espera-se um pouco mais
de profundidade técnica e se possível detalhes, detalhes. Assim fica fácil
conseguir um espaço na trilha desenvolvimento: copia-se parte de algum site de
projeto que você gosta e manda isso como proposta de palestra. Isso quando o
palestrante não ficava dando voltas e mais voltas e não concluía a descrição e ainda
nem tinha dito nada de relevante pra ajudar na avaliação.

Sobre os currículos dos palestrantes... se foi falta de atenção ou simplesmente
descaso com o currículo relacionado eu não sei, mas vi muitos currículos
totalmente vazios. No máximo, máximo mesmo, tinha um e-mail @projeto_importante.org ou
@gov.br, o que na minha terra é conhecido como carteirada. Não é porque a
pessoa tem uma posição de destaque em um projeto que ela não precise mandar
currículo relacionado ao tema como todo mundo. Currículos vazios eram motivos
pra uma negação da palestra da minha parte ou uma avaliação baixa (pelo menos),
como em casos extremos onde tudo estava perfeito e faltava só algum currículo.

Trilhas erradas foram problema também, mas pelo jeito foram casos isolados. No
entanto, algumas propostas vinham com indicação do próprio autor pra mudar a
trilha se fosse o caso. Não é assim que funciona, IMHO. Você é quem precisa
dar um certo carinho pra proposta e ler, reler e reler a descrição de trilha e
ver em qual delas a sua palestra se encaixa.

Por causa disso (talvez, talvez) onde era necessário alguma informação
referencial, uma URL, uma explicação sobre termo técnico ou filosófico... não
havia nada. Em algumas palestras era normal ler geekísmo um atrás do outro ou
parágrafos chapados de obscurantismo. Era como se o palestrante ou não ligasse
pra quem vai avaliar a proposta (quando em muitos casos são pessoas normais
com tempo curto pra isso e que se esforçam no Google) ou fizesse questão de que
poucos entendessem do assunto. O que mais ilustra bem esse problema é o uso
absurdo de siglas sem explicar o que significam. Quando não era isso, era o
contrário. Temas ou muito iniciantes ou bobos pro nível atual do FISL eram o
problema ("o que é software livre", por exemplo).

Uma sugestão pro FISL seria criar um limite máximo de papers por pessoa ou quem
sabe por instituição também. Isso ou a garantia de que somente uma palestra de
um grupo ou pessoa seria aprovada, não permitindo paper bombing (inventei
agora esse termo). Isso evitaria que uma pessoa pegasse um assunto
razoavelmente complexo e longo e o dividisse em vários papers (4 por exemplo),
elevando assim as suas chances de ser aceito caso poucos percebam a
estratégia. E falando em paper bombing, deu pra notar uma quantidade bem
grande de palestras sobre Java e sistemas relacionados e também sobre PHP ou sistemas
web usando ele ou também algo ligado a ele. Igualmente, uma enorme quantidade
de palestras simplesmente descrevendo "metodologias" ou "práticas de
desenvolvimento" foi submetida pra avaliação...

Apesar de tudo isso, as 4 palestras enviadas pra avaliação pelo autor do netfilter do
kernel Linux (Harald Welte) tinham um conteúdo bem interessante e iam desde
debates nada técnicos até uma sobre OpenEXZ ou sistemas de biometria (se não me
falha a memória ingrata, esses foram 2 assuntos escolhidos por ele). O laforge
(como ele também é conhecido) indiscutivelmente sabe do que fala e já que
mencionei isso... somente uma única palestra veio com um currículo específico
indicado de forma explícita. Algo como "segue abaixo o resto do meu currículo,
a parte relacionada ao tema escolhido". Isso sem dúvida nenhuma ajudou... ao
contrário dos que botaram até mesmo toda a descrição da palestra no campo de
comentários dela; e aqui cabe um adendo, o de que poucos realmente usaram os
espaços certos de divisão do paper (abstract, description e comments).

E não é que teve somente outro paper solitário que usou uma ótima estratégia
pra facilitar a avaliação? Em um deles o autor do paper especificou keywords,
palavra-chave e termos relacionados ao tema de forma bem clara. Isso ajudou
a avaliação sem sombras de dúvida (independente da qualidade do paper).

Houve também infelizmente, na minha opinião, uma certa quantidade de palestras ou repetidas
e já apresentadas no FISL (o tema e o que foi descrito pelo menos, não
realmente toda a palestra, é óbvio) ou ainda palestras que foram indicadas
pelo próprio autor como já tendo sido apresentada em vários outros eventos.

Nao me levem a mal, mas palestras repetidas ou com conteúdo batido, e pior, ou
que já cresceram barba de tão velhas que são e repetidamente apresentadas...
bom, todas receberam uma avaliação no máximo média. Acho que por mais que um assunto
seja interessante, nada conta a favor de algo que não evoluiu ou avança, e que
faz questão de ficar estacionado sem ter nada a acrescentar. O mesmo serviu
para palestrantes que não enviaram currículo algum como já falei, seja por qual
motivo foi. A bomba foi do mesmo tamanho.

Inversamente, palestras sobre NetBSD, OpenBSD e FreeBSD tiveram algumas
regalias (pelo menos da minha parte, claro) e acho que mereciam ser um pouco
"incentivadas", já que formam uma parcela extremamente considerável da
comunidade de software livre e em geral trazem temas novos e interessantes.

À propósito, todos os comentários iam diretamente pro autor do paper e pra
equipe do FISL que cuida do Temário esse ano. Poderiam ter sido enviados
somente ao próprio temário, mas mesmo que o conteúdo dos comentários não fosse
tão gentil com quem falhou nos pontos acima ou mesmo que fossem indelicados,
acho que o mais transparente, justo e honesto é enviar também ao palestrante o
texto exato enviado a organização. Da minha parte foi assim. Todos os meus
comentários começavam com um traço no início de cada item comentado e em
letra maiúscula. Assim fica mais fácil me esculacharem em PVT. Facilitei um
bocado, hein?

Aos palestrantes que enviaram propostas pro FISL este ano mas não foram
aprovados, uma sugestão realmente sincera: preparem, antes de submeter o
paper, alguns "slides", trechos do conteúdo que de fato será usado.
Aparentemente muitos nem mesmo tinham pensado a respeito e uns até mencionaram
que o tema ainda seria trabalhado... e ah, pra quem perdeu ou esqueceu da
existência disso, algumas palestras do ano passado ainda estão online e podem
servir em uma comparação ou guia:

http://twiki.softwarelivre.org/bin/view/Fisl6/SlidesDosPalestrantes

Mas o mais importante é: por favor, nós imploramos, indiquem o nível de
envolvimento com o assunto escolhido! É simplesmente impossível avaliar a
experiência de alguém com XYZ se isso nem mesmo é mencionado no currículo do
palestrante. O mesmo vale pra licenciamento de soluções ou idéias... é melhor
usar o currículo pra isso do que pra indicar em quais eventos já foi ou
palestrou anteriormente (o que na verdade deveria ser indicado em comentários,
não no currículo).