#210 Docs: Convert all docs to native AsciiDoc
Merged 9 months ago by jflory7. Opened 9 months ago by jflory7.
Fedora-Council/ jflory7/council-docs change/one-sentence-per-line  into  main

@@ -109,7 +109,7 @@ 

  link:{FWIKI}/User:Decause[Remy DeCausemaker]::

    February 2015 – June 2016 (_Fedora Linux 22 to 24_)

  

- [[previous-title]]

+ [[previous-titles]]

  === What about FCAIC and FCL?

  

  The title of this role evolved and changed over the years since its inception in February 2015.

@@ -6,24 +6,26 @@ 

  They are employed full-time by Red Hat to manage the planning and release processes for Fedora Linux.

  This includes schedule management, change wrangling, and providing status reports to the community and to Red Hat.

  

+ 

  [[current]]

  == Current Program Manager

  

  The role was eliminated in May 2023.

  

+ 

  [[roles]]

- == Roles and Responsibilities ==

+ == Roles and Responsibilities

  

  Within the Fedora Project, the Program Manager is primarily responsible for release coordination activities.

  

  [[roles-changes]]

- === Changes Process ===

+ === Changes Process

  

  * Shepharding Change proposals through the xref:program_management::changes_policy.adoc[Changes process]

  * Tracking the status of Changes during the development/testing cycle

  

  [[roles-releases]]

- === Release Coordination ===

+ === Release Coordination

  

  * https://fedorapeople.org/groups/schedule/[Scheduling] xref:releases::index.adoc[Fedora Linux releases]

  * Coordinating release readiness (within QA, Release Engineering, FESCo, etc.)
@@ -31,26 +33,28 @@ 

  * Perform mass updates of bugs at branch and end-of-life time

  

  [[roles-elections]]

- === Elections ===

+ === Elections

  

  * Managing xref:program_management::elections.adoc[elections] for {team_name}, FESCo, and Mindshare

  * Ad-hoc election support for other teams when needed

  

  [[roles-council]]

- === {team_name} ===

+ === {team_name}

  

  * Serve as a member of the {team_name}

  * Act as {team_name} secretary

  

  [[roles-misc]]

- === Miscellaneous ===

+ === Miscellaneous

  

  * Advise on the processes in the Fedora Project

  * Provide regular status reports to the community

  * Coordinate the xref:program_management::prioritized_bugs.adoc[Prioritized Bugs process]

  * Manage the processes for removing inactive packagers and inactive provenpackagers

  

- == History ==

+ 

+ [[history]]

+ == History

  

  Previous Fedora Program Managers:

  
@@ -60,7 +64,10 @@ 

  * link:{FWIKI}/User:Rbergero[Robyn Bergeron] (Fedora 17-20)

  * link:{FWIKI}/User:Poelstra[John Poelstra] (Fedora 8-16)

  

- == Useful links ==

+ 

+ [[links]]

+ == Useful links

+ 

  * https://fedorapeople.org/groups/schedule[Schedules] in HTML, ICS, and JSON formats

  * https://pagure.io/fedora-pgm/schedule[Schedule repository] to report scheduling issues

- * xref:releases::lifecycle.adoc[Fedora Linux Release Life Cycle] aka how to schedule next Fedora release

+ * xref:releases::lifecycle.adoc[Fedora Linux Release Life Cycle], A.K.A. how to schedule next Fedora release

@@ -3,124 +3,78 @@ 

  

  [NOTE]

  ====

- The "Stable Updates Vision"

- was adopted by the Fedora Board

- in March 2010,

- and is referenced in the _current_

- Fedora Engineering Steering Committee

- https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[updates policy].

- While some of the background factors

- have changed since then,

- the fundamentals which informed the FESCo policy

- are still relevant.

+ The "Stable Updates Vision" was adopted by the Fedora Board in March 2010, and is referenced in the _current_ Fedora Engineering Steering Committee https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[updates policy].

+ While some of the background factors have changed since then, the fundamentals which informed the FESCo policy are still relevant.

  ====

  

+ 

+ [[background]]

  == Background

  

- Discussions on March 2010 in various Fedora mailing lists have shown

- that we currently have a wide variety of positions on what Fedora's

- update strategy should look like. These range from a _rolling_ release,

- to a _locked down security-only update_ solution. The lack of clarity on

- this issue contributes to confusion among package maintainers and end

- users alike.

+ Discussions on March 2010 in various Fedora mailing lists have shown that we currently have a wide variety of positions on what Fedora's update strategy should look like.

+ These range from a _rolling_ release, to a _locked down security-only update_ solution.

+ The lack of clarity on this issue contributes to confusion among package maintainers and end users alike.

  

- Most people agree that broken updates are detrimental to the Fedora

- distribution and should be avoided.

+ Most people agree that broken updates are detrimental to the Fedora distribution and should be avoided.

  

  Fewer people agree on:

  

- * How many updates are acceptable for a stable release and how to

- measure them

+ * How many updates are acceptable for a stable release and how to measure them.

  * What constitutes an acceptable update to a stable release.

- * At what cost should broken updates be avoided, trading off occasional

- broken updates for delivery speed for new software and maintainer

- workflow simplicity.

+ * At what cost should broken updates be avoided, trading off occasional broken updates for delivery speed for new software and maintainer workflow simplicity.

  

- For these reasons, the Fedora Board is issuing a stable release update

- vision statement to help guide the creation and implementation of a

- Fedora Updates policy. This policy is not meant to govern the

- introduction of new packages.

+ For these reasons, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy.

+ This policy is not meant to govern the introduction of new packages.

  

- By creating this statement it is the Board's belief that:

+ By creating this statement, it is the Board's belief that:

  

  * End-user satisfaction with our distribution will increase

- * Developers and end-users will have a more solid stable release

- experience

- * End-users and developers will have more time to focus on other areas

- in Fedora

+ * Developers and end-users will have a more solid stable release experience

+ * End-users and developers will have more time to focus on other areas in Fedora

+ 

  

+ [[factors]]

  == Factors

  

- When creating an updates overview, there are some factors that need to

- be taken into account. The first, and foremost, is keeping in mind

- https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html[the

- broad criteria] the Board set out for the target audience of the entire

- Fedora distribution, which describe someone who:

+ When creating an updates overview, there are some factors that need to be taken into account.

+ The first, and foremost, is keeping in mind https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html[the broad criteria] the Board set out for the target audience of the entire Fedora distribution, which describe someone who:

  

  . is voluntarily switching to Linux

- . is familiar with computers but is not necessarily a hacker or

- developer

- . is likely to collaborate in some fashion when something's wrong with

- Fedora, and

- . wants to use Fedora for general productivity, either using desktop

- applications or a Web browser.

- 

- A shifting platform and visible behavioral changes will affect the

- user's productivity because the user must take time away from the

- desired tasks to discover what has changed, adjust the way they perform

- supporting tasks, and refocus on their original objectives. Because

- productivity is postulated as important to this user, this outcome is

- undesirable. Similarly, dealing with a large number of updates on a

- regular basis is distracting from the user's desired productivity tasks.

- 

- Updates offered by our built-in tools under the auspices of the Fedora

- Project are seen as authoritative by users. While a user fitting these

- criteria is likely to file a bug when something goes wrong, the user

- does not therefore automatically expect new issues to emerge in a stable

- release as a result of consuming those updates. When such issues do

- emerge, the user's confidence in the platform is undermined.

- 

- Another factor to keep in mind is Fedora's rapid development cycle. A

- six month development cycle for a release allows Fedora to integrate the

- latest and greatest releases from upstream projects into the 'rawhide'

- distribution and have that body of work available to the user base in a

- relatively short amount of time. Ideally, this rapid paced release cycle

- allows both developers and users the chance to focus on a coherent,

- consistent, and well functioning set of software content per release.

+ . is familiar with computers but is not necessarily a hacker or developer

+ . is likely to collaborate in some fashion when something's wrong with Fedora, and

+ . wants to use Fedora for general productivity, either using desktop applications or a Web browser.

+ 

+ A shifting platform and visible behavioral changes will affect the user's productivity because the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives.

+ Because productivity is postulated as important to this user, this outcome is undesirable.

+ Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks.

+ 

+ Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by users.

+ While a user fitting these criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming those updates.

+ When such issues do emerge, the user's confidence in the platform is undermined.

+ 

+ Another factor to keep in mind is Fedora's rapid development cycle.

+ A six-month development cycle for a release allows Fedora to integrate the latest and greatest releases from upstream projects into the 'rawhide' distribution and have that body of work available to the user base in a relatively short amount of time.

