Community health, templates, diagnostics, and CLI

[mrl280]

• Added several community health documents:

  • Updated the Code of Conduct (CODE_OF_CONDUCT.md) based on feedback received during our February sprint meeting.
  • Added contributing guidelines (CONTRIBUTING.md).
  • Added diversity statement (DIVERSITY_STATEMENT.md).
  • Added security policy (SECURITY.md).
  • Added coding guidelines (CODING.md). This document includes general guidelines, Python-specific guidelines, documentation guidelines, testing guidelines, guidelines for Git and GitHub, as well as information on building docs and our development process.

• Made a few updates to the README, mostly just adding links to relevant community health documents and the to support forum.

• Added issue templates for bug reports and feature requests, and added a link to the support forum on the issue selection page. Now, when uses go to submit an issue, they will see this:

When drafting an issue, they will be reminded at the bottom that their contribution must align with the relevant community health documents.

• Added pull request template.

• Initialized RIA CLI, powered by Click. CLI is now composable, so all commands are executed using ria [OPTIONS] COMMAND [ARGS]... syntax. Furthermore, all commands are defined independently of the RIA CLI and found and integrated automatically, meaning no need to ever update ria_cli.py nor to modify the command definitions when pulling them in from development repos.

• Added diagnostics package with print_version_info() function. This function finds and prints out system, dependency, and CUDA information. We prompt the users to include this information in their bug reports. Example output (on my work laptop):

This information can also be accessed from the command line using ria version. Further work is required to find all the version information for the libraries that don't provide metadata in the expected format.

Note: If you want to test the issue or pull request templates prior to merging, you'll have to do so in my workspace: https://github.com/qoherent/michael.

@Alec1234567, you'll want to check out how I'm generating a composable CLI with Click.
@UmairK5669, can you verify whether my instructions for building the project's docs for sphinx-autobuild are accurate and complete? (They're in CODING.md)

[UmairK5669]

Instructions for building docs with sphinx-autobuild are all good. One thing I want to clarify further is the types of changes that get built automatically. I think explicitly mentioning that only changes within the source directory, including the .rst files and _templates/layout.html will get built automatically will probably be useful. Let me know your thoughts!

[mrl280]

Instructions for building docs with sphinx-autobuild are all good. One thing I want to clarify further is the types of changes that get built automatically. I think explicitly mentioning that only changes within the source directory, including the .rst files and _templates/layout.html will get built automatically will probably be useful. Let me know your thoughts!

Thanks @UmairK5669. Ya, when we run sphinx-build, it will process the files in the source directory. When processing the automodule directives, Sphinx should generate the corresponding HTML files from the project source. So, changes to docstrings should automatically be captured in this way.

As I understand, the only thing that is not automatic is adding the automodule directives for new modules, for which I use sphinx-apidoc, by running sphinx-apidoc -o ./source ../ria or similiar, and then you have to manually update the links in the index.rst files. Sounds like lots of work has been done to automate this, so perhaps we should adopt one of these work arounds: readthedocs/readthedocs.org#1139? Also, I guess this also means that right now sphinx-apidoc is not technically a project dependency, but just a tool we suggest using.

Perhaps for now the I should just update step 3 to read: "A working copy of the docs will now be available at http://localhost:8000/, and any changes made to the configurations in the docs/source directory will be automatically reflected there. Docstring changes will be automatically reflected for all components with automodule directives." And then further explain the use of sphinx-apidoc in the note at the bottom? Let me know if you think these changes are accurate and would strengthen the instructions, or if you had something else in mind.

[abeigi]

reviewed diffs and tested ria version and all appears to be working.

[UmairK5669]

Perhaps for now the I should just update step 3 to read: "A working copy of the docs will now be available at http://localhost:8000/, and any changes made to the configurations in the docs/source directory will be automatically reflected there. Docstring changes will be automatically reflected for all components with automodule directives." And then further explain the use of sphinx-apidoc in the note at the bottom? Let me know if you think these changes are accurate and would strengthen the instructions, or if you had something else in mind.

These new instructions are great. I don't necessarily think we need to further explain sphinx-apidoc as you mention its use clearly above, however, if you do think further clarification is necessary/useful then it should be added.