[LCFC] webwml://portuguese/devel/constitution.wml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olá,
A Constituição do Debian sofreu modificações (relativamente
grandes), em anexo a nova constituição (1.3) e o diff em relação à
versão 1.2. Eu já enviei para o repositório, mas agradeceria
revisões. :)
Abraço,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFFMrRjCjAO0JDlykYRAnRuAJ44KFF2sowqvf0ywktKSqoqJbwzhQCgmK1K
JZK0fZRb3m7FXzP7Wt/9og4=
=uArx
-----END PGP SIGNATURE-----
#use wml::debian::template title="Constituição Debian" BARETITLE="true"
#use wml::debian::translation-check translation="1.18"
<H1>Constituição para o Projeto Debian (v1.3)</H1>
<p>Versão 1.3 ratificada em 24 de setembro de 2006. Substitui a
<a href="constitution.1.2">Versão 1.2</a> ratificada em 29 de
outubro de 2003. Substitui a <a href="constitution.1.1">Versão
1.1</a> ratificada em 21 de junho de 2003, que substituiu a
<a href="constitution.1.0">Versão 1.0</a> ratificada em 2 de
Dezembro de 1998.
</p>
<H2>1. Introdução</H2>
<P><CITE>O Projeto Debian é uma associação de indivíduos que têm
a causa comum de criar um sistema operacional livre.</CITE></P>
<P>Esse documento descreve a estrutura organizacional para tomadas
de decisões formais no Projeto. Ele não descreve os objetivos do
Projeto ou como alcança-los, nem contém quaisquer políticas exceto
aquelas diretamente relacionadas ao processo de tomada de decisões.</P>
<H2>2. Corpos e indivíduos na tomada de decisões</H2>
<P>Cada decisão no Projeto é tomada por um ou mais dos seguintes:</P>
<OL>
<LI>Os Desenvolvedores, por via de Resolução Geral ou votação;</LI>
<LI>O Líder do Projeto;</LI>
<LI>O Comitê Técnico e/ou seu Líder;</LI>
<LI>O Desenvolvedor particular trabalhando em uma tarefa particular;</LI>
<LI>Delegados apontados pelo Líder do Projeto para tarefas específicas;</LI>
<LI>O Secretário do Projeto.</LI>
</OL>
<P>A maior parte do restante desse documento irá descrever os poderes desses
corpos, sua composição e nomeação e o procedimento para suas tomadas de
decisões. Os poderes de uma pessoa ou corpo pode estar sujeito a revisão
e/ou limitação por outros; nesse caso o corpo revisor ou a a entrada da
pessoa irá mostrar isso. <CITE>Na lista acima, uma pessoa ou corpo é
normalmente listado antes de quaisquer pessoas ou corpos cujas tomadas
de decisões podem ser anuladas por este ou aqueles que eles (ajudam a)
nomeiam - mas nem todos os listados no início podem anular a todos listados
ao fim.</CITE></P>
<H3>2.1. Regras Gerais</H3>
<OL>
<LI>
<P>Nada nessa constituição impõe uma obrigação a alguém de trabalhar
para o Projeto. Uma pessoa que não quer trabalhar em uma tarefa a
que foi designada ou delegada a ela não precisa executá-la.
No entanto, elas não podem trabalhar ativamente contra essas regras
e decisões tomadas propriamente sob elas.</P>
</LI>
<LI>
<P>Uma pessoa pode ter vários cargos, exceto que o Líder do Projeto, o
Secretário do Projeto e o Líder do Comitê Técnico devem ser distintos
e que o Líder não pode nomear estes como seus Delegados.</P>
</LI>
<LI>
<P>Uma pessoa pode deixar o Projeto ou renunciar de um cargo em particular
que possua a qualquer momento, fazendo isso publicamente.</P>
</LI>
</OL>
<H2>3. Desenvolvedores Individuais</H2>
<H3>3.1. Poderes</H3>
<P>Um Desenvolvedor Individual pode</P>
<OL>
<LI>tomar qualquer decisão técnica ou não-técnica no que diz respeito
a seu próprio trabalho;</LI>
<LI>propor ou apadrinhar rascunhos de Resoluções Gerais;</LI>
<LI>propor a sí mesmo como candidato a Líder do Projeto nas
eleições;</LI>
<LI>votar em Resoluções Gerais e em eleições para Líder.</LI>
</OL>
<H3>3.2. Composição e nomeação</H3>
<OL>
<LI>
<P>Desenvolvedores são voluntários que concordam com os objetivos
futuros do Projeto como participantes dele e que mantém
pacotes para o Projeto ou fazem algum outro trabalho que
seja considerado importante pelo(s) Delegado(s) do
Líder do Projeto.</P>
</LI>
<LI>
<P>O(s) Delegado(s) do Líder do Projeto podem escolher não admitir
novos Desenvolvedores ou expelir Desenvolvedores existentes.
<CITE>Se os Desenvolvedores acham que os Delegados estão
abusando de sua autoridade eles podem, é claro, anular a
decisão por meio de uma Resolução Geral - veja
§4.1(3), §4.2.</CITE></P>
</LI>
</OL>
<H3>3.3. Procedimento</H3>
<P>Desenvolvedores podem tomar decisões quando eles acharem conveniente.</P>
<H2>4. Os Desenvolvedores por meio de uma Resolução Geral ou Votação</H2>
<H3>4.1. Poderes</H3>
<P>Juntos, os Desenvolvedores podem:</P>
<OL>
<LI>
<P>Nomear ou reeleger o Líder do Projeto.</P>
</LI>
<LI>
<P>Emendar esta constituição, desde que concordem com maioria de 3:1.</P>
</LI>
<li>
<p>Tomar ou anular qualquer decisão autorizada pelos poderes do Líder do
Projeto ou por um Delegado.</p>
</li>
<li>
<p>Tomar ou anular qualquer decisão autorizada pelo poderes do Comitê
Técnico, desde que concordem com maioria de 2:1.</p>
</li>
<LI>
<P>Criar, substituir e retirar documentos e declarações de políticas
não-técnicas.</P>
<P>Esses incluem documentos descrevendo os objetivos do projeto, sua
relação com outras entidades de software livre e políticas não-técnicas
como termos de licença de software livre com os quais o software no Debian
deve concordar.</P>
<P>Eles podem também incluir declarações sobre posicionamente sobre assuntos
do dia.</P>
<OL style="list-style: decimal;">
<LI>Um Documento Fundamental é um documento ou declaração considerada
crítica à missão e aos propósitos do Projeto.</LI>
<LI>Os Documentos Fundamentais são os trabalhos entitulados <q>Contrato
Social Debian</q> e <q>Definição Debian de Software Livre</q>.</LI>
<LI>Um Documento Fundamental requer uma maioridade de 3:1 para sua
substituição. Documentos Fundamentais novos são criados e os existentes
são retirados alterando a lista de Documentos Fundamentais nesta
constituição.</LI>
</OL>
</LI>
<li>
<p>Tomar decisões sobre propriedades mantidas em confiança para propósitos
relacionados ao Debian. (Veja §9.).</p>
</li>
<li>
<p>Em caso de um desentendimento entre o líder do projeto e o secretário
titular, apontar um novo secretário.</p>
</li>
</OL>
<H3>4.2. Procedimento</H3>
<OL>
<LI>
<P>Os desenvolvedores seguem o Procedimento de Resolução Padrão,
abaixo. Uma resolução ou emenda é introduzida se proposta por
qualquer Desenvolvedor e apadrinhada por pelo menos K outros
Desenvolvedores, ou se proposta pelo Líder do Projeto ou pelo
Comitê Técnico.</P>
</LI>
<LI>
<P>Adiando uma decisão tomada pelo Líder do Projeto ou seu Delegado:</P>
<OL>
<LI>Se o Líder do Projeto, ou seu Delegado, ou o Comitê Técnico
tomou uma decisão, então os Desenvolvedores podem anulá-la
passando uma resolução para tal; veja s4.1(3).</LI>
<LI>Se tal resolução for apadrinhada por pelo menos 2K Desenvolvedores,
ou se for proposta pelo Comitê Técnico, a resolução adia a decisão
imediatamente (desde que a resolução diga isso).</LI>
<LI>Se a decisão original foi para mudar um período de discussão ou
um período de votação, ou a resolução é para anular o Comitê
Técnico, então apenas K Desenvolvedores precisam apadrinhar a
resolução para que a decisão seja adiada.</LI>
<LI>Se a decisão é adiada, uma votação imediata acontece para determinar
se a decisão deve continuar até que a votação completa seja feita
ou se a implementação da decisão original será adiada até lá. Não
há quorum para esse procedimento de votação imediata.</LI>
<LI>Se o Líder do Projeto (ou o Delegado) retira a decisão original
a votação se torna um debate e não é mais conduzida.</LI>
</OL>
</LI>
<LI>
<P>
Votações são organizadas pelo Secretário do Projeto. Votos, estimativas
e resultados não serão revelados durante o período de votação;
depois da votação o Secretário do Projeto lista todos os votos.
O período de votação é de 2 semanas mas pode ser variado em até 1 semana
pelo Líder do Projeto.
</P>
</LI>
<LI>
<P>O período de discussão mínimo é de 2 semanas mas pode ser variado
em até uma semana pelo Líder do Projeto. O Líder do Projeto tem
o voto de minerva. Há um quorum de 3Q.</P>
</LI>
<LI>
<P>Propostas, padrinhos, emendas, chamadas para a votação e
outras ações formais são feitas anunciando em uma lista de
discussão publicamente legível designada pelo(s) Delegado(s)
do Líder do Projeto; qualquer Desenvolvedor pode postar
lá.</P>
</LI>
<LI>
<P>Os votos são enviados por email em uma maneira que convenha ao
Secretário. O Secretário determina para cada votação se os
votantes podem trocar seus votos ou não.</P>
</LI>
<LI>
<P>Q é a metade da raiz quadrada do número atual de Desenvolvedores.
K é Q ou 5, o que for menor. Q e K não precisam ser inteiros e não
são arredondados.</P>
</LI>
</OL>
<H2>5. Líder do Projeto</H2>
<H3>5.1. Poderes</H3>
<P>O <a href="leader">Líder do Projeto</a> pode:</P>
<OL>
<LI>
<P>Nomear Delegados ou delegar decisões ao Comitê Técnico.</P>
<P>O Líder pode definir uma área de responsabilidade ou uma decisão
específica e passá-la a qualquer outro desenvolvedor ou ao
Comitê Técnico.</P>
<P>Uma vez que uma decisão particular tenha sido delegada e tomada o
Líder do Projeto não pode voltar atrás na delegação; no entanto
ele pode voltar atrás em uma delegação corrente de uma área de
responsabilidade particular.</P>
</LI>
<LI>
<P>Emprestar autoridade a outros Desenvolvedores.</P>
<P>O Líder do Projeto pode criar declarações de suporte para pontos
de vista ou para outros membros do projeto, quando requisitado
ou não; essas declarações tem força se e apenas se o Líder
possuir poderes para tomar a decisão em questão.</P>
</LI>
<LI>
<P>Tomar decisões que requeiram ação urgente.</P>
<P>Isso não se aplica a decisões que se tornaram gradualmente urgentes
pela falta de ação relevante a menos que haja um prazo fixado.</P>
</LI>
<LI>
<P>Tomar decisões para as quais ninguém mais tem responsabilidade.</P>
</LI>
<LI>
<P>Propor rascunhos de Resoluções Gerais e emendas.</P>
</LI>
<LI>
<P>Juntamente com o Comitê Técnico, nomear novos membros para o
Comitê. (Veja §6.2.)</P>
</LI>
<LI>
<P>Usar um voto de minerva quando os Desenvolvedores votam.</P>
<P>O Líder do Projeto têm também um voto normal em tais votações.</P>
</LI>
<LI>
<P>Alterar o período de discussões para votações dos Desenvolvedores
(como acima).</P>
</LI>
<LI>
<P>Liderar discussões entre os Desenvolvedores.</P>
<P>O Líder do Projeto deve tentar tomar parte em discussões entre
os Desenvolvedores de uma maneira que ajude e traga as discussões
ao assunto chave. O Líder do Projeto não deve usar sua posição
de liderança para promover seus próprios pontos de vista.</P>
</LI>
<li>
<p>Em consulta com os desenvolvedores, tomar decisões que afetem
propriedades mantidas em confiança para propósitos relacionados
ao Debian. (Veja §9.). Tais decisões são comunicadas aos membros
pelo Líder do Projeto ou seu(s) Delegado(s). Gastos maiores deveriam
ser propostos e debatidos na lista de discussão antes dos fundos serem
despendidos.</p>
</li>
<li>
<p>Adicionar ou remover organizações da lista de organizações
de confiança (veja §9.3) que estão autorizadas a aceitar e
manter bens para o Debian. A avaliação e discussão que leva a
tal decisão ocorre em uma lista de discussão eletrônica designada
pelo Líder do Projeto ou seu(s) Delegado(s), na qual qualquer
desenvolvedor pode enviar mensagens. Há um período mínimo de
discussão de duas semanas antes que uma organização possa ser
adicionada à lista de organizações de confiança.</p>
</li>
</OL>
<H3>5.2. Nomeação</H3>
<OL>
<LI>O Líder do Projeto é eleito pelos Desenvolvedores.</LI>
<LI>A eleição começa nove semanas antes do posto de liderança
ficar vago ou (se já é muito tarde) imediatamente.</LI>
<LI>Pelas três semanas seguintes qualquer Desenvolvedor pode
nomear a si mesmo como um candidato a Líder do Projeto.</LI>
<LI>Pelas próximas três semanas nenhum candidato pode ser nomeado;
os candidatos devem usar esse tempo para fazer campanha (para
tornar suas identidades e posições conhecidas). Se não há
candidatos ao fim do período de nomeação então o período de
nomeação é extendido pelas três semanas seguintes, repetidamente
se necessário.</LI>
<LI>As próximas três semanas são o período de eleição durante o qual os
Desenvolvedores podem enviar seus votos. Votos nas eleições de
liderança são mantidos em segredo, mesmo após o término das
eleições.</LI>
<LI>As opções das cédulas serão aqueles candidatos que se nomearam e não
desistiram ainda, mais Nenhum Dos Acima. Se Nenhum Dos Acima
ganhar a eleição então o procedimento de eleição é repetido, muitas
vezes se necessário.</LI>
<LI>
A decisão será tomada usando o método especificado na seção §A.6
do Procedimento de Resolução Padrão. O quorum
é o mesmo que o usado em Resoluções Gerais (§4.2) e a
opção padrão é Nenhum Dos Acima.</LI>
<LI>O Líder do Projeto serve por um ano a partir de sua eleição.</LI>
</OL>
<H3>5.3. Procedimento</H3>
<P>O Líder do Projeto deve tentar tomar decisões que são consistentes
com o consenso das opiniões dos Desenvolvedores.</P>
<P>Onde couber, o Líder do Projeto deve informalmente solicitar os
pontos de vista dos Desenvolvedores.</P>
<P>O Líder do Projeto deve evitar que seu ponto de vista sobressaia quando
for tomar decisões em sua capacidade de Líder.</P>
<H2>6. Comitê Técnico</H2>
<H3>6.1. Poderes</H3>
<P>O <a href="tech-ctte">Comitê Técnico</a> pode:</P>
<OL>
<LI>
<P>Decidir em qualquer problema de política técnica.</P>
<P>Isso inclui o conteúdo dos manuais de políticas técnicas, materiais
de referência dos desenvolvedores, pacotes de exemplo e o comportamento
das ferramentas de construção de pacotes não experimentais. (Em cada caso
o mantenedor normal do programa relevante ou da documentação
toma as decisões inicialmente, no entanto; veja 6.3(5).)</P>
</LI>
<LI>
<P>Decidir qualquer assunto técnico onde há sobreposição da jurisdição
dos Desenvolvedores.</P>
<P>Em casos onde os Desenvolvedores precisam implementar políticas
técnicas ou locais (por exemplo, se eles não concordam sobre
as prioridades de pacotes conflitantes ou sobre o dono de um
nome de comando ou sobre qual pacote é responsável por um erro
que ambos os mantenedores concordam ser um erro) o comitê
técnico pode decidir o problema.</P>
</LI>
<LI>
<P>Tomar uma decisão quando requisitado para tal.</P>
<P>Qualquer pessoa ou corpo pode delegar uma decisão própria ao
Comitê Técnico ou procurar aconselhamento com ele.</P>
</LI>
<LI>
<P>Sobrepujar um Desenvolvedor (requer uma maioria de 3:1).</P>
<P>O Comitê Técnico pode pedir a um Desenvolvedor para tomar um
curso de ação técnica particular mesmo que o Desenvolvedor
não queira; isso requer uma maioria de 3:1. Por exemplo, o
Comitê pode determinar que uma reclamação feita pelo emissor
de um erro é justificada e que a solução proposta pelo emissor
deve ser implementada.</P>
</LI>
<LI>
<P>Oferecer conselhos.</P>
<P>O Comitê Técnico pode fazer anúncios formais sobre seus pontos de vista
sobre qualquer problema. <CITE>Membros individuais podem, é claro, criar
declarações informais sobre seus pontos de vista e sobre os prováveis
pontos do Comitê.</CITE></P>
</LI>
<LI>
<P>Juntamente com o Líder do Projeto, nomear novos membros para si
ou remover membros existentes. (Veja §6.2.)</P>
</LI>
<LI>
<P>Nomear o Líder do Comitê Técnico.</P>
<P>
O Líder é eleito pelo Comitê, entre seus membros. Todos os membros do
comitê estão automáticamente nomeados; o comitê começa a votar com uma
semana faltando para que o posto fique vago (ou imediatamente se já
é muito tarde). Os membros podem votar por aclamação pública em
qualquer colega membro do comitê, incluindo a si mesmos; não há
opção padrão. A votação acaba quando todos os membros votaram
ou quando o período de votos estiver terminado. O resultado é determinado
usando o método especificado na seção A.6 do Procedimento de Resolução Padrão..</P>
</LI>
<LI>
<P>O Líder do Comitê pode servir de Líder do Projeto, juntamente com o
Secretário</P>
<P>Como detalhado em §7.1(2), o Líder do Comitê Técnico e o
Secretário do Projeto podem, juntos, servirem como Líderes do
Projeto se não houver Líder.</P>
</LI>
</OL>
<H3>6.2. Composição</H3>
<OL>
<LI>
<P>O Comitê Técnico consiste em até 8 Desenvolvedores e
normalmente deve ter pelo menos 4 membros.</P>
</LI>
<LI>
<P>Quando há menos de 8 membros o Comitê Técnico pode recomendar
membros novos ao Líder do Projeto, que pode escolher
(indivualmente) nomeá-los ou não.</P>
</LI>
<LI>
<P>Quando houver 5 membros ou menos o Comitê Técnico pode nomear
membros novos até que o número de membros atinja 6.</P>
</LI>
<LI>
<P>Quando houver 5 membros ou menos por pelo menos uma semana o Líder
do Projeto pode nomear novos membros até que o número de
membros atinja 6, em intervalos de pelo menos uma semana por
nomeação.</P>
</LI>
<LI>
<P>Se o Comitê Técnico e o Líder do Projeto concordarem, eles
podem remover ou substituir um membro existente do Comitê
Técnico.</P>
</LI>
</OL>
<H3>6.3. Procedimento</H3>
<OL>
<LI>
<P>O Comitê Técnico usa o Procedimento Padrão de Resolução.</P>
<P>Um rascunho de resolução ou emenda pode ser proposto por qualquer
membro do Comitê Técnico. Não há período de discussão mínimo;
o período de votação dura por uma semana ou até que o resultado
não seja mais duvidoso. Os membros podem mudar seus votos.
Há um quorum de dois.</P>
</LI>
<LI>
<P>Detalhes relacionados à votação</P>
<P>O Líder tem um voto de minerva. Quando o Comitê Técnico vota
para sobrepujar um Desenvolvedor que também é membro do
Comitê, esse membro não pode votar (a menos que seja o
Líder, nesse caso ele pode usar apenas seu voto de minerva).</P>
</LI>
<LI>
<P>Discussão Pública e tomada de decisões.</P>
<P>Discussão, rascunhos de resoluções e emendas e votos dos membros
do comitê são feitos publicamente na lista de discussão do
Comitê Técnico. Não há secretário separado para o Comitê.</P>
</LI>
<LI>
<P>Nomeações Confidenciais.</P>
<P>O Comitê Técnico pode manter discussões confidenciais via email
privado ou lista de discussão privada ou outros meios para discutir
nomeações para o Comitê. No entanto, as votações para as nomeações
devem ser públicas.</P>
</LI>
<LI>
<P>Não criar trabalhos de desing detalhados.</P>
<P>O Comitê Técnico não entra no desenho de novas propostas e políticas.
Tal trabalho deve ser conduzido por indivíduos privadamente ou
junto com outros e discutido em fóruns ordinários de design e
políticas técnicas.</P>
<P>O Comitê Técnico restringe a si escolher ou adotar compromissos
entre soluções e decisões que foram propostas e razoavelmente discutidas
em outros lugares.</P>
<P><CITE>Membros individuais do comitê técnico podem, é claro, participar
por si mesmos no trabalho de design e políticas.</CITE></P>
</LI>
<LI>
<P>O Comitê Técnico toma decisões apenas como último recurso.</P>
<P>O Comitê Técnico não toma uma decisão técnica até que esforços
para se resolver a questão via consenso tenham sido feitos
e falhado a menos que ele tenha sido solicitado para tomar
uma decisão pela pessoa ou corpo que seria normalmente responsável
por ela.</P>
</LI>
</OL>
<H2>7. O Secretário do Projeto</H2>
<H3>7.1. Poderes</H3>
<P>O <a href="secretary">Secretário</a>:</P>
<OL>
<LI>
<P>Pega os votos entre os Desenvolvedores e determina o número
e a identidade dos Desenvolvedores, sempre que requerido por
essa constituição.</P>
</LI>
<LI>
<P>Pode servir de Líder do Projeto, junto com o Líder do Comitê
Técnico.</P>
<P>Se não há Líder do Projeto então o Líder do Comitê Técnico
e o Secretário do Projeto podem por concordância tomar
decisões se eles considerarem isso imperativo.</P>
</LI>
<LI>
<P>Resolve qualquer disputa sobre a interpretação da constituição.</P>
</LI>
<LI>
<P>Pode delegar parte ou toda a sua autoridade para alguém ou
desistir dessa delegação a qualquer momento.</P>
</LI>
</OL>
<H3>7.2. Nomeação</H3>
<P>O Secretário do Projeto é nomeado pelo Líder do Projeto e pelo
Secretário atual do Projeto.</P>
<p>Se o Líder do Projeto e o Secretário do Projeto atuais não podem
concordar em uma nova nomeação eles devem pedir aos Desenvolvedores
via uma Resolução Geral que nomeiem um Secretário.</p>
<P>Se não há Secretário do Projeto ou o Secretário atual está indisponível
e não delegou autoridade para uma decisão, então a decisão pode ser
tomada ou delegada pelo Líder do Comitê Técnico, como Secretário
Agente.</P>
<P>O mandato do Secretário do Projeto é de 1 ano, depois do qual
ele ou outro Secretário deve ser (re)nomeado.</P>
<H3>7.3. Procedimento</H3>
<P>O Secretário do Projeto deve tomar decisões que são bem razoaveis
e preferívelmente consistentes com o consenso dos Desenvolvedores.</P>
<P>Quando agindo conjuntamente como Líderes do Projeto o Líder do
Comitê Técnico e o Secretário do Projeto devem tomar decisões somente
quando absolutamente necessárias e somente quando consistentes com o
consenso dos Desenvolvedores.</P>
<H2>8. Os Delegados do Líder do Projeto</H2>
<H3>8.1. Poderes</H3>
<P>Os Delegados do Líder do Projeto:</P>
<OL>
<LI>tem poderes delegados a eles pelo Líder do Projeto;</LI>
<LI>podem tomar certas decisões que o Líder não pode tomar diretamente,
incluindo aprovação ou removeção de Desenvolvedores ou designação
de pessoas como Desenvolvedores que não mantém pacotes. <CITE>Isso
é para evitar concentração de poder, particularmente sobre a entrada
de Desenvolvedores, nas mãos do Líder do Projeto.</CITE></LI>
</OL>
<H3>8.2. Nomeação</H3>
<P>Os Delegados são nomeados pelo Líder do Projeto e podem ser substituídos
pelo Líder a seu critério. O Líder do Projeto não pode dar a posição de
Delegado com condições sobre decisões particulares do Delegado nem pode
anular uma decisão tomada por um Delegado uma vez que esteja tomada.</P>
<H3>8.3. Procedimento</H3>
<P>Os Delegados podem tomar decisões como acharem melhor mas devem tentar
implementar decisões técnicas boas e/ou seguir a opinião do consenso.</P>
<H2>9. Bens mantidos em confiança para o Debian</H2>
<p>Na maioria das jurisdições ao redor do mundo, o projeto Debian não está
em posição de diretamente manter fundos ou outras propriedades. Portanto,
propriedades têm que ser mantidas por uma das várias organizações conforme
detalhado em §9.2.</p>
<p>Tradicionalmente, SPI era a única organização autorizada a guardar
propriedades e dinheiro para o Projeto Debian. SPI foi criada nos EUA
para guardar dinheiro em confiança lá.</p>
<p>A <a href="http://www.spi-inc.org";>SPI</a> e o Debian são organizações
separadas que compartilham alguns objetivos.
O Debian é grato pelo suporte legal oferecido pela SPI.</p>
<H3>9.1. Relacionamento com Organizações Associadas</H3>
<OL>
<li>
<p>Desenvolvedores Debian não se tornam agentes ou empregados
de organizações mantendo bens em confiança para o Debian, ou
uns dos outros, ou de pessoas com autoridade no Projeto Debian,
somente pela virtude de serem Desenvolvedores Debian. Uma pessoa
agindo como um Desenvolvedor o faz como indivíduo, em nome
próprio. Tais organizações podem, de acordo próprio,
estabelecer relacionamentos com indivíduos que também sejam
desenvolvedores Debian.</p>
</li>
</ol>
<H3>9.2. Autoridade</H3>
<ol>
<li>
<p>Uma organização mantendo bens para o Debian não tem autoridade
sobre decisões técnicas ou não-técnicas do Debian, exceto que
nenhuma decisão do Debian com respeito a quaisquer propriedades
mantidas pela organização irá requerer que a mesma atue fora de sua
própria autoridade legal.</p>
</li>
<li>
<p>O Debian não clama por autoridade sobre uma organização que mantém
bens para o Debian além da autoridade sobre o uso das propriedades
mantidas em confiança para o Debian.</p>
</li>
</ol>
<h3>9.3. Organizações confiáveis</h3>
<p>Quaisquer doações para o Projeto Debian devem ser feitas para qualquer
uma das organizações designadas pelo Líder do Projeto (ou um delegado)
para serem autorizadas a manusear bens a serem usados para o Projeto
Debian.</p>
<p>Organizações mantendo bens em confiança para o Debian devem se encarregar
das obrigações razoáveis para o manuseio de tais bens.</p>
<p>O Debian mantém pública uma Lista de Organizações de Confiança que
aceitam doações e mantêm bens em confiança para o Debian
(incluindo ambos propriedade tangível e propriedade intelectual)
que inclui os compromissos que essas organizações fizeram sobre
como estes bens serão manuseados.</p>
<H2>A. Procedimento Padrão para Resolução</H2>
<P>Essas regras aplicam-se a tomadas de decisões comunais por comitês e
plebiscitos, onde colocado acima.</P>
<H3>A.1. Proposta</H3>
<P>O procedimento formal começa quando um rascunho de resolução é
proposto e apadrinhado, como requerido.</P>
<H3>A.1. Discussão e Emendamento</H3>
<OL>
<LI>Seguindo a proposta, a resolução pode ser discutida. Emendas devem
ser tornadas formais sendo propostas e apadrinhadas de acordo
com os requerimentos para uma nova resolução ou diretamente pelo
proponente da resolução original.</LI>
<LI>Um emendamento formal pode ser aceito pelo proponente da resolução
em cujo caso o rascunho da resolução formal é imediamente alterado
para igualar-se.</LI>
<LI>Se um emendamento formal não é aceito ou um dos padrinhos da resolução
não concordam com a aceitação pelo proponente de um emendamento
formal, o emendamento continua como um emendamento e será votado.</LI>
<LI>Se um emendamento aceito pelo proponente original não é do gosto
dos outros, eles podem propor outra emenda para reverter a
mudança feita anteriormente (novamente, eles precisam atingir
os requerimentos para proponente e padrinho(s).)</LI>
<LI>O proponente ou uma resolução pode sugerir mudanças para os dizeres
dos emendamentos; esses tomam efeito se o proponente do emendamento
concordar e nenhum dos padrinhos objetarem. Nesse caso o emendamento
mudado será votado ao invés dos originais</LI>
<LI>O proponente de uma resolução pode fazer mudanças para correção de
erros pequenos (por exemplo erros tipográficos ou inconsistências)
ou mudanças que não alteram o significado, desde que ninguém objete
dentro de 24 horas. Nesse caso o período de discussão mínimo não
é reiniciado.</LI>
</OL>
<H3>A.2. Chamada para votação</H3>
<OL>
<LI>O proponente ou um padrinho de uma moção ou uma emenda pode chamar
para uma votação, desde que o período de discussão mínimo (se
houver) tiver terminado.</LI>
<LI>O proponente ou qualquer padrinho de uma resolução podem chamar para uma
votação naquela resolução e todas as emendas relacionadas.</LI>
<LI>A pessoa que chama para uma votação diz o que acha que os
dizeres da resolução e quaisquer emendas relevantes devam ser e,
consequentemente a forma que a votação deve tomar. No entanto,
a decisão final na forma da(s) votação(ões) é do Secretário -
veja 7.1(1), 7.1(3) e A.3(4).</LI>
<LI>
O período de discussão mínimo é contado a partir do momento em que
a última emenda é aceita ou do momento que a resolução
completa foi proposta se nenhuma emenda foi proposta e aceita.</LI>
</OL>
<H3>A.3. Procedimento de Votação</H3>
<OL>
<LI>
Cada resolução e suas emendas relacionadas são votadas em uma única
cédula que incluí uma opção para a resolução original, cada emenda,
e a opção padrão (aonde aplicável).
</LI>
<LI>
A opção padrão não deve ter nenhum requerimento de supermaioridade.
Opções que não tiverem um requerimento explícito de supermaioridade
tem um requerimento de maioridade 1:1.
</LI>
<LI>
Os votos são contados de acordo com as regras em A.6. A opção padrão é
"Mais Discussões", a não ser que outra seja especificada.
</LI>
<LI>Em casos de dúvida, o Secretário do Projeto decidirá as questões de
procedimento.</LI>
</OL>
<H3>A.4. Retirando resoluções ou emendas não aceitas</H3>
<P>O proponente de uma resolução ou emenda não aceita pode retirá-la.
Nesse caso novos proponentes podem vir e mantê-la viva, a
primeira pessoa a fazê-lo torna-se o novo proponente e quaisquer outros
se tornam padrinhos se já não o são.</P>
<P>Um padrinho de uma resolução ou emenda (a menos que ela tenha sido
aceita) pode retirá-la.</P>
<P>Se a retirada do proponente e/ou padrinhos significa que uma resolução
não tem proponente ou padrinhos o suficiente ela não será votada a menos
que isso seja retificado antes do vencimento da resolução.</P>
<H3>A.5. Vencimento</H3>
<P>
Se uma resolução proposta não foi discutida, emendada, votada ou de
outra forma manejada por 4 semanas, o Secretário pode avisar que a questão
está sendo retirada. Se nenhum dos padrinhos de qulquer um dos proponentes
discordar durante 1 semana, a questão é retirada.
</P>
<P>
O Secretário também pode incluir sugestões de como proceder, se
apropriado.
</P>
<H3>A.6. Contagem de Votos</H3>
<OL>
<li> A cédula de cada votante gradua as opções que estão sendo votadas.
Nem todas as opções precisam ser graduadas. Opções graduadas são
consideradas preferidas em relação às não-graduadas. Votantes podem
graduar opções igualmente. Opções não graduadas são consideradas como
graduadas igualmente entre si. Detalhes de como as cédulas podem ser
preenchidas serão incluídas na Chamada para Votos.
</li>
<li> Se a votação tiver um requerimento de quorum R qualquer opção que não
seja a padrão que não receber pelo menos R votos graduando aquela opção
acima da padrão é desconsiderada.
</li>
<li> Qualquer opção (não padrão) que não vencer a opção padrão na sua
proporção requerida de maioridade é desconsiderada.
<ol>
<li>
Dadas duas opções A e B, V(A,B) é o número de votantes que
preferem a opção A sobre a B.
</li>
<li>
Uma opção A vence a opção padrão D por uma proporção de
maioridade N se V(A,D) for estritamente maior que N * V(D,A).
</li>
<li>
Se uma supermaioridade de S:1 é requerida por A, sua proporção
de maioridade é S; caso contrário, sua proporção de maioridade é 1.
</li>
</ol>
</li>
<li> Da lista de opções consideradas, nós geramos uma lista de vitórias
em pares.
<ol>
<li>
Uma opção A vence uma opção B se V(A,B) for estritamente maior
que V(B,A)
</li>
</ol>
</li>
<li> Da lista de vitórias em pares [não desconsideradas], nós geramos um
conjunto de vitórias transitivas.
<ol>
<li>
Uma opção A vence transitivamente uma opção C se A vencer C ou se
há alguma outra opção B aonde A vence B E B vence C transitivamente.
</li>
</ol>
</li>
<li> Nós construímos o conjunto Schwartz do conjunto de vitórias transitivas.
<ol>
<li>
Uma opção A está no conjunt Schwartz se para todas as opções B,
A vence transitivamente de B ou B não vence transitivamente A.
</li>
</ol>
</li>
<li> Se houverem vitórias entre opções no conjunto Schwartz, nós removemos
a mais fraca destas vitórias da lista de vitórias em pares, e
retornamos para o passo 5.
<ol>
<li>
Uma vitória (A,X) é mais fraca que uma vitória (B,Y) se V(A,X)
for menor que V(B,Y). (A,X) também é mais fraca que (B,Y) se V(A,X)
for igual a V(B,Y) e V(X,A) for maior que V(Y,B).
</li>
<li>
A vitória mais fraca é aquela que não possuí uma vitória mais fraca
que ela. Pode haver mais que uma destas vitórias.
</li>
</ol>
</li>
<li> Se não houverem vitórias dentro do conjunto Schwartz, então o vencedor é
escolhido das opções do conjunto Schwartz. Se houver apenas uma dessas
opções, esta é a vencedora. Se houverem múltiplas opções, o eleitor com o
voto dado escolhe qual das opções ganha.
</li>
</OL>
<p>
<strong>Nota:</strong> Opções que os votantes graduam acima da opção padrão
são opções que eles acham aceitáveis. Opções graduadas abaixo da opção padrão
são opções que eles acham inaceitáveis.
</p>
<P><CITE>Quando o Procedimento Padrão de Resolução vai ser usado,
o texto que se refere a ela deve especificar o que é suficiente para
se ter um rascunho de resolução proposto e/ou apadrinhado, qual o
período de discussão mínimo e qual o período mínimo de votação.
Deve também especificar qualquer supermaioria e/ou quorum (e opção
padrão) a ser usado.</CITE></P>
<H2>B. Uso de linguagem e tipografia</H2>
<P>O presente do indicativo ('é', por exemplo) significa que a
declaração é uma regra nessa constituição. `Pode' indica que a
pessoa ou corpo tem prudência. `Deve' significa que será considerado
uma boa coisa se a sentença for obedecida, mas esta não é obrigatória.
<CITE>Texto marcado como citação, como esse, é um raciocínio e não
é parte da constituição. Ele deve ser usado apenas para ajudar
na interpretação em casos duvidosos.</CITE></P>
--- constitution.wml 2006-10-12 21:31:46.423596750 -0300
+++ constitution-faw.wml 2006-10-15 02:52:40.421653750 -0200
@@ -1,13 +1,15 @@
#use wml::debian::template title="Constituição Debian" BARETITLE="true"
-#use wml::debian::translation-check translation="1.16"
+#use wml::debian::translation-check translation="1.18"
-<H1>Constituição para o Projeto Debian (v1.2)</H1>
+<H1>Constituição para o Projeto Debian (v1.3)</H1>
- <P>Versão 1.2 ratificada em 29 de outubro de 2003. Substitui a <a
- href="constitution.1.1">Versão 1.1</a> ratificada em 21 de junho de
- 2003, que substituiu a <a href="constitution.1.0">Versão 1.0</a>
- ratificada em 2 de Dezembro de 1998.
- </P>
+ <p>Versão 1.3 ratificada em 24 de setembro de 2006. Substitui a
+ <a href="constitution.1.2">Versão 1.2</a> ratificada em 29 de
+ outubro de 2003. Substitui a <a href="constitution.1.1">Versão
+ 1.1</a> ratificada em 21 de junho de 2003, que substituiu a
+ <a href="constitution.1.0">Versão 1.0</a> ratificada em 2 de
+ Dezembro de 1998.
+ </p>
<H2>1. Introdução</H2>
@@ -128,15 +130,15 @@
<P>Emendar esta constituição, desde que concordem com maioria de 3:1.</P>
</LI>
- <LI>
- <P>Anular qualquer decisão tomada pelo Líder do Projeto ou por um
- Delegado.</P>
- </LI>
+ <li>
+ <p>Tomar ou anular qualquer decisão autorizada pelos poderes do Líder do
+ Projeto ou por um Delegado.</p>
+ </li>
- <LI>
- <P>Anular qualquer decisão tomada pelo Comitê Técnico, desde que concordem
- com maioria de 2:1.</P>
- </LI>
+ <li>
+ <p>Tomar ou anular qualquer decisão autorizada pelo poderes do Comitê
+ Técnico, desde que concordem com maioria de 2:1.</p>
+ </li>
<LI>
<P>Criar, substituir e retirar documentos e declarações de políticas
@@ -162,11 +164,15 @@
</OL>
</LI>
- <LI>
- <P>Juntos com o Líder do Projeto e o SPI, tomar decisões sobre propriedades
- guardadas em confiança para propósitos relacionados ao Debian. (Veja
- §9.1.)</P>
- </LI>
+ <li>
+ <p>Tomar decisões sobre propriedades mantidas em confiança para propósitos
+ relacionados ao Debian. (Veja §9.).</p>
+ </li>
+
+ <li>
+ <p>Em caso de um desentendimento entre o líder do projeto e o secretário
+ titular, apontar um novo secretário.</p>
+ </li>
</OL>
<H3>4.2. Procedimento</H3>
@@ -313,11 +319,24 @@
de liderança para promover seus próprios pontos de vista.</P>
</LI>
- <LI>
- <P>Juntamente com o SPI, tomar decisões que afetem a propriedade
- guardada em confiança para propósitos relacionados ao Debian.
- (Veja §9.1.)</P>
- </LI>
+ <li>
+ <p>Em consulta com os desenvolvedores, tomar decisões que afetem
+ propriedades mantidas em confiança para propósitos relacionados
+ ao Debian. (Veja §9.). Tais decisões são comunicadas aos membros
+ pelo Líder do Projeto ou seu(s) Delegado(s). Gastos maiores deveriam
+ ser propostos e debatidos na lista de discussão antes dos fundos serem
+ despendidos.</p>
+ </li>
+ <li>
+ <p>Adicionar ou remover organizações da lista de organizações
+ de confiança (veja §9.3) que estão autorizadas a aceitar e
+ manter bens para o Debian. A avaliação e discussão que leva a
+ tal decisão ocorre em uma lista de discussão eletrônica designada
+ pelo Líder do Projeto ou seu(s) Delegado(s), na qual qualquer
+ desenvolvedor pode enviar mensagens. Há um período mínimo de
+ discussão de duas semanas antes que uma organização possa ser
+ adicionada à lista de organizações de confiança.</p>
+ </li>
</OL>
<H3>5.2. Nomeação</H3>
@@ -589,9 +608,9 @@
<P>O Secretário do Projeto é nomeado pelo Líder do Projeto e pelo
Secretário atual do Projeto.</P>
-<P>Se o Líder do Projeto e o Secretário do Projeto atuais não podem
-concordar em uma nova nomeação eles devem solicitar à bancada do SPI
-(veja §9.1.) para nomear um Secretário.</P>
+<p>Se o Líder do Projeto e o Secretário do Projeto atuais não podem
+concordar em uma nova nomeação eles devem pedir aos Desenvolvedores
+via uma Resolução Geral que nomeiem um Secretário.</p>
<P>Se não há Secretário do Projeto ou o Secretário atual está indisponível
e não delegou autoridade para uma decisão, então a decisão pode ser
@@ -639,67 +658,68 @@
<P>Os Delegados podem tomar decisões como acharem melhor mas devem tentar
implementar decisões técnicas boas e/ou seguir a opinião do consenso.</P>
-<H2>9. Software in the Public Interest</H2>
-
-<p>O <a href="http://www.spi-inc.org";>SPI</a> e o Debian são organizações
-separadas que compartilham alguns
-objetivos. O Debian é grato pelo suporte legal oferecido pelo SPI.
-<CITE>Os Desenvolvedores do Debian são atualmente membros do SPI em
-virtude do seu status de Desenvolvedores.</CITE></P>
+<H2>9. Bens mantidos em confiança para o Debian</H2>
-<H3>9.1. Autoridade</H3>
-
-<OL>
- <LI>O SPI não tem autoridade relativa a decisões técnicas ou não-técnicas
- do Debian, exceto que nenhuma decisão do Debian com respeito a
- qualquer propriedade guardada pelo SPI deve requerer que o SPI
- haja fora de sua autoridade legal e que a constituição do Debian
- pode ocasionalmente usar o SPI como um corpo de decisão em último
- recurso.</LI>
-
- <LI>O Debian não reivindica nenhuma autoridade sobre o SPI a não ser
- sobre o uso de algumas das propriedades do SPI, descritas abaixo,
- apesar de os Desenvolvedores Debian terem autoridade dentro do SPI
- de acordo com as regras do SPI.</LI>
-
- <LI>Os Desenvolvedores Debian não são agentes ou empregados do SPI ou
- vice-versa, nem de pessoas de autoridade no Projeto Debian.
- Uma pessoa agindo como um Desenvolvedor o faz como um indivíduo
- em seu próprio nome.</LI>
-</OL>
-
-<H3>9.2. Gerenciamento de propriedades para propósitos relacionados ao Debian</H3>
-
-<P>Já que o Debian não tem autoridade para guardar dinheiro ou propriedades,
-qualquer doação para o Projeto Debian deve ser feita ao SPI, que gerencia
-tais negócios.</P>
-
-<P>O SPI tem as seguintes incumbências:</P>
-
-<OL>
- <LI>O SPI irá guardar dinheiro, marcas e outras propriedades
- tangíveis ou intangíveis e gerenciar outros negócios
- para propósitos relacionados ao Debian.</LI>
-
- <LI>Tal propriedade será contabilizada separadamente e guardada em
- confiança para esses propósitos, decididos pelo Debian e pelo
- SPI de acordo com essa seção.</LI>
+<p>Na maioria das jurisdições ao redor do mundo, o projeto Debian não está
+em posição de diretamente manter fundos ou outras propriedades. Portanto,
+propriedades têm que ser mantidas por uma das várias organizações conforme
+detalhado em §9.2.</p>
+
+<p>Tradicionalmente, SPI era a única organização autorizada a guardar
+propriedades e dinheiro para o Projeto Debian. SPI foi criada nos EUA
+para guardar dinheiro em confiança lá.</p>
+
+<p>A <a href="http://www.spi-inc.org";>SPI</a> e o Debian são organizações
+separadas que compartilham alguns objetivos.
+O Debian é grato pelo suporte legal oferecido pela SPI.</p>
+
+<H3>9.1. Relacionamento com Organizações Associadas</H3>
+
+<OL>
+ <li>
+ <p>Desenvolvedores Debian não se tornam agentes ou empregados
+ de organizações mantendo bens em confiança para o Debian, ou
+ uns dos outros, ou de pessoas com autoridade no Projeto Debian,
+ somente pela virtude de serem Desenvolvedores Debian. Uma pessoa
+ agindo como um Desenvolvedor o faz como indivíduo, em nome
+ próprio. Tais organizações podem, de acordo próprio,
+ estabelecer relacionamentos com indivíduos que também sejam
+ desenvolvedores Debian.</p>
+ </li>
+</ol>
- <LI>O SPI não irá dispor ou usar propriedade guardada em confiança para
- o Debian sem aprovação do Debian, que pode ser dada pelo Líder do
- Projeto ou por Resolução Geral dos Desenvolvedores.</LI>
+<H3>9.2. Autoridade</H3>
- <LI>O SPI considerará usar ou dispor de propriedade guardada em confiança
- para o Debian quando requisitada a fazer tal pelo Líder do Projeto.</LI>
+<ol>
+ <li>
+ <p>Uma organização mantendo bens para o Debian não tem autoridade
+ sobre decisões técnicas ou não-técnicas do Debian, exceto que
+ nenhuma decisão do Debian com respeito a quaisquer propriedades
+ mantidas pela organização irá requerer que a mesma atue fora de sua
+ própria autoridade legal.</p>
+ </li>
+ <li>
+ <p>O Debian não clama por autoridade sobre uma organização que mantém
+ bens para o Debian além da autoridade sobre o uso das propriedades
+ mantidas em confiança para o Debian.</p>
+ </li>
+</ol>
- <LI>O SPI usará ou disporá de propriedade guardada em confiança para o Debian
- quando requisitado a fazê-lo por Resolução Geral dos Desenvolvedores,
- dado que isso seja compatível com a autoridade legal do SPI.</LI>
+<h3>9.3. Organizações confiáveis</h3>
- <LI>O SPI notificará os Desenvolvedores por correio eletrônico para uma
- lista de discussão do Projeto Debian quando ele usar ou dispor de
- propriedade guardada em confiança para o Debian.</LI>
-</OL>
+<p>Quaisquer doações para o Projeto Debian devem ser feitas para qualquer
+uma das organizações designadas pelo Líder do Projeto (ou um delegado)
+para serem autorizadas a manusear bens a serem usados para o Projeto
+Debian.</p>
+
+<p>Organizações mantendo bens em confiança para o Debian devem se encarregar
+das obrigações razoáveis para o manuseio de tais bens.</p>
+
+<p>O Debian mantém pública uma Lista de Organizações de Confiança que
+aceitam doações e mantêm bens em confiança para o Debian
+(incluindo ambos propriedade tangível e propriedade intelectual)
+que inclui os compromissos que essas organizações fizeram sobre
+como estes bens serão manuseados.</p>
<H2>A. Procedimento Padrão para Resolução</H2>
Reply to: