Clarify that issues must be accepted and assigned prior to PR submission

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,13 +1,15 @@
 <!--
     Thank you for your interest in contributing to NetBox! Please note
     that our contribution policy requires that a feature request or bug
-    report be opened for approval prior to filing a pull request. This
+    report be approved and assigned prior to filing a pull request. This
     helps avoid wasting time and effort on something that we might not
     be able to accept.
 
-    Please indicate the relevant feature request or bug report below.
-    IF YOUR PULL REQUEST DOES NOT REFERENCE AN ACCEPTED BUG REPORT OR
-    FEATURE REQUEST, IT WILL BE MARKED AS INVALID AND CLOSED.
+    Please indicate the assigned feature request or bug report below.
+    IF YOUR PULL REQUEST DOES NOT REFERENCE AN ISSUE WHICH HAS BEEN ASSIGNED
+    TO YOU, IT WE BE CLOSED AUTOMATICALLY. For example:
+
+    ### Fixes: #1234
 -->
 ### Fixes: <ISSUE NUMBER GOES HERE>
 <!--

CONTRIBUTING.md

@@ -102,23 +102,28 @@ appropriate labels will be applied for categorization.
 [getting started](https://docs.netbox.dev/en/stable/development/getting-started/)
 documentation for tips on setting up your development environment.
 
-* Be sure to open an issue **before** starting work on a pull request, and
-discuss your idea with the NetBox maintainers before beginning work. This will
-help prevent wasting time on something that might we might not be able to
-implement. When suggesting a new feature, also make sure it won't conflict with
-any work that's already in progress.
+* Be sure to open an issue and wait for it to be assigned to you **before**
+starting work on a pull request, and discuss your idea with the NetBox
+maintainers before beginning work. This will help prevent wasting time on
+proposed changes that we might not be able to accept. When suggesting a new
+feature, also make sure it won't conflict with any work that's already in
+progress.
 
 * Once you've opened or identified an issue you'd like to work on, ask that it
-be assigned to you so that others are aware it's being worked on. A maintainer
-will then mark the issue as "accepted."
+be assigned to you so that others are aware it's being worked on. If it meets
+the acceptance criteria, a maintainer will then mark the issue as "accepted"
+and assign it to you. (Note that GitHub requires that a user first comment on
+an issue before it can be assigned to that user.)
 
-* Any pull request which does _not_ relate to an **accepted** issue will be closed.
+* Any pull request which does not relate to an **assigned** issue will be
+closed.
 
 * All new functionality must include relevant tests where applicable.
 
 * When submitting a pull request, please be sure to work off of the `develop`
 branch, rather than `master`. The `develop` branch is used for ongoing
-development, while `master` is used for tagging stable releases.
+development, while `master` is used for tagging stable releases. (If you're
+developing for the next minor release, use `feature` instead.)
 
 * In most cases, it is not necessary to add a changelog entry: A maintainer will
 take care of this when the PR is merged. (This helps avoid merge conflicts
@@ -136,8 +141,10 @@ these checks):
 
 Only comment on an issue if you are sharing a relevant idea or constructive
 feedback. **Do not** comment on an issue just to show your support (give the
-top post a :+1: instead) or ask for an ETA. These comments will be deleted to
-reduce noise in the discussion.
+top post a :+1: instead) or to ask for an update. Doing so generates
+unnecessary noise in the discussion, and is especially annoying for people who
+have subscribed to updates for the issue. Any comments without substance
+relevant to the discussion will be deleted.
 
 ## Issue Lifecycle