+ Ideally, this rapid paced release cycle allows both developers and users the chance to focus on a coherent, consistent, and well functioning set of software content per release.

+ 

  

  [[vision_statement]]

  == Vision Statement

  

- Taking the background and various factors above into account, the Board

- believes update streams should be managed with the following purposes in

- mind:

- 

- * The update repositories for stable releases of the Fedora distribution

- should provide our users with a consistent and high quality stream of

- updates.

- * Stable releases should provide a consistent user experience throughout

- the lifecycle, and only fix bugs and security issues.

- * Stable releases should not be used for tracking upstream version

- closely when this is likely to change the user experience beyond fixing

- bugs and security issues.

- * Close tracking of upstream should be done in the Rawhide repo wherever

- possible, and we should strive to move our patches upstream.

- * More skilled and/or intrepid users are encouraged to use link:Rawhide[

- _Rawhide_] along with participating in testing of stable branches during

- the development and pre-release period.

- * Stable releases, pre-release branches, and Rawhide have a graduated

- approach to what types of updates are expected. For example, a

- pre-release branch should accept some updates which a stable release

- would not, and rawhide would accept updates that are not appropriate for

- either a stable release or a pre-release.

- * Project members should be able to transparently measure or monitor a

- new updates process to objectively measure its effectiveness, and

- determine whether the updates process is achieving the aforementioned

- vision statements.

+ Taking the background and various factors above into account, the Board believes update streams should be managed with the following purposes in mind:

+ 

+ * The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates.

+ * Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.

+ * Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues.

+ * Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream.

+ * More skilled and/or intrepid users are encouraged to use xref:releases:rawhide.adoc[_Rawhide_] along with participating in testing of stable branches during the development and pre-release period.

+ * Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected.

+   For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release.

+ * Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements.

+ 

  

+ [[implementation]]

  == Implementation

  

- Following the Fedora Board vision statement, the following policy was

- approved and in effect from October 2010:

+ Following the Fedora Board vision statement, the following policy was approved and in effect from October 2010:

  

- https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]

+ xref:fesco::Updates_Policy.adoc[Updates Policy]

@@ -2,28 +2,11 @@ 

  

  = Fedora Governance Historical Documents

  

- Fedora has a long history,

- and things have changed along the way.

- Sometimes,

- there are policy or procedure documents

- that have significance for remembering

- why things are the way they are

- and how we got here.

+ Fedora has a long history, and things have changed along the way.

+ Sometimes, there are policy or procedure documents that have significance for remembering why things are the way they are and how we got here.

  

- This section is for those,

- so they can be found in one plcae

- rather than scattered everywhere,

- and so they aren't accidentally lost forever

- in some future infrastructure transition.

+ This section is for those, so they can be found in one place rather than scattered everywhere, and so they aren't accidentally lost forever in some future infrastructure transition.

  

- We don't want to keep _everything_,

- and even of text worth preserving,

- this isn't necessarily the place.

- But if you find something that

- you think is relevant to Fedora's

- guiding policies,

- overall governance,

- or similar,

- please submit as a pull request

- to the https://pagure.io/Fedora-Council/council-docs[{team_name} Docs].

+ We don't want to keep _everything_, and even of text worth preserving, this isn't necessarily the place.

+ But if you find something that you think is relevant to Fedora's guiding policies, overall governance, or similar, please submit as a pull request to the https://pagure.io/Fedora-Council/council-docs[{team_name} Docs].

  Thank you!

@@ -2,11 +2,12 @@ 

  

  = {team_name} and Board Historical Membership

  

- == History of {team_name} Membership

+ [[council]]

+ == {team_name} Membership

  

  Previous members of the {team_name} are listed here.

  

- 

+ [[council-elected]]

  === Elected Representatives

  

  |===
@@ -23,12 +24,11 @@ 

  |Langdon White     | November 2014 – August 2016 (f22, f23-f24, f25-f26)

  |===

  

- _Historical note:  The initial elected representatives were selected in a

- single election, with the candidate with the most votes selected for a full

- term (through the release of F23) and the runner-up for a half term (through

- the release of F22)._

+ _Historical note:

+ The initial elected representatives were selected in a single election, with the candidate with the most votes selected for a full term (through the release of F23) and the runner-up for a half term (through the release of F22)._

  

- === Project Objective Leads

+ [[council--initiative-leads]]

+ === Community Initiative Leads

  

  |===

  |Stephen Gallagher | _Three Editions (Fedora.next)_ | January 2015 – November 2015
@@ -44,6 +44,7 @@ 

  |Akashdeep Dhar | _Websites & Apps Revamp_ | June 2021 – April 2023

  |===

  

+ [[council-engineering]]

  === Engineering Representative

  

  |===
@@ -52,6 +53,7 @@ 

  |David Cantrell | June 2020 - present

  |===

  

+ [[council-mindshare]]

  === Mindshare Representative

  

  |===
@@ -62,7 +64,8 @@ 

  |Alberto Rodríguez Sánchez | April 2021 - present

  |===

  

- === Diversity, Equity, & Inclusion Advisor

+ [[council-dei]]

+ === Diversity, Equity, & Inclusion (DEI) Advisor

  

  |===

  |María Leandro    | March 2016 — March 2017
@@ -73,7 +76,8 @@ 

  |Jona Azizaj  | September 2023 - present

  |===

  

- === Fedora Program Manager

+ [[council-fpgm]]

+ === Fedora Program Manager (FPgM)

  

  |===

  |Ben Cotton       | June 2018 – May 2023
@@ -81,7 +85,8 @@ 

  |Jaroslav Reznik  | September 2014 – May 2015

  |===

  

- === Fedora Community Action and Impact Coordinator

+ [[council-fca]]

+ === Fedora Community Architect (FCA)

  

  |===

  |Marie Nordin      | November 2019 - October 2022
@@ -90,17 +95,11 @@ 

  |===

  

  

