Charte du Conseil Fedora

council logo 500px

Le Conseil Fedora est notre organe de direction et de gouvernance communautaire de haut niveau. Il est responsable de la gestion du projet Fedora dans son ensemble et soutient la santé et la croissance de la communauté de Fedora.

Le Conseil est composé d’un mélange de représentants de différents domaines du projet, de rôles nommés par Red Hat, et d’un nombre variable de sièges liés aux objectifs à moyen terme du projet. Les décisions sont prises par un processus de consensus, dans lequel nous travaillons ensemble comme une équipe commune pour trouver des solutions partagées et répondre aux préoccupations, en mettant l’accent sur le fait de donner une voix plutôt que sur l’équilibre des pouvoirs.

Le Conseil est responsable en dernier ressort de l’ensemble du projet Fedora, et est chargé de conseiller et de superviser les autres organes et équipes de gouvernance de Fedora selon les besoins.

Responsabilités

Le Conseil est responsable des questions d’importance stratégique pour Fedora qui nécessitent un leadeurship et une coordination entre les différentes équipes et sous-projets pour être réalisées.

Son rôle principal est d’identifier les objectifs à court, moyen et long terme de la communauté Fedora, d’organiser et de permettre au projet de les atteindre au mieux. Faisant cela en consultation avec l’ensemble de la communauté Fedora par le biais d’un débat public transparent.

Le Conseil gère les ressources financières de Fedora, en travaillant avec notre ou nos sponsors pour établir un budget annuel alloué pour soutenir les initiatives de Fedora, y compris les ambassadeurs de Fedora, les évènements gérés par Fedora, et d’autres activités qui font avancer les objectifs du projet.

Le Conseil décide également des questions relatives à l’utilisation des marques commerciales de Fedora, est responsable de l’arbitrage final des plaintes liées aux politiques du projet et du règlement des différends provenant d’autres comités ou sous-groupes, et peut traiter des questions juridiques ou personnelles sensibles qui nécessitent des recherches et des discussions pour protéger les intérêts du projet Fedora ou de son ou ses sponsors.

Prise de décisions

La prise de décision par consensus a pour but d’être :

  • Une recherche d’accord : un processus de décision par consensus tente d’aider chacun à obtenir ce dont il a besoin.

  • Collaboratif : les participants contribuent à une proposition commune et la façonnent en une décision qui répond autant que possible aux préoccupations de tous les membres du groupe.

  • Coopératif : les participants à un processus de consensus efficace doivent s’efforcer de parvenir à la meilleure décision possible pour le groupe et tous ses membres, plutôt que de se faire concurrence pour des préférences personnelles.

  • Égalitaire : tous les membres d’un organe décisionnel de consensus devraient, dans la mesure du possible, avoir une participation égale au processus. Tous les membres ont la possibilité de présenter et d’amender des propositions.

  • Inclusif : le plus grand nombre possible de parties prenantes doit être impliqué dans le processus de décision par consensus.

  • Participatif : le processus de consensus devrait activement solliciter la contribution et la participation de tous les décideurs

De nombreuses décisions de base sont prises par le biais d’un processus appelé « approbation paresseuse », dans lequel le consentement général est présumé sauf si des objections valables sont soulevées dans un certain délai — généralement de trois à sept jours, bien que le délai doive être indiqué à chaque fois et soit proportionnel à l’impact de l’action. Ce processus est utilisé pour les décisions ayant des conséquences à court terme et qui peuvent être facilement annulées. Tout membre du projet peut demander que le délai soit prolongé ou que la décision soit portée à un niveau supérieur pour exiger un consensus complet.

Les décisions les plus importantes sont prises par un processus de plein consensus. Pour être adoptées, ces décisions doivent recueillir trois votes positifs (+3) et aucun vote négatif (-1). Un vote négatif interrompt immédiatement le processus et nécessite une discussion. Par conséquent, pour rester valables, les votes négatifs doivent être accompagnés de préoccupations spécifiques concernant la proposition et de suggestions sur ce qui pourrait être modifié pour rendre la proposition acceptable. Un vote de « 0 » est parfois utilisé pour indiquer un désaccord avec une volonté de s’écarter de la discussion ; il doit être accompagné d’une explication.

Ce modèle correspond à la fondation « Friends » de Fedora, qui appelle à trouver un consensus acceptable pour servir les intérêts de la promotion du logiciel libre. Il fonctionne parce que nous travaillons ensemble dans une communauté de respect mutuel, même lorsque nous ne sommes pas d’accord.

En général, le Conseil mène ses activités dans le cadre de débats publics, et tout membre du projet Fedora peut émettre un vote négatif ou positif. Il est du devoir du Conseil de prendre sérieusement en considération les préoccupations soulevées de cette manière, mais seuls les votes des membres du Conseil sont contraignants dans le décompte final.

Lorsqu’un consensus ne peut être atteint, le Conseil peut demander au chef du projet Fedora de décider d’une résolution. Une telle demande peut être faite lorsque des questions conduisant à des votes négatifs sont en suspens et que tous les membres du Conseil conviennent que le Conseil est dans l’impasse, ou si le litige n’est pas résolu après quatorze jours et qu’une majorité simple des membres du Conseil est en faveur de la demande.

Composition

Objectifs principaux

On an ongoing basis, including sessions at Flock and in public online meetings, the Council will identify two to four key community objectives with a timeframe of approximately eighteen months, and appoint Objective Leads for each goal. These will serve as auxiliary Council members, with binding votes only over concerns relevant to their particular area.

Each objective will be documented with measurable goals, and the objective 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.

Representatives

The Council also includes four representative seats, an Engineering Representative, an Mindshare Representative, and two Elected 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 the people active in those areas, coordinated by the Fedora Engineering Steering Committee (FESCo) and a to-be-created mindshare group respectively, and serve for terms to be determined by those committees.

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 Council 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 Council seat can be elected. If a seat becomes vacant, the Council will arrange for a temporary replacement.

Appointed Leadership Positions

Fedora Project Leader

The Fedora Project Leader serves as the chair of the Council, 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 Council.

Fedora Community Action and Impact Coordinator

The Fedora Community Action and Impact Coordinator (FCAIC) initiatives 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.

Auxiliary Seats

As with the objective leads, the next two appointed positions are auxiliary seats. They are intended to have significant positive impact on the project as a whole, but in order to minimize the overall influence of appointed positions vs. those selected by the community, their votes in the consensus process are expected to be related to the scope of the respective role.

Diversity Team Representative

The Fedora Diversity Team works on initiatives to assess and promote equality and inclusion within the Fedora contributor and user communities, and helps develop project strategy on diversity issues. The Diversity Team Representative connects the team’s efforts to the Council.

This position is appointed by members of the Fedora Diversity Team, with the approval of the Council.

Fedora Program Manager

The 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 Fedora Council Meetings.

This position is funded by and hired for by Red Hat, with the approval of the Council.

Coda

Meetings

The Fedora Council is not driven by meetings or by tickets, but does hold regular public IRC meetings to discuss current issues, to clear through anything outstanding which can be quickly resolved, and to ensure that nothing important is left in limbo. All members are be expected to regularly communicate what’s going on in their area, through blog posts or other public updates.

Additionally, the Fedora Project Leader will set aside regular times on IRC to meet with the community. Attendance is not mandatory for all members but is encouraged.

Transparency

The general policy of the Fedora Council is to default to open. Meetings are held in public IRC channels, and open to all Fedora users and contributors. Discussion is held in on a public mailing list open to all subscribers, and formal decisions will be recorded in a public ticket tracking system.

Occasionally, when personal, private, or sensitive issues need to be discussed, a phone 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.

Time Commitment

Serving on the Fedora Council 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 Council 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 Council 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 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.

Record of Former Members

Former membership on the Fedora Council, along with membership on the previous Fedora Board, is documented on the History of Council Membership page.

Document History

This charter was approved by the Fedora Project Board on 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 git repository for Council documents.

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

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

2017-04-05: Switched “Outreach” to Mindshare. (ticket)

2014-11-26: Initital approval by the Fedora Project Board (ticket)