% SiSU 0.38

@title: Constitución de Debian

@subtitle: Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3]

@creator: Debian Project

@type: information

@subject: debian policy

@date.created: 1998-12-03

@date.issued: 1998-12-03

@date.valid: 2003-10-29

@date.available: 2003-10-29

@date.modified: 2006-11-14

% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC

@date: 2003-10-29

@language.document: Spanish

@language.original: English

@level: new=C; num_top=1

@skin: skin_debian

@bold: Debian; DPL

% @italics:

@rights: http://www.debian.org/license.es.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.<br>Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ). <br>"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc.

@links: {Authoritative Source Document}http://www.debian.org/devel/constitution
{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
{About Debian}http://www.debian.org/intro/about
{News}http://www.debian.org/News/
{Getting Debian}http://www.debian.org/distrib/
{Support}http://www.debian.org/support
{Developer's Corner}http://www.debian.org/devel/
{Sitemap}http://www.debian.org/sitemap
{Search}http://search.debian.org/

@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original

@rcs: $Id: debian_constitution_v1.2~es.s3,v 1.6 2006/02/28 12:11:55 ralph Exp $

:A~ Constitución de Debian

:B~ Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3]

1~pre [Prefix]-#

Versión 1.2 ratificada el 29 de octubre de 2003. Sustituye a la versión 1.1 ratificada el 21 de junio de 2003, que a su vez sustituía a la versión 1.0 ratificada el 2 de diciembre de 1998.

1~ 1. Introducción

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

Este documento describe la estructura organizativa para la toma 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.

1~ 2. Individuos y organismos de toma de decisiones

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

# Los Desarrolladores, mediante una Resolución General o una elección;

# El Líder del Proyecto;

# El Comité Técnico o su Presidente (chairman);

# El Desarrollador que trabaja en una tarea determinada;

# Delegados nombrados por el Líder del Proyecto para tareas específicas;

# El Secretario del Proyecto.

La mayoría del resto de este documento le ayudará a formar una idea de 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. 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.

2~ Reglas generales

# 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 apropiadamente siguiéndolas.

# Una persona puede ocupar varios puestos, pero el Líder del Proyecto, el Secretario del Proyecto y el Presidente del Comité Técnico deben ser personas distintas, además de que el Líder no puede elegirlos como sus Delegados.

# Una persona puede abandonar el Proyecto o dimitir de un cargo en particular, en cualquier momento, diciéndolo públicamente.

1~ Desarrolladores individuales

2~ Atribuciones

Un Desarrollador puede

# tomar una decisión técnica o no técnica con respecto a su propio trabajo;

# proponer o patrocinar borradores de Resoluciones Generales;

# proponerse a sí mismos como candidatos a Líder del Proyecto durante las elecciones;

# votar en una Resolución General y en las elecciones a Líder.

2~ Composición y nombramiento

# Los Desarrolladores son voluntarios 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.

# 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. 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 §4.1(3), §4.2).

2~ Procedimiento

Los Desarrolladores pueden tomar estas decisiones según crean adecuado.

1~ Los Desarrolladores mediante una Resolución General o elección

2~ Atribuciones

En conjunto, los Desarrolladores pueden:

# Elegir o cesar al Líder del Proyecto.

# Enmendar esta constitución, siempre que esté de acuerdo con una mayoría de las tres cuartas partes.

# Anular cualquier decisión del Líder del Proyecto o uno de sus Delegados.

# Anular cualquier decisión del Comité Técnico, siempre y cuándo estén de acuerdo dos terceras partes.

# Generar documentos no técnicos sobre normas y declaraciones.

Generar, sustituir y retirar documentos sobre normas y declaraciones no técnicos. -#

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.

También pueden formular recomendaciones sobre los asuntos incluidos en el orden del día.

_# Un Documento Fundamental (Foundation Document) es un documento o declaración clasificada como crítica para la misión y propósitos del Proyecto.

_# Los Documentos Fundamentales son las obras tituladas Contrato Social de Debian (Debian Social Contract) y Directrices de Software libre de Debian (Debian Free Software Guidelines).

_# 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.

# Junto con el Líder del Proyecto y SPI, tomar decisiones sobre las propiedades mantenidas en fideicomiso para propósitos relacionados con Debian (Ver §9.1.)

2~ Procedimiento

# Los Desarrolladores seguirán el Procedimiento Estándar de Resolución, que se indica más adelante. Se introduce una resolución o enmienda 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.

# Retraso de una decisión del Líder del Proyecto o sus Delegados:

_# 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; vea s4.1(3).

_# 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).

_# Si la decisión original versaba sobre cambiar el periodo de un debate o votación, o si la resolución pretende anular uan decisión del Comité Técnico, entonces sólo hace falta el apoyo de 'K' Desarrolladores para poder congelar inmediatamente la decisión.

_# 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.

_# 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.

# 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.

# El periodo mínimo de discusión es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana. El Líder tiene un voto decisivo. El quorum es de 3Q.

# Las propuestas, patrocinadores, enmiendas, 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.

# 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.

# 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.

1~ El Líder del Proyecto

2~ Poderes

El Líder del Proyecto puede:

# Nombrar Delegados o delegar decisiones en el Comité Técnico.

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.

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.

# Ceder autoridad a otros Desarrolladores.

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.

# Tomar cualquier decisión que precise una acción urgente.

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.

# Tomar cualquier decisión sobre la que ningún otro tenga responsabilidad.

# Proponer borradores de Resoluciones Generales y enmiendas.

# Junto al Comité Técnico, nombrar nuevos miembros del Comité. (Ver §6.2.)

# Usar su voto decisivo cuando los Desarrolladores votan.

El Líder también dispone de un voto normal en tales votaciones.

# Variar el periodo de discusión de las votaciones de los desarrolladores (tal como se dijo anteriormente).

# Dirigir discusiones entre Desarrolladores.

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.

# Junto con SPI, tomar decisiones que afecten a propiedad cedida en préstamo para propósitos relacionados con Debian. (Ver §9.1.)

2~ Nombramiento

# El Líder del Proyecto es elegido por los Desarrolladores.

# La elección comienza nueve semanas antes de que el puesto quede vacante, o (si ya es demasiado tarde) inmediatamente.

# Durante las tres semanas siguientes cualquier Desarrollador puede proponerse a sí mismo como candidato a Líder del Proyecto.

# 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 (hacer conocer sus identidades y sus opiniones). Si no hay candidatos al final del periodo de nominación, queda extendido por otras tres semanas, repetidamente si fuera necesario.

# Las tres 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.

# 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.

# La decisión se tomará usando el método especificado en la sección §A.6 del Procedimiento Estándar de Resolución. El quórum es el mismo que para una Resolución General (§4.2) y la opción por defecto es "None Of The Above".

# El Líder del Proyecto ejerce un año de mandato tras su elección.

2~ Procedimiento

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

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

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

1~ Comité técnico

2~ Poderes

El Comité Técnico puede:

# Decidir sobre cualquier norma en materia técnica

Esto incluye el contenido de los manuales de normativa técnica (policy), 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 (Ver § 6.3(5)).

# Decidir sobre cualquier materia técnica donde se solape la jurisdicción de los Desarrolladores.

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.

# Tomar una decisión cuando se le pida.

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

# Imponer su decisión sobre la de un Desarrollador (precisa una mayoría de las tres cuartas partes).

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 bug, y que debe implementarse la solución que propuso.

# Ofrecer consejo.

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

# Junto con el Líder del Proyecto, nombrar nuevos miembros para sí mismo, o eliminar a los existentes. (Ver §6.2.)

# Nombrar al Presidente del Comité Técnico.

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 la sección A.6 del Procedimiento Estándar de Resolución.

# El Presidente puede ejercer las funciones de Líder, junto con el Secretario.

Como se detalla en la §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.

2~ Composición

# El Comité Técnico se compone de hasta 8 Desarrolladores, y normalmente debería tener al menos 4 miembros.

# Cuando hayan 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.

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

# Cuando el número de miembros sea de 5 o menos durante al menos una semana, el Líder del Proyecto podrá nombrar nuevos miembros hasta que su número llegue a 6, a intervalos de al menos una semana por nombramiento.

# 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.

2~ Procedimiento

# El Comité Técnico usa el Procedimiento Estándar de Resolución.

Cualquier miembro del Comité Técnico puede proponer un borrador de resolución o enmienda. No hay periodo mínimo de discusión; el periodo de votación dura una semana, o hasta que el resultado esté fuera de duda. Los miembros pueden cambiar sus votos. Existe un quorum de dos.

# Detalles al respecto de la votación

El Presidente dispone de un voto decisivo. 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).