- '''

- <<<

- 

- 

- 

- History of Fedora Board Membership

- ----------------------------------

+ [[board]]

+ == Fedora Board Membership

  

- The Fedora Board was the Project's top-level governance body from July 2007

- to November 2014. Before that, the "Fedora Advisory Board" was merely (as

- the name suggests) advisory and had no formal membership.

+ The Fedora Board was the Project's top-level governance body from July 2007 to November 2014.

+ Before that, the "Fedora Advisory Board" was merely (as the name suggests) advisory and had no formal membership.

  

  |===

  |Elliot Lee          |   Apr 2006 - Nov 2006

@@ -6,100 +6,73 @@ 

  

  {team_summary}

  

- The {team_name} is composed of a mix of representatives from different areas

- of the project, named roles appointed by Red Hat, and a variable number

- of seats connected to medium-term project goals. Decisions are made by a

- *consensus process*, in which we work together as a common team to find

- shared solutions and address concerns, with a focus on giving voice

- rather than on balance of power.

+ The {team_name} is composed of a mix of representatives from different areas of the project, named roles appointed by Red Hat, and a variable number of seats connected to medium-term project goals.

+ Decisions are made by a *consensus process*, in which we work together as a common team to find shared solutions and address concerns, with a focus on giving voice rather than on balance of power.

  

- The {team_name} is ultimately accountable for the Fedora Project as a whole,

- and is responsible for providing advice to and oversight of other Fedora

- governance bodies and teams as needed.

+ The {team_name} is ultimately accountable for the Fedora Project as a whole, and is responsible for providing advice to and oversight of other Fedora governance bodies and teams as needed.

  

- Responsibilities

- ----------------

  

- The {team_name} is responsible for issues of strategic importance for Fedora

- that require leadership and coordination across the various teams and

- subprojects to achieve.

+ [[responsibilities]]

+ == Responsibilities

  

- *Its primary role is to identify the short, medium, and long term goals

- of the Fedora community and to organize and enable the project to best

- achieve them.* This is done in consultation with the entire Fedora

- community through transparent, public discussion.

+ The {team_name} is responsible for issues of strategic importance for Fedora that require leadership and coordination across the various teams and sub-projects to achieve.

  

- The {team_name} *governs Fedora's financial resources*, working with our

- sponsor(s) to establish an annual budget allocated to support Fedora

- initiatives, including Fedora Ambassadors, Fedora-managed events, and

- other activities which advance the project's goals.

+ *Its primary role is to identify the short, medium, and long term goals of the Fedora community and to organize and enable the project to best achieve them*.

+ This is done in consultation with the entire Fedora community through transparent, public discussion.

  

- The {team_name} also decides on issues regarding use of the Fedora

- *trademarks*, is responsible for final *arbitration of complaints*

- related to project policies and for *settling disputes* escalated from

- other committees or subgroups, and may handle *sensitive legal or

- personnel issues* which require research and discussion to protect the

- interests of the Fedora Project or its sponsor(s).

+ The {team_name} *governs Fedora's financial resources*, working with our sponsor(s) to establish an annual budget allocated to support Fedora initiatives, including Fedora Ambassadors, Fedora-managed events, and other activities which advance the project's goals.

  

+ The {team_name} also decides on issues regarding use of the Fedora *trademarks*, is responsible for final *arbitration of complaints* related to project policies and for *settling disputes* escalated from other committees or subgroups, and may handle *sensitive legal or personnel issues* which require research and discussion to protect the interests of the Fedora Project or its sponsor(s).

  

- Making Decisions

- ----------------

+ 

+ [[decisions]]

+ == Making Decisions

  

  [sidebar.width33]

  ****

  Consensus decision-making aims to be:

  

- * *Agreement Seeking:* A consensus decision-making process attempts to help everyone get what they need.

- * *Collaborative:* Participants contribute to a shared proposal and shape it into a decision that meets the concerns of all group members as much as possible.

- * *Cooperative:* Participants in an effective consensus process should strive to reach the best possible decision for the group and all of its members, rather than competing for personal preferences.

- * *Egalitarian:* All members of a consensus decision-making body should be afforded, as much as possible, equal input into the process. All members have the opportunity to present, and amend  proposals.

- * *Inclusive:* As many stakeholders as possible should be involved in the consensus decision-making process.

- * *Participatory:* The consensus process should actively solicit the input and participation of all decision-makers

+ * *Agreement Seeking:*

+   A consensus decision-making process attempts to help everyone get what they need.

+ * *Collaborative:*

+   Participants contribute to a shared proposal and shape it into a decision that meets the concerns of all group members as much as possible.

+ * *Cooperative:*

+   Participants in an effective consensus process should strive to reach the best possible decision for the group and all of its members, rather than competing for personal preferences.

+ * *Egalitarian:*

+   All members of a consensus decision-making body should be afforded, as much as possible, equal input into the process.

+   All members have the opportunity to present, and amend  proposals.

+ * *Inclusive:*

+   As many stakeholders as possible should be involved in the consensus decision-making process.

+ * *Participatory:*

+   The consensus process should actively solicit the input and participation of all decision-makers.

  

  — from https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives[Wikipedia on Consensus decision-making]

- 

  ****

  

- Many basic decisions are made through a process known as “*lazy

- approval*”, in which general consent is assumed unless valid objections

- are raised within a period of time — generally three to seven days,

- although the timeframe should be stated each time and should be

- proportionate to the impact of the action. This process is used for

- decisions with short-term consequences and which can be easily reversed.

- Any project member can ask for the deadline to be extended or the

- decision escalated to require full consensus.

- 

- More significant decisions are made through a process of *full

- consensus*. In order to pass, these decisions need three positive votes

- (+3) and _no_ negative votes (-1). A negative vote immediately halts the

- process and requires discussion. Therefore, in order to remain valid,

- negative votes must be supported with a specific concerns about the

- proposal, and suggestions for what could be changed in order to make the

- proposal acceptable. A vote of “0” is sometimes used to indicate a

- disagreement but willingness to stand aside; this should also be

- accompanied with an explanation.

- 

- This model matches Fedora's “Friends” foundation, which calls for

- finding acceptable consensus to serve the interests of advancing free

- software. It works because we work together in a community of mutual

- respect even when we disagree.

- 

- In general, the {team_name} conducts business in public discussion, and any

- Fedora project member can make negative or positive votes. It is the

- duty of the {team_name} to take concerns raised in this way into serious

- consideration, but only {team_name} members' votes are binding in the final

- tally.

- 

- When consensus can't be reached, the {team_name} may ask the Fedora Project

- Leader to decide on a resolution. Such a request can be made when issues

- leading to negative votes are outstanding and all {team_name} members agree

- that the {team_name} is deadlocked, or if the dispute is unresolved after

- fourteen days and a simple majority of {team_name} members are in favor of

- the request.

+ Many basic decisions are made through a process known as “*lazy approval*”, in which general consent is assumed unless valid objections are raised within a period of time — generally three to seven days, although the timeframe should be stated each time and should be proportionate to the impact of the action.

+ This process is used for decisions with short-term consequences and which can be easily reversed.

+ Any project member can ask for the deadline to be extended or the decision escalated to require full consensus.

+ 

+ More significant decisions are made through a process of *full consensus*.

+ In order to pass, these decisions need three positive votes (+3) and _no_ negative votes (-1).

+ A negative vote immediately halts the process and requires discussion.

+ Therefore, in order to remain valid, negative votes must be supported with a specific concerns about the proposal, and suggestions for what could be changed in order to make the proposal acceptable.

+ A vote of “0” is sometimes used to indicate a disagreement but willingness to stand aside; this should also be accompanied with an explanation.

+ 

+ This model matches Fedora's “Friends” foundation, which calls for finding acceptable consensus to serve the interests of advancing free software.

+ It works because we work together in a community of mutual respect even when we disagree.

  

+ In general, the {team_name} conducts business in public discussion, and any Fedora project member can make negative or positive votes.

+ It is the duty of the {team_name} to take concerns raised in this way into serious consideration, but only {team_name} members' votes are binding in the final tally.

  

+ When consensus cannot be reached, the {team_name} may ask the xref:fpl.adoc[Fedora Project Leader] to decide on a resolution.

+ Such a request can be made when issues leading to negative votes are outstanding and all {team_name} members agree that the {team_name} is deadlocked, or if the dispute is unresolved after fourteen days and a simple majority of {team_name} members are in favor of the request.

+ 

+ 

+ [[composition]]

  == Composition

  

+ [[composition--initiative-leads]]

  === Community Initiative Leads

  

  On an ongoing basis, including sessions at Flock and in public online meetings, the {team_name} will identify two to four key xref:project::initiatives.adoc[Community Initiatives] with a timeframe of approximately eighteen months, and appoint *Community Initiative Leads* for each goal.
@@ -107,87 +80,74 @@ 

  

  Each Community Initiative will be documented with measurable goals, and the Community Initiative Lead is responsible for coordinating efforts to reach those goals, evaluating and reporting on progress, and working regularly with all relevant groups in Fedora to ensure that progress is made.

  

+ [[composition-representatives]]

  === Representatives

  

- The {team_name} also includes five representative seats, an *Engineering Representative*, a *Mindshare Representative*, a *DEI Advisor* and two *Elected Representatives*.

+ The {team_name} also includes five representative seats: an *Engineering Representative*, a *Mindshare Representative*, a xref:dei:roles:council-advisor.adoc[*DEI Advisor*], and two *Elected Representatives*.

  

+ [[composition--representatives--engineering-mindshare]]

  ==== Engineering & Mindshare Representatives

  

- “Engineering” and “Mindshare” are broad areas roughly encompassing two

- of the major areas of activity in Fedora. _Engineering_ is the technical

- work related to building and releasing the Fedora operating system and

- the infrastructure related to that. _Mindshare_ includes marketing,

- design, and Fedora Ambassadors — largely activities that happen between

- Fedora and the world at large, with the distribution release cycle

- serving as a fuel source, not the thing that's being worked on.

+ “Engineering” and “Mindshare” are broad areas roughly encompassing two of the major areas of activity in Fedora.

+ _Engineering_ is the technical work related to building and releasing the Fedora operating system and the infrastructure related to that.

+ _Mindshare_ includes marketing, design, and Fedora Ambassadors — largely activities that happen between Fedora and the world at large, with the distribution release cycle serving as a fuel source, not the thing that's being worked on.

  

  The engineering and mindshare representatives' responsibility is to

  represent their areas collectively, _not_ to be just an individual voice

  that happens to be voted-in by some subset of Fedora.

  They are selected by contributors working in those areas, under the rules of the xref:fesco::Fedora_Council_Engineering_Rep.adoc[Fedora Engineering Steering Committee (FESCo)] and the xref:mindshare-committee::procedures/council_rep.adoc[Mindshare Committee], respectively.

  

+ [[composition-representatives-dei]]

  ==== Diversity, Equity, & Inclusion (DEI) Advisor

  

- The *Fedora Diversity, Equity, & Inclusion (DEI) Advisor* is a liaison between the {team_name} and the Fedora community on topics and issues related to diversity, equity, and inclusion in Fedora.

+ The xref:dei:roles:council-advisor.adoc[*Fedora Diversity, Equity, & Inclusion (DEI) Advisor*] is a liaison between the {team_name} and the Fedora community on topics and issues related to diversity, equity, and inclusion in Fedora.

  The DEI Advisor works with {team_name} leadership to represent perspectives and voices of the Fedora community in decision-making and project discussions.

- Additionally, they also lead initiatives to assess and promote equity and inclusion in collaboration with the xref:dei::index.adoc[Fedora DEI Team].

- 

- This position is appointed by members of the Fedora DEI Team, with the approval of the {team_name}.

+ This position is appointed by members of the xref:dei::index.adoc[Fedora DEI Team], with the approval of the {team_name}.

  

+ [[composition-representatives-elected]]

  ==== Elected Representatives

  

- The elected positions cover all Fedora subprojects that are not under the

- engineering or mindshare banners, and the community at large. One

- specific responsibility is to represent the voice of individual

- contributors to the Fedora project. Each representative will also work

- on specific goals which she or he brings to the {team_name} as highlighted

- during the election process.

+ The elected positions cover all Fedora subprojects that are not under the engineering or mindshare banners, and the community at large.

+ One specific responsibility is to represent the voice of individual contributors to the Fedora Project.

+ Each representative will also work on specific goals which they bring to the {team_name} as highlighted during the election process.

  

- Elections are held twice a year, in concert with the joint Fedora

- election cycle. One seat is selected at each election, and each position

- has a two-election (approximately one year) term. No person who

- currently holds another {team_name} seat can be elected. If a seat becomes

- vacant, the {team_name} will arrange for a temporary replacement.

+ Elections are held twice a year, in concert with the joint Fedora election cycle.

+ One seat is selected at each election, and each position has a two-election (approximately one year) term.

+ No person who currently holds another {team_name} seat can be elected.

+ If a seat becomes vacant, the {team_name} will arrange for a temporary replacement.

  

+ [[composition-appointed]]

  === Appointed Leadership Positions

  

- *Fedora Project Leader*

+ [[composition-appointed-fpl]]

+ ==== Fedora Project Leader (FPL)

  

- The xref:fpl.adoc[Fedora Project Leader] serves as the

- chair of the {team_name}, organizing discussion agendas, bringing issues to

- the table, and facilitating the consensus process. He or she is

- accountable for success in all areas of the project, but is not a

- dictator, benevolent or otherwise. The FPL often serves as the public

- face and collective voice of the project, and has a corresponding duty

- to listen to, understand, and fairly represent the collective views and

- needs of project contributors and stakeholders.

+ The xref:fpl.adoc[Fedora Project Leader] (FPL) serves as the chair of the {team_name}, organizing discussion agendas, bringing issues to the table, and facilitating the consensus process.

+ He or she is accountable for success in all areas of the project, but is not a dictator, benevolent or otherwise.

+ The FPL often serves as the public face and collective voice of the project, and has a corresponding duty to listen to, understand, and fairly represent the collective views and needs of project contributors and stakeholders.

  

- The Fedora Project Leader is hired by Red Hat with the advice and

- consent of the {team_name}.

+ The Fedora Project Leader is hired by Red Hat with the advice and consent of the {team_name}.

  

- *Fedora Community Architect*

+ [[composition-appointed-fca]]

+ ==== Fedora Community Architect (FCA)

  

- The xref:fca.adoc[Fedora Community Architect (FCA)] works to grow the Fedora user and developer

- communities, and to make Red Hat / Fedora interactions even more

- transparent and positive. The Fedora community budget comes to us

- through the Red Hat Open Source Program Office, and this position facilitates decision-making on how to

- best focus that to meet our collective objectives.

+ The xref:fca.adoc[Fedora Community Architect] (FCA) works to grow the Fedora user and developer communities, and to make Red Hat / Fedora interactions even more transparent and positive.

+ The Fedora community budget comes to us through the Red Hat Open Source Program Office, and this position facilitates decision-making on how to best focus that to meet our collective objectives.

  

- *Fedora Program Manager*

+ [[composition-appointed-fpgm]]

+ ==== Fedora Program Manager (FPgM)

  

- The link:{FWIKI}/Fedora_Program_Management#Fedora_Program_Manager[FPgM] coordinates the planning and

- scheduling of Fedora releases, and tracks changes and features during

- the development and testing cycle. He or she also assists with the

- creation, maintenance, and execution of formal, repeatable Fedora

- processes. Additionally, the FPgM serves as record keeper and secretary

- for {team_name} Meetings.

+ The xref:fpgm.adoc[Fedora Program Manager] (FPgM) coordinates the planning and scheduling of Fedora releases, and tracks changes and features during the development and testing cycle.

+ He or she also assists with the creation, maintenance, and execution of formal, repeatable Fedora processes.

+ Additionally, the FPgM serves as record keeper and secretary for {team_name} meetings.

  

- This position is funded by and hired for by Red Hat, with the approval

- of the {team_name}.

+ This position is funded by and hired for by Red Hat, with the approval of the {team_name}.

  

  

+ [[coda]]

  == Coda

  

+ [[coda-meetings]]

  === Meetings

  

  The {team_name} is not driven by meetings or by tickets, but does hold link:{FWIKI}/Council_Meetings[regular public meetings] (via a chat system or video call).
@@ -202,6 +162,7 @@ 

  Additionally, the xref:fpl.adoc[Fedora Project Leader] will set aside regular times to meet with the community.

  Attendance is not mandatory for all {team_name} members but is encouraged.

  

+ [[coda-transparency]]

  === Transparency

  

  The general policy of the {team_name} is to default to open.
@@ -211,92 +172,54 @@ 

  Occasionally, when personal, private, or sensitive issues need to be discussed, a video call might be used.

  A private mailing list and ticket tracking instance also exist for these situations, but will also only be used when dealing with these uncommon issues.

  

+ [[coda-time]]

+ === Time Commitment

  

- Time Commitment

- ~~~~~~~~~~~~~~~

- 

- Serving on the {team_name} is a significant commitment of time and

- energy. Workload for the various roles will vary, but each will require

- a number of hours every week, and in most cases, the more, the better a

- {team_name} member is able to do the job fully.

- 

- We recognize that most Fedora community members do not have the luxury

- of working on Fedora full-time or as part of a paid position. The time

- commitment required for these roles comes simply from what is required

- to lead a large project like Fedora, and is not intended to be an

- artificial limit on who can participate. We know that that it can be a

- _pragmatic_ limit, and for that reason, the {team_name} is responsible for

- extra effort to receive, recognize, be responsive to, and meaningfully

- reward the input of contributors offering their individual time.

- 

- 

- Governance Philosophy

- ~~~~~~~~~~~~~~~~~~~~~

- 

- To advance free software, we need to provide a sustainable integration

- of free software without cutting corners. By providing a positive first

- impression before and during installation and real use, we support

- Fedora's reputation as a leading and reliable product that attracts

- future users and contributors. To provide that integration and

- experience we must have a clear set of priorities to help all

- contributors decide how to allocate resources and resolve conflicts.

- These priorities are not meant to be exclusive, or to keep contributors

- from working on the parts of Fedora that matter to them.

- 

- These priorities will sometimes expose gaps where contributors need

- additional assistance, and allow them to seek it both within the

- community and by bringing in additional contributors to help,

- exclusively on their particular interest area if desired. While

- narrowing our focus in some areas, though, we must provide opportunities

- for exploration to all contributors within the framework of our core

- values and without impeding progress.

- 

- 

- Historical Note

- ~~~~~~~~~~~~~~~

- 

- The previous link:{FWIKI}/Board[previous governance structure (Fedora Board)]

- had five members directly appointed by Red Hat and five elected at

- large. The current structure is more complicated but has a much greater

- proportion of members selected by the community by election or merit. In

- the previous board structure, the Fedora Project leader had a special

- veto power; in the current model, all voting members can block on

- issues, with a valid reason. The FPL does not have a special veto, but

- does have a limited power to “unstick” things if consensus genuinely

- can't be reached and a decision needs to be made.

+ Serving on the {team_name} is a significant commitment of time and energy.

+ Workload for the various roles will vary, but each will require a number of hours every week, and in most cases, the more, the better a {team_name} member is able to do the job fully.

  

+ We recognize that most Fedora community members do not have the luxury of working on Fedora full-time or as part of a paid position.

+ The time commitment required for these roles comes simply from what is required to lead a large project like Fedora, and is not intended to be an artificial limit on who can participate.

+ We know that that it can be a _pragmatic_ limit, and for that reason, the {team_name} is responsible for extra effort to receive, recognize, be responsive to, and meaningfully reward the input of contributors offering their individual time.

  

- Record of Former Members

- ~~~~~~~~~~~~~~~~~~~~~~~~

+ [[coda-governance]]

+ === Governance Philosophy

  

- Former membership on the {team_name}, along with membership on the

- previous Fedora Board, is documented on the xref:history.adoc[History of

- {team_name} Membership] page.

+ To advance free software, we need to provide a sustainable integration of free software without cutting corners.

+ By providing a positive first impression before and during installation and real use, we support Fedora's reputation as a leading and reliable product that attracts future users and contributors.

+ To provide that integration and experience we must have a clear set of priorities to help all contributors decide how to allocate resources and resolve conflicts.

+ These priorities are not meant to be exclusive, or to keep contributors from working on the parts of Fedora that matter to them.

  

+ These priorities will sometimes expose gaps where contributors need additional assistance, and allow them to seek it both within the community and by bringing in additional contributors to help, exclusively on their particular interest area if desired.

+ While narrowing our focus in some areas, though, we must provide opportunities for exploration to all contributors within the framework of our core

+ values and without impeding progress.

  

- Document History

- ~~~~~~~~~~~~~~~~

- 

- This charter was approved by the Fedora Project Board on

- https://fedorahosted.org/council/ticket/13[Oct. 9th, 2014] and is in effect

- as of Nov. 26th, 2014. Any other significant changes will be noted here;

- smaller changes (minor wording or formating, etc., without impact on

- meaning) can be found in the

- https://pagure.io/Fedora-Council/council-docs/commits/main[git repository]

- for {team_name} documents.

- 

- 2023-05-04: Rename Fedora Community Action and Impact Coordinator to Fedora Community Architect

+ [[coda-historical]]

+ === Historical Note

  

- 2023-04-28: Equalize the auxiliary positions based on link:{team_issue_tracker}/issue/447[ticket #447]

+ The previous link:{FWIKI}/Board[previous governance structure (Fedora Board)] had five members directly appointed by Red Hat and five elected at large.

+ The current structure is more complicated but has a much greater proportion of members selected by the community by election or merit.

+ In the previous board structure, the xref:fpl.adoc[Fedora Project Leader] had a special veto power; in the current model, all voting members can block on issues, with a valid reason.

+ The FPL does not have a special veto, but does have a limited power to “unstick” things if consensus genuinely cannot be reached and a decision needs to be made.

  

- 2023-02-07: Change name of Objectives to Community Initiatives. See xref:project::initiatives.adoc#history[Community Initiatives History & Future].

+ [[coda--former-members]]

+ === Record of Former Members

  

- 2023-02-02: Update Diversity & Inclusion Team Representative to DEI Advisor, remove auxiliary status and designate as a full voting member.

+ Former membership on the {team_name}, along with membership on the previous Fedora Board, is documented on the xref:history.adoc[History of {team_name} Membership] page.

  

- 2017-11-15: Update Diversity Advisor to Diversity & Inclusion Team Representative

  

- 2017-10-20: Move current membership list and contact info to separate docs.

+ [[document-history]]

+ == Document History

  

- 2017-04-05: Switched “Outreach” to Mindshare. (link:{team_issue_tracker}/issue/102[ticket])

+ This charter was approved by the Fedora Project Board on https://fedorahosted.org/council/ticket/13[Oct. 9th, 2014] and is in effect as of Nov. 26th, 2014.

+ Any other significant changes will be noted here; smaller changes (minor wording or formatting, etc., without impact on meaning) can be found in the https://pagure.io/Fedora-Council/council-docs/commits/main[git repository] for {team_name} documents.

  

- 2014-11-26: Initital approval by the Fedora Project Board (link:{team_issue_tracker}/issue/13[ticket])

+ . *2014-11-26*: Initial approval by the Fedora Project Board (link:{team_issue_tracker}/issue/13[ticket]).

+ . *2017-04-05*: Switched “Outreach” to Mindshare (link:{team_issue_tracker}/issue/102[ticket]).

+ . *2017-10-20*: Move current membership list and contact info to separate docs.

+ . *2017-11-15*: Update Diversity Advisor to Diversity & Inclusion Team Representative.

+ . *2023-02-02*: Update Diversity & Inclusion Team Representative to xref:dei:roles:council-advisor.adoc[DEI Advisor], remove auxiliary status, and designate as a full voting member.

+ . *2023-02-07*: Change name of Objectives to Community Initiatives.

+   See xref:project::initiatives.adoc#history[Community Initiatives History & Future].

+ . *2023-04-28*: Equalize the auxiliary positions based on link:{team_issue_tracker}/issue/447[ticket #447].

+ . *2023-05-04*: Rename _Fedora Community Action and Impact Coordinator_ to xref:fca.adoc[_Fedora Community Architect_].

@@ -12,25 +12,23 @@ 

  

  * Elected Representative: *link:{FWIKI}/User:Sumantrom[Sumantro Mukherjee]* _(f37-f38)_

  +

- Sumantro Mukherjee (sumantrom) works in Fedora QA team and takes part in the day to day testing activities.

+ Sumantro Mukherjee (sumantrom) works in Fedora Quality Team and takes part in the day to day testing activities.

  He was formerly elected to Mindshare and represented Mindshare to {team_name} from (2018-2020).

  He loves to blog technical walkthroughs and running community onboarding calls and classroom.

- Currently, is striving to stay positive and test negative (Covid-19 Jokes) :D

+ Currently, he is striving to stay positive and test negative (Covid-19 Jokes) :D

  

  * Engineering Representative: *link:{FWIKI}/User:Dcantrell[David Cantrell]*

  +

- David has been involved in the Linux community since the 1997.  He

- first worked on Fedora Core starting with Fedora Core 4 in 2005.  He

- worked on the installation software (anaconda) and related projects

- for more than 10 years.  His current projects focus on developer

- workflow tools.  He is a Fedora Ambassador and a member of the Fedora

- Engineering Steering Committee.

+ David has been involved in the Linux community since 1997.

+ He first worked on Fedora Core starting with Fedora Core 4 in 2005.

+ He worked on the installation software (anaconda) and related projects for more than 10 years.

+ His current projects focus on developer workflow tools.

+ He is a Fedora Ambassador and a member of the Fedora Engineering Steering Committee.

  

  * Mindshare Representative: *link:{FWIKI}/User:Bt0dotninja[Alberto Rodríguez Sánchez]*

  +

  Alberto 'bt0dotninja' Rodríguez S. describes himself as "a Happy Fedora Contributor".

- As part of the Ambassadors, CommOps, and Fedora-Join and member Mindshare committee,

- he is very interested in finding new ways to grow the contributor base and retain our long-term contributors.

+ As part of the Ambassadors, CommOps, and Fedora-Join and member Mindshare committee, he is very interested in finding new ways to grow the contributor base and retain our long-term contributors.

  He loves getting involved in the local communities, make docs and translations, tacos, and cats.

  

  * DEI Advisor: *link:{FWIKI}/User:Jonatoni[Jona Azizaj]*

@@ -2,7 +2,8 @@ 

  

  = Code of Conduct response policy

  

- Once a ticket notifying us of a code of conduct issue has been filed, the {team_name} will respond with an initial contact message within one week. That will come with a request for response, and further action will come within a week of the {team_name}'s initial response.

+ Once a ticket notifying us of a Code of Conduct issue has been filed, the {team_name} will respond with an initial contact message within one week.

+ That will come with a request for response, and further action will come within a week of the {team_name}'s initial response.

  

  ({team_name} IRC meeting, 2018-05-23)

  
@@ -12,4 +13,4 @@ 

  In this case, each ban should be treated as a separate issue with its own ticket.

  Community members who wish to appeal the ban may file a link:{team_issue_tracker}/issues[ticket with the {team_name}].

  

- The FCAIC is empowered to take action on Code of Conduct reports with an additional +1 from another core {team_name} member or the Diversity & Inclusion Advisor and report back to {team_name}.

+ The xref:fca.adoc[FCA] is empowered to take action on Code of Conduct reports with an additional +1 from another core {team_name} member or the xref:dei:roles:council-advisor.adoc[DEI Advisor] and report back to {team_name}.

@@ -8,78 +8,75 @@ 

  This document describes the process for promoting an existing Fedora deliverable to Edition status.

  

  

- 

+ [[what-makes-edition]]

  == What makes an "Edition"?

  

  A Fedora Edition:

  

- * addresses a distinct,

-   relevant,

-   and broad

-   use-case or userbase

-   that a Fedora Edition is

-   not currently serving;

- 

- * is a long term investment

-   for the Fedora Project; and

- 

- * is consistent

-   with all of

-   Fedora's foundations.

+ * addresses a distinct, relevant, and broad use-case or user-base that a Fedora Edition is not currently serving;

+ * is a long term investment for the Fedora Project; and

+ * is consistent with all of Fedora's Four Foundations.

  

  

+ [[prerequisites]]

  == Prerequisites

  

- * The candidate Edition must be backed by a team that holds regular public meetings

+ * The candidate Edition must be backed by a team that holds regular public meetings.

  * The candidate Edition must get trademark approval from the {team_name}.

    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) (link:{FWIKI}/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 is used by other teams within Fedora.

+   For example, the Quality Team uses it to develop release criteria and test cases and 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

+ ** 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 (link:{FWIKI}/Workstation/Technical_Specification[example]) that provides additional detail about the specific features described in the PRD.

  

- NOTE: It is helpful to have someone on the team assigned to handle the bureaucratic tasks

+ [TIP]

+ ====

+ It is helpful to have someone on the team assigned to handle the bureaucratic tasks.

+ ====

  

+ 

+ [[process]]

  == Process

  

- When all of the prerequisites have been met,

- and approved by the {team_name},

- the team submits promotion as a System-Wide Change.

+ When all of the prerequisites have been met and approved by the {team_name}, 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:

  

- * *Approval from the {team_name}.*

+ * *Approval from the {team_name}*.

    File a ticket and participate in related discussion.

- * *Review test cases and release criteria with QA.*

-   The QA team will draft test cases and release criteria based on the PRD.

+ * *Review test cases and release criteria with the Quality Team*.

+   The Quality 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 may choose to assign a person to be the liaison with the Quality 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.

  

  After the change proposal is approved, the following additional tasks should be completed no later than the Beta freeze, which should be considered the contingency deadline for the change.

  Note that these tasks should be started as early as possible.

  

- * *Request design deliverables.*

-   If customized graphics for the website, stickers, et cetera are needed, the Edition team should contact the Design team as soon as possible.

- * *Provide updated website content.*

-   The Edition team should send text, graphics, and screenshots to the Websites team as soon as possible to ensure getfedora.org will be up-to-date on release day.

- * *Notify Documentation and Translation teams.*

+ * *Request design deliverables*.

+   If customized graphics for the website, stickers, et cetera are needed, the Edition team should contact the Design Team as soon as possible.

+ * *Provide updated website content*.

+   The Edition team should send text, graphics, and screenshots to the Websites & Apps Team as soon as possible to ensure fedoraproject.org will be up-to-date on release day.

+ * *Notify Documentation and Translation teams*.

    The Edition team should let the Documentation team know of any updates or new documentation required.

-   The Edition team should also inform the Translation team of incoming website and documentation updates so they can prepare to translate it in advance of the release

- * *Provide marketing blurbs.*

+   The Edition team should also inform the Translation team of incoming website and documentation updates so they can prepare to translate it in advance of the release.

+ * *Provide marketing blurbs*.

    The Edition team should send basic promotional text to the Marketing and Magazine teams.

    This will allow the release announcement, et cetera to include meaningful information about the new Edition.

    The Edition team may consider writing one or several full Fedora Magazine articles in support of the Edition.

  

+ 

+ [[history]]

  == History

  

  This policy was approved in link:{team_issue_tracker}/issue/296[{team_name} ticket #296].

@@ -7,25 +7,30 @@ 

  The Fedora Project's https://docs.fedoraproject.org/en-US/project/#_our_mission[Vision] is:

  

  ____

- _The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities._

+ _The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities_.

  ____

  

  To accomplish this, our https://docs.fedoraproject.org/en-US/project/#_our_mission[Mission] is:

  

  ____

- _Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users._

+ _Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users_.

  ____

  

- We do this within the context of the four foundations: freedom, friends, features, and first.

+ We do this within the context of the Four Foundations: Freedom, Friends, Features, and First.

  

+ 

+ [[context]]

  == Context

  

  The {team_name} identifies the short-, medium-, and long-term goals necessary to keep the Project on the leading edge of technology.

  The Fedora.next initiative focused the outputs of the project around use cases.

  In 2017, we updated the mission statement to reflect changes in the computing landscape.

- Today, it’s too difficult to build new solutions in Fedora.

+ Today, it is too difficult to build new solutions in Fedora.

+ 

  

+ [[approach]]

  == Our Approach

+ 

  We will make it easy for the community to build solutions, address specific developer problems, and meet their end users’ specific needs.

  We will do this by encouraging and helping Objectives which make the necessary changes required to ease the process.

  This accelerates the transformation of Fedora into a community that enables the construction of solutions. 
@@ -34,11 +39,24 @@ 

  The outputs of Fedora are the Solutions our community members build.

  Our focus on enablement allows experimentation without prior judgement or gate-keeping.

  

+ 

+ [[meaning]]

  == What does this mean?

+ 

  Teams such as Design, Documentation, Packagers, Release Engineering, and Quality Assurance provide building blocks and offer services to other community members and Teams.

- Services and building blocks include: CI infrastructure, community building advice and guidance, event funding, logo services, RPM or other software packages, swag, testing and validation, user support, or UX design.

+ Services and building blocks include the following:

+ 

+ * CI infrastructure

+ * Community building advice and guidance

+ * Event funding

+ * Logo services

+ * RPM or other software packages

+ * Swag

+ * Testing and validation

+ * User support

+ * UX design

  

- Anyone may use Building Blocks like software packages and artwork to create a Solution.

+ Anyone may use building blocks like software packages and artwork to create a Solution.

  Example solutions include: Fedora Workstation, KDE Plasma, and the Python Classroom Lab.

  Teams define criteria for services they provide to solution-builders.

  For example, teams providing press and promotional support may choose to provide additional support to Solutions with larger user bases.

@@ -2,66 +2,81 @@ 

  

  = How to run the Fedora Annual Contributor Survey 

  

- ### Survey Schedule

- 

- * **Apr 1st** Open link:{team_issue_tracker}/new_issue[{team_name} ticket] to track progress and collect feedback

- * **Apr 1st** Open https://pagure.io/fedora-badges/new_issue[Badges ticket] to request badge design & publication

- * **April 1st** Open https://pagure.io/design/new_issue[Design ticket] to request banner design

- * **May 1st** Open https://docs.fedoraproject.org/en-US/websites/[Websites and Apps Team ticket] to request banner published on Fedora sites

- * **May 15-24th** Update LimeSurvey data according to the changes in the Survey Questions accumulated over the last year.

- * **May 24-31st** Review of actual survey in LimeSurvey. Approval from xref:fca.adoc[FCA] is necessary at this step.

- * **June 1st** Publish link:{COMMBLOG}/[Community Blog] Post promoting survey

- * **June 1st-30th** Survey runs

- ** **June 1st** Announce survey is open for month of June on IRC and Twitter

- ** **June 15th** Two week reminder to fill out survey on IRC and Twitter

- ** **June 30th** One day reminder to fill out survey on IRC and Twitter

- * **July 1st-31st** First round of survey analysis

- * **First weekend in August** Flock to Fedora/Nest with Fedora presentation

- * **By end of August** Publish link:{COMMBLOG}/writing-community-blog-article/[Community Blog] Post with results, analysis, and overview of presence at Flock/Nest.

- 

- ### Promotion

- 

- #### Fedora Badges

- 

- Each year we generate a https://badges.fedoraproject.org/[Fedora Badge] that survey recipients can claim

- when they submit their survey responses. A ticket needs to be opened

- on the https://pagure.io/fedora-badges/issues[Badges repo] requesting the badge. The panda graphic stays the

- same, and the year is updated accordingly. **This ticket should be

- opened by April 1st** in order to give the Badges team enough time to

- generate the artwork, push the badge to the website, and provide a

- claim link to the Survey team.

- 

- ##### Past Badges

+ [[schedule]]

+ == Survey Schedule

+ 

+ * **Apr 1st**:

+   Open link:{team_issue_tracker}/new_issue[{team_name} ticket] to track progress and collect feedback

+ * **Apr 1st**:

+   Open https://pagure.io/fedora-badges/new_issue[Badges ticket] to request badge design & publication

+ * **April 1st**:

+   Open https://pagure.io/design/new_issue[Design ticket] to request banner design

+ * **May 1st**:

+   Open https://docs.fedoraproject.org/en-US/websites/[Websites and Apps Team ticket] to request banner published on Fedora sites

+ * **May 15-24th**:

+   Update LimeSurvey data according to the changes in the Survey Questions accumulated over the last year.

+ * **May 24-31st**:

+   Review of actual survey in LimeSurvey. Approval from xref:fca.adoc[FCA] is necessary at this step.

+ * **June 1st**:

+   Publish link:{COMMBLOG}[Community Blog] Post promoting survey

+ * **June 1st-30th**:

+   Survey runs

+ ** **June 1st**:

+    Announce survey is open for month of June on IRC and Twitter

+ ** **June 15th**:

+    Two week reminder to fill out survey on IRC and Twitter

+ ** **June 30th**:

+    One day reminder to fill out survey on IRC and Twitter

+ * **July 1st-31st**:

+   First round of survey analysis

+ * **First weekend in August**:

+   Flock to Fedora/Nest with Fedora presentation

+ * **By end of August**:

+   Publish link:{COMMBLOG}/writing-community-blog-article/[Community Blog].

+   Post with results, analysis, and overview of presence at Flock/Nest.

+ 

+ [[promotion]]

+ == Promotion

+ 

+ [[promotion-badges]]

+ === Fedora Badges

+ 

+ Each year we generate a https://badges.fedoraproject.org/[Fedora Badge] that survey recipients can claim when they submit their survey responses.

+ A ticket needs to be opened on the https://pagure.io/fedora-badges/issues[Badges repo] requesting the badge.

+ The panda graphic stays the same, and the year is updated accordingly.

+ *This ticket should be opened by April 1st* in order to give the Badges team enough time to generate the artwork, push the badge to the website, and provide a claim link to the Survey team.

+ 

+ [[promotion-badges-past]]

+ ==== Past Badges

+ 

  * 2021

  ** https://badges.fedoraproject.org/badge/community-survey-taker-i[Badge]

  ** https://pagure.io/fedora-badges/issue/800[Ticket]

  

- #### Community Blog Post

+ [[promotion--community-blog]]

+ === Community Blog Post

  

- Each year we need to write at least two blog posts for the survey. The

- first one is to promote taking the survey, the second features the

- released dataset and any findings. These are published on the

- link:{COMMBLOG}/[CommBlog], make sure to follow link:{COMMBLOG}/writing-community-blog-article/[the guidelines]. The promotional blog post should then be pinned on

- Discussion.fpo for the month the survey is open.

+ Each year we need to write at least two blog posts for the survey.

+ The first one is to promote taking the survey, the second features the released dataset and any findings.

+ These are published on the link:{COMMBLOG}[CommBlog], make sure to follow link:{COMMBLOG}/writing-community-blog-article/[the guidelines].

+ The promotional blog post should then be pinned on Discussion.fpo for the month the survey is open.

  

  * 2021

  ** link:{COMMBLOG}/help-make-fedora-awesome-by-taking-the-first-annual-contributor-survey/[Survey Promotion]

  ** link:{COMMBLOG}/fedora-contributor-annual-survey-data-set-available/[Dataset]

  

- #### Fedora Websites Banner

+ [[promotion--websites-banner]]

+ === Fedora Websites Banner

  

- To help ensure we reach the maximum number of Fedora contributors, we

- promote the survey across as many Fedora spaces as possible including

- our websites. This work is done with the assistance of the link:{FWIKI}/Design[Design Team]

- and the https://docs.fedoraproject.org/en-US/websites/[Websites and Apps Team].

+ To help ensure we reach the maximum number of Fedora contributors, we promote the survey across as many Fedora spaces as possible including our websites.

+ This work is done with the assistance of the link:{FWIKI}/Design[Design Team] and the xref:websites::index.adoc[Websites & Apps Team].

  

- The first step is to open a ticket on the https://pagure.io/design/issues[Design Team pagure] to get

- any updates on artwork. **This ticket should be opened by April 1st,

- and closed by May 1st.** If there are no changes from the Design Team,

- proceed with the previous design. Once the artwork is finalized, a

- ticket is opened on the https://pagure.io/fedora-websites/issues[Websites & Apps Team] repo to get it

- published. **This ticket should be opened by May 1st** and needs

- continuous check-ins. The websites that we aim to cover are:

+ The first step is to open a ticket on the https://pagure.io/design/issues[Design Team pagure] to get any updates on artwork.

+ *This ticket should be opened by April 1st, and closed by May 1st.*

+ If there are no changes from the Design Team, proceed with the previous design.

+ Once the artwork is finalized, a ticket is opened on the https://pagure.io/fedora-websites/issues[Websites & Apps Team] repo to get it published.

+ *This ticket should be opened by May 1st* and needs continuous check-ins.

+ The websites that we aim to cover are:

  

  * https://lists.fedorahosted.org/archives/list/hyperkitty-devel@lists.fedorahosted.org/[Hyperkitty]

  * https://docs.fedoraproject.org/en-US/docs/[Docs.fpo]
@@ -69,40 +84,37 @@ 

  * link:{FWIKI}/Fedora_Project_Wiki[Fedora Wiki]

  * https://start.fedoraproject.org/[Start.fpo]

  

- #### Mailing Lists

+ [[promotion--mailing-lists]]

+ === Mailing Lists

  

- A lot of folks are on multiple mailing lists so it is important to

- choose high level "announce" channels over team channels. A short

- email should be sent with a link to the Community Blog post as well as

- a link directly to the survey.

+ A lot of folks are on multiple mailing lists so it is important to choose high level "announce" channels over team channels.

+ A short email should be sent with a link to the Community Blog post as well as a link directly to the survey.

  

  * https://lists.fedoraproject.org/admin/lists/mindshare@lists.fedoraproject.org/[Mindshare]

  * https://lists.fedoraproject.org/admin/lists/devel-announce.lists.fedoraproject.org/[Devel-announce]

  * https://lists.fedoraproject.org/admin/lists/diversity.lists.fedoraproject.org/[DEI] 

  

- #### IRC & Twitter

+ [[promotion--irc-twitter]]

+ === IRC & Twitter

  

- For increased visibility we also promote the survey on IRC and

- Twitter. This should be done sparingly as their is a potential for it

- to feel spammy. It could potentially go to other social media

- platforms but the main audience for that platform should be

- contributors not users. Don't forget to remind people they can earn a

- badge!

+ For increased visibility we also promote the survey on IRC and Twitter.

+ This should be done sparingly as their is a potential for it to feel spammy.

+ It could potentially go to other social media platforms but the main audience for that platform should be contributors not users.

+ Don't forget to remind people they can earn a badge!

  

  * IRC & Twitter

  ** (June 1st) Announce survey is open for month of June

  ** (June 15th) Two week reminder to fill out survey

  ** (June 30th) One day reminder to fill out survey

  

- ## Storage and process to make changes

+ [[changes]]

+ == Storage and process to make changes

  

  * Take markdown file in {team_name} repo

  ** PR's reviewed and accepted to markdown file through out the year

- ** git diff to locate the differences and make changes directly in the

-    LimeSurvey UI two weeks prior to running survey

+ ** git diff to locate the differences and make changes directly in the LimeSurvey UI two weeks prior to running survey

  * Take the lss-file of the previous survey

  * Upload lss-file to LimeSurvey under you personal account

  * Add all changes from the Markdown file as accumulated over the year using Lime Survey interface

  * Export lss-file and submit it as an update to this repository

  * Share the update lss-file with LimeSurvey Wrangler so that new Survey is created under Fedora account.

- 

@@ -2,9 +2,12 @@ 

  

  = Fedora Annual Contributor Survey Overview

  

+ 

+ [[goals]]

  == Goals

  

- In 2021 the {team_name} ran the first Fedora Annual Contributor Survey. We intend to improve and iterate year over year to help achieve the following goals:

+ In 2021, the {team_name} ran the first Fedora Annual Contributor Survey.

+ We intend to improve and iterate year over year to help achieve the following goals:

  

  - To gain an understanding of the usage patterns in various Fedora flavours and tooling

  - To analyze trends based on particular tools, preferred media platforms, or role
@@ -12,10 +15,15 @@ 

  - To analyze the accessibility of documentation, engagement, and resources

  - To gain insight on awareness and visibility of teams and activities happening across Fedora

  

+ 

+ [[audience]]

  == Audience

  

- The audience for this survey is Fedora contributors. This is inclusive of every Fedora contributor, whatever the scope of interest or activity. 

+ The audience for this survey is Fedora contributors.

+ This is inclusive of every Fedora contributor, whatever the scope of interest or activity.

  

+ 

+ [[what-we-do]]

  == What are we doing with the results?

  

  - Publish open, anonymous datasets for contributors to analyze.
@@ -23,6 +31,8 @@ 

  - Review and analysis by the {team_name}.

  - Review and analysis by the Mindshare Committee.

  

+ 

+ [[maintenance]]

  == Survey maintenance

  

  Maintenance for a survey includes continuous activities, which can be performed anytime through the entire year.
@@ -30,18 +40,23 @@ 

  - Analysis of the data

  - Edits/changes/additions requests to the content of the survey 

  

+ 

+ [[access]]

  == Who has access to the LimeSurvey account? 

  

- The Fedora Action and Impact Coordinator and the LimeSurvey Wrangler,

- currently Vipul Siddharth. Access to this account is limited due to

- data sensitivity.

+ The xref:fca.adoc[Fedora Community Architect] and the LimeSurvey Wrangler, currently Vipul Siddharth.

+ Access to this account is limited due to data sensitivity.

+ 

  

+ [[get-involved]]

  == How do I get involved?

  

  - Suggest new questions or edits to current questions with a {team_name} ticket.

  - Analyze data and publish results to the Community Blog and make sure to let the {team_name} know.

- - Provide feedback and share ideas about the survey with the {team_name} via link:{team_asynch_communication}[Discussion site] and use the tag #council

+ - Provide feedback and share ideas about the survey with the {team_name} via link:{team_asynch_communication}[#council tag on Fedora Discussion].

+ 

  

- == Past Survey CSVs

+ [[data]]

+ == Past survey data

  

  - link:{FWIKI}/Fedora_Annual_Contributor_Survey_2021[Contributor Survey 2021 Responses CSV]

@@ -2,30 +2,26 @@ 

  

  = Fedora Contributor Annual Survey

  

- ## Intro

+ [[intro]]

+ == Intro

  

  Hello and thank you for taking the Fedora Annual Contributor Survey!

- We hope to use the data from this survey to understand the usage,

- engagement, and development patterns to further enrich our

- community. We will be sharing our findings at Nest <Year>.

+ We hope to use the data from this survey to understand the usage, engagement, and development patterns to further enrich our community.

+ We will be sharing our findings at Nest <Year>.

  

- This survey is targeted to Fedora Contributors and Community

- Members. Fedora contributors and community members are those that

- participate in the project in any way, be it coding, bug testing,

- docs, graphic design, translations, outreach, etc.

+ This survey is targeted to Fedora Contributors and Community Members.

+ Fedora contributors and community members are those that participate in the project in any way, be it coding, bug testing, docs, graphic design, translations, outreach, etc.

  

- This survey is being ran by the {team_name} to better understand

- our Fedora Contributors and Community Members, and to better steward

- the Fedora Project based on data.

+ This survey is being ran by the {team_name} to better understand our Fedora Contributors and Community Members, and to better steward the Fedora Project based on data.

  

  Who gets to see the raw data::

- {team_name} members and survey moderator (vsiddhar@redhat.com)

+ {team_name} members and LimeSurvey moderator.

      

  Who gets to see the summary data::

- Public

+ Public.

  

  How to contact someone about issues with the survey::

- Send an email to vsiddhar@redhat.com

+ Send an email to fca@fedoraproject.org.

  

  Survey open and close dates::

  <June 1st - 30th>
@@ -36,388 +32,405 @@ 

  * 2023: Add Developer role, removed Ask and Twitter, added a question on membership in leadership teams.

  * 2022: Added more variants for many answers based on previous survey answers.

  

+ [[intro-notes]]

+ === Notes

  

- ### Notes

+ * Alphabetize answers, leaving "Other" and "I don't know" at the end.

+ * [M] for multi-choice and [S] for single choice questions

+ * For questions with "Other" answer, we would like to have a text field where one can write their own answer.

  

- - Alphabetize answers, leaving "Other" and "I don't know" at the end.

- - [M] for multi-choice and [S] for single choice questions

- - For questions with "Other" answer, we would like to have a text field where one can write their own answer.

  

- ## Questions

+ [[questions]]

+ == Questions

  

- ### About you

+ [[questions--about-you]]

+ === About you

  

  * What are your current role(s) in Fedora Project? [M]

-     - Developer

-     - Design

-     - DEI Team

-     - Documentation

-     - Infrastructure

-     - Localization

-     - Outreach (Ambassadors, Join, Advocates)

-     - Package Maintainer

-     - Quality Assurance/Testing

-     - Support

-     - User

-     - Other 

+ ** Developer

+ ** Design

+ ** DEI Team

+ ** Documentation

+ ** Infrastructure

+ ** Localization

+ ** Outreach (Ambassadors, Join, Advocates)

+ ** Package Maintainer

+ ** Quality Assurance/Testing

+ ** Support

+ ** User

+ ** Other

  

  * What do you use Fedora for? [M]

-     - Data analysis

-     - Development

-     - Gaming 

-     - Generic desktop

-     - Graphics/photo/video/design

-     - Media playing

-     - Office tasks

-     - Operations (SysAdmin, DevOps) tasks

-     - Other

+ ** Data analysis

+ ** Development

+ ** Gaming

+ ** Generic desktop

+ ** Graphics/photo/video/design

+ ** Media playing

+ ** Office tasks

+ ** Operations (SysAdmin, DevOps) tasks

+ ** Other

  

  * On a scale of 1-5 how familiar are you with Linux-based operating systems? [S]

-     - Rate from 1(new to Linux) to 5(power user)

+ ** Rate from 1 (new to Linux) to 5 (power user)

  

  * Which social networks do you regularly use? [M]

-     - Diaspora

-     - Facebook

-     - Instagram

-     - LinkedIn

-     - Fediverse (Mastodon and other ActivityPub-compatible services)

-     - Twitter

-     - Reddit

-     - I don't use social networks

-     - Other 

+ ** Diaspora

+ ** Facebook

+ ** Instagram

+ ** LinkedIn

+ ** Fediverse (Mastodon and other ActivityPub-compatible services)

+ ** Twitter

+ ** Reddit

+ ** I don't use social networks

+ ** Other

  

  * Which messaging services do you regularly use? [M]

-     - Discord

-     - Google Hangouts/Chat

-     - IRC

-     - Jabber

-     - Matrix/Element

-     - Signal

-     - Slack

-     - Telegram

-     - WhatsApp

-     - I don't use messaging

-     - Other

+ ** Discord

+ ** Google Hangouts/Chat

+ ** IRC

+ ** Jabber

+ ** Matrix/Element

+ ** Signal

+ ** Slack

+ ** Telegram

+ ** WhatsApp

+ ** I don't use messaging

+ ** Other

  

  * Which Fedora communication channels do you follow? [M]

-     - Fedora Community Blog

-     - Fedora Magazine

-     - Fedora News on Telegram

-     - Fedora Planet

-     - Fedora on Facebook

-     - devel-announce@ and other *-announce mailing lists

-     - devel@ mailing list

-     - Fedora at Fosstodon.org (ActivityPub)

-     - discussion.fedoraproject.org

-     - r/fedora on Reddit

-     - I don't follow Fedora news

-     - Other

- 

- * How comfortable do you feel speaking up about your ideas/opinions/theories or asking questions in Fedora spaces?(chat platforms, pagure, discussion)

-     - Completely comfortable

-     - Somewhat comfortable

-     - Neutral

-     - Uncomfortable

-     - Varies depending on space

-     - Other

+ ** Fedora Community Blog

+ ** Fedora Magazine

+ ** Fedora News on Telegram

+ ** Fedora Planet

+ ** Fedora on Facebook

+ ** `devel-announce@` and other `*-announce` mailing lists

+ ** devel@ mailing list

+ ** Fedora at Fosstodon.org (ActivityPub)

+ ** discussion.fedoraproject.org

+ ** r/fedora on Reddit

+ ** I don't follow Fedora news

+ ** Other

+ 

+ * How comfortable do you feel speaking up about your ideas/opinions/theories or asking questions in Fedora spaces? (chat platforms, pagure, discussion)

+ ** Completely comfortable

+ ** Somewhat comfortable

+ ** Neutral

+ ** Uncomfortable

+ ** Varies depending on space

+ ** Other

  

  * Is English your first language?

-     - Yes

-     - No

+ ** Yes

+ ** No

  

- ### Generic

+ [[questions-generic]]

+ === Generic

  

  * Which Fedora Editions do you use? [M]

-     - Cloud

-     - CoreOS

-     - IoT

-     - Labs

-     - Minimal or custom

-     - Server

-     - Silverblue (GNOME, rpm-ostree)

-     - Kinoite (KDE, rpm-ostree)

-     - Onyx (Budgie, rpm-ostree)

-     - Spins

-     - Workstation (GNOME, default)

-     - Other

+ ** Cloud

+ ** CoreOS

+ ** IoT

+ ** Labs

+ ** Minimal or custom

+ ** Server

+ ** Silverblue (GNOME, rpm-ostree)

+ ** Kinoite (KDE, rpm-ostree)

+ ** Onyx (Budgie, rpm-ostree)

+ ** Spins

+ ** Workstation (GNOME, default)

+ ** Other

  

  * Which architectures do you use? [M]

-     - aarch64