[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[TAF] wml://devel/constitution.wml



Hola a todos/as

Llevo un montón de tiempo con el ITT de la actualización de la constitución de Debian pero no consigo terminarla, y veo que es poco realista seguir con dicha traducción asignada porque no creo que encuentre un rato largo con pensamiento claro para acabarla.

Así que envío este TAF (Travail À Faire) a la lista, por si alguien puede y quiere seguir con ello. En el documento adjunto, está avanzada la traducción hasta la línea:

#### HASTA AQUÍ LA ACTUALIZACIÓN DE LA TRADUCCIÓN ####

a partir de esa marca el documento no está revisado.

Nota importante: en este tiempo la constitución de Debian ha vuelto a actualizarse, por lo que aunque el archivo que adjunto y el TAF es para constitution.wml, realmente ese archivo pasará a ser, una vez actualizado, constitution.1.8.wml, y a partir del 1.8 habría que incorporar los últimos cambios de la versión 1.9 (esos son más sencillos).

Si alguien quiere ponerse con ello y tiene dudas que escriba o me contacte por IRC.

Si nadie lo retoma, quizá yo pueda retomarlo durante el mes de julio, pero no estoy segura. Si decido retomarlo yo enviaría un nuevo ITT.

Muchas gracias y saludos
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
#use wml::debian::template title="Constitución de Debian" BARETITLE="true"
#use wml::debian::translation-check translation="5a315ddb15a28dd0269d23be676be33d0f75f371" maintainer="Laura Arjona Reina" mindelta="-1" maxdelta="1"
#use wml::debian::toc

<h1>Constitución del Proyecto Debian (v.1.8)</h1>

<p>Versión 1.8 ratificada el 28 de enero de 2022.</p>

<p>Sustituye a la 
<a href="constitution.1.7">versión 1.7</a> ratificada el 14 de agosto de 2016, a la
<a href="constitution.1.6">versión 1.6</a> ratificada el 13 de diciembre de 2015, a la
<a href="constitution.1.5">versión 1.5</a> ratificada el 9 de enero de 2015, a la
<a href="constitution.1.4">versión 1.4</a> ratificada el 7 de octubre de 2007, a la
<a href="constitution.1.3">versión 1.3</a> ratificada el 24 de septiembre de 2006, a la
<a href="constitution.1.2">versión 1.2</a> ratificada el 29 de octubre de 2003, a la
<a href="constitution.1.1">versión 1.1</a> ratificada el 21 de junio de 2003
y a la <a href="constitution.1.0">versión 1.0</a> ratificada el 2 de diciembre de 
1998.</p>

<toc-display />

<toc-add-entry name="item-1">1. Introducción</toc-add-entry>

<p><cite>El Proyecto Debian es una asociación de individuos que han hecho
causa común para crear un sistema operativo libre.</cite></p>

<p>Este documento describe la estructura organizativa para la toma formal de
decisiones en el Proyecto. No describe las metas del Proyecto o cómo
alcanzarlas, ni contiene ninguna norma excepto aquellas relacionadas
directamente con el proceso de toma de decisiones.</p>

<toc-add-entry name="item-2">2. Individuos y organismos de toma de decisiones</toc-add-entry>

<p>Cada decisión en el Proyecto la toman uno o más de los siguientes:</p>

<ol>
  <li>Los Desarrolladores, mediante una Resolución General
      o una elección;</li>

  <li>El Líder del Proyecto;</li>

  <li>El Comité Técnico o su Presidente (chair);</li>

  <li>El Desarrollador que trabaja en una tarea determinada;</li>

  <li>Delegados nombrados por el Líder del Proyecto para tareas
  específicas;</li>

  <li>El Secretario del Proyecto.</li>
</ol>

<p>La mayoría del resto de este documento describirá 
las atribuciones de estos organismos, su composición y nombramientos, y el
proceso de toma de decisiones. Las atribuciones de una persona u organismo
pueden estar sujetos a revisión y/o limitación por parte de terceros; en
ese caso el organismo o personas encargadas de la revisión indicarán dicha
posibilidad. <cite>En la lista anterior, normalmente se lista a una
persona u organismo antes de aquellos cuyas decisiones puede anular o a
los que escoge (o ayuda a escoger); pero no todos los que se nombran al
principio mandan sobre todos los posteriores.</cite></p>

<h3>2.1. Reglas generales</h3>

<ol>
  <li>
    <p>Nada en esta constitución impone obligaciones a nadie que trabaje
    para el Proyecto. Una persona que no quiera hacer la tarea que le ha
    sido delegada o asignada no necesita hacerla. Sin embargo, no se debe
    actuar activamente en contra de estas reglas y las decisiones tomadas
    habiéndolas seguido apropiadamente.</p>
  </li>

  <li>
    <p>Una persona puede ocupar varios puestos, pero los puestos de Líder del
    Proyecto, Secretario del Proyecto y Presidente
    del Comité Técnico deben ostentarlos personas distintas, además de que el
    Líder no puede elegirlos como sus Delegados.</p>
  </li>

  <li>
    <p>Una persona puede abandonar el Proyecto o dimitir de un cargo en
    particular, en cualquier momento, diciéndolo públicamente.</p>
  </li>
</ol>

<toc-add-entry name="item-3">3. Desarrolladores individuales</toc-add-entry>

<h3>3.1. Atribuciones</h3>

<p>Un Desarrollador puede</p>

<ol>
  <li>tomar una decisión técnica o no técnica con respecto a su propio
  trabajo;</li>

  <li>proponer o patrocinar borradores de Resoluciones Generales;</li>

  <li>proponerse a sí mismo como candidato a Líder del Proyecto durante
  las elecciones;</li>

  <li>votar en las Resolución Generales y en las elecciones a Líder.</li>
</ol>

<h3>3.2. Composición y nombramiento</h3>

<ol>
  <li>
    <p>Los Desarrolladores son personas voluntarias que colaboran para hacer
    avanzar los objetivos del proyecto mientras participan en él, y que
    mantienen paquetes para el Proyecto, o realizan alguna otra tarea
    que el (los) Delegado(s) del Líder del Proyecto consideren
    adecuada.</p>
  </li>

  <li>
    <p>El (o los) Delegado(s) del Líder del Proyecto puede(n) elegir no
    admitir nuevos Desarrolladores, o expulsar a los que ya lo sean.
    <cite>Si los Desarrolladores consideran que los Delegados están
    abusando de su autoridad pueden por supuesto anular su decisión
    mediante la vía de una Resolución General (vea &sect;4.1(3),
    &sect;4.2).</cite></p>
  </li>
</ol>

<h3>3.3. Procedimiento</h3>

<p>Los Desarrolladores pueden tomar estas decisiones según crean adecuado.</p>

<toc-add-entry name="item-4">4. Los Desarrolladores mediante una Resolución General o elección</toc-add-entry>

<h3>4.1. Atribuciones</h3>

<p>En conjunto, los Desarrolladores pueden:</p>

<ol>
  <li>
    <p>Elegir o cesar al Líder del Proyecto.</p>
  </li>

  <li>
    <p>Enmendar esta constitución, siempre que esté de acuerdo con una
    mayoría de las tres cuartas partes.</p>
  </li>

  <li>
    <p>Tomar o anular cualquier decisión autorizada por las atribuciones del Líder del Proyecto 
      o uno de sus Delegados.</p>
  </li>

  <li>
    <p>Tomar o anular cualquier decisión autorizada por las atribuciones del Comité Técnico, 
       siempre y cuándo estén de acuerdo dos terceras partes.</p>
  </li>

  <li>
    <p>Generar, sustituir y retirar documentos no técnicos sobre normas y
       declaraciones.</p>

    <p>Esto incluye documentos que describan los objetivos del proyecto,
       sus relaciones con otras entidades de software libre, y normas no
       técnicas tales como los términos de licencias de software libre a los
       que debe ajustarse el software de Debian.</p>

    <p>También pueden incluir declaraciones de posicionamientos sobre asuntos
    de actualidad.</p>

    <ol style="list-style: decimal;">
      <li>Un Documento Fundamental («Foundation Document») es un documento o
       declaración clasificado como crítico para la misión y propósitos del Proyecto.</li>
      <li>Los Documentos Fundamentales son las obras tituladas <q>Contrato
       Social de Debian</q> («Debian Social Contract») y <q>Directrices de
       Software libre de Debian</q> («Debian Free Software Guidelines»).</li>
      <li>La sustitución de un Documento Fundamental precisa de una
       mayoría de las tres cuartas partes. Se pueden generar nuevos
       Documentos Fundamentales y retirar los ya existentes mediante una
       enmienda a la lista de Documentos Fundamentales en esta constitución.</li>
    </ol>

  </li>

  <li>
    <p>Tomar decisiones sobre las propiedades mantenidas en fideicomiso para propósitos
    relacionados con Debian. (Vea &sect;9).</p>
  </li>

  <li>
    <p>En caso de desacuerdo entre el líder de proyecto y el secretario que 
    le incumba, designar un secretario nuevo.</p>
  </li>
</ol>

<h3>4.2. Procedimiento</h3>

<ol>
  <li>
    <p>Los Desarrolladores seguirán el Procedimiento Estándar de
    Resolución, que se indica más adelante. Se introduce una resolución
    u opción de la papeleta si algún desarrollador la propone y es apoyado por al menos
    otros «K» Desarrolladores, o si es propuesta por el Líder del Proyecto
    o el Comité Técnico.</p>
  </li>

  <li>
    <p>Retraso de una decisión del Líder del Proyecto o sus Delegados:</p>

    <ol>
      <li>Si el Líder del Proyecto o sus Delegados, o el Comité Técnico
      han tomado una decisión, los Desarrolladores pueden invalidarla
      aprobando una resolución que lo haga, véase &sect;4.1(3).</li>

      <li>Si tal resolución es apoyada por al menos «2K» Desarrolladores,
      o si es propuesta por el Comité Técnico, provoca que la decisión
      sea congelada de forma inmediata (siempre que la propia resolución
      lo indique).</li>

      <li>Si la decisión original versaba sobre cambiar el periodo de un
      debate o votación, o si la resolución pretende anular una decisión
      del Comité Técnico, entonces sólo hace falta el apoyo de «K»
      Desarrolladores para poder congelar inmediatamente la decisión.</li>

      <li>Si la decisión queda postergada, se votará inmediatamente para
      determinar si se mantiene la decisión hasta que se produzca una
      votación formal al respecto, o si se deberá retrasar la
      implementación de la decisión original hasta entonces. No hay
      quorum para esta votación inmediata.</li>

      <li>Si el Líder del Proyecto (o su Delegado) se retracta de la
      decisión original, la votación se hace innecesaria, y no se
      lleva a cabo.</li>
    </ol>
  </li>

  <li>
    <p>
       El Secretario del Proyecto toma los votos. Los votos y resultados
       del recuento no son revelados durante el periodo de votación;
       una vez terminado, el Secretario del Proyecto publicará todos los
       votos depositados. El periodo de votación es de dos semanas, pero
       el Líder del Proyecto puede variarlo en hasta una semana.
    </p>
  </li>

  <li>
    <p>El Líder tiene un voto decisivo. El quorum es de 3Q.
    La opción predeterminada es «None Of The Above» (Ninguna de las anteriores).</p>
  </li>

  <li>
    <p>Las propuestas, patrocinadores, opciones de la papeleta, llamadas a votación
    y otras acciones formales se anuncian en una lista de correo
    electrónico pública señalada por el (los) Delegado(s) del Líder
    del Proyecto. Cualquier Desarrollador podrá enviar mensajes a
    ella.</p>
  </li>

  <li>
    <p>Los votos son depositados mediante correo electrónico de una
    manera que el Secretario considere adecuada. El Secretario
    determinará, para cada votación, si los votantes pueden cambiar
    su voto.</p>
  </li>

  <li>
    <p>Q es la mitad de la raíz cuadrada del número total de
    Desarrolladores. K es Q o 5, lo que sea más pequeño. Q y K no
    tienen por qué ser enteros, y no se les aplica redondeo.</p>
  </li>
</ol>

<toc-add-entry name="item-5">5. El Líder del Proyecto</toc-add-entry>

<h3>5.1. Atribuciones</h3>

<p>El <a href="leader">Líder del Proyecto</a> puede:</p>

<ol>
  <li>
    <p>Nombrar Delegados o delegar decisiones en el Comité Técnico.</p>

    <p>El Líder puede definir un área de responsabilidad o una decisión
    específica y delegarla en otro Desarrollador o en el Comité Técnico.</p>

    <p>Una vez que una decisión en particular se haya delegado y se
    haya tomado, el Líder del Proyecto no puede retirar esa delegación;
    sin embargo, puede retirar una delegación actual de un área de
    responsabilidad en particular.</p>
  </li>

  <li>
    <p>Ceder autoridad a otros Desarrolladores.</p>

    <p>El Líder del Proyecto puede respaldar a otros miembros del
    proyecto o sus opiniones, tanto si se le solicita como por propia
    voluntad. Sin embargo, sus declaraciones tendrán «fuerza»
    si y sólo si se le ha dado potestad para tomar la decisión en
    cuestión.</p>
  </li>

  <li>
    <p>Tomar cualquier decisión que precise una acción urgente.</p>

    <p>Esto no se aplica a decisiones que se hayan vuelto urgentes de
    forma gradual debido a la falta de acción relevante, a menos que
    haya un plazo fijado.</p>
  </li>

  <li>
    <p>Tomar cualquier decisión sobre la que ningún otro tenga responsabilidad.</p>
  </li>

  <li>
    <p>Proponer borradores de Resoluciones Generales y opciones de la papeleta para 
    Resoluciones Generales. Cuando son propuestas del Líder del Proyecto,
    no se requieren patrocinadores para la Resolución General u opción de la papeleta; vea
    &sect;4.2.1.</p>
  </li>

  <li>
    <p>Junto al Comité Técnico, nombrar nuevos miembros del Comité.
    (Vea &sect;6.2.)</p>
  </li>

  <li>
    <p>Usar su voto decisivo cuando los Desarrolladores votan.</p>

    <p>El Líder también dispone de un voto normal en tales votaciones.</p>
  </li>

  <li>
    <p>Variar el periodo de discusión de las votaciones de los desarrolladores (tal como se dijo anteriormente).</p>
  </li>

  <li>
    <p>Dirigir discusiones entre Desarrolladores.</p>

    <p>El Líder debería intentar participar en las discusiones entre
    Desarrolladores de una manera útil, intentando mantener la discusión
    dentro de los temas clave. El Líder del Proyecto no debería usar su
    posición para promocionar sus opiniones personales.</p>
  </li>

   <li>
   <p>En consulta a los desarrolladores, tomar decisiones que afecten a
   propiedades mantenidas en fideicomiso para propósitos relacionados con Debian.
   (Ver &sect;9). Tales decisiones se comunican a los miembros a
   través del Líder de Proyecto o su(s) Delegado(s). Los gastos importantes
   se deberían proponer y debatir en la lista de correo antes de que los
   fondos se desembolsen.</p>
   </li>
   <li>
   <p>Añadir o eliminar organizaciones de la lista de organizaciones de 
   confianza (vea &sect;9.3) que están autorizadas a aceptar y mantener
   en fideicomiso bienes para Debian. La evaluación y discusión que lleve a 
   tal decisión se realizarán en una lista de correo electrónico designada por 
   el Líder de Proyecto o su(s) delegado(s), a la que cualquier desarrollador pueda 
   escribir. Hay un período mínimo de discusión de dos semanas antes de que
   una organización se añada a la lista de organizaciones de confianza.</p>
   </li>
</ol>

<h3>5.2. Nombramiento</h3>

<ol>
  <li>El Líder del Proyecto es elegido por los Desarrolladores.</li>

  <li>La elección comienza seis semanas antes de que el puesto quede
  vacante, o (si ya es demasiado tarde) inmediatamente.</li>

  <li>Durante la primera semana cualquier Desarrollador puede
  proponerse a sí mismo como candidato a Líder del Proyecto,
  y resumir sus planes para el término.</li>

  <li>Durante las siguientes tres semanas, no se podrán proponer más
  candidatos; los que ya lo sean deberían usar este tiempo para hacer
  campaña y discusión sobre sus opiniones. Si no hay
  candidatos al final del periodo de nominación, queda extendido por
  otra semana, repetidamente si fuera necesario.</li>

  <li>Las dos semanas siguientes constituyen el tiempo de votación,
  durante el cual los Desarrolladores pueden emitir su voto. Los votos
  destinados a la elección de un líder se mantendrán en secreto, incluso
  tras acabar el periodo de elecciones.</li>

  <li>Las opciones que aparezcan en la papeleta serán las de aquellos
  candidatos que se hayan propuesto a sí mismos, y no se hayan
  retirado, además de «None Of The Above» (Ninguno de los anteriores).
  Si «None Of The Above» gana las elecciones, entonces se ha de repetir
  el proceso, tantas veces como sea necesario.</li>

  <li>
        La decisión se tomará usando el método especificado en &sect;A.5
        del Procedimiento Estándar de Resolución. El quorum es el mismo que 
        para una Resolución General (&sect;4.2) y la opción predeterminada es 
        <q>None Of The Above</q>.
  </li>

  <li>El Líder del Proyecto realiza un año de servicio tras su elección.</li>
</ol>

<h3>5.3. Procedimiento</h3>

<p>El Líder del Proyecto debería intentar tomar decisiones consistentes
con el consenso de las opiniones de los Desarrolladores.</p>

<p>Cuando sea práctico, el Líder debería solicitar informalmente la
opinión de los Desarrolladores.</p>

<p>El Líder debería evitar presentar sus propios puntos de vista con
demasiado énfasis cuando tome decisiones en su calidad de Líder.</p>

<toc-add-entry name="item-6">6. Comité técnico</toc-add-entry>

<h3>6.1. Atribuciones</h3>

<p>El <a href="tech-ctte">Comité Técnico</a> puede:</p>

<ol>
  <li>
    <p>Decidir sobre cualquier norma en materia técnica</p>

    <p>Esto incluye el contenido de los manuales de normativa técnica
    (<i>policy</i>), material de referencia para desarrolladores, paquetes
    de ejemplo y el comportamiento de herramientas para construcción de
    paquetes que no sean experimentales. (En cada caso, el mantenedor
    original del software o documentación relevante toma las decisiones
    iniciales, sin embargo; vea 6.3(5)).</p>
  </li>

  <li>
    <p>Decidir sobre cualquier materia técnica donde se solape la
    jurisdicción de los Desarrolladores.</p>

    <p>En los casos en que varios Desarrolladores necesiten implementar
    normas técnicas compatibles (por ejemplo, si no están de acuerdo en
    las prioridades de paquetes en conflicto, o sobre la propiedad del
    nombre de una orden, o sobre qué paquete es responsable de un fallo
    cuando ambos mantenedores están de acuerdo en que es un fallo, o
    sobre quién debería mantener un paquete), el comité técnico puede
    decidir sobre el asunto.</p>
  </li>

  <li>
    <p>Tomar una decisión cuando se le pida.</p>

    <p>Cualquier persona u organismo puede delegar una decisión en el
    Comité Técnico, o pedirle consejo.</p>
  </li>

  <li>
    <p>Imponer su decisión sobre la de un Desarrollador (precisa una
    mayoría de las tres cuartas partes).</p>

    <p>El Comité Técnico puede indicar a un Desarrollador que siga un
    curso de acción técnico en particular, incluso si no es el que desea;
    esto precisa una mayoría de las tres cuartas partes. Por ejemplo,
    el Comité puede determinar que está justificada una queja formulada
    por quien envía un informe de fallo, y que debe implementarse la
    solución que propuso.</p>
  </li>

  <li>
    <p>Ofrecer consejo.</p>

    <p>El Comité Técnico puede hacer anuncios formales sobre su punto
    de vista en cualquier asunto. <cite>Los miembros individuales pueden,
    por supuesto, hacer propuestas informales sobre sus puntos de vista
    y sobre los del comité.</cite></p>
  </li>

  <li>
    <p>Junto con el Líder del Proyecto, nombrar nuevos miembros para sí
    mismo, o eliminar a los existentes. (Vea &sect;6.2).</p>
  </li>

  <li>
    <p>Nombrar al Presidente del Comité Técnico.</p>

    <p>
        Al Presidente lo elige el Comité de entre sus miembros. Todos
        los miembros del comité quedan nominados automáticamente; la
        votación comienza una semana antes de que el puesto quede
        vacante (o inmediatamente, si ya es demasiado tarde). Los
        miembros pueden votar por aclamación pública a cualquier colega
        miembro del comité, incluyéndose a sí mismos; no existe la
        opción predeterminada. La votación termina cuando todos los
        miembros hayan emitido su voto, o cuando haya terminado el periodo
        de votación. El resultado se determina usando el método
        especificado en &sect;A.5 del Procedimiento Estándar de Resolución.
        No hay voto decisivo. Si hay múltiples opciones sin vencedor en el 
        conjunto de Schwartz al final de  &sect;A.5.8, el ganador se elegirá
        aleatoriamente entre esas opciones, a través de un mecanismo elegido
        por el Secretario del Proyecto.        
    </p>
  </li>

  <li>
    <p>El Presidente puede ejercer las funciones de Líder, junto con
    el Secretario.</p>

    <p>Como se detalla en la &sect;7.1(2), el Presidente del Comité
    Técnico y el Secretario del Proyecto pueden, en conjunto, ejercer
    las funciones del Líder si no hay Líder.</p>
  </li>
</ol>

<h3>6.2. Composición</h3>

<ol>
  <li>
    <p>El Comité Técnico se compone de hasta 8 Desarrolladores, y
    normalmente debería tener al menos 4 miembros.</p>
  </li>

  <li>
    <p>Cuando haya menos de 8 miembros, el Comité Técnico puede
    recomendar nuevos miembros al Líder del Proyecto, quien puede
    escoger (individualmente) si nombrarlos o no.</p>
  </li>

  <li>
    <p>Cuando haya 5 miembros o menos, el Comité Técnico puede nombrar
    nuevos miembros hasta que su número total llegue a 6.</p>
  </li>

  <li>
    <p>Cuando ha habido 5 miembros o menos durante al menos una semana,
    el Líder del Proyecto puede nombrar nuevos miembros hasta que su número
    total llegue a 6, en intervalos de al menos una semana por nombramiento.</p>
  </li>

  <li>
      <p>Un Desarrollador no es elegible para ser (re)nombrado para el
      Comité Técnico si ha sido miembro durante los 12 meses previos.</p>
  </li>

  <li>
    <p>Si el Comité Técnico y el Líder del Proyecto están de acuerdo,
    pueden destituir o sustituir a un miembro del Comité Técnico.</p>
  </li>

  <li>
    <p>Duración del nombramiento:</p>
    <ol>
      <li>
    <p>El 1 de enero de cada año se establece que el 31 de diciembre 
    de ese año expira 
    el nombramiento de cualquier miembro 
    del Comité que ha servido más de 42 meses (3 años y medio) y que es 
    uno de los dos miembros más antiguos.</p>
      </li>
      <li>
    <p>Se dice que uno de los miembros del Comité Técnico es más antiguo
    que otro si fue nombrado antes, o fueron nombrados al mismo tiempo y 
    ha sido miembro del Proyecto Debian por más tiempo. En el caso de que un
    miembro haya sido nombrado más de una vez, se tiene en cuenta solamente 
    el nombramiento más reciente.</p>
      </li>
    </ol>
  </li>
</ol>

<h3>6.3. Procedimiento</h3>

<ol>
  <li>
    <p>Procedimiento de resolución.</p>
    
    <p>El Comité Técnico usa el siguiente proceso para preparar una
    resolución para votar:</p>

    <ol>
    <li>Cualquier miembro del Comité Técnico puede proponer un una resolución.
    Esto crea una papeleta inicial con dos opciones, siendo la otra opción la
    predeterminada «None of the above» («ninguna de las anteriores»).
    La persona que propone la resolución se convierte en la persona que propone la opción de la papeleta.</li>
    
    <li>Cualquier miembro del Comité Técnico puede proponer
    opciones de papeleta adicionales o modificar o retirar una opción de papeleta que haya
    propuesto.</li>
    
    <li>Si se retiran todas las opciones de la papeleta excepto la predeterminada, 
    el proceso es cancelado.</li>
    
    <li>Cualquier miembro del Comité Técnico puede llamar a urnas sobre la papeleta
    tal y como está. Esta votación empieza inmediatamente, pero si
    cualquier otro miembro del Comité Técnico objeta a la llamada a urnas antes de que
    se complete la votación, la votación se cancela y no tiene efecto.</li>
    
    <li>Dos semanas tras la propuesta original, la papeleta se cierra para cualquier
    posible cambio y la votación comienza automáticamente. Esta votación no puede
    cancelarse.</li>
        
    <li>Si se cancela una votación bajo &sect;6.3.1.4 más tarde de 13 días
    tras la propuesta inicial de resolución, el voto especificado en &sect;6.3.1.5 comienza 24 horas 
    tras la hora de cancelación. Durante dicho periodo de 24 horas, nadie puede llamar a urnas,
    pero los miembros del Comité Técnico pueden hacer cambios en la papeleta bajo    
    &sect;6.3.1.2.</li>
    </ol>
  </li>

  <li>
    <p>Detalles al respecto de la votación</p>

    <p>Las votaciones se deciden por el mecanismo de recuento de votos descrito en
    &sect;A.5. El periodo de votación dura una semana o hasta que el resultado ya no deja
    lugar a dudas asumiendo que ningún miembro cambia su voto, lo que sea más corto.
    Los miembros pueden cambiar sus votos hasta que termina el periodo de votación.
    Hay un quorum de dos. El Presidente dispone de un voto decisivo. 
    La opción predeterminada es «None of the above» («ninguno de los anteriores»).</p>
    
    <p>Cuando el Comité Técnico vota si se debe anular la autoridad de un Desarrollador
    que además es miembro del Comité, ese miembro no podrá votar (a menos que sea el Presidente, en cuyo caso sólo podrá usar su voto decisivo).
  </li>

  <li>
    <p>Discusión pública y toma de decisiones.</p>

    <p>Las discusiones, borradores de resoluciones y opciones de las papeletas, y
    votaciones de los miembros del comité, se hacen públicas en la lista
    pública de discusión del Comité Técnico. El Comité no dispone de
    secretario propio.</p>
  </li>

  <li>
    <p>Confidencialidad de los acuerdos.</p>

    <p>El Comité Técnico puede mantener discusiones confidenciales
    mediante mensajes electrónicos privados, una lista de correo privada,
    o cualquier otro medio para discutir acuerdos del Comité. Sin embargo,
    las votaciones sobre dichos acuerdos deben ser públicas.</p>
  </li>

  <li>
    <p>Trabajo de diseño poco detallado.</p>

    <p>El Comité Técnico no se encarga del diseño de nuevas propuestas
    y normas. Tal trabajo de diseño debe ser llevado acabo por individuos
    de forma privada o conjunta y discutida en los foros ordinarios
    dedicados al diseño y normativa técnicos.</p>

    <p>El Comité Técnico se restringe a sí mismo a adoptar o escoger
    compromisos entre soluciones y decisiones que hayan sido propuestas
    y razonablemente discutidas en otro lugar.</p>

    <p><cite>Los miembros individuales del comité pueden, por supuesto,
    participar a título personal en cualquier aspecto del trabajo en
    diseño y normativa.</cite></p>
  </li>

  <li>
    <p>El Comité Técnico toma decisiones sólo como último recurso.</p>

    <p>El Comité Técnico no toma decisiones técnicas hasta que hayan
    fracasado otros esfuerzos para resolverlo por la vía del consenso,
    a menos que así se lo pida la persona u organismo responsables de
    dicha decisión.</p>
  </li>
    <li>
    <p>Propuesta de Resolución General.</p>

    <p>Cuando el Comité Técnico propone una resolución general o una
    opción de papeleta en una resolución general bajo
    &sect;4.2.1, puede delegar en uno de sus miembros (a través de una resolución u otros medios
    acordados por el Comité Técnico) la autoridad para retirar, modificar o hacer
    cambios menores en la opción de papeleta. Si no lo hace,
    estas decisiones deben tomarse mediante resolución del Comité Técnico.</p>
  </li>
</ol>

<toc-add-entry name="item-7">7. El Secretario del Proyecto</toc-add-entry>

<h3>7.1. Atribuciones</h3>

<p>El <a href="secretary">Secretario</a>:</p>

<ol>
  <li>
    <p>Recibe los votos de los Desarrolladores, y determina el número
    e identidad de los Desarrolladores, siempre que la constitución lo
    requiera.</p>
  </li>

  <li>
    <p>Puede ejercer las funciones de Líder, junto con el Presidente
    del Comité Técnico.</p>

    <p>Si no hay Líder del Proyecto, entonces el Presidente del Comité
    Técnico y el Secretario del Proyecto pueden tomar decisiones mediante
    acuerdo si consideran imperativo hacerlo.</p>
  </li>

  <li>
    <p>Juzga cualquier disputa sobre interpretaciones de la
    constitución.</p>
  </li>

  <li>
    <p>Puede delegar parte de su autoridad en cualquier otro, o
    derogar tal delegación en cualquier momento.</p>
  </li>
</ol>

<h3>7.2. Nombramiento</h3>

<p>El Secretario del Proyecto es nombrado por el Líder del
Proyecto y por el Secretario actual del Proyecto.</p>

<p>Si el Líder del Proyecto y el Secretario saliente no llegan a un
acuerdo sobre el nuevo nombramiento, deberán preguntar a los 
Desarrolladores a través de una Resolución General para nombrar
a un Secretario.</p>

<p>Si no hay Secretario del Proyecto o el Secretario actual no está
disponible, y no ha delegado la autoridad para una decisión, entonces
el Presidente del Comité Técnico puede tomar tal decisión o delegarla,
como Secretario en funciones.</p>

<p>El ejercicio del Secretario del Proyecto dura 1 año, en cuyo momento
debe escogerse otro Secretario o ratificarle en el cargo.</p>

<h3>7.3. Procedimiento</h3>

<p>El Secretario del Proyecto debería tomar decisiones que sean
justas y razonables, preferiblemente consistentes con el consenso de
los Desarrolladores.</p>

<p>Cuando actúen juntos en función del Líder del Proyecto ausente,
el Presidente del Comité Técnico y el Secretario del Proyecto deberían
tomar decisiones sólo cuando fuera absolutamente necesario y sólo siendo
consistentes con el consenso de los Desarrolladores.</p>

<toc-add-entry name="item-8">8. Los Delegados del Líder del Proyecto</toc-add-entry>

<h3>8.1. Atribuciones</h3>

<p>Los Delegados del Líder del Proyecto:</p>

<ol>
  <li>disponen de las atribuciones que el Líder del Proyecto haya delegado
  en ellos;</li>

  <li>pueden tomar ciertas decisiones que el Líder no puede tomar
  directamente, incluyendo la admisión o expulsión de Desarrolladores
  o nombramiento de personas como Desarrolladores que no mantienen
  paquetes. <cite>Esto evita la concentración de poder, particularmente
  sobre la pertenencia al proyecto de un Desarrollador, en manos del
  Líder del Proyecto.</cite></li>
</ol>

<h3>8.2. Nombramiento</h3>

<p>Los Delegados son nombrados por el Líder del Proyecto y pueden
ser reemplazados a discreción del Líder. El Líder no puede condicionar
el puesto de Delegado sobre decisiones particulares que éste tome, ni
puede anular una decisión del Delegado, una vez tomada.</p>

<h3>8.3. Procedimiento</h3>

<p>Los Delegados toman las decisiones que crean convenientes, pero
deberían intentar implementarlas de una forma técnicamente correcta
o siguiendo una opinión de consenso.</p>

<toc-add-entry name="item-9">9. Mantenimiento de bienes para Debian</toc-add-entry>

<p>En la mayoría de las jurisdicciones del mundo, el proyecto Debian no
está en posición de mantener directamente fondos u otras propiedades.
Por tanto, la propiedad tiene que recaer en algunas organizaciones, como
se detalla en &sect;9.2.</p>

<p>Tradicionalmente, SPI era la única organización autorizada a mantener
propiedades y fondos del proyecto Debian. SPI se creó en EEUU para 
mantener los fondos allí.</p>

<p><a href="https://www.spi-inc.org/";>SPI</a> y Debian son organizaciones
separadas que comparten algunos objetivos.
Debian agradece la estructura de soporte legal que le
ofrece SPI.</p>

<h3>9.1. Relaciones con Organizaciones Asociadas</h3>

<ol>
  <li>
    <p>Los Desarrolladores de Debian no pueden llegar a ser agentes
    o empleados de organizaciones que tengan bienes mantenidos en 
    fideicomiso para Debian, ni unos de otros, ni de personas con 
    autoridad en el proyecto Debian, solamente por la virtud
    de ser Desarrolladores de Debian. Una persona actuando como
    desarrollador lo hace como individuo, en su propio nombre. Tales 
    organizaciones pueden, por decisión propia, establecer relaciones
    con individuos que también son desarrolladores de Debian.
    </p>
  </li>
</ol>

<h3>9.2. Autoridad</h3>

<ol>
  <li>
    <p>Una organización que mantiene bienes en 
     fideicomiso para Debian carece de poder de decisión sobre cuestiones 
     técnicas y de cualquier otro ámbito relacionadas con Debian, con la 
     salvedad de que ninguna decisión de Debian con respecto a cualquier propiedad
     mantenida por la organización requerirá actuar fuera de su
     autoridad legal.</p>
  </li>
  <li>
    <p>Debian no pretende autoridad alguna sobre una organización que 
     mantenga es fideicomiso bienes para Debian distinta del uso de las propiedades
     que mantenga para Debian.</p>
  </li>
</ol>

<h3>9.3. Organizaciones de confianza</h3>

<p>Cualquier donación para el proyecto Debian se debe hacer a cualquiera
  del conjunto de organizaciones designadas por el líder de proyecto (o un
  delegado) como autorizadas para manipular bienes a utilizar en el 
  proyecto Debian.</p>
    
<p>Las organizaciones que dispongan de bienes mantenidos en fideicomiso 
  para Debian deberían asumir obligaciones razonables para la manipulación
  de tales bienes.</p>

<p>Debian mantiene una lista pública de organizaciones de confianza que 
  aceptan donaciones y mantienen bienes para Debian (incluyendo propiedad 
  tangible e intelectual) que incluye los compromisos que estas 
  organizaciones han hecho sobre cómo se manipularán esos bienes.</p>

<toc-add-entry name="item-A">A. Procedimiento Estándar de Resolución</toc-add-entry>

<p>Estas reglas se aplican a la toma de decisiones comunitarias de
comités y plebiscitos, tal como se indicó anteriormente.</p>

<h3>A.0. Propuesta</h3>

<ol>
<li>El procedimiento formal comienza cuando se propone y patrocina un
borrador de resolución, tal como se especifica en  &sect;4.2.1.</li>

<li>Este borrador de resolución se convierte en una opción de papeleta en 
una papeleta inicial con dos opciones, siendo la otra opción la opción predeterminada,
y la persona proponente de la resolución se convierte en la persona proponente de esa
opción de papeleta.</li>
</ol>

#### HASTA AQUÍ LA ACTUALIZACIÓN DE LA TRADUCCIÓN ####

<h3>A.1. Discusión y Enmienda</h3>

<ol>
  <li>The discussion period starts when a draft resolution is proposed and
  sponsored. The minimum discussion period is 2 weeks. The maximum
  discussion period is 3 weeks.</li>

  <li>A new ballot option may be proposed and sponsored according to the
  requirements for a new resolution.</li>

  <li>The proposer of a ballot option may amend that option provided that
  none of the sponsors of that ballot option at the time the amendment is
  proposed disagree with that change within 24 hours. If any of them do
  disagree, the ballot option is left unchanged.</li>

  <li>The addition of a ballot option or the change via an amendment of a
  ballot option changes the end of the discussion period to be one week
  from when that action was done, unless that would make the total
  discussion period shorter than the minimum discussion period or longer
  than the maximum discussion period. In the latter case, the length of
  the discussion period is instead set to the maximum discussion
  period.</li>

  <li>The proposer of a ballot option may make minor changes to that
  option (for example, typographical fixes, corrections of
  inconsistencies, or other changes which do not alter the meaning),
  providing no Developer objects within 24 hours. In this case the length
  of the discussion period is not changed. If a Developer does object, the
  change must instead be made via amendment under &sect;A.1.3.</li>

  <li>The Project Leader may, at any point in the process, increase or
  decrease the minimum and maximum discussion period by up to 1 week from
  their original values in &sect;A.1.1, except that they may not do so in
  a way that causes the discussion period to end within 48 hours of when
  this change is made. The length of the discussion period is then
  recalculated as if the new minimum and maximum lengths had been in place
  during all previous ballot changes under &sect;A.1.1 and &sect;A.1.4.</li>

  <li>The default option has no proposer or sponsors, and cannot be
  amended or withdrawn.</li>
</ol>

<h3>A.2. Llamada a urnas</h3>

<ol>
  <li>El proponente o patrocinador de una moción o enmienda puede pedir
  una votación, siempre que haya pasado el tiempo mínimo de discusión
  (si es que lo había).</li>

  <li>
     El proponente o patrocinador de una moción puede pedir una
     votación sobre esa resolución y todas las enmiendas relacionadas.
  </li>

  <li>La persona que pide una votación indica el que cree que debería ser
  el texto de la resolución y cualquier enmienda relevante y,
  consecuentemente, el contenido de las papeletas. Sin embargo, la
  decisión final del contenido de las papeletas es del Secretario
  (vea 7.1(1), 7.1(3) y A.3(4))</li>

  <li>
       El periodo mínimo de discusión se cuenta desde el momento en
       que fue aceptada la última enmienda formal, o el momento en que
       se propuso la resolución si no se han propuesto y aceptado enmiendas.
  </li>
</ol>

<h3>A.3. Procedimiento de votación</h3>

<ol>
  <li>
       Cada resolución y sus enmiendas relacionadas se votan en una
       única papeleta que incluye una opción para la resolución
       original, cada enmienda, y la opción predeterminada (si se
       aplica).
  </li>

  <li>
       La opción predeterminada no tiene ningún requerimiento de
       supermayoría. Las opciones que no precisen explícitamente de
       supermayoría, tienen un requerimiento de mayoría 1:1.
  </li>

  <li>
       Los votos se cuentan de acuerdo con las reglas en A.6. La opción
       predeterminada es "Further Discussion" («continuar la discusión»), a menos que se especifique
       otra cosa.
  </li>

  <li>En caso de duda, el Secretario del Proyecto decidirá en materia
  de procedimiento.</li>
</ol>

<h3>A.4. Retirada de resoluciones o enmiendas rechazadas</h3>

<p>El proponente de una resolución o enmienda rechazada puede retirarla.
En este caso, pueden aparecer nuevos proponentes para mantenerlas
activas, en cuyo caso la primera persona que lo haga se convierte en el
nuevo proponente y cualquier otro se convierte en patrocinador si no los
había ya.</p>

<p>El patrocinador de una resolución o enmienda puede retirarse
(a menos que sea aceptada).</p>

<p>Si la retirada del proponente o patrocinadores implica que la
resolución no tiene proponente o suficientes patrocinadores, no será
llevada a votación a menos que se rectifique antes de que la resolución
expire.</p>

<h3>A.5. Expiración</h3>

<p>
   Si una resolución propuesta no ha sido discutida, enmendada, votada o
   movida de alguna manera durante 4 semanas el secretario puede anunciar
   que está siendo retirada. Si ninguno de los patrocinadores de
   cualquiera de las propuestas objeta durante una semana, la resolución
   se retira.
</p>

<p>
   El secretario también puede incluir sugerencias sobre cómo
   proceder, si fuera apropiado.
</p>

<h3>A.6. Recuento de votos</h3>

<ol>
   <li> La papeleta de cada votante califica las opciones sobre las que
        se vota. No hace falta calificar todas las opciones. Las opciones
        calificadas se consideran preferidas sobre todas las que no lo
        hayan sido. Los votantes pueden dar la misma calificación a las
        opciones. Se considera que las no calificadas tienen la misma
        calificación entre ellas. Se incluirán en la Llamada al voto los
        detalles de la manera en que se debe rellenar la papeleta.
   </li>
   <li> Si la papeleta precisa un quorum R, cualquier opción diferente a
        la predeterminada que no obtenga al menos R votos calificándola
        por encima de la opción predeterminada se elimina de toda
        consideración.
   </li>
   <li> Cualquier opción (que no sea la predeterminada) que no venza a la
        predeterminada por la proporción de mayoría precisada se elimina
        de toda consideración.
        <ol>
             <li>
                  Dadas dos opciones A y B, V(A,B) es el número de
                  votantes que prefieren la opción A sobre la opción B.
             </li>
             <li>
                  Una opción A vence a la opción predeterminada D por una
                  proporción de mayoría N, si V(A,D) es mayor o igual
                  que N * V(D,A) y V(A,D) es estrictamente mayor que V(D,A).
             </li>
             <li>
                  Si A necesita una supermayoría de S:1, su proporción de
                  mayoría es S; si no, su proporción de mayoría es 1.
             </li>
        </ol>
   </li>
   <li> De la lista de opciones sin eliminar, generamos una lista de
        derrotas a pares.
        <ol>
             <li>
                  Una opción A vence a una opción B, si V(A,B) es
                  estrictamente mayor que V(B,A).
             </li>
        </ol>
   </li>
   <li> De una lista de derrotas a pares (sin eliminar), generamos un
        conjunto de derrotas transitivas.
        <ol>
             <li>
                  Una opción A derrota transitivamente a una opción C si A
                  derrota a C o si hay otra opción B donde A derrota a B Y
                  B derrota transitivamente a C.
             </li>
        </ol>
   </li>
   <li> Construimos el conjunto de Schwartz partiendo del conjunto de
        derrotas transitivas.
        <ol>
             <li>
                  Una opción A está en el conjunto de Schwartz si para
                  todas las opciones B, bien A derrota transitivamente a
                  B, o B no derrota transitivamente a A.
             </li>
        </ol>
   </li>
   <li> Si hay derrotas entre opciones en el conjunto de Schwartz,
        eliminamos a la más débil de tales derrotas de la lista de
        derrotas por pares, y volvemos al quinto paso.
        <ol>
             <li>
                  Una derrota (A,X) es más débil que una derrota (B,Y) si
                  V(A,X) es menor que V(B,Y). Además, (A,X) es más débil
                  que (B,Y) si V(A,X) es igual a V(B,Y) y V(X,A) es mayor
                  que V(Y,B).
             </li>
             <li>
                  La derrota más débil es aquella que no tiene ninguna
                  derrota más débil que ella. Puede haber más de una de
                  tales derrotas.
             </li>
        </ol>
   </li>
   <li> Si no hay derrotas dentro del conjunto de Schwartz, entonces el
        ganador se escoge de entre las opciones en dicho conjunto. Si sólo
        hay una de tales opciones, es la ganadora. Si hay varias, el
        elector con el voto de calidad escoge cual de estas opciones gana.
   </li>
</ol>

<p>
 <strong>Nota:</strong> Las opciones que los votantes califiquen por
 encima de la opción predeterminada son aquellas que encuentran
 aceptables. Las opciones calificadas por debajo de la predeterminada son
 las que encuentran inaceptables.
</p>

<p><cite>Cuando se deba usar el Procedimiento Estándar de Resolución, el
texto que se refiera a ello debe especificar si es suficiente tener un
borrador o patrocinadores de la resolución propuesta, cual es el periodo
mínimo de discusión, y el periodo de votación. También se debe especificar
la necesidad de una mayoría absoluta o el quorum (y la opción predeterminada)
necesarios.</cite></p>

<toc-add-entry name="item-B">B. Uso del lenguaje y tipografía</toc-add-entry>

<p>N. del T.: se refiere al original en inglés.</p>

<p>El presente indicativo («is», por ejemplo) indica que la frase es una
regla de esta constitución. «May» o «can» indica que la persona u
organismo puede actuar a discreción. «Should» indica que se consideraría
bien la obediencia a dicha frase, pero no es vinculante. <cite>El texto
marcado como cita, tal como éste, indica la base lógica del texto, y no
forma parte de la constitución. Se debe usar sólo como ayuda en caso de
duda.</cite></p>

Reply to: