Communicating is the most important part of a program manager’s job. There are few required communications for the Fedora Program Manager, but your success will depend in part on communicating information out to the community.
This section describes what Ben Cotton does. Feel free to modify and adapt it to fit your style.
Unless otherwise indicated, the communications in this section are stored in the pgm_communication repository.
This is a weekly report in the Program Management category for 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
report.md file in the
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 and Release Readiness 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.
There’s no one, unified place to get relevant CfPs, Pay attention to social media (particularly upstream accounts), etc. You can also use:
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
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
Open floor — Leaving the meeting open to see if someone else shows up and wants to talk about stuff.
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
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:
Go through each of the bugs in the Blocker Bugs list
Review the content of the bug and summarize the current state, including upstream bug URLs, package updates that require testing, etc.
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.
Add the bug owner to the bcc list if they have an action item. Also include anyone marked as needinfo.
Include an action summary at the top.
Send the email to the devel and test mailing lists, and bcc the people you identified above.