As abelhas ocupadas da Equipe principal têm uma série de responsabilidades para manter a colméia que é o BeeWare em movimento. Este é um projeto 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.

Esses níveis podem ser descritos da seguinte forma:

Abelha, ou abelha operária:

  • Qualquer membro da comunidade BeeWare. Como trabalhamos de forma aberta no GitHub, qualquer pessoa pode sugerir alterações no código e ter seu código código seja mesclado. O único limite à sua capacidade de contribuir é ter seu trabalho seja mesclado por um membro da equipe com direitos para isso.

Apicultor:

  • Uma abelha que foi reconhecida como colaboradora confiável. Essas abelhas demonstraram capacidade em relação a uma parte específica do projeto projeto BeeWare durante um período de tempo. Isso pode ser em um nível técnico técnico (conhecimento de JavaScript, Python, Objective-C; GTK+, macOS ), ou em outro nível (gerenciamento de comunidade, revisão de código). Os apicultores também podem ter o bit de commit do projeto em que sua experiência é reconhecida.

Apicultores sênior:

  • Apicultores com acesso elevado no GitHub e também com um nível adicional de responsabilidade de supervisionar o projeto como um todo. Eles são capazes de tomar decisões arquitetônicas, mas, em última análise, respondem ao BDFN.

Apicultor fundador: Russell Keith-Magee

  • O homem que primeiro parou em uma colina e viu um iaque que precisava ser barbeado
  • Essa função nunca muda e continua ad infinitum
  • Essa função é diferente da função BDFN

Ditador benevolente por enquanto (BDFN): Russell Keith-Magee

  • Uma versão de [Benevolent Dictator for Life] (https://en.wikipedia.org/wiki/Benevolent_dictator_for_life), a responsabilidade pela direção e pelas decisões do projeto em última instância, é do BFDN. O uso de "For Now" em vez de "For Life" é uma referência ao tema do Django de não submeter as responsabilidades responsabilidades de mantenedor do núcleo por toda a vida natural de uma pessoa. vida natural de uma pessoa. A vida existe fora do open source, e o equilíbrio entre código/vida e e o bem-estar geral é uma coisa muito importante para se ter em mente.

Diretrizes (não regras reais)

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:

  • Ser uma boa representação do projeto para a comunidade em geral**
  • Tratar toda consulta e contribuição para qualquer projeto do BeeWare com respeito**
  • Presumir que todos têm boas intenções, mesmo que não tenham escolhido bem suas palavras bem escolhidas
  • Presumir que, se alguém fez algo da maneira "errada", é porque porque falhamos no processo de comunicação
  • Assumir que qualquer expressão de raiva ou frustração vem de um genuíno de querer usar uma ferramenta/biblioteca do BeeWare
  • Incentive outros membros da comunidade a refletir esses ideais em suas em suas próprias comunicações, tanto dentro quanto fora da comunidade BeeWare comunidade BeeWare
  • Nenhum apicultor deve comprometer seu próprio código
    • Exceção: "Algo está muito quebrado 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 código deve passar nos testes de integração contínua antes de ser mesclado
    • Exceção: código que é conhecido por estar quebrado e precisa ser confirmado por outros motivos
    • Exceção: código em um repositório com testes de CI insuficientes
    • Exceção: Trabalhar e ser aceito é melhor do que ser perfeito e não ser aceito
  • Os processos de aceitação devem ser automatizados sempre que possível
    • Isso significa testes, linting, verificação ortográfica, cobertura e muito mais

Como se tornar 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 "introduzidos" (por falta de uma palavra melhor) nos valores fundamentais e diretrizes do projeto. Um resumo dos valores centrais pode ser encontrado na página sobre. Qualquer pessoa que se juntar à equipe equipe deverá defender esses valores e contribuir para 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.