Comunicación de Arquitectura de Operaciones

La comunicación es la parte más importante del trabajo del Arquitecto de Operaciones de Fedora. Hay pocas comunicaciones obligatorias para el arquitecto de operaciones de Fedora, pero su logro dependerá en parte de la comunicación de información a la comunidad.

Esta sección describe lo que hace Ben Cotton. Siéntete libre de modificarlo y adaptarlo para que se ajuste a tu estilo.

A no ser que se indique otra cosa, las comunicaciones de esta sección se almacenan en el repositorio pgm_communication.

Datos sobre Fedora del viernes

Este es un informe semanal del Blog de la Comunidad de Fedora. Se publica los viernes por la tarde y contiene un resumen de las actividades de la semana anterior y los próximos eventos. Las cifras de lectores, según lo informado por WordPress, no son abrumadoras, pero todos con quienes hablo al respecto expresan su agradecimiento. Cuando uno hace bien su trabajo como administrador de programas, no recibe mucha retroalimentación.

Conservo el contenido actualizado durante la semana editando el archivo fridays_fedora_facts.md interno al repositorio pgm_communication. Puedes utilizar pandoc para convertir esto a HTML para pegarlo directamente a la consola de WordPress.

Las secciones a incluir son:

  • Anuncios — Anuncios importantes, como retirada de paquetes, convocatorias para artículos (consulte más abajo), propuestas y cambios de directivas, etc. Para los artículos con fecha límite, generalmente dejo el anuncio hasta que la fecha límite haya pasado. Para los artículos sin fecha límite, los dejo entre 1 y 4 semanas, dependiendo de su relevancia e impacto.

  • Se busca ayuda — Solicitudes de ayuda de los equipos de Fedora. Generalmente, estas solicitudes se obtienen consultando las actas de las reuniones y las listas de correo de los equipos de Fedora. Generalmente las dejo para unas semanas.

  • Upcoming meetings & test days — Project-level meetings that will occur within the next week. I generally include Council meetings, blocker review meetings, prioritized bugs meetings, and the FPgM office hours as regular entries. I also include the Go/No-Go meetings when appropriate. If the QA team has organized test days, I will include those as well.

  • Fedora N — Information about the current in-progress Fedora release (you may have N+1 as well).

    • Schedule — Upcoming schedule milestones, generally within the next month

    • Changes — Changes announced, submitted to FESCo, and approved/rejected by FESCo. These are normally removed the week following approval or rejection. I link to the wiki page and — while the proposal is pending with FESCo — a link to the FESCo ticket. If changes are withdrawn after being approved, I will keep the withdrawal in the report a length of time that seems reasonable to me at the time.

    • Blocker bugs — A table including the bug ID (with a link to Bugzilla), blocker status (proposed or accepted), component, and bug status. I include this once I begin producing the blocker bug report.

CfP sources

There’s no one, unified place to get relevant CfPs. Pay attention to social media (particularly upstream accounts), etc. You can also use:

FPgM office hours

This is no longer active, but if a need for it resurfaces, content can be found in the file office_hours.md in the pgm_communication repository.

Blocker report

The blocker bug process belongs to the QA team, but Ben Cotton adopted the weekly blocker review email to give Adam Williamson more time to test and diagnose bugs. The content of the email is in the blocker_email.txt file in the pgm_communication repository.

Begin sending the emails on the first Friday of the Beta freeze and continue until the final release is declared "Go". I generally ignore the final blockers until Beta is released.

To produce the report:

  1. Go through each of the bugs in the Blocker Bugs list

  2. Review the content of the bug and summarize the current state, including upstream bug URLs, package updates that require testing, etc.

  3. Note the action required for each bug. This may be QA verifying a fix, upstream fixing the bug, the package maintainer producing a new release, etc. If the bug has the needinfo flag set, include that.

  4. Add the bug owner to the bcc list if they have an action item. Also include anyone marked as needinfo.

  5. Include an action summary at the top.

  6. Send the email to the devel and test mailing lists, and bcc the people you identified above.

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