From Mageia wiki
Jump to: navigation, search
(New translation pt-PT)
 
m
Line 1: Line 1:
{{multi language banner|[[Vorgaben für neue Funktionen-de|Alemão]] ; [[Features_policy|Inglês]] ; [[Política de características|Espanhol]] ; [[Intégration des nouvelles fonctionnalités-fr|Francês]] ; [[Politica_de_funcionalidades|Português (Portugal)]] ; }}
+
{{Faixa multilíngue-pt|[[Vorgaben für neue Funktionen-de|Deutsch]] ; [[Features_policy|English]] ; [[Política de características|Español]] ; [[Intégration des nouvelles fonctionnalités-fr|Français]] ; [[Politica_de_funcionalidades|Português (Portugal)]] ; }}
  
 
== O porquê desta política? ==
 
== O porquê desta política? ==

Revision as of 22:38, 25 November 2020

Template:Faixa multilíngue-pt

O porquê desta política?

A lot of new features were proposed for previous versions of Mageia. Some were implemented but a lot still needs to be done. We miss priorities, real planning and well-defined features so that people can be motivated and contribute.

What we define here:

  • what is a feature
  • how to define and propose a feature
  • how features are selected for coming specifications
  • how do we follow features implementation

All this work has been done after having a look at how other distributions manage this important step. We specifically looked at Fedora as they have done a lot in formalizing the process.

O que é uma funcionalidade

Only noteworthy changes should be proposed as features. Update of a component which involves modification or update of several other components is probably a feature. Something which involves some new development in Mageia tools is probably a feature. Update of a single package on which nothing depends, probably shouldn't be listed as a feature.

Exemplo de funcionalidades:

  • migração para "systemd"
  • Suporte para grub2 no instalador
  • Suporte para GPT no instalador

Example of things that shouldn't be listed as features :

  • update cowsay to the latest version
  • fix crash of XXX package
  • add package for XXXX software

Como definir e propor uma funcionalidade

Everybody is free to propose new features for coming releases but this will have to be done using the following procedure :

  1. If not already done, register an account on http://identity.mageia.org to be able to edit the wiki
  2. create a wiki page of the name http://wiki.mageia.org/en/Feature:<feature_name> using the following template.
  3. When you think the feature page is ready :
    • add the page to the category ProposedFeatureMageia7 (add the text [[Category:ProposedFeatureMageia7]] at the bottom of the page). Your feature should then appear in the list of proposed features.
    • send an email to the dev mailing list, with the subject "Proposed Feature: featurename" to discuss the feature and let people know about it, so they can add themselves to the page if they plan to participate

Como participr numa funcionalidade

If you think a feature is interesting, and you plan to help implement it, add yourself to the resources list.

Lista de funcionalidades propostas

The list of proposed features for mga3 is available on this page.
The list of proposed features for mga4 is available on this page.
The list of proposed features for mga5 is available on this page.
The list of proposed features for mga6 is available on this page.
The list of proposed features for mga7 is available on this page.
The list of proposed features for mga8 is available on this page.

Criteria used to choose features

Example for Mageia 5: FeatureMageia5_Review

Here is a non-exhaustive list of criteria:

  • wiki page to apply is complete on following items:
    • Summary
    • Owner
    • Targeted release
    • Detailed Description
    • Why it would be good for Mageia to include it
    • Software / Packages Dependencies
    • What could disrupt development of this new feature
    • Planning
    • Contingency (aka Plan B - what happens if it doesn't work)
  • amount of people that plan to be involved in the feature: a feature cannot be implemented if nobody plans to work on it

Features acceptance

After the end of feature proposal submissions, a mail is sent to the dev mailing list with a preliminary list of accepted and rejected features.

The accepted features have been reckoned as :

  • useful and consistent with the goal and policies of the project
  • having enough details
  • having a realistic planning
  • having enough people involved in the features
  • having seen no major and unanswered objections in discussions about the feature

The rejected features list includes for each feature the reason(s) for not accepting the feature. Features can be rejected for different reasons (non-exhaustive list) :

  • not enough people plan to be involved in the feature
  • not enough details about the feature
  • missing planning or contingency plan
  • unrealistic planning
  • objections to the feature in discussions on the mailing list

When the preliminary list of accepted and rejected features is published, comments are received for one week :

  • objections to an accepted feature
  • comments adding more details to a rejected feature (description, planning, contingency plan ...)
  • people adding themselves to the list of feature contributors

Depois de uma semana:

  • accepted features that receive no new comment are officially accepted
  • rejected features that receive no new comment are officially refused
  • accepted features that receive objection comments are officially rejected unless a consensus is reached in the discussions
  • rejected features that receive additional details or interested contributors and reached consensus for acceptance in discussions are officially accepted

A lista final das funcionalidades aceites é:

  • published on the blog and wiki (added to category FeatureMageia3) and advertised
  • development of the features is started according to the planning
  • the planning of each feature is monitored and discussed in developers meetings until the feature is completed

Rejected features are not included in the official specifications of the distribution, and planning is not monitored in developers meetings. Depending on the reasons for rejecting the feature, it can still be implemented by interested people.