From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Otros idiomas
Deutsch ; English ; Español ; Français ; Portuguese (Portugal) ;

Propósito de esta política

Se propusieron muchas características nuevas para versiones anteriores de Mageia. Algunas fueron implementadas, pero queda mucho por hacer. Nos falto priorizar, una planificación real y características bien definidas, para que las personas pudieran motivarse y contribuir.

Lo que definimos aquí:

  • Qué es una característica.
  • Cómo definir y proponer una característica.
  • Cómo se seleccionan las características para las próximas especificaciones.
  • Cómo seguimos la implementación de las características.

Todo este trabajo se ha realizado después de ver cómo otras distribuciones gestionan este importante paso. Miramos específicamente a Fedora, ya que han hecho mucho para formalizar el proceso.

¿Qué es una característica?

Sólo se deben proponer cambios notables como características. La actualización de un componente que implica la modificación o actualización de varios otros componentes es probablemente una característica. Algo que implica un nuevo desarrollo en las herramientas de Mageia es probablemente una característica. La actualización de un solo paquete del que no depende nada, probablemente no debería aparecer como una característica.

Ejemplos de características :

  • Migración a systemd.
  • Soporte Grub2 en el instalador.
  • Soporte GPT en el instalador.

Ejemplo de cosas que no deberían enumerarse como características :

  • Actualizar cosway a la última versión.
  • Arreglar un fallo del paquete XXX.
  • Añadir paquete para el software XXX.

Cómo definir y proponer una característica

Todos tienen la libertad de proponer nuevas funciones para los próximos lanzamientos, pero esto deberá hacerse mediante el siguiente procedimiento:

  1. Si aún no la hecho, registre una cuenta en: http://identity.mageia.org para poder editar la wiki.
  2. Cree una página con el nombre http://wiki.mageia.org/en/Feature:<Nombre_de_Característica> usando la siguiente plantilla.
  3. Cuando crea que la página de características está lista:
    • Agregue la página a la categoría ProposedFeatureMageia7 (agregue el texto [[Category:ProposedFeatureMageia7]] al final de la pagina). Su propuesta deberá aparecer en la lista de características propuestas.
    • Envié un correo a la lista dev, con asunto "Proposed Feature: Nombre_de_Característica" para debatir la característica e informar a las personas sobre ella, así podrán añadirse a la pagina si planean participar.
Nota:
Se debe utilizar el idioma ingles tanto para el nombre de la característica, para su descripción, y para el correo a la lista dev; pida ayuda en la comunidad de ser necesario

Como participar en una característica

Si cree que una característica es interesante y planea ayudar a implementarla, agréguese a la lista de recursos. resources.

Lista de características propuestas

La lista de características propuestas está disponible en esta página.

Criterio utilizado para elegir características

Ejemplo para Mageia 5: FeatureMageia5_Review

Aquí hay una lista no exhaustiva de criterios:

  • La página wiki para aplicar está completa en los siguientes artículos:
    • Sumario.
    • Propietario.
    • Lanzamiento.
    • Descripción detallada.
    • Por qué sería bueno que Mageia lo incluyera.
    • Dependencias de software/paquetes.
    • ¿Qué podría interrumpir el desarrollo de esta nueva característica?
    • Planificación.
    • Contingencia (también conocido como Plan B: qué sucede si no funciona)
  • Cantidad de personas que planean participar en la función: una función no puede implementarse si nadie planea trabajar en ella.

Aceptación de caracteristicas

Una vez finalizados los envíos de propuestas de funciones, se envía un correo a la lista de correo de desarrollo con una lista preliminar de funciones aceptadas y rechazadas. Las características aceptadas han sido consideradas como:

  • Útil y consistente con el objetivo y las políticas del proyecto.
  • Tener suficientes detalles.
  • Tener una planificación realista.
  • Tener suficientes personas involucradas en las características.
  • No haber visto objeciones importantes y sin respuesta en las discusiones sobre la característica.

La lista de características rechazadas incluye para cada característica las razones para no aceptar la característica. Las características pueden ser rechazadas por diferentes razones (lista no exhaustiva):

  • No hay suficientes personas involucradas en la función.
  • No hay suficientes detalles de la característica.
  • No hay planificación o plan de contingencia.
  • Planificación poco realista.
  • Objeciones a la característica en las listas de correo.

Cuando se publica la lista preliminar de características aceptadas y rechazadas, se reciben comentarios durante una semana:

  • Objeciones a una característica aceptada.
  • Comentarios que agregan más detalles a una característica rechazada (descripción, planificación, plan de contingencia ...)
  • Personas que se agregan a la lista de contribuyentes de características.

Despues de una semana:

  • Las características aceptadas que no reciben ningún nuevo comentario son aceptadas oficialmente.
  • Las características rechazadas que no reciben ningún nuevo comentario son oficialmente rechazadas.
  • Las características aceptadas que reciben comentarios de objeción se rechazan oficialmente a menos que se alcance un consenso en las discusiones.
  • Se aceptan oficialmente las características rechazadas que reciben detalles adicionales o colaboradores interesados y se alcanzó un consenso para la aceptación en las discusiones.

La lista final de características aceptadas es:

  • Publicada en el blog y wiki (agregada a la categoría FeatureMageia3) y anunciada.
  • El desarrollo de las características se inicia de acuerdo a la planificación.
  • La planificación de cada función se supervisa y se analiza en las reuniones de desarrolladores hasta que se completa la función.

Las características rechazadas no se incluyen en las especificaciones oficiales de la distribución, y la planificación no se supervisa en las reuniones de desarrolladores. Dependiendo de las razones para rechazar la función, aún puede ser implementada por personas interesadas.