Directorio de Equipos de Fedora

Para proporcionar visibilidad a qué equipos existen y están activos en Fedora, el Consejo decidio mantener un directorio que recibe comprobaciones regulares. Los representantes del Consejo son los responsables de una evaluación periódica de los equipos de su área (I+D, Ingeniería y Conocimiento de Marca). "Equipos" debe leerse como un término general para los grupos en Fedora que pueden llamarse "Grupos de Interés Especial (SIGs)", "Grupos de Trabajo" o cualquier otro término similar.

Intent

The team directory is intended to make visible: 1. what teams are active in the community, and 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 don’t 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.

Responsibilites

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

The Diversity & Inclusion, Engineering, and Mindshare representatives to the Fedora Council are responsible for ensuring that the team that fall under their area keep the information is up-to-date and removing 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 {team_name}, {team_summary} etc. anywhere on the page.

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