Friday’s Fedora Facts SOP

This document describes the procedures for publishing the Friday’s Fedora Facts posts on the Fedora Community Blog.

Trigger/timing

Publish the post weekly on Friday (hence the name). For ease of maintenance, update the source file throughout the week.

Procedures

Write the update

  1. Collect announcements. This is an h2 level. Sources include:

  2. Collect calls for participation (CfPs). This is an h3 level. Sources are listed in the markdown file. Use your best judgment in determining what might be of broad interest to the Fedora community. CfPs should be a table sorted by the CfP close date, ordered from soonest to latest. The table has the following columns:

    • Conference. Includes the name and a link to the event website.

    • Location. Includes the city and country (use the 2-letter code). Add the state if it takes places in the United States. For online conferences, use "virtual" as the location. For hybrid conferences, use the city and "and virtual".

    • Date. List day(s) of month followed by the three-letter month abbreviation. Do not include the year.

    • CfP. Use "closes <date>" for CfPs with a defined close date. Use "open" for CfPs with an ambiguous or unstated close date. In that case, sort it based on a reasonable interpolation from event dates. In all cases, link directly to the CfP portal or a page specifically describing the conference’s CfP process.

  3. Add help wanted calls. This is an h2 level. Include the following:

    • A link to open package review requests, and specificially call out the count awaiting a reviewer and the count needing a sponsor.

    • A link to orphaned package or package retirement announcements from the devel-announce mailing list.

    • Community surveys if any are open.

    • Other calls for help that you notice on mailing lists, Discussion, or in chat.

  4. Add upcoming test days. This is an h3 level. Comment it out if there are no active test days. Add upcoming test days as an unordered list with the form "<date> — <subject>". Include a link to a CommBlog announcement or wiki page, if available. Sources include the QA calendar and the "test days" label in the fedora-qa repo.

  5. Add meetings and events. This is an h2 level. Include entries in the form "<meeting> — <time (UTC)> <day> in <location>". Link the date to a calendar event when practical. Link the location the venue when not in one of the regular #fedora-meeting-* channels. Keep the meetings at project-level interest. For example: blocker reviews, Council, Mindshare, FESCo, prioritized bugs, Flock.

  6. Add releases. This is an h2 level. Generally, the only thing in this level should be a table of open bugs. The open bugs table should list all supported and in-development releases (including Rawhide) with a count of open bugs.

  7. Add prioritized bugs. This is an h3 level. Include a link to the Prioritized Bugs process documentation. List the bugs in a table with the following columns:

    • Bug number (with a link to the bug in Bugzilla)

    • Component

    • Status

  8. Add release-specific information. For each release where one of the following has content, include an h3 of "Fedora Linux <N>".

    • Count open of Fails To Build From Source and Fails To Install bugs as an unordered list.

    • Upcoming schedule milestones. Only include important deadlines within the next 6–8 weeks. List them as an unordered list in the form "<date> — <Milestone/deadline>" under an h4 of "Schedule".

    • Changes. List active change proposals in a table. Remove proposals after publishing the FFF where they have reached a terminal state (approved, rejected, or withdrawn). Link to the change set page and the tracking bug so readers can find approved proposals. The table should have the following columns:

      • Proposal. This is the title of the proposal with a link to the wiki page.

      • Type. (System-Wide or Self-Contained)

      • Status. One of "announced" (include a link to the devel mailing list thread), "FESCo #<ticket number>" (include a link to the FESCo ticket), approved, rejected, or withdrawn.

    • Changes status. After the branch point, begin including a table of Change statuses. This is a table with the following columns:

      • Status. The Bugzilla status.

      • Count. The number of tracking bugs in that status.

    • Blockers. List all active blockers for the next release milestone, starting after branch day. (You can choose to include final blockers prior to the beta release, if you feel like doing the work.) List blockers in a table with the following columns:

      • Bug ID. The Bugzilla number with a link to the Bugzilla bug.

      • Component. The current component that the bug is filed against.

      • Bug status. The status from Bugzilla.

      • Blocker status. One of "Proposed(<milestone>)" or "Accepted(<milestone>)".

Publish the update

  1. Run make in the directory where the fridays_fedora_facts.md file lives. This will generate HTML that you can copy and paste into WordPress.

  2. Title the post "Friday’s Fedora Facts: <YYYY>-<WW>", where <YYYY> is the year and <WW> is the week of the year. The command date +%Y-%V will give you the correct date stamp.

  3. Copy the HTML and convert to blocks.

  4. Add a "More" element below the table of contents.

  5. Set the category to "Program Management".

  6. Add the following tags: "releases", "Fedora release changeset", "Friday’s Fedora Facts". In addition, use "Call for Papers (CfP)", "Help wanted", "Test Days", "elections", and any other tags that might apply to the contents of this week’s report.

  7. Set the featured image to be "fpgm" (a photo of a clipboard with the text "From the Fedora Program Manager") in the WordPress media library.

  8. After publishing the update, remove outdated content from the fridays_fedora_facts.md file.

Refer to the Community Blog contribution documentation and article guidelines for more details.

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