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.
Esta sección describe lo que hace Ben Cotton. Sea libre de modificarlo y adaptarlo para que coincida con su propio estilo.
A no ser que se indique otra cosa, las comunicaciones de esta sección se almacenan en el repositorio pgm_communication.
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
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, 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.
CPE update — A report of status from the Community Platform Engineering team. This is provided by the team.
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 cc 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 cc the people you identified above.