245 lines
18 KiB
Text
245 lines
18 KiB
Text
include::ROOT:partial$attributes.adoc[]
|
||
|
||
= {team_name} Charter
|
||
|
||
image::council-logo.png[The Fedora Council logo features a stylized "f" in white within a light blue circle, followed by the word "COUNCIL" in dark blue, set against a gray background. This is the logo for the Fedora Council, the governing body of the Fedora Project.]
|
||
|
||
{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 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]]
|
||
== Responsibilities
|
||
|
||
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.
|
||
*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.
|
||
|
||
{team_name} members engage with people across the community to make sure Fedora is functioning smoothly and that teams are empowered to do interesting and meaningful things.
|
||
They decide on issues regarding use of the Fedora *trademarks*, are responsible for final *arbitration of complaints* related to project policies and for *settling disputes* escalated from other committees or subgroups.
|
||
They may handle *sensitive legal or personnel issues* which require research and discussion to protect the interests of the Fedora Project or its sponsors.
|
||
|
||
To support project efforts with more ambitious scope, the {team_name} sponsors xref:project::initiatives.adoc[Community Initiatives] proposed by the community.
|
||
{team_name} members serve as xref:project::initiatives.adoc#proposing-sponsors[Executive Sponsors] for these Initiatives, working personally to ensure that the <<composition\--initiative-leads,Leads>> have everything they need to succeed.
|
||
|
||
The {team_name} *governs Fedora’s financial resources*, working with our sponsor to establish an annual budget allocated to support these Initiatives, various Fedora teams and programs, Fedora-managed events, and other activities which advance the Fedora Strategy.
|
||
|
||
The {team_name} is also responsible for developing, tracking, and updating the Fedora Strategy.
|
||
|
||
|
||
[[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.
|
||
|
||
— 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 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.
|
||
Each xref:project::initiatives.adoc[Community Initiative] is represented by one {team_name} seat.
|
||
Typically, this seat is filled by the Lead of the Initiative, although it is possible for two people (at most) to share a single {team_name} seat as Co-Leads.
|
||
While naturally the people in these roles will focus primarily on their own Initiative, this is a full {team_name} position and Community Initiative Leads are invited to participate in all {team_name} activities and decisions.
|
||
|
||
[NOTE]
|
||
====
|
||
This policy may be surprising, but we have found that this wider engagement connects the specific work to everything going on in Fedora, leading to greater success for the Initiative.
|
||
Community Initiative Leads may even serve as Executive Sponsors for other Initiatives.
|
||
====
|
||
|
||
Community Initiative Leads typically serve on the {team_name} for the duration of their Initiative.
|
||
When the Initiative concludes, the {team_name} term also expires.
|
||
|
||
Each Community Initiative Lead is paired with an xref:project::initiatives.adoc#proposing-sponsors[Executive Sponsor], who is another member of the {team_name}.
|
||
|
||
Community Initiatives must be documented with measurable goals.
|
||
The Community Initiative Leads are 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.
|
||
xref:project::initiatives.adoc#proposing-sponsors[Executive Sponsors] are responsible for making sure the Initiative is on track and for removing blockers.
|
||
|
||
|
||
[[composition-representatives]]
|
||
=== 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.
|
||
|
||
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 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.
|
||
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 they bring to the {team_name} as highlighted during the election process.
|
||
|
||
Elections are held once per year, in concert with the joint Fedora election cycle.
|
||
Two seats are selected at the even-numbered release election, e.g F40, F42, etc, and each position has a two-election (approximately one year) term. This change came into effect from the F40 election, following a council vote on [https://pagure.io/Fedora-Council/tickets/issue/470 this ticket] at the 2024 council hackfest.
|
||
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
|
||
|
||
[[composition-appointed-fpl]]
|
||
==== Fedora Project Leader (FPL)
|
||
|
||
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}.
|
||
|
||
[[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.
|
||
|
||
[[composition-appointed-foa]]
|
||
==== Fedora Operations Architect
|
||
|
||
The xref:foa.adoc[Fedora Operations Architect] (FOA) is employed full-time by Red Hat to assist the community in managing technical changes.
|
||
This includes oversight of the Change process, schedule management, communications, and ownership of key strategic efforts.
|
||
They also assist with the creation, improvement, maintenance, and execution of formal, repeatable Fedora processes.
|
||
Additionally, the Fedora Operations Architect serves as record-keeper and secretary for Fedora Council Meetings.
|
||
|
||
|
||
[[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).
|
||
The {team_name} discusses current issues, clear through anything outstanding which can be quickly resolved, and to ensure that nothing urgent is left pending.
|
||
All members are expected to regularly communicate what is going on in their area, through blog posts or other public updates.
|
||
|
||
The {team_name} holds a multi-day, face-to-face meeting annually.
|
||
All members should strive to attend in person (travel funding is available).
|
||
We also often meet for a day before or after other significant Fedora-related conferences (Flock, DevConf.cz).
|
||
These meetings are not public, but minutes and summary documents will be provided.
|
||
|
||
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.
|
||
Most meetings are held in public channels, and open to all Fedora users and contributors.
|
||
Discussion is held in a link:{team_asynch_communication}[public forum] open to all, and formal decisions will be recorded in a public ticket tracking system.
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
[[coda-governance]]
|
||
=== 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.
|
||
|
||
[[coda-historical]]
|
||
=== 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 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.
|
||
|
||
[[coda--former-members]]
|
||
=== Record of Former Members
|
||
|
||
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.
|
||
|
||
|
||
[[document-history]]
|
||
== 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 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*: 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_].
|