FreeBSD Status Report Process | FreeBSD Documentation Portal
Description: Instructions for both writers and editors of status reports

# FreeBSD Status Report Process

Copyright © 2023-2025 The FreeBSD Documentation Project
trademarks

FreeBSD is a registered trademark of the FreeBSD Foundation.

Git and the Git logo are either registered trademarks or trademarks of Software Freedom Conservancy, Inc., corporate home of the Git Project, in the United States and/or other countries.

GitHub is a trademark of GitHub Inc., registered in the United States and other countries.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol.

FreeBSD status reports are published quarterly and provide the general public with a view of what is going on in the Project, and they are often augmented by special reports from Developer Summits. As they are one of our most visible forms of communication, they are very important.

Throughout this document and in other places related to FreeBSD status reports as well, the expression status report is used both to indicate the document published on a quarterly basis and the single entries that are in it.

## 1. Instructions for writers

This section provides some advice on writing status report entries. Instructions on how to submit your entries are also given.

Do not worry if you are not a native English speaker. The status team will check your entries for spelling and grammar, and fix it for you.

### 1.1. Introduce Your Work

Do not assume that the person reading the report knows about your project.

The status reports have a wide distribution. They are often one of the top news items on the FreeBSD web site and are one of the first things that people will read if they want to know a bit about what FreeBSD is. Consider this example:

    abc(4) support was added, including frobnicator compatibility.

Someone reading this, if they are familiar with UNIX man pages, will know that `abc(4)` is some kind of device. But why should the reader care? What kind of device is it? Compare with this version:

    A new driver, abc(4), was added to the tree, bringing support for
    Yoyodyne's range of Frobnicator network interfaces.

Now the reader knows that `abc` is a network interface driver. Even if they do not use any Yoyodyne products, you have communicated that FreeBSD’s support for network devices is improving.

### 1.2. Show the Importance of Your Work

Status reports are not just about telling everyone that things were done, they also need to explain why they were done.

Carry on with the previous example. Why is it interesting that we now support Yoyodyne Frobnicator cards? Are they widespread? Are they used in a specific popular device? Are they used in a particular niche where FreeBSD has (or would like to have) a presence? Are they the fastest network cards on the planet? Status reports often say things like this:

    We imported Cyberdyne Systems T800 into the tree.

And then they stop. Maybe the reader is an avid Cyberdyne fan and knows what exciting new features the T800 brings. This is unlikely. It is far more likely that they have vaguely heard of whatever you have imported (especially into the ports tree: remember that there are over 35,000 other things there too…​). List some of the new features, or bug fixes. Tell them why it is a good thing that we have the new version.

### 1.3. Tell Us Something New

Do not recycle the same status report items.

Bear in mind that status reports are not just reports on the status of the project, they are reports on the change of status of the project. If there is an ongoing project, spend a couple of sentences introducing it, but then spend the rest of the report talking about the new work. What progress has been made since the last report? What is left to do? When is it likely to be finished (or, if "finished" does not really apply, when is it likely to be ready for wider use, for testing, for deployment in production, and so on)?

### 1.4. Sponsorship

Do not forget about your sponsors.

If you or your project has received sponsorship, a scholarship from somebody or you have been already working as a contractor or an employee for a company, please include it. Sponsors always certainly appreciate if you thank them for their funding, but it is also beneficial for them to show that they are actively supporting the Project this way. Last, but not least, this helps FreeBSD to learn more about its important consumers.

### 1.5. Open Items

If help is needed, make this explicit!

Is there any help needed with something? Are there tasks other people can do? There are two ways in which you can use the open items part of the status report: to solicit help, or to give a quick overview of the amount of work left. If there are already enough people working on the project, or it is in a state where adding more people would not speed it up, then the latter is better. Give some big work items that are in progress, and maybe indicate who is focussing on each one.

List tasks, with enough detail that people know if they are likely to be able to do them, and invite people to get in contact.

### 1.6. Submit your report

The following methods are available to submit your reports:

- submit a Phabricator review and add the group status to the reviewers list. You should put your reports in the appropriate subdirectory of `doc/website/content/en/status/` (create it if it is missing);

- submit a pull request to the doc repository through its GitHub mirror . You should put your reports in the appropriate subdirectory of `doc/website/content/en/status` (create it if it is missing);

- send an email to status-submissions@FreeBSD.org including your report.

An AsciiDoc sample report template is available.

## 2. Instructions for editors

This section describes how the reviewing and publication process works.

Status reports main webpage | https://www.FreeBSD.org/status/
Status reports archived GitHub repository (was used for reports from 2017Q4 to 2022Q4): | https://github.com/freebsd/freebsd-quarterly
Main status team email address | status@FreeBSD.org
Email address for reports submission | status-submissions@FreeBSD.org
Mailing list for receiving calls for status reports | freebsd-status-calls@FreeBSD.org
Phabricator status team main page | https://reviews.freebsd.org/project/88/

### 2.1. Timeline

Reports are always accepted by the status team, but the main collection process happens the last month of each quarter, hence in March, June, September and December. The months of January, April, July and October are dedicated to putting together the reports submitted during the precedent quarter. Reports for the finished quarter are still accepted within the first 14 days of the month, but not later. Status reports publication is done during the same months as soon as the report are ready.

Explicit calls for status reports will be sent with deadline reminders.

Reviewing of submitted reports by people not part of the status team should be essentially complete by mid-January/April/July/October (third-party review slush). That is, barring typos or other light copyediting, the status team should be able to assemble the submissions starting on the 15th.

| First quarter | Second quarter | Third quarter | Fourth quarter
--- | --- | --- | --- | ---
First call for reports | March 1st | June 1st | September 1st | December 1st
1 month left reminder | March 15th | June 15th | September 15th | December 15th
2 weeks left reminder | March 31st | June 30th | September 30th | December 31st
Submissions deadline and third-party review slush | April 14th | July 14th | October 14th | January 14th

### 2.2. Call for reports

Calls for status reports are sent to the following recipients:

- the freebsd-status-calls@FreeBSD.org mailing list;

- to all submitters of last status reports (they may have updates or further improvements);

- and, depending on the season,

  - Various conference organizers:

    - AsiaBSDCon in March (First Quarter);

    - BSDCan in May (Second Quarter);

  - Various conference attendees:

    - EuroBSDcon in September - October (Third-Fourth Quarter); EuroBSDcon as an organization is not interested in writing reports for FreeBSD - at least it was not in October 2019: its reason is that the conference is not FreeBSD specific. Hence, reports about this event should be asked of members of the FreeBSD community that attended it.

  - Google Summer of Code students and their mentors.

The easiest way to send calls for status reports is to use the sendcalls perl script in the tools/sendcalls directory of the doc git repository. The script automatically sends calls to all intended recipients. It can also be used through cron jobs, for example:

    0      0       1,15,31 3,12        *       cd ~/doc/tools/sendcalls && git pull && ./sendcalls -s 'Lorenzo Salvadore'
    0      0       1,15,30 6,9        *       cd ~/doc/tools/sendcalls && git pull && ./sendcalls -s 'Lorenzo Salvadore'

| If you are in charge of sending calls for status reports and you are indeed using a cron job, please run it on freefall and sign it with your name so that it is possible to infer who has configured the cron job, in case something goes wrong. Also please update the example above with your name, as an additional safety measure.

It may also be worth making a call for reports on the forums as was done in the past.

### 2.3. Building the report

Submitted reports are reviewed and merged in the proper subdirectory of doc/website/content/en/status/ as they come in. While the reports are being updated, people outside the status team may also review the individual entries and propose fixes.

Usually the last step in the content review process is writing the introduction in a file named intro.adoc: a good introduction can only be written once all the reports have been collected. If possible, it is a good idea to ask different people to write the introduction to add variety: different people will bring different viewpoints and help keep it fresh.

Once all the reports and the introduction are ready, the _index.adoc file needs to be created: this is the file in which the reports are distributed into the various categories and sorted.

### 2.4. Publishing the report

When all the files of the status report are ready, it is time to publish it.

First doc/website/content/en/status/_index.adoc is edited: the next due date is updated and a link to the new report is added. The change is then pushed on the repository and the status team checks that everythings works as expected.

Then the news entry for the main website page is added to doc/website/data/en/news/news.toml.

Here is a sample for the news entry:

    [[news]]
    date = "2021-01-16"
    title = "October-December 2020 Status Report"
    description = "The <a href=\"https://www.FreeBSD.org/status/report-2020-10-2020-12.html\">October to December 2020 Status Report</a> is now available with 42 entries."

Once the HTML version of the report has been built and is online, w3m(1) is used to dump the website as plain-text, e.g:

    % w3m -cols 80 -dump https://www.FreeBSD.org/status/report-2021-01-2021-03/ > /tmp/report-2021-01-2021-03.txt

w3m(1) has full proper unicode support. `-dump` simply outputs text rendering of the HTML code that can then have a few elements snipped, while `-cols` ensures that everything is wrapped to 80 columns.

A link to the rendered report is added between the introduction and the first entry.

The report is finally ready to be sent, toggling disposition (the report should be inlined), and ensuring it is encoded as UTF-8.

Two emails are sent, both with subject in the format `FreeBSD Status Report - <First/Second/Third/Fourth> Quarter <year>`:

- one to freebsd-announce@FreeBSD.org;

| This one must be approved, so if you are in charge of sending this email, ensure that someone does it (mail postmaster if it is taking long).

- one to freebsd-hackers@FreeBSD.org, which also has freebsd-current@FreeBSD.org and freebsd-stable@FreeBSD.org in CC and `developers@FreeBSD.org` in BCC.

Last modified on: February 27, 2026 by Lorenzo Salvadore