Checklist

This checklist lists items to check before submitting a pull request:

Usability

Minimize JSON inputs where possible. If the command inputs can be split up into simple types, such as strings and integers, then do so.

Ensure that the PR has a descriptive summary.
Update the <root>\CODEOWNERS file as appropriate. Instruction for how to add is included in the file itself.
Update the <root>\src\README.rst file to summarize the changes included in the pull request. If required by semantic versioning, include change logs under a new version. Include the PR number at the end of each entry, with format New feature (#70) where 70 is the pull request number.
In the <root>\src\README.rst file, all new entries that are not published yet should be marked as 'Unreleased'.
For each new command added, make sure appropriate documentation is added to the corresponding help file.
If your command has a custom help text section, check that the content is still current.

Any new functionality should include testing. Tests that require a live cluster connection are optional, and should be avoided if possible. Non live testing is required. Suggested testing includes unit testing, as well as paths generation test, which can be found in <root>\src\sfctl\tests\request_generation_test.py.
Any new commands, command groups, or commands whose names have been changed, should include a test in the file <root>\src\sfctl\tests\help_text_test.py. This test helps ensure that the help text is present and displayed correctly.
Make sure that all test assert calls include an explanatory message for ease of debugging errors.
Test method names must start with test_. Otherwise, they will not be picked up by nose2 test finder. However, test file names can end in _test.py.

If adding a new dependency in <root>\src\setup.py, make sure to include it in <root>\requirements.txt as well.
Ensure that all new code follows PEP8 conventions.