Governança da Comunidade FreedomBox

Sobre a nossa Comunidade

O projeto de software FreedomBox é governado por uma comunidade que inclui voluntários em tempo parcial e colaboradores em tempo integral. Na governança, nos baseamos em nosso código de conduta escrito e em padrões mutuamente aplicados. A comunidade busca tomar decisões por meio de discussão aberta e consenso. Em caso de desacordo, a comunidade discute até que uma solução seja encontrada ou concorde em adiar a discussão. Embora um número seleto de nossos desenvolvedores tenha o poder de aceitar solicitações de mesclagem, qualquer pessoa é bem-vinda para se juntar à nossa comunidade de colaboradores e enviar contribuições, com ou sem código.

Equipa Principal

Conheça os membros da nossa equipe principal! Embora vários membros da comunidade contribuam, a equipe principal é composta por aqueles que estão mais envolvidos no desenvolvimento do FreedomBox.

Colaboradores

Embora nossa equipe principal seja pequena, centenas de voluntários contribuíram para a FreedomBox ao longo dos anos. Muitos desses colaboradores estão listados <a href="https://wiki.debian.org/FreedomBox/Contributors">aqui</a>. Agradecemos a eles pelo trabalho!

Como as decisões são tomadas

Geralmente, as decisões sobre desenvolvimento e design de software são discutidas pelos membros da equipe principal e implementadas usando nossa plataforma aberta de desenvolvimento de software (ou seja, GitLab). Muitas das decisões tomadas por nossa equipe são incontroversas e não exigem longos períodos de discussão.

Mas, às vezes, longos períodos de discussão são necessários. Para propostas que podem plausivelmente estar sujeitas a desacordo, usamos um procedimento de “Solicitação de Comentários” (RFC). Os RFCs devem ser publicados em uma de nossas plataformas de desenvolvimento aberto (ou seja, Gitlab ou fórum) e devem incluir (1) um resumo escrito, esboço ou mock-up da proposta, (2) uma breve explicação de por que a proposta é necessária e (3) uma lista de itens de ação necessários para implementar a proposta. Opcionalmente, também se pode incluir no RFC um quarto item: um cronograma sugerido para o processo de discussão, a fim de evitar atrasos desnecessários. Às vezes, desacordos dificultam o cumprimento dos cronogramas prescritos; nesses casos, os participantes devem se esforçar de boa-fé para chegar a um acordo e, na falta disso, podem estender a discussão.

Melhoria por Revisão

Em geral, quando propostas de desenvolvimento ou design de software são aceitas, elas são tratadas como passíveis de revisão, e não como permanentes. Essa abordagem de melhoria por revisão das propostas nos permite aceitar propostas geralmente sólidas, sem nos determos em pequenos detalhes. Pequenos ajustes nas propostas aceitas sempre podem ser feitos posteriormente, em vez de antecipadamente. Assim como a proposta original, as revisões estão sujeitas a discussão e não podem ser feitas unilateralmente. No espírito de experimentação, abraçamos a possibilidade de revisão para promover melhorias incrementais em nosso software.