Merge pull request #82 from SURGroup/feature/Restructuring

Code base restructuring and CI implementation

.coveragerc

@@ -0,0 +1,2 @@
+[run]
+omit = tests/*

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,32 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: bug
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: enhancement
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/pull_request_template.md

@@ -0,0 +1,37 @@
+# [Title goes here]
+Provide a general summary of your changes in the Title above
+
+## Description
+Describe your changes in detail
+
+## Related Issue
+This project only accepts pull requests related to open issues
+If suggesting a new feature or change, please discuss it in an issue first
+If fixing a bug, there should be an issue describing it with steps to reproduce
+Please link to the issue here:
+
+## Motivation and Context
+Why is this change required? What problem does it solve?
+
+## How Has This Been Tested?
+Please describe in detail how you tested your changes.
+Include details of your testing environment, and the tests you ran to
+see how your change affects other areas of the code, etc.
+
+## Screenshots (if appropriate):
+
+## Types of changes
+What types of changes does your code introduce? Put an `x` in all the boxes that apply:
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+
+## Checklist:
+Go over all the following points, and put an `x` in all the boxes that apply.
+If you're unsure about any of these, don't hesitate to ask. We're here to help!
+- [ ] My code follows the code style of this project.
+- [ ] My change requires a change to the documentation.
+- [ ] I have updated the documentation accordingly.
+- [ ] I have read the **CONTRIBUTING** document.
+- [ ] I have added tests to cover my changes.
+- [ ] All new and existing tests passed.

.pylintrc

@@ -0,0 +1,29 @@
+[MASTER]
+
+# A comma-separated list of package or module names from where C extensions may
+# be loaded. Extensions are loading into the active Python interpreter and may
+# run arbitrary code.
+extension-pkg-whitelist=numpy,scipy
+
+[MESSAGES CONTROL]
+
+# Only show warnings with the listed confidence levels. Leave empty to show
+# all. Valid levels: HIGH, INFERENCE, INFERENCE_FAILURE, UNDEFINED.
+
+# Disable the message, report, category or checker with the given id(s). You
+# can either give multiple identifiers separated by comma (,) or put this
+# option multiple times (only on the command line, not in the configuration
+# file where it should appear only once). You can also use "--disable=all" to
+# disable everything first and then reenable specific checks. For example, if
+# you want to run only the similarities checker, you can use "--disable=all
+# --enable=similarities". If you want to run only the classes checker, but have
+# no Warning level messages displayed, use "--disable=all --enable=classes
+# --disable=W".
+disable=no-name-in-module
+
+[TYPECHECK]
+# List of module names for which member attributes should not be checked
+# (useful for modules/projects where namespaces are manipulated during runtime
+# and thus existing member attributes cannot be deduced by static analysis. It
+# supports qualified module names, as well as Unix pattern matching.
+ignored-modules=scipy

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contributing guidelines
+
+### Coding styles ([PEP8](https://www.python.org/dev/peps/pep-0008/ "Style Guide for Python"))
+___
+We strive to make our code as community friendly as possible. In order to achieve that, our aim is to abibe by the code style guide PEP8 for python. This guide provides many conventions for Python languge and in the scope of UQpy, specific attention is given to the naming conventions provided. The contributor is adviced to give specific attention to these conventions that make the code, developer friendly as well as self-explanatory in most cases, thus reducing the need for code explanatory comments. To this end, single letter names are detered, as they are considered a left-over of old programming languages. Specific attention is given to to the following naming [conventions](https://pep8.org/#prescriptive-naming-conventions "Python naming conventions")
+
+* Module names: Module names should comprise of only lowercase letters. If a module name is comprised of multiple words, underscores can be used to improve readability.
+
+* Class names: For naming classes the **PascalCase** convention is followed, where the first letter of each word that comprises the name of the class is capitalized. In addition, abbreviations are detered to improve readability. For instance, the class name LatinHypercubeSampling is preferred to LHS.
+
+* Variable names: In case of local variable names the **snake_case** convention is followed. Once again abbreviations or single letter names are detered. In case of constants, capitalized words separated by underscores are favoured (e.g. MAX_ITERATIONS).
+
+* Functions: Similar to local variables, functions should abide to the **snake_case** naming convention. Prefer full names here as well. (e.g. evaluate_polynomial is preferred than ev_p)
+
+### Code formatting
+___
+For the rest of the coding/styling conventions defined in PEP8, the contributor is encouraged to use the [Black](https://pypi.org/project/black/#:~:text=Black%20is%20the%20uncompromising%20Python,energy%20for%20more%20important%20matters. "coding formatter"), that takes care of most other PEP8 conventions automatically.  This is not yet a prerequite for new pull requests, but will be integrated to the next version of Continuous Integration tasks. To use it, utilize the following commands:
+
+> pip install black
+>
+> black {uqpy_src_path}
+
+
+Alternatively, in case of anaconda distributions
+
+> conda install -c anaconda black
+>
+> black {uqpy_src_path}
+
+### Docstrings
+___
+Before uploading a code make sure all new classes and methods added are accompanied by the required docstrings. The [PEP 257](https://www.python.org/dev/peps/pep-0257/ "Docstring conventions") guideline contains the specifications for creating and maintaining the respective code documentation.
+
+### Documentation
+___
+The documentation of the project is two-fold. The first part comprises of a [ReadTheDocs](https://uqpyproject.readthedocs.io/en/latest/ "UQpy documentation") part that contains the docstrings, as well the theory that backs up the respective classes and is contained in the **docs/** folder of the repository. The second part regards Jupyter notebook examples that showcase the self-contained applications of the code and exists in the **example/** folder of the repo. In case of new feature contributions, the extention of the existing documentation will be required to include the respective theory and docstrings and at least one jupyter notebook example of the new feature. Pull requests that do not contain the required documentation will not be merged until all required examples are provided.
+
+
+## Continous Integration
+To ensure the quality of the code and its immediate distribution to all channels, a Continuous Integration pipeline is implemented in [Azure Pipelines](https://dev.azure.com/UQpy/UQpy/_build). The minimum requirements for a pull request to be acceptable are succesfull Pylint execution, successfull unit test execution and greater or equal to 80% code coverage on new code with **A** maintainability rating.  All of the above will be explained in detail below.
+
+### Pylint
+___
+Pylint (along with **flake8**) is one of the most well-known linting packages for python. In the case of UQpy, pylint is utilized to detect the errors that the IDE was not able to recognize. For the time being all warnings, conventions, refactors and infos are disabled. The contributors are encouraged to run Pylint localy before creating a pull request. A  detailed configuration of Pylint with the Pycharm IDE can be found [here](https://www.jetbrains.com/help/pycharm/configuring-third-party-tools.html).
+
+### Running and writing tests
+___
+Another vital part of the continuous integration process is the successfull test execution. Using the [Pytest](https://docs.pytest.org/en/stable/) framework, a set of unit test are developed that reside in the **tests/** folder of the repository. For all pull requests as mentioned above, there are two are main requirements in order to be accepted. This first requirement is the successfull test execution of all unit test of the repo. The second requirement is a minimum of 80% coverage on new code. The contributors are encouraged to check for successfull test execution localy before uploading their code and issuing a pull request. Detailed information on how to set up the [pytest framework](https://www.jetbrains.com/help/pycharm/pytest.html#pytest-bdd) and [code coverage](https://www.jetbrains.com/help/pycharm/code-coverage.html#run-with-coverage) in Pycharm IDE are provided in the respective links. Note that for Code Coverage in Pycharm the Professional Edition is required, which is also available for students and academic faculty.
+
+### Sonarcloud & Quality gates
+___
+Sonarcloud is a static code analysis tool that ensures code quality and security. Integrated in the CI procedure, Sonarcloud analyzes the code uploaded in each pull request and detects tricky bugs and vulnerabilities that might lead to undefined behaviour of the code  and thus, impacting end-user. The current metrics of the UQpy code can be found [here](https://sonarcloud.io/dashboard?id=SURGroup_UQpy). The minimum requirements for a Sonarcloud analysis to be successfull is the default Quality Gate provided by the tool, which translates to minimum 80% coverage on new code, less than 3% duplicated code and **A** maintainability, reliability and security ratings. All the above can also be found in the project [Quality Gate](https://sonarcloud.io/organizations/jhusurg/quality_gates/show/9). 
+
+
+### Branching stategies
+
+For all contributors, **master** and **Development** branches are protected. As a result no-one can commit directly to these branches. For contributors that belong to the organization, the recommented procedure is to start the branches from **Development** branch. In order for the CI procedure to run automatically, two different naming strategies are followed. Either **feature/{name_of_feature}** in case this branch is used for the development of a non-existing feature, or **bugfix/{name_of_bugfix}** in case the respective branch is used to fix a bug on the existing code. Note that ALL pull requests must point to the Development branch. Any pull requests to the master branch will be closed and should be resubmitted to the Development branch. For external contributors, the suggested procedure is to create a fork of the existing repository. After the contribution is completed, a pull request should be issued to the Development branch of the main repository. In all cases, make sure that all the above CI requirements are satisfied for your pull request to acceptable.
+

GitVersion.yml

@@ -0,0 +1,9 @@
+mode: Mainline
+major-version-bump-message: '\+semver:\s?(breaking|major)'
+minor-version-bump-message: '\+semver:\s?(feature|minor)'
+patch-version-bump-message: '\+semver:\s?(fix|patch)'
+commit-message-incrementing: Enabled
+branches: {}
+ignore:
+  sha: []
+merge-message-formats: {}

README.rst

@@ -1,3 +1,14 @@
+|AzurePipelines| |PyPIdownloads| |PyPI| |Conda| |CondaForge| |LatestRelease| |Binder|
+
+.. |PyPIdownloads| image:: https://img.shields.io/pypi/dm/UQpy?style=plastic   :alt: PyPI - Downloads
+.. |PyPI| image:: https://img.shields.io/pypi/v/UQpy?style=plastic   :alt: PyPI
+.. |Conda| image:: https://img.shields.io/conda/dn/conda-forge/UQpy?style=plastic   :alt: Conda
+.. |CondaForge| image:: https://img.shields.io/conda/v/conda-forge/UQpy?style=plastic   :alt: Conda
+.. |LatestRelease| image:: https://img.shields.io/github/downloads/SURGroup/UQpy/latest/total?style=plastic   :alt: GitHub Releases (by Release)
+.. |Binder| image:: https://mybinder.org/badge_logo.svg
+ :target: https://mybinder.org/v2/gh/SURGroup/UQpy/master
+.. |AzurePipelines| image:: https://img.shields.io/azure-devops/build/UQpy/UQpy/1   :alt: Azure DevOps builds
+
 
 *******************************************
 Uncertainty Quantification with python (UQpy)
@@ -9,7 +20,6 @@ Uncertainty Quantification with python (UQpy)
 
 :Authors: Michael D. Shields, Dimitris G. Giovanis, Audrey Olivier, Aakash Bangalore Satish, Mohit Singh Chauhan, Lohit Vandanapu, Ketson RM dos Santos, Katiana Kontolati
 :Contact: [email protected]
-:Version: 3.0.4
 
 
 Description
@@ -53,51 +63,39 @@ From PyPI
 
                         pip install UQpy
 
-In order to uninstall it
-
-            * ::
-
-                        pip uninstall UQpy
-
 Using Conda
 
             * ::
 
-                        conda install --channel  ``SURG_JHU``  uqpy
+                        conda install -c conda-forge uqpy
 
 Clone your fork of the UQpy repo from your GitHub account to your local disk (to get the latest version): 
 
             * ::
 
                         git clone https://github.com/SURGroup/UQpy.git
                         cd UQpy/
-                        python setup.py install  (user installation)
-                        python setup.py develop (developer installation)
+                        python setup.py {version} install  (user installation)
+                        python setup.py {version} develop (developer installation)
+
+You will need to replace {version} with the latest version.
 
 Referencing UQpy
 =================
 
 If you are using this software in a work that will be published, please cite this paper:
 
-Olivier, A., Giovanis, D.G., Aakash, B.S., Chauhan, M., Vandanapu, L., and Shields, M.D. (2020). "UQpy: A general purpose Python package and development environment for uncertainty quantification". Journal of Computational Science.
+Olivier, A., Giovanis, D.G., Aakash, B.S., Chauhan, M., Vandanapu, L., and Shields, M.D. (2020). "UQpy: A general purpose Python package and development environment for uncertainty quantification". Journal of Computational Science, DOI:  10.1016/j.jocs.2020.101204.
 
 
 Help and Support
 ===========
 
 For assistance with the UQpy software package, please raise an issue on the Github Issues page. Please use the appropriate labels to indicate which module you are specifically inquiring about.
 
-.. image:: https://img.shields.io/pypi/dm/UQpy?style=plastic   :alt: PyPI - Downloads
-.. image:: https://img.shields.io/conda/dn/conda-forge/UQpy?style=plastic   :alt: Conda
-.. image:: https://img.shields.io/github/downloads/SURGroup/UQpy/V3.0.4/total?style=plastic   :alt: GitHub Releases (by Release)
-
-.. image:: https://img.shields.io/pypi/v/UQpy?style=plastic   :alt: PyPI
-.. image:: https://img.shields.io/conda/v/conda-forge/UQpy?style=plastic   :alt: Conda
-
 .. |logo| image:: logo.jpg
     :scale: 25 %
     :target: https://gihub.com/SURGroup/UQpy
 
 
-.. image:: https://mybinder.org/badge_logo.svg
- :target: https://mybinder.org/v2/gh/SURGroup/UQpy/master
+