Projetos de Software Livre: Como Funcionam e Como Ajudar? - Abertura Quem somos O que esta apresentação compreende - Como se organizam projetos de software livre? Projetos tem um nome próprio, e são uma combinação de pessoas, software, processo e ferramentas de apoio ao processo. O processo varia significativamente, mas existe um padrão geral. Tópicos essenciais: - Mantenedor/Gerente do projeto Normalmente escreve a maior parte do código Liderança técnica, indica como deve ser alterado e por que Resolve disputas entre membros da equipe Revisa/reescreve e decide quais alterações devem ser integradas Decide quando serão lançamentos - Membros do projeto/Voluntários Fazem parte do trabalho do projeto, conforme desejam. Tarefas são as tradicionalmente executadas em projetos: - Suporte - Codificação - Documentação - QA/GQS - Outras atividades menos freqüentes manutenção de website, auxílio de administração de sistemas, projeto de UI e teste de usabilidade, prospecção por outros voluntários, prospecção e comercial, divulgação técnica e científica, auxílio no lançamento de versões novas - Direito Autoral e Licença Importante se considerando contribuir código para o projeto, a licença pode ou não restringir redistribuição (`viralidade'). Código normalmente tem copyright compartilhado; pode ser solicitada transferência de copyright para uma entidade ou pessoa central (Zope, Mozilla, Linux) Normalmente documentação permanece sob o direito autoral do autor. - Código-fonte Majoritariamente em C, Perl, C++ e Python. Alguns projetos Java, e outras linguagens especializadas em certas situações. Shell, yacc, awk e sed usados normalmente como linguagens de apoio. Código normalmente mantido sob controle de versão. - Ferramentas Código-fonte em algum sistema de controle de versões (CVS/Subversion primordialmente) Listas de discussão e email Website e local para download Controle de alterações/erros (Bugzilla, RT, SF bugtracker) IRC/ICQ/AIM - Por que ajudar - Treinamento e experiência [prática] profissional - Destaque pessoal - Complemento ou pré-requisito para alguma atividade profissional ou pesquisa. - Por que escrever software livre é construir riqueza sem restrições. - Por que os projetos precisam *muito* de ajuda. A maior parte dos projetos é pequeno e sofre com a falta de voluntários para escrever código, documentar e dar suporte ao software. - Required skills to participate - English - CVS - Programming, writing, tech support - Tarefas 0. - Procurar projeto interessante: domínio legal? Tecnologia que te interessa? Chance de trabalho remunerado? Tem a ver com seu emprego ou pesquisa atuais? - Baixar código-fonte (e binário, ou compilar binário) e instalar software. - Assinar listas de discussão, e ler arquivos. - Suporte (minutos a horas) - 1. Ler mensagens na lista de discussão - 2. Opcional: Esclarecer problema, perguntar sobre situações relacionadas, triar erro - 3. verificar FAQ; procurar soluções; testar sugestões - 4. Responder - 5. Repitir - GQS/QA Basicamente envolve: - Testar software, e reportar falhas - Verificar a existência de outras falhas semelhantes, montar casos de teste para facilitar reprodução do problema, sugerir soluções potenciais. Para projetos maiores, pode ser um trabalho altamente envolvido, que inclui categorização de falhas, triagem de erros, busca de informes duplicados. Para certas aplicações, uma tarefa associada à QA (mas que envolve codificação) é escrever testes e suites de testes que possam executar automaticamente e assegurar que o software continue funcionando ao longo do tempo. - Hacking (dias a semanas de trabalho) - 1. Baixar código-fonte - 2. Procurar pequenas alterações para fazer - Como usuário, é fácil descobrir se deveria fazer algo que não faz. - É sempre melhor fazer uma mudança de 5 linhas do que uma reescrita do sistema; você precisa ter seu código revisado e aceito, e isso jamais é fácil (e normalmente demora) - - 3. Escrever alteração. Gerar patch. - 4. Submeter patch - Pode ser simplesmente enviar um email à lista de discussão - Pode consistir em anexar a uma ferramenta de controle de alterações/bugs como o Bugzilla ou o SF bugtracker - 5. Esperar Integração ou Rejeição - E cutucar periodicamente pedindo revisão, ou reenviando patches. - 6. Repetir - Procurando trabalhos gradualmente maiores; com o passar do tempo procurar uma parte da arquitetura que te interessa ou com a qual possui afinidade especial. - Documentação (semanas a meses de trabalho) - 1. Verificar que documentação já existe - 2. Verificar falhas ou problemas comuns informados na lista de discussão. Montar um mini-FAQ manual. - 3. Optar por qual tipo de documentação é necessária (peça ajuda aos mantenedores!) A partir do mini-FAQ, escolher entre os tipos padrão: - Tutorial: bom para conseguir novos usuários e iniciantes. Um tutorial deve seguir gradualmente do mais simples para o mais complexo, de preferência descrevendo tarefas completas mas restritas e expendindo a partir desta. Seções do documento geralmente correspondem às divisões (ou degraus) de funcionalidade do software. - Referência: para usuários avançados e com experiência. Requier cobertura minuciosa do funcionamento ou uso do software, e deve ser organizado de forma sistemática para - FAQ: para manter o tráfego na lista de discussões baixo :-) Para cada pergunta na lista, tente generalizar e montar uma resposta (muitas vezes baseado no que for respondido ali mesmo). - 4. Escrever. Escrever. Escrever. - 5. Opcional: Pedir revisão à lista - 6. Escolher uma opção de hospedagem; opções são website do projeto, website próprio, hosting independente. - 7. Publicar. - 8. Repetir - Fechamento Reiterar por que participar é importante Oferecer formas de contato Abrir para perguntas