2. fedora-docs-l10n/council
3. master/pages/policy/edition-promotion-policy
4. Portuguese
5. Browse

1 / 2

/ 2

All strings

• Not translated strings • state:empty
• Strings needing action • state:<translated
• Translated strings • state:>=translated
• Strings marked for edit • state:needs-editing
• Strings with suggestions • has:suggestion
• Strings with variants • has:variant
• Strings with labels • has:label
• Strings with context • has:context
• Strings needing action without suggestions • state:<translated AND NOT has:suggestion
• Strings with comments • has:comment
• Strings with any failing checks • has:check
• Approved strings • state:approved
• Strings waiting for review • state:translated

Position and priority

• Position and priority
• Position
• Priority
• Labels
• Source string
• Translated string
• Age of string
• Number of words
• Number of comments
• Number of failing checks
• Key

	English	Portuguese
	Process for promoting a Fedora deliverable to Edition
	Fedora Editions are curated sets of packages, guidelines and configuration, and artifacts built from those pieces, that address a specific, targeted use-case. The Editions are the primary Fedora outputs that most Fedora users are encouraged to use and directed towards through the download site.
	This document describes the process for promoting an existing Fedora deliverable to Edition status.
	Prerequisites
	The candidate Edition must be backed by a team that holds regular public meetings
	The candidate Edition must get trademark approval from the Fedora Council. If this includes a name change or a new name (e.g. “Fedora Bilverslue”), plan time for legal review.
	The candidate Edition must have a product requirements document (PRD) (https://fedoraproject.org/wiki/Workstation/Workstation_PRD[example]). The PRD is used by other teams within Fedora (for example: the QA team uses it to develop release criteria and test cases, the marketing team uses it to develop collateral and positioning). The PRD must include:
	Market target, including key use cases and personas
	Core services and features
	Core applications
	Unique policies for installation, updates, etc
	Scope of hardware support (including anything that is explicitly unsupported)
	Produced deliverables, and whether or not they should be considered release blocking
	The candidate Edition may have a technical specification (https://fedoraproject.org/wiki/Workstation/Technical_Specification[example]) that provides additional detail about the specific features described in the PRD.
	It is helpful to have someone on the team assigned to handle the bureaucratic tasks
	Process
	When all of the prerequisites have been met, the team submits promotion as a System-Wide Change. This ensures that Release Engineering, FESCo, and the community at large have the opportunity to provide input. It also implies that the promotion may be delayed to the next release if the appropriate supporting pieces are not in place by the Beta or GA freezes.
	Prior to submitting the Change proposal, the following tasks should be completed:
	*Review test cases and release criteria with QA.* The QA team will draft test cases and release criteria based on the PRD. However, the Edition team must verify that these are valid. The Edition team may choose to assign a person to be the liaison with the QA team.
	*Work with Release Engineering.* The Edition team should work with release engineering on how they are planning on composing the new edition, release process, mirrors sync locations, any changes needed to koji, bodhi or autosigning.