Contributing article: Indicate it is for Bugzilla

This Article was written long before Phabricator and Pull Requests were accepted ways to submit change requests or bug issues to FreeBSD. As a first step to bringing it up to date, disambiguate the "PR" term, and spell it out as "Bugzilla Problem Request". There are many more problems here to be solved. Reviewed by:	imp, pauamma_gundo.com, ziaee Differential Revision:https://reviews.freebsd.org/D53638 

1 files changed, 17 insertions, 17 deletions

diff --git a/documentation/content/en/articles/contributing/_index.adoc b/documentation/content/en/articles/contributing/_index.adoc
index 022dc29e2e..44f7b3180b 100644
--- a/documentation/content/en/articles/contributing/_index.adoc
+++ b/documentation/content/en/articles/contributing/_index.adoc
@@ -108,9 +108,10 @@ Most of the tasks listed here may require a considerable investment of time, an
 However, there are also many useful tasks which are suitable for "weekend hackers".
 
 . If you run FreeBSD-CURRENT and have a good Internet connection, there is a machine `current.FreeBSD.org` which builds a full release once a day-every now and again, try to install the latest release from it and report any failures in the process.
-. Read the {freebsd-bugs}.
+. Learn about changes or problems that have already been proposed.
 There may be a problem you can comment constructively on or with patches you can test.
 Or you could even try to fix one of the problems yourself.
+. One way is to read the {freebsd-bugs} (for issues submitted through Bugzilla).
 . If you know of any bug fixes which have been successfully applied to -CURRENT but have not been merged into -STABLE after a decent interval (normally a couple of weeks), send the committer a polite reminder.
 . Move contributed software to [.filename]#src/contrib# in the source tree.
 . Make sure code in [.filename]#src/contrib# is up to date.
@@ -125,12 +126,12 @@ If you are able, figure out how to fix it and include a patch in the PR.
 If you think the standard is wrong, ask the standards body to consider the question.
 . Suggest further tasks for this list!
 
-=== Work through the PR Database
+=== Work through the Bugzilla Problem Report Database
 
-The https://bugs.FreeBSD.org/search/[FreeBSD PR list] shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users.
-The PR database includes both programmer and non-programmer tasks.
+The https://bugs.FreeBSD.org/search/[FreeBSD Problem Report list] shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users via Bugzilla.
+This database includes both programmer and non-programmer tasks.
 Look through the open PRs, and see if anything there takes your interest.
-Some of these might be very simple tasks that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one.
+Some of these might be very simple tasks that just need an extra pair of eyes to look over them and confirm that the fix is a good one.
 Others might be much more complex, or might not even have a fix included at all.
 
 Start with the PRs that have not been assigned to anyone else.
@@ -201,7 +202,7 @@ process crossref:contributing[ports-contributing, Contributing to ports].
 
 The docs team also accepts pull requests via GitHub, but has not established any policy for them yet.
 
-If you find a bug or are submitting a specific change, please report it using the https://bugs.FreeBSD.org/submit/[bug submission form].
+If you find a bug or are submitting a specific change, please report it using the https://bugs.FreeBSD.org/submit/[Bugzilla bug submission form].
 Try to fill-in each field of the bug report.
 Unless they exceed 65KB, include any patches directly in the report.
 If the patch is suitable to be applied to the source tree put `[PATCH]` in the synopsis of the report.
@@ -249,7 +250,7 @@ would generate a set of unified diffs for the given source file or directory hie
 
 See man:diff[1] for more information.
 
-Once you have a set of diffs (which you may test with the man:patch[1] command), you should submit them for inclusion with FreeBSD as a bug report.
+Once you have a set of diffs (which you may test with the man:patch[1] command), you may submit them for inclusion with FreeBSD as a Bugzilla problem report.
 _Do not_ just send the diffs to the {freebsd-hackers} or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the PR database until we do.
 Indicate your submission by including `[PATCH]` in the synopsis of the report.
 
@@ -337,7 +338,7 @@ Also read the extref:{porters-handbook}[Porter's Handbook].
 _Please do not commit yourself to more than you feel you can comfortably handle._
 
 You may request maintainership of any unmaintained port as soon as you wish.
-Simply set `MAINTAINER` to your own email address and send a PR (Problem Report) with the change.
+Simply set `MAINTAINER` to your own email address and send a Problem Report with the change.
 If the port has build errors or needs updating, you may wish to include any other changes in the same PR.
 This will help because many committers are less willing to assign maintainership to someone who does not have a known track record with FreeBSD.
 Submitting PRs that fix build errors or update ports are the best ways to establish one.
@@ -425,7 +426,7 @@ This is especially important if your update changes the shared library version;
 
 . Submit changes
 +
-Send your update by submitting a PR with an explanation of the changes and a patch containing the differences between the original port and the updated one.
+Send your update by submitting a Problem Report with an explanation of the changes and a patch containing the differences between the original port and the updated one.
 Please refer to extref:{problem-reports}[Writing FreeBSD Problem Reports] for information on how to write a really good PR.
 +
 [NOTE]
@@ -503,7 +504,7 @@ If so, this may even help their users on other BSD-based systems as well and per
 Please consider sending any applicable patches to the authors as a courtesy.
 ====
 
-===== Investigate bug reports and PRs related to your port
+===== Investigate bug reports and Bugzilla Problem Reports related to your port
 
 This section is about discovering and fixing bugs.
 
@@ -516,7 +517,7 @@ These are the tasks you need to perform to ensure your port continues to work as
 ====
 . Respond to bug reports
 +
-Bugs may be reported to you through email via the https://bugs.FreeBSD.org/search/[Problem Report database].
+Bugs may be reported to you through email via the https://bugs.FreeBSD.org/search/[Bugzilla Problem Report database].
 Bugs may also be reported directly to you by users.
 +
 You should respond to PRs and other reports within 14 days, but please try not to take that long.
@@ -549,7 +550,7 @@ As with build errors, you will need to sort out a fix to the problem.
 Again, remember to ask if you are stuck!
 . Submit or approve changes
 +
-Just as with updating a port, you should now incorporate changes, review and test, and submit your changes in a PR (or send a follow-up if a PR already exists for the problem).
+Just as with updating a port, you should now incorporate changes, review and test, and submit your changes in a Bugzilla PR (or send a follow-up if a PR already exists for the problem).
 If another user has submitted changes in the PR, you can also send a follow-up saying whether or not you approve the changes.
 ====
 
@@ -566,7 +567,7 @@ Take the opportunity to tell them that your port is up to date (if it is, of cou
 Sometimes users and developers will decide that you are a busy person whose time is valuable and do some of the work for you.
 For example, they might:
 
-* submit a PR or send you patches to update your port,
+* submit a Bugzilla PR or send you patches to update your port,
 * investigate and perhaps provide a fix to a PR, or
 * otherwise submit changes to your port.
 
@@ -583,7 +584,7 @@ If you can make them feel that their contribution is appreciated (and it should
 
 There are some really good places to find a port that needs some attention.
 
-You can use the https://bugs.freebsd.org/search[web interface] to the Problem Report database to search through and view unresolved PRs.
+You can use the https://bugs.freebsd.org/search[web interface] to the Problem Report database to search through and view unresolved Bugzilla PRs.
 The majority of ports PRs are updates, but with a little searching and skimming over synopses you should be able to find something interesting to work on.
 
 https://portsfallout.com/[PortsFallout] shows port issues gathered from the FreeBSD package building.
@@ -614,11 +615,10 @@ By this, we mean that there are unresolved problems or pending updates that have
 The extref:{porters-handbook}[Porter's Handbook] is your hitchhiker's guide to the ports system.
 Keep it handy!
 
-extref:{problem-reports}[Writing FreeBSD Problem Reports] describes how to best formulate and submit a PR.
-In 2005 more than eleven thousand ports PRs were submitted!
+extref:{problem-reports}[Writing FreeBSD Problem Reports] describes how to best formulate and submit a Problem Report.
 Following this article will greatly assist us in reducing the time needed to handle your PRs.
 
-The https://bugs.freebsd.org/bugzilla/query.cgi[Problem Report database].
+The https://bugs.freebsd.org/bugzilla/query.cgi[Bugzilla Problem Report database].
 
 The http://portscout.FreeBSD.org[FreeBSD Ports distfile scanner (portscout)] can show you ports for which the distfiles are not fetchable.
 You can check on your own ports or use it to find ports that need their `MASTER_SITES` updated.