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

This commit is contained in:
jeremystretch 2022-08-26 13:33:55 -04:00
parent 3da8e4c1bb
commit 83db8d2072
2 changed files with 24 additions and 15 deletions

View File

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

View File

@ -102,23 +102,28 @@ appropriate labels will be applied for categorization.
[getting started](https://docs.netbox.dev/en/stable/development/getting-started/) [getting started](https://docs.netbox.dev/en/stable/development/getting-started/)
documentation for tips on setting up your development environment. documentation for tips on setting up your development environment.
* Be sure to open an issue **before** starting work on a pull request, and * Be sure to open an issue and wait for it to be assigned to you **before**
discuss your idea with the NetBox maintainers before beginning work. This will starting work on a pull request, and discuss your idea with the NetBox
help prevent wasting time on something that might we might not be able to maintainers before beginning work. This will help prevent wasting time on
implement. When suggesting a new feature, also make sure it won't conflict with proposed changes that we might not be able to accept. When suggesting a new
any work that's already in progress. 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 * 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 be assigned to you so that others are aware it's being worked on. If it meets
will then mark the issue as "accepted." 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. * All new functionality must include relevant tests where applicable.
* When submitting a pull request, please be sure to work off of the `develop` * 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 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 * 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 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 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 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 top post a :+1: instead) or to ask for an update. Doing so generates
reduce noise in the discussion. 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 ## Issue Lifecycle