The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: section/para
Context English State
<emphasis>Environment:</emphasis> This should describe, as accurately as possible, the environment in which the problem has been observed. This includes the operating system version, the version of the specific program or file that contains the problem, and any other relevant items such as system configuration, other installed software that influences the problem, etc.—quite simply everything a developer needs to know to reconstruct the environment in which the problem occurs.
<emphasis>Description:</emphasis>A complete and accurate description of the problem you are experiencing. Try to avoid speculating about the causes of the problem unless you are certain that you are on the right track, as it may mislead a developer into making incorrect assumptions about the problem. It should include the actions you need to take to reproduce the problem. If you know any workaround, include it. It not only helps other people with the same problem work around it, but may also help a developer understand the cause for the problem.
Once the problem report has been filed, you will receive a confirmation by email which will include the tracking number that was assigned to your problem report and a URL you can use to check its status. With a little luck, someone will take an interest in your problem and try to address it, or, as the case may be, explain why it is not a problem. You will be automatically notified of any change of status, and you will receive copies of any comments or patches someone may attach to your problem report's audit trail.
If someone requests additional information from you, or you remember or discover something you did not mention in the initial report, please submit a follow up. The number one reason for a bug not getting fixed is lack of communication with the originator. The easiest way is to use the comment option on the individual PR's web page, which you can reach from the <link xlink:href="">PR search page</link>.
If the problem report remains open after the problem has gone away, just add a comment saying that the problem report can be closed, and, if possible, explaining how or when the problem was fixed.
Sometimes there is a delay of a week or two where the problem report remains untouched, not assigned or commented on by anyone. This can happen when there is an increased problem report backlog or during a holiday season. When a problem report has not received attention after several weeks, it is worth finding a committer particularly interested in working on it.
There are a few ways to do so, ideally in the following order, with a few days between attempting each communication channel:
Find the relevant FreeBSD mailing list for the problem report from the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">list in the Handbook</link> and send a message to that list asking about assistance or comments on the problem report.
Join the relevant <acronym>IRC</acronym> channels. A partial listing is here: <link xlink:href=""/>. Inform the people in that channel about the problem report and ask for assistance. Be patient and stay in the channel after posting, so that the people from different time zones around the world have a chance to catch up.
Find committers interested in the problem that was reported. If the problem was in a particular tool, binary, port, document, or source file, check the <link xlink:href="">SVN Repository</link>. Locate the last few committers who made substantive changes to the file, and try to reach them via <acronym>IRC</acronym> or email. A list of committers and their emails can be found in the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributors">Contributors to FreeBSD</link> article.
Remember that these people are volunteers, just like maintainers and users, so they might not be immediately available to assist with the problem report. Patience and consistency in the follow-ups is highly advised and appreciated. With enough care and effort dedicated to that follow-up process, finding a committer to take care of the problem report is just a matter of time.
If There Are Problems
If you found an issue with the bug system, file a bug! There is a category for exactly this purpose. If you are unable to do so, contact the bug wranglers at <email></email>.
Further Reading
This is a list of resources relevant to the proper writing and processing of problem reports. It is by no means complete.
<link xlink:href="">How to Report Bugs Effectively</link>—an excellent essay by Simon G. Tatham on composing useful (non-FreeBSD-specific) problem reports.
<link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/pr-guidelines/article.html">Problem Report Handling Guidelines</link>—valuable insight into how problem reports are handled by the FreeBSD developers.
Component Translation Difference to current string
This translation Translated FreeBSD Doc (Archived)/articles_problem-reports
The following string has the same context and source.
Translated FreeBSD Doc (Archived)/articles_pr-guidelines


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: section/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/problem-reports.pot, string 117