git: f6daa7eae9 - main - Problem reports: Correct wrong usage of hyphens

The branch main has been updated by carlavilla:

URL: https://cgit.FreeBSD.org/doc/commit/?id=f6daa7eae9911209e17c6840940a9a43dff8f257

commit f6daa7eae9911209e17c6840940a9a43dff8f257
Author:     Minsoo Choo <minsoochoo0122@proton.me>
AuthorDate: 2023-07-22 08:58:19 +0000
Commit:     Sergio Carlavilla Delgado <carlavilla@FreeBSD.org>
CommitDate: 2023-07-22 08:58:19 +0000

    Problem reports: Correct wrong usage of hyphens
    
    Differential Revision:  https://reviews.freebsd.org/D41144
---
 .../content/en/articles/problem-reports/_index.adoc    | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/documentation/content/en/articles/problem-reports/_index.adoc b/documentation/content/en/articles/problem-reports/_index.adoc
index 671e610365..f201711526 100644
--- a/documentation/content/en/articles/problem-reports/_index.adoc
+++ b/documentation/content/en/articles/problem-reports/_index.adoc
@@ -68,7 +68,7 @@ Read the entire document before submitting a problem report, rather than treatin
 There are many types of problems, and not all of them should engender a problem report.
 Of course, nobody is perfect, and there will be times when what seems to be a bug in a program is, in fact, a misunderstanding of the syntax for a command or a typographical error in a configuration file (though that in itself may sometimes be indicative of poor documentation or poor error handling in the application).
 There are still many cases where submitting a problem report is clearly _not_ the right course of action, and will only serve to frustrate both the submitter and the developers.
-Conversely, there are cases where it might be appropriate to submit a problem report about something else than a bug-an enhancement or a new feature, for instance.
+Conversely, there are cases where it might be appropriate to submit a problem report about something else than a bug—an enhancement or a new feature, for instance.
 
 So how does one determine what is a bug and what is not? As a simple rule of thumb, the problem is _not_ a bug if it can be expressed as a question (usually of the form "How do I do X?" or "Where can I find Y?").
 It is not always quite so black and white, but the question rule covers a large majority of cases.
@@ -83,7 +83,7 @@ Consider these factors when submitting PRs about ports or other software that is
 A bug that cannot be reproduced can rarely be fixed.
 If the bug only occurred once and you cannot reproduce it, and it does not seem to happen to anybody else, chances are none of the developers will be able to reproduce it or figure out what is wrong.
 That does not mean it did not happen, but it does mean that the chances of your problem report ever leading to a bug fix are very slim.
-To make matters worse, often these kinds of bugs are actually caused by failing hard drives or overheating processors - you should always try to rule out these causes, whenever possible, before submitting a PR.
+To make matters worse, often these kinds of bugs are actually caused by failing hard drives or overheating processors—you should always try to rule out these causes, whenever possible, before submitting a PR.
 
 Next, to decide to whom you should file your problem report, you need to understand that the software that makes up FreeBSD is composed of several different elements:
 
@@ -110,13 +110,13 @@ You should therefore check all the obvious places before submitting your problem
 For FreeBSD, this means:
 
 * The FreeBSD extref:{faq}[Frequently Asked Questions] (FAQ) list. The FAQ attempts to provide answers for a wide range of questions, such as those concerning  extref:{faq}[hardware compatibility, hardware], extref:{faq}[user applications, applications], and extref:{faq}[kernel configuration, kernelconfig].
-* The extref:{handbook}eresources/[mailing lists, eresources-mail]-if you are not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the searchable archives] on the FreeBSD web site. If the problem has not been discussed on the lists, you might try posting a message about it and waiting a few days to see if someone can spot something that has been overlooked.
+* The extref:{handbook}eresources/[mailing lists, eresources-mail]. If you are not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the searchable archives] on the FreeBSD web site. If the problem has not been discussed on the lists, you might try posting a message about it and waiting a few days to see if someone can spot something that has been overlooked.
 * Optionally, the entire web-use your favorite search engine to locate any references to the problem. You may even get hits from archived mailing lists or newsgroups you did not know of or had not thought to search through.
 * Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR database] (Bugzilla). Unless the problem is recent or obscure, there is a fair chance it has already been reported.
 * Most importantly, attempt to see if existing documentation in the source base addresses your problem.
 +
 For the base FreeBSD code, you should carefully study the contents of [.filename]#/usr/src/UPDATING# on your system or the latest version at https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING].
-(This is vital information if you are upgrading from one version to another-especially if you are upgrading to the FreeBSD-CURRENT branch).
+(This is vital information if you are upgrading from one version to another, especially if you are upgrading to the FreeBSD-CURRENT branch).
 +
 However, if the problem is in something that was installed as a part of the FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for changes that affect the entire Ports Collection).
 https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] are also available via cgit.
@@ -188,7 +188,7 @@ If you attach a patch inline, instead of as an attachment, note that the most co
 Do not send patches as attachments using `Content-Transfer-Encoding: quoted-printable`.
 These will perform character escaping and the entire patch will be useless.
 
-Also note that while including small patches in a PR is generally all right-particularly when they fix the problem described in the PR-large patches and especially new code which may require substantial review before committing should be placed on a web or ftp server, and the URL should be included in the PR instead of the patch.
+Also note that while including small patches in a PR is generally all right—particularly when they fix the problem described in the PR-large patches and especially new code which may require substantial review before committing should be placed on a web or ftp server, and the URL should be included in the PR instead of the patch.
 Patches in email tend to get mangled, and the larger the patch, the harder it will be for interested parties to unmangle it.
 Also, posting a patch on the web allows you to modify it without having to resubmit the entire patch in a followup to the original PR.
 Finally, large patches simply increase the size of the database, since closed PRs are not actually deleted but instead kept and simply marked as complete.
@@ -252,8 +252,8 @@ You have a common PC-based machine, and think you have encountered a problem spe
 You are having a problem with an add-in peripheral card on a commonly seen bus, or a problem with a particular type of hard disk drive: in this case, it probably applies to more than one architecture, and `kern` is the right category.
 ====
 ** If you really do not know where the problem lies (or the explanation does not seem to fit into the ones above), use the `misc` category. Before you do so, you may wish to ask for help on the {freebsd-questions} first. You may be advised that one of the existing categories really is a better choice.
-* _Environment:_ 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.
-* __Description:__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.
+* _Environment:_ 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.
+* _Description:_ 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.
 
 [[pr-followup]]
 == Follow-up
@@ -294,5 +294,5 @@ If you are unable to do so, contact the bug wranglers at  mailto:bugmeister@Free
 This is a list of resources relevant to the proper writing and processing of problem reports.
 It is by no means complete.
 
-* https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[How to Report Bugs Effectively]-an excellent essay by Simon G. Tatham on composing useful (non-FreeBSD-specific) problem reports.
-* extref:{pr-guidelines}[Problem Report Handling Guidelines]-valuable insight into how problem reports are handled by the FreeBSD developers.
+* https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[How to Report Bugs Effectively]: An excellent essay by Simon G. Tatham on composing useful (non-FreeBSD-specific) problem reports.
+* extref:{pr-guidelines}[Problem Report Handling Guidelines]: Valuable insight into how problem reports are handled by the FreeBSD developers.