Obtendo contribuições adequadas

Getting the right kind of contributions

Autor original: Jake Edge

Publicado originalmente no: http://lwn.net/

Tradução: Roberto Bechtlufft

A maioria dos projetos de software livre incentiva a participação de seus contribuidores – e raros são os projetos com contribuidores sobrando – mas a qualidade das contribuições varia bastante. Incentivar boas contribuições, ou aquelas que levarão a outras mais úteis no futuro, é parte importante de qualquer projeto. Mas é um balanço delicado. Às vezes é difícil determinar os tipos de tarefas adequadas a novos contribuidores que, mais tarde, resultem em contribuições mais importantes.

O outro lado da moeda é como lidar com contribuições que parecem não levar a lugar algum. Leva muito tempo só para passar os olhos pelas contribuições significativas nas listas de discussão de projetos grandes – a lista linux-kernel é um ótimo exemplo; complicar as coisas com patches praticamente inúteis só torna as coisas mais difíceis. Mas os novos contribuidores geralmente querem começar por algo relativamente fácil, o que acaba gerando alguma tensão.

Não é fácil desencorajar patches que não sejam particularmente úteis de maneira a não espantar potenciais hackers do kernel. A intempestiva sugestão de Al Viro de criar uma besteirenta lista na linux-kernel não parece ser a melhor abordagem. Ele estava reagindo a um patch que reformatava o cabeçalho de um arquivo do kernel para que os argumentos ficassem alinhados. Viro não é conhecido por suas habilidades diplomáticas, mas ele estava reagindo a um problema que outros hackers do kernel também conhecem. Há uma quantidade cada vez maior de contribuições triviais de limpeza que não andam se traduzindo em contribuições mais úteis e substanciais posteriormente.

Em outro post, Viro explicou sua preocupação:

Temos aqui uma área separada. A área “escolha um trabalho mecânico e inútil da lista, faça-o, não aprenda nada com isso e escolha outro ou, de repente, procure outros passatempos igualmente inúteis.” Claro que isso sempre existiu; a diferença é que agora isso não é mais apenas um estágio de transição do qual o sujeito ainda vai se envergonhar daqui a alguns anos. É algo que se torna mais visível, que se sustenta e fica mais pegajoso a cada dia – já se tornou uma subcultura própria e, pelo que vejo, incentiva cada vez mais as pessoas a ficarem por ali mesmo ao invés de seguirem em frente.

Há um custo real associado aos posts da linux-kernel. Ela é o principal mecanismo de comunicação sobre o desenvolvimento do kernel, e quem está envolvido nesse trabalho precisa ler esses posts todos. David Miller lamenta o tempo que perde peneirando as mensagens:

Depois de deletar tudo o que não presta, já estou cansado demais para trabalhar com o que sobrou e acabo deletando também. :-/ É pior do que o meu processamento diário de mensagem administrativas e de falha de envio na vger.kernel.org

Vocês não acham que seria melhor eu ter energia sobrando para analisar alguns patches úteis?

O projeto kernel oferece vários recursos aos interessados em ajudar que não sabem como nem por onde começar. O movimento Kernel Newbies, ou Novatos do Kernel, foi criado para ajudar as pessoas a darem seus primeiros passos no kernel, oferecendo um wiki, uma lista de discussão e um canal IRC voltados às necessidades dos novatos. A idéia é oferecer informações úteis e orientações que vão levar a contribuições úteis para o kernel.

Um subprojeto é o Kernel Janitors, ou Garis do Kernel, que se foca no trabalho de limpeza do código.

Nós damos uma passada pelo fonte do kernel, analisando o código, consertando código sem manutenção e fazendo uma limpeza e algumas conversões na API. É uma boa maneira de começar no kernel hacking.

Ambos os movimentos têm como objetivo preparar as pessoas para que o kernel como um todo melhore. Esse trabalho todo é importante, mas há outras tarefas do kernel que não estão sendo feitas, possivelmente porque os contribuidores estão se concentrando na limpeza. Andrew Morton tem algumas sugestões aos interessados:

Entende-se que um desenvolvedor decida escrever um patch com espaços em branco que não faça nada só para aquecer, mas se me perguntarem, eu não recomendaria essa prática. Geralmente eu recomendo às pessoas que baixem e testem os mais recentes kernels -rc, linux-next e -mm, que os compilem e os rodem. Com certeza elas vão encontrar coisas que precisam ser resolvidas. Muitas vezes são coisas simples como erros de compilação, outras vezes pode ser necessária uma busca bisseccional.

O problema é que boa parte desse trabalho é mais difícil do que uma limpeza de espaços vazios. Aos interessados em pôr seus nomes nos “holofotes” – na forma de uma mensagem de commit ao kernel – o caminho dos patches triviais parece mais simples. Reações como a de Viro podem detê-los, mas correm o risco de fazer a linux-kernel parecer um lugar hostil e desencorajar desenvolvedores.

Há tarefas extremamente importantes no kernel que muitas vezes não recebem a devida atenção. Enviar relatórios detalhados de bugs, bisseccionar o kernel para encontrar o patch que quebrou tudo ou testar as correções propostas são tarefas que muitas vezes passam em branco, ao menos a julgar pelo log de commits do kernel. Já se pensou em adicionar tags a esses patches específicos, mas até agora não houve nenhuma proposta concreta.

Há duas novas iniciativas em andamento para dar assistência a novos desenvolvedores do kernel. Jesper Juhl está trabalhando em um Guia do Kernel para Novatos, a ser incluído na árvore de Documentação do kernel. Ele pode ir parar em Documentation/HOWTO ou ser um arquivo separado, mas a idéia é colocar as pessoas no caminho certo, fugindo de patches que invoquem a ira de hackers do kernel. Jonathan Corbet, do LWN, também mencionou um documento maior no qual trabalha com apoio da Linux Foundation que deve estar pronto para análise em junho.

Os novos desenvolvedores na linux-kernel podem encontrar alguma grosseria e hostilidade, mas as coisas raramente chegam ao nível que chegaram na lista openbsd-misc, em outubro. Em resposta à solicitação de uma lista de tarefas menos complicadas a serem realizadas no OpenBSD – no estilo do que os Kernel Janitors vêm fazendo – o líder do projeto, Theo de Raadt, que não é conhecido mesmo por sua diplomacia, soltou o verbo:

Eles estão ocupados demais choramingando por listas, ao invés de procurar por elas.

Vou repetir de forma mais clara — seus chorões, vocês fedem. Sabemos que vocês nunca vão escrever um diff, e cabe a vocês provar que estamos errados. Como vocês não escrevem diffs, fica difícil sentirmos falta de vocês.

Isso é o extremo da atitude “mostre-nos o código” mas, de sua maneira inimitável, de Raat está reagindo ao mesmo problema. Leva tempo e dá trabalho arrebanhar novos hackers do kernel. Perder tempo ajudando a pessoas que nunca contribuirão de verdade é um desperdício; esse tempo seria melhor empregado na caça aos bugs, e em soluções para eles. Como disse o hacker do Linux, Ted Ts’o:

A questão é se as pessoas que estão tão preocupadas com espaços em branco e erros de ortografia nos comentários irão algum dia escrever patches úteis de verdade. Se a resposta for não, então não há motivos para incentivá-las.

E como um projeto determina quais interessados serão contribuidores úteis e quais não serão? É um problema difícil que precisa ser trabalhado. Ele certamente não é exclusividade de projetos de kernel, já que qualquer projeto de alto nível tem um uma alta barreira de entrada e alguns desenvolvedores que devem ser desencorajados.

Claro que nunca haverá um teste apurado para detectar futuros contribuidores, mas pode haver maneiras de se ter uma idéia mais clara de quem são eles. Enquanto isso, agredir pessoas bem-intencionadas não vai ajudar muito. Informar ao Linux Newbies quais patches não são apropriados, na esperança de que esses contribuidores mudem de foco, pode ser um bom começo.

Créditos a Jake Edgehttp://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X