# Discusión pública y toma de decisiones.

Las discusiones, borradores de resoluciones y enmiendas, 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.

# Confidencialidad de los acuerdos.

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.

# Trabajo de diseño poco detallado.

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.

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.

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

# El Comité Técnico toma decisiones sólo como último recurso.

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.

1~ El Secretario del Proyecto

2~ Poderes

El Secretario:

# Recibe los votos de los Desarrolladores, y determina el número e identidad de los Desarrolladores, siempre que la constitución lo requiera.

# Puede ejercer las funciones de Líder, junto con el Presidente del Comité Técnico.

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.

# Juzga cualquier disputa sobre interpretaciones de la constitución.

# Puede delegar parte de su autoridad en cualquier otro, o derogar tal delegación en cualquier momento.

2~ Nombramiento

El nuevo Secretario del Proyecto es nombrado por el Líder del Proyecto y por el Secretario que abandona el cargo.

Si el Líder del Proyecto y el Secretario saliente no llegan a un acuerdo sobre el nuevo nombramiento, deberán pedir al Consejo de SPI (ver §9.1.) el nombramiento de un Secretario.

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.

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

2~ Procedimiento

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

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.

1~ Los Delegados del Líder del Proyecto

2~ Poderes

Los Delegados del Líder del Proyecto:

# disponen de los poderes que el Líder del Proyecto haya delegado en ellos;

# 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. Esto evita la concentración de poder, particularmente sobre la pertenencia al proyecto de un Desarrollador, en manos del Líder del Proyecto.

2~ Nombramiento

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.

2~ Procedimiento

Los Delegados toman las decisiones que crean convenientes, pero debertían intentar implementarlas de una forma técnicamente correcta o siguiente una opinión de consenso.

1~ Software in the Public Interest

SPI y Debian son organizaciones separadas que comparten algunos objetivos. Debian agradece la estructura de soporte legal que le ofrece SPI. Los Desarrolladores de Debian son actualemente miembros de SPI por virtud de su estatus de Desarrollador.

2~ Autoridad

# SPI carece de poder de decisión sobre cuestiones técnicas y de cualquier otro ámbito relacionadas con Debian, con la salvedad de que Debian no podrá imponerse a SPI en ningún caso que contravenga a su autoridad legal sobre las propiedades en poder de SPI, si bien la constitución de Debian podrá recurrir a SPI como órgano decisorio en última instancia

# Debian no pretende autoridad alguna sobre SPI otra que el uso de ciertos bienes de SPI, tal como se describe más adelante, aunque se pueda conceder autoridad dentro de SPI a los Desarrolladores de Debian mediante las propias reglas de SPI.

# Los Desarrolladores de Debian no son agentes comerciales ni empleados de SPI, ni unos de otros, ni de personas con autoridad en el Proyecto Debian. Una persona actuando como Desarrollador lo hace como individuo, en su propio nombre.

2~ Gestión de bienes para propósitos relacionados con Debian

Dado que Debian no puede poseer dinero ni bienes, cualquier donación al Proyecto Debian debe ser dirigida a SPI, que gestiona tales cuestiones.

SPI garantiza lo siguiente:

# SPI actuará como depositario del dinero, marcas registradas y otros bienes tangibles e intangibles y gestionará otros asuntos con propósitos relacionados con Debian.

# Tales bienes serán contabilizados por separado y mantenidos en fideicomiso para dichos propósitos, decididos por Debian y SPI de acuerdo a esta sección.

# SPI no dispondrá de o usará bienes mantenidos en fideicomiso para Debian sin la aprobación de Debian, que debe ser emitida por el Líder del Proyecto o mediante una Resolución General de los Desarrolladores.

# SPI tomará en consideración usar o disponer de bienes mantenidos en fideicomiso para Debian cuando se lo pida el Líder del Proyecto.

# SPI usará o dispondrá de bienes mantenidos en fideicomiso para Debian cuando le sea pedido mediante una Resolución General de los Desarrolladores, siempre que sea compatible con la autoridad legal de SPI.

# SPI informará a los Desarrolladores mediante mensaje electrónico a una lista del Proyecto Debian cuando use o disponga de bienes mantenidos en fideicomiso para Debian.

1~a A. Procedimiento Estándar de Resolución

Estas reglas se aplican a la toma de decisiones comunitaria de comités y plebiscitos, tal como se indicó anteriormente.

2~a1 A.1. Propuesta

El procedimiento formal comienza cuando se propone y patrocina un borrador de resolución, tal como se requiere.

2~a1a A.1. Discusión y Enmienda

# Siguiendo la propuesta, se debe discutir la resolución. Se pueden hacer enmiendas formales proponiéndolas y patrocinándolas de acuerdo a los requerimientos de una nueva resolución, o haciéndolo directamente el proponente de la resolución original.

# El proponente de la resolución puede aceptar una enmienda formal, en cuyo caso se cambia inmediatamente el borrador de la resolución formal para que se ajuste a la enmienda.

# Si no se acepta una enmienda formal, o uno de los patrocinadores de la resolución no está de acuerdo con que el proponente acepte la enmienda formal, se mantiene como enmienda y pasa a ser votada.

# Si una enmienda aceptada por el proponente original no es del gusto de otros, pueden proponer otra enmienda para invertir el cambio anterior (de nuevo, necesitan cumplir los requerimientos de proponente y patrocinador(es).)

# El proponente o una resolución pueden sugerir cambios en el texto de la enmienda; lo cual tendrá efecto si el proponente de la enmienda está de acuerdo y ninguno de sus patrocinadores se opone. En tal caso se votará la enmienda modificada en lugar de la original.

# El proponente de una resolución puede hacer cambios para corregir errores menores (por ejemplo, errores tipográficos o inconsistencias) o cambios que no alteren el significador, siempre que nadie objete en las siguientes 24 horas. En este caso, no se reinicia el periodo mínimo de discusión.

2~a2 A.2. Llamada a urnas

# 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).

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

# 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 (Ver 7.1(1), 7.1(3) y A.3(4))

# 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.

2~a3 A.3. Procedimiento de votación

# 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).

# 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.

# Los votos se cuentan de acuerdo con las reglas en A.6. La opción predeterminada es "Further Discussion", a menos que se especifique otra cosa.

# En caso de duda, el Secretario del Proyecto decidirá en materia de procedimiento.

2~a4 A.4. Retirada de resoluciones o enmiendas rechazadas

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.

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

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.

2~a5 A.5. Expiración

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.

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

2~a6 A.6. Recuento de votos

# 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.

# Si la papeleta precisa un quórum 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.

# 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.

_# 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.

_# Una opción A vence a la opción predeterminada D por una proporción de mayoría N, si V(A, D) es estrictamente mayor que N * V(D,A).

_# 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.

# De la lista de opciones sin eliminar, generamos una lista de derrotas a pares.

_# Una opción A vence a una opción B, si V(A,B) es estrictamente mayor que V(B,A).

# De una lista de derrotas a pares (sin eliminar), generamos un conjunto de derrotas transitivas.

_# 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.

# Construimos el conjunto de Schwartz partiendo del conjunto de derrotas transitivas.

_# 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.

# 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.

_# 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).

_# 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.

# 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.

Nota: 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.

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 por defecto) necesario.

1~b B. Uso del lenguaje y tipografía

N. del T.: se refiere al original en ingles.

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. 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.

% Volver a la página principal de Debian.
% Cómo modificar el idioma por defecto de los documentos
% Para informar de un problema con el servidor web, por favor, envíe un correo (en inglés) a debian-www@lists.debian.org. Para consultar información de contacto adicional consulte la página de contactos de Debian.
% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC
% Proyecto Debian
% Elija un servidor cerca de usted
% Nota: La página original es más nueva que esta traducción.
% Constitución de Debian
% Constitución del Proyecto Debian (v1.2)

%% SiSU markup sample Notes:
% SiSU http://www.jus.uio.no/sisu
% SiSU markup for 0.16 and later:
%   0.20.4 header 0~links
%   0.22 may drop image dimensions (rmagick)
%   0.23 utf-8 ß
%   0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
%   0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
% markup in this document is 0.38, (rad) experimental