Fedora Team Directory

In order to provide visibility into what teams exist and are active in Fedora, the Fedora Council decided to maintain a directory that receives regular checks. Fedora Council representatives are responsible for periodic evaluation of the teams under their area (DEI, Engineering, and Mindshare). "Teams" should be read as a catch-all term for groups in Fedora that may call themselves "Special Interest Groups (SIGs)", "Working Groups (WGs)", or any other similar term.

Intent

The team directory is intended to make visible:

  1. What teams are active in the community.

  2. How to contact them.

Fedora is a large community with many different activities, and the directory will help existing and potential community members find the team they are looking for. Having periodic checks helps to ensure that the information is accurate and that we do not point people toward teams that are no longer active.

The intent is not to increase the administrative burden on teams or the barriers to starting a team. The intent is not to say "if you are not listed, you are not allowed to be a team in Fedora". However, presence in the directory may be used by other teams to evaluate funding or work requests (e.g. website work or design assets).

Content

Teams should list the following information in the format specified by the template:

  • Team name

  • Team summary

  • Team website

  • Team status (active or inactive)

  • Team’s preferred asynchronous communication channel (e.g. mailing list, forum category, etc)

  • Team’s preferred synchronous communication channel (e.g. IRC channel, Telegram room, etc)

  • Team’s issue tracker

  • Team’s meeting (preferably a link to a Fedocal event, alternatively a static day and time)

  • Additional information the team desires to publish in the directory

It is expected that not all teams will have answers for the above. They should be provided when they exist.

Content may be stored in the council-docs repo if the team does not have its own docs repo. If a team has its own docs repo, the content can be kept in that repo so that it can be used to render the team’s own documentation. This allows for a single source of truth and prevents content from diverging.

Responsibilities

Teams are responsible for ensuring their entries are up to date.

The DEI, Engineering, and Mindshare representatives to the Fedora Council are responsible for ensuring that the team that falls under their area keeps the information up-to-date and removes teams that do not appear to be active. They are not responsible for providing the information. Representatives may delegate sections of their area as they see fit. Checks can be done at any time, but should be done around the branch date for each release at a minimum.

Mechanism

Team information files

The directory requires a file that contains the information about the team. The suggested naming convention is NAME_team_info.adoc, but any valid file name is acceptable. The file may be stored in the team’s own documentation repository or in the council-docs repository. See the example template for format and structure.

Rendering the directory

Teams will appear in the directory if the team info file is included in the {engineering,mindshare}/modules/ROOT/pages/index.adoc directory of the council-docs repo. After include-ing the info file, the index page must include the team_render.adoc file that defines the rendering.

Reusing the data on team pages

Teams can include their NAME_team_info.adoc file on their page(s), and then use Fedora Council, The Fedora Council is our top-level community leadership and governance body. It is responsible for stewardship of the Fedora Project as a whole, and supports the health and growth of the Fedora community. etc. anywhere on the page.

Want to help? Learn how to contribute to Fedora Docs ›