Merge branch 'realese/v0.2.0'

.github/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. 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

.github/CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contributing to scikit-uplift
+
+First off, thanks for taking the time to contribute! 🙌👍🎉
+
+All development is done on GitHub: https://github.com/maks-sh/scikit-uplift.
+
+## Submitting a bug report or a feature request
+
+We use GitHub issues to track all bugs and feature requests.
+Feel free to open an issue if you have found a bug or wish to see a feature implemented at https://github.com/maks-sh/scikit-uplift/issues.
+
+## Contributing code
+
+### How to contribute
+
+The code in the master branch should meet the current release. 
+So, please make a pull request to the ``dev`` branch.
+
+1. Fork the [project repository](https://github.com/maks-sh/scikit-uplift).
+2. Clone your fork of the scikit-uplift repo from your GitHub account to your local disk:
+    ``` bash
+    $ git clone git@github.com:YourLogin/scikit-uplift.git
+    $ cd scikit-learn
+    ```
+3. Add the upstream remote. This saves a reference to the main scikit-uplift repository, which you can use to keep your repository synchronized with the latest changes:
+    ``` bash
+    $ git remote add upstream https://github.com/maks-sh/scikit-uplift.git
+    ```
+4. Synchronize your ``dev`` branch with the upstream ``dev`` branch:
+    ``` bash
+    $ git checkout dev
+    $ git pull upstream dev
+    ```
+5. Create a feature branch to hold your development changes:
+    ``` bash
+    $ git checkout -b feature/my_new_feature
+    ```
+    and start making changes. Always use a feature branch. It’s a good practice.
+6. Develop the feature on your feature branch on your computer, using Git to do the version control. When you’re done editing, add changed files using ``git add`` and then ``git commit``.
+Then push the changes to your GitHub account with:
+
+    ``` bash
+    $ git push -u origin feature/my_new_feature
+    ```
+7. Create a pull request from your fork into ``dev`` branch.
+
+### Styleguides
+
+#### Python
+
+We follow the PEP8 style guide for Python. Docstrings follow google style.
+
+#### Git Commit Messages
+
+* Use the present tense ("Add feature" not "Added feature")
+* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
+* Limit the first line to 72 characters or less
+* Reference issues and pull requests liberally after the first line

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,34 @@
+---
+name: "Bug Report"
+about: Submit a bug report to help us improve scikit-uplift
+---
+
+## 🐛 Bug
+
+<!-- A clear and concise description of what the bug is. -->
+
+## To Reproduce
+
+Steps to reproduce the behavior:
+
+1.
+1.
+1.
+
+<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->
+
+## Expected behavior
+
+<!-- A clear and concise description of what you expected to happen. -->
+
+## Environment
+
+ - scikit-uplift version (e.g., 0.1.2):
+ - scikit-learn version (e.g., 0.22.2):
+ - Python version (e.g., 3.7):
+ - OS (e.g., Linux):
+ - Any other relevant information:
+
+## Additional context
+
+<!-- Add any other context about the problem here. -->

.github/ISSUE_TEMPLATE/doc-report.md

@@ -0,0 +1,8 @@
+---
+name: "Documentation"
+about: Report an issue related to https://scikit-uplift.readthedocs.io#
+---
+
+## 📚 Documentation
+
+<!-- A clear and concise description of what content in https://scikit-uplift.readthedocs.io is an issue. -->

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,16 @@
+---
+name: "Feature request"
+about: Suggest an idea for improve scikit-uplift
+---
+
+## 💡 Feature request
+
+<!-- One paragraph explanation of the feature. -->
+
+## Motivation
+
+<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->
+
+## Additional context
+
+<!-- Add any other context or references. -->

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -0,0 +1,45 @@
+---
+name: "Pull request"
+about: Make changes in scikit-uplift
+---
+
+## 📑 Description of the Change
+
+<!--
+
+We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
+
+-->
+
+## Verification Process
+
+<!--
+
+What process did you follow to verify that your change has the desired effects?
+
+- How did you verify that all new functionality works as expected?
+- How did you verify that all changed functionality works as expected?
+
+-->
+
+## Release Notes
+
+<!--
+
+Please describe the changes in a single line that explains this improvement in
+terms that a user can understand. This text will be used in release history.
+
+If this change is not user-facing or notable enough to be included in release notes
+you may use the strings "Not applicable" or "N/A" here.
+
+Examples:
+
+- Fix typo in TwoModels docstring.
+- Add tutorial “Example of usage model from sklift.models in sklearn.pipeline”.
+- Add plot_uplift_by_percentile.
+
+-->
+
+## Additional info
+
+<!-- Add any other information or references. -->