Comunicación PgM

La comunicación es la parte más importantes del trabajo de un administrador de programa. Hay pocas comunicaciones requeridas para el Administrador de Programa de Fedora, pero su éxito dependerá de la comunicación de la información a la comunidad.

This section describes what Ben Cotton did. Feel free to modify and adapt it to fit your style.

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

Friday’s Fedora Facts

This is a weekly report in the Fedora Community Blog. It is published on Friday afternoons and contains a summary of the previous week’s activities and upcoming events. The readership numbers, as reported by WordPress, are not overwhelming, but everyone I talk to about it expresses appreciation. When you’re doing your job right as a program manager, you don’t get much feedback.

I keep the content up-to-date during the week by editing the fridays_fedora_facts.md file in the pgm_communication repository. You can use pandoc to convert this to HTML to paste directly into the WordPress console.

The sections to include are:

  • Announcements — Important announcements, including package retirements, conference calls for papers (see below), policy proposals and changes, etc. For items with a defined deadline, I generally leave the announcement in there until the deadline has passed. For items without a defined deadline, I leave them for 1–4 weeks, depending on the relevance and impact.

  • Help wanted — Requests for help from teams within Fedora. These generally come from observing the meeting minutes and mailing lists of teams within Fedora. I generally leave them for a few weeks.

  • 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

I conduct weekly office hours in IRC. It is almost always unattended, but it’s a good opportunity to be visible and if someone shows up, great. I keep the content in the file office_hours.md in the pgm_communication repository.

The meeting consists of two sections:

  • Announcements — Some of the content from the weekly report. I include upcoming deadlines (with #info) and requests for help (with #help).

  • Open floor — Leaving the meeting open to see if someone else shows up and wants to talk about stuff.

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 ›