Why this policy?
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.
What is a feature
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.
Example of features :
- migration to systemd
- grub2 support in the installer
- GPT support in the installer
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
How to define and propose a feature
Everybody is free to propose new features for coming releases but this will have to be done using the following procedure :
- If not already done, register an account on http://identity.mageia.org to be able to edit the wiki
- create a wiki page of the name http://wiki.mageia.org/en/Feature:<feature_name> using the following template.
- When you think the feature page is ready :
- add the page to the category ProposedFeatureMageia9 (add the text [[Category:ProposedFeatureMageia9]] 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
How to participate in a feature
If you think a feature is interesting, and you plan to help implement it, add yourself to the resources list.
List of proposed features
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:
- 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
- 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
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
After one week :
- 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
The final list of accepted features is :
- 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.