Governança¶
Os membros da [Equipe Principal] têm várias responsabilidades para manter o projeto BeeWare em funcionamento. Este é um projeto em evolução, portanto, esta página está sujeita a alterações.
Isso inclui, mas não se limita a, responder a problemas, revisar e mesclagem de código, orientação de novos colaboradores e arquitetura do projeto projeto BeeWare como um todo.
Há pessoas em quem confiamos para tomar decisões de código; há pessoas em quem para tomar 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 equipe¶
Os diferentes níveis de senioridade 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 mesclado. A única limitação à sua capacidade de contribuir é ter seu trabalho mesclado por um membro da equipe com direitos para fazê-lo.
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 em outro nível (gestão de comunidade, revisão de código). Os apicultores também podem ter o commit bit para o projeto em que 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, em última instância, respondem ao BDFN.
Ditador Benevolente por Enquanto (DBPE)¶
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 mantenedor principal a toda a vida 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 aspectos muito importantes a serem considerados.
O BDFN da BeeWare é Russell Keith-Magee.
Apicultor fundador¶
O homem que primeiro se posicionou em uma colina e avistou um iaque que precisava ser tosquiado. Essa função nunca muda e continua indefinidamente; no entanto, ela não transfere inerentemente 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 commit, há há uma série de diretrizes gerais que a equipe deve seguir:
- Seja um bom representante do projeto para a comunidade em geral
- Trate todas as perguntas e contribuições para qualquer projeto BeeWare com respeito
- Presuma que todos têm boas intenções, mesmo que não tenham escolhido bem as palavras.
- Suponha que, se alguém fez algo da maneira “errada”, é porque falhamos em comunicar o processo.
- Presuma que qualquer expressão de raiva ou frustração vem de um desejo genuíno de usar uma ferramenta/biblioteca BeeWare.
- Incentive outros membros da comunidade a refletir esses ideais em suas próprias comunicações, tanto dentro quanto fora da comunidade BeeWare.
- Nenhum apicultor deve comprometer seu próprio código.
- Exceção: “Algo está muito danificado e precisa ser consertado agora”
- Exceção: BDFN (isso pode mudar no futuro)
- Todo código enviado para revisão por um membro da equipe principal deve ser revisado por outro membro da equipe.
- Exceção: BDFN (isso pode mudar no futuro)
- Todo o código deve passar nos testes de integração contínua antes de ser mesclado.
- Exceção: código que se sabe estar corrompido e precisa ser confirmado por outros motivos.
- Exceção: código em um repositório com testes de CI insuficientes
- Exceção: Trabalhar e se comprometer é melhor do que ser perfeito e não fazer nada.
- Os processos de aceitação devem ser automatizados sempre que possível.
- Isso significa testes, linting, verificação ortográfica, cobertura e muito mais.
Tornando-se um apicultor¶
A introdução de um novo apicultor na equipe fica a critério exclusivo da da equipe principal existente. Embora não haja atualmente nenhuma regra sólida para isso, em geral, alguém será convidado a ser apicultor em um projeto do projeto BeeWare se tiver demonstrado contribuições sólidas para o projeto. projeto. Isso também pode ser estendido a alguém com conhecimento de domínio específico específico (por exemplo, iOS/macOS) que possa estar faltando na equipe existente. equipe existente. Também não precisa ser baseado em commits. Qualquer pessoa que que possa demonstrar interesse no projeto em geral pode pedir permissão para se comprometer pedir permissão para se comprometer com o projeto.
Todos os novos apicultores serão “iniciados” (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 à equipe 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 mantenedor de qualquer coisa. Há muitos apicultores, e muitos outros além deles, que podem oferecer ajuda, aconselhamento e orientação.
“Bit de confirmação”?¶
Nos sistemas Unix, um único bit em um arquivo é usado para indicar a permissão para executar um arquivo. Nos sistemas de controle de origem, existe um bit semelhante para denotar a capacidade de mesclar código. Dizer que alguém tem o "commit bit" significa que essa pessoa tem acesso de gravação a uma base de código. Nos termos do GitHub, isso significa que ele tem a capacidade de mesclar Pull Requests e fazer commit de código diretamente no o projeto.