Browse files

license and code of conduct

  • Loading branch information...
sachinruk committed Sep 1, 2017
1 parent 5d1bfed commit 6ada2914ba31af0d515b1fdc58a497d75b4728dc
Showing with 206 additions and 1 deletion.
  1. +46 −0
  2. +159 −0
  3. +1 −1 LICENSE
@@ -0,0 +1,46 @@
# 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, gender identity and expression, level of experience, 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 sachin [DOT] abeywardana [at] gmail. The project team will review and investigate all complaints, and will respond in a way that it deems 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 [][version]
@@ -0,0 +1,159 @@
# Guidelines for Contributing
As a scientific community-driven software project, welcomes contributions from interested individuals or groups. These guidelines are provided to give potential contributors information to make their contribution compliant with the conventions of the project, and maximize the probability of such contributions to be merged as quickly and efficiently as possible.
There are 4 main ways of contributing to the project (in descending order of difficulty or scope):
* Adding new or improved functionality to the existing codebase
* Fixing outstanding issues (bugs) with the existing codebase. They range from low-level software bugs to higher-level design problems.
* Contributing or improving the documentation (`docs`) or examples (``)
* Submitting issues related to bugs or desired enhancements
# Opening issues
We appreciate being notified of problems with the existing code. We prefer that issues be filed the on [Gitub Issue Tracker](, rather than on social media or by direct email to the developers.
Please verify that your issue is not being currently addressed by other issues or pull requests by using the GitHub search tool to look for key words in the project issue tracker.
# Contributing code via pull requests
While issue reporting is valuable, we strongly encourage users who are inclined to do so to submit patches for new or existing issues via pull requests. This is particularly the case for simple fixes, such as typos or tweaks to documentation, which do not require a heavy investment of time and attention.
Contributors are also encouraged to contribute new code to enhance's functionality, also via pull requests.
<!---Please consult the [ documentation]( to ensure that any new contribution does not strongly overlap with existing functionality.
The preferred workflow for contributing to is to fork the [GitHUb repository](, clone it to your local machine, and develop on a feature branch.
## Steps:
1. Fork the [project repository]( by clicking on the 'Fork' button near the top right of the main repository page. This creates a copy of the code under your GitHub user account.
2. Clone your fork of the repo from your GitHub account to your local disk, and add the base repository as a remote:
$ git clone<your GitHub handle>/
$ cd
$ git remote add upstream
3. Create a ``feature`` branch to hold your development changes:
$ git checkout -b my-feature
Always use a ``feature`` branch. It's good practice to never routinely work on the ``master`` branch of any repository.
4. Please use the Dockerfile even when developing.
5. Develop the feature on your feature branch. Add changed files using ``git add`` and then ``git commit`` files:
$ git add modified_files
$ git commit
to record your changes locally.
After committing, it is a good idea to sync with the base repository in case there have been any changes:
$ git fetch upstream
$ git rebase upstream/master
Then push the changes to your GitHub account with:
$ git push -u origin my-feature
6. Go to the GitHub web page of your fork of the repo. Click the 'Pull request' button to send your changes to the project's maintainers for review. This will send an email to the committers.
## Pull request checklist
We recommended that your contribution complies with the following guidelines before you submit a pull request:
* If your pull request addresses an issue, please use the pull request title to describe the issue and mention the issue number in the pull request description. This will make sure a link back to the original issue is created.
* All public methods must have informative docstrings with sample usage when appropriate.
* Please prefix the title of incomplete contributions with `[WIP]` (to indicate a work in progress). WIPs may be useful to (1) indicate you are working on something to avoid duplicated work, (2) request broad review of functionality or API, or (3) seek collaborators.
* All other tests pass when everything is rebuilt from scratch. See
[Developing in Docker](#Developing-in-Docker) for information on running the test suite locally.
* When adding additional functionality, provide at least one example script or Jupyter Notebook in the ```` folder. Have a look at other examples for reference. Examples should demonstrate why the new functionality is useful in practice and, if possible, compare it to other methods available in
* Documentation and high-coverage tests are necessary for enhancements to be accepted.
* Run any of the pre-existing examples in that contain analyses that would be affected by your changes to ensure that nothing breaks. This is a useful opportunity to not only check your work for bugs that might not be revealed by unit test, but also to show how your contribution improves for end users.
You can also check for common programming errors with the following
* Code with good test **coverage** (at least 80%), check with:
$ pip install pytest pytest-cov coverage
$ pytest
* No `pyflakes` warnings, check with:
$ pip install pyflakes
$ pyflakes path/to/
* No PEP8 warnings, check with:
$ pip install pycodestyle
$ pycodestyle path/to/
* AutoPEP8 can help you fix some of the easy redundant errors:
$ pip install autopep8
$ autopep8 path/to/
## Developing in Docker
We have provided a Dockerfile which helps for isolating build problems, and local development.
Install [Docker]( for your operating system, clone this repo, then
run `docker-compose up --build`. This should start a local docker container wth a notebook server running on port 9000. The repo will be running the code from your local copy of ``,
so it is good for development.
You may also use it to run the test suite, with
$ docker exec -it bash # logon to the container
$ cd ~/
$ . ./scripts/ # takes a while!
This should be quite close to how the tests run on TravisCI.
If the container was started without opening the browser, you
need the a token to work with the notebook. This token can be
access with
docker exec -it jupyter notebook list
## Style guide
Follow [TensorFlow's style guide]( or the [Google style guide]( for writing code, which more or less follows PEP 8.
#### This guide was derived from the [scikit-learn guide to contributing](
@@ -195,7 +195,7 @@ All rights reserved.
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Copyright [2017] [Sachinthaka Abeywardana]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.

0 comments on commit 6ada291

Please sign in to comment.