Writing FreeBSD Problem Reports

Dag-Erling Smørgrav

Contributed by  

Mark Linimon

Revision: 46642
Legal Notice
Last modified on 2015-05-01 by rene.
Abstract

This article describes how to best formulate and submit a problem report to the FreeBSD Project.

[ Split HTML / Single HTML ]

Table of Contents
1. Introduction
2. When to Submit a Problem Report
3. Preparations
4. Writing the Problem Report
5. Follow-up
6. If There Are Problems
7. Further Reading
Index

1. Introduction

One of the most frustrating experiences one can have as a software user is to submit a problem report only to have it summarily closed with a terse and unhelpful explanation like not a bug or bogus PR. Similarly, one of the most frustrating experiences as a software developer is to be flooded with problem reports that are not really problem reports but requests for support, or that contain little or no information about what the problem is and how to reproduce it.

This document attempts to describe how to write good problem reports. What, one asks, is a good problem report? Well, to go straight to the bottom line, a good problem report is one that can be analyzed and dealt with swiftly, to the mutual satisfaction of both user and developer.

Although the primary focus of this article is on FreeBSD problem reports, most of it should apply quite well to other software projects.

Note that this article is organized thematically, not chronologically. Read the entire document before submitting a problem report, rather than treating it as a step-by-step tutorial.

All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/

Questions that are not answered by the documentation may be sent to <[email protected]>.
Send questions about this document to <[email protected]>.