Governação¶
Os membros da [Equipa Principal] têm várias responsabilidades para manter o projeto BeeWare em movimento. Este é um projeto em evolução, assim esta página está sujeita a alterações.
Isto inclui, mas não se limita a, responder a problemas, revisar e misturar código, orientação de novos colaboradores e arquitetura do projeto BeeWare como um todo.
Há pessoas em quem confiamos para tomar decisões de código; há pessoas que cofiamos para fazer decisões sobre o código e a organização; e há uma pessoa que orienta a visão de toda a organização e é encarregada de tomar uma decisão final se a comunidade não conseguir chegar a um consenso.
Antiguidade na equipa¶
Os diferentes níveis de antiguidade no projeto BeeWare são:
Abelha, ou Abelha Operária¶
Qualquer membro da comunidade BeeWare. Como trabalhamos abertamente no GitHub, qualquer pessoa pode sugerir alterações no código e ter seu código misturado. A única limitação à sua capacidade de contribuir é ter o seu trabalho misturado por um membro da equipa com direitos para o fazer.
Apicultor¶
Uma abelha que foi reconhecida como colaboradora confiável. Essas abelhas demonstraram habilidade em relação a uma parte específica do projeto BeeWare durante um período de tempo. Isso pode ser em nível técnico (conhecimento em JavaScript, Python, Objective-C; GTK+, macOS) ou noutro nível (gestão de comunidade, revisão de código). Os apicultores também podem ter o bit de confirmação para o projeto onde a sua experiência é reconhecida.
Apicultores Seniores¶
Apicultores com acesso elevado no GitHub, e também um nível adicional de responsabilidade para supervisionar o projeto como um todo. Eles podem tomar decisões arquitetónicas, mas po último respondem ao BDFN.
Abelha Benevolente Ditadora por Enquanto (BDFN)¶
Uma abordagem do Ditador Benevolente Vitalício, a responsabilidade pela direção e pelas decisões do projeto recai, em última instância, sobre o BDFN. O uso de “Por Agora” em vez de “Vitalício” é uma referência ao tema do Django de não sujeitar as responsabilidades do maintainer principal a vida toda natural de uma pessoa. A vida existe fora do código aberto, e o equilíbrio entre código e vida, bem como o bem-estar geral, são aspetos muito importantes a serem considerados.
O BDFN da BeeWare é Russell Keith-Magee.
Apicultor Fundador¶
O homem que primeiro se posicionou numa colina e avistou um iaque que precisava ser tosquiado. Essa função nunca muda e continua indefinidamente; no entanto, ela não transfere naturalmente nenhum poder adicional na organização. Atualmente, o Apicultor Fundador também é o BDFN, mas isso pode mudar com o tempo.
Diretrizes (não regras efetivas)¶
Como em qualquer projeto com mais de uma pessoa com direitos de submeter, há uma série de diretrizes gerais que a equipa deve seguir:
- Ser um bom representante do projeto para a comunidade em geral
- Tratar todos os inquéritos e contribuições para qualquer projeto BeeWare com respeito
- Assumir que todos têm boas intenções, mesmo que não tenham escolhido bem as palavras
- Assumir que se alguém fez algo da maneira “errada”, é porque falhamos em comunicar o processo
- Assumir que qualquer expressão de raiva ou frustração vem de um desejo genuíno de usar uma ferramenta/biblioteca BeeWare
- Incentivar outros membros da comunidade a refletir esses ideais em nas suas próprias comunicações, tanto dentro como fora da comunidade BeeWare
- Nenhum Apicultor deve submeter o seu próprio código
- Exceção: “Algo está muito danificado e precisa ser corrigido agora”
- Exceção: BDFN (isto pode mudar no futuro)
- Todo o código enviado para revisão por um membro da equipa principal deve ser revisto por outro membro da equipa
- Exceção: BDFN (isto pode mudar no futuro)
- Todo o código deve passar nos testes de Integração Contínua antes de ser fundido
- Exceção: código que se sabe estar corrompido e precisa ser submetido por outras razões
- Exceção: código num repositório com testes de CI insuficientes
- Exceção: A funcionar e submetido é melhor do que perfeito e não fazer nada
- Os processos de aceitação devem ser automatizados sempre que possível
- Isto significa testes, análise sintática, verificação ortográfica, abrangência e muito mais
Tornar-se um Apicultor¶
A introdução de um novo Apicultor na equipa fica a critério exclusivo da Equipa Principal existente. Embora não haja atualmente nenhuma regra sólida para isso, em geral, alguém será convidado a ser Apicultor num projeto do BeeWare se tiver demonstrado contribuições sólidas para o projeto. Isso também pode ser estendido a alguém com conhecimento de domínio específico (por exemplo, iOS/macOS) que possa estar a faltar na equipa existente. Também não precisa ser baseado em compromissos. Qualquer pessoa que possa demonstrar interesse no projeto em geral pode pedir permissão para se comprometer com o projeto.
Todos os novos apicultores vão ser “endossados” (por falta de uma palavra melhor) nos valores fundamentais e nas diretrizes do projeto. Um resumo dos valores fundamentais pode ser encontrado na página Sobre. Espera-se que todos os que se juntarem à equipa defendam esses valores e contribuam para as discussões sobre a evolução desses valores ao longo do tempo.
Não se espera que qualquer Apicultor, novo ou antigo, seja o único maintainer de qualquer coisa. Há muitos apicultores, e muitos outros além deles, que podem oferecer ajuda, aconselhamento e orientação.
“Bit de submissão?¶
Nos sistemas Unix, um único bit num ficheiro é usado para indicar a permissão para executar o ficheiro. Nos sistemas de controle de fonte, existe um bit semelhante para denotar a capacidade de fundir código. Dizer que alguém tem o "bit de submissão" significa que essa pessoa tem acesso de escrita numa base de código. Nos termos do GitHub, isso significa que ela tem a capacidade de fundir Pedidos de Puxar e fazer submissões de código diretamente no projeto.