Merge branch 'develop'

.gitignore

@@ -0,0 +1,78 @@
+*.py[cod]
+target
+*~
+#*
+doc/source/schemas/*.avpr
+build
+
+#********** windows template**********
+
+# Windows image file caches
+Thumbs.db
+
+# Folder config file
+Desktop.ini
+
+# Recycle Bin used on file shares
+$RECYCLE.BIN/
+
+
+#********** osx template**********
+
+.DS_Store
+
+# Thumbnails
+._*
+
+# Files that might appear on external disk
+.Spotlight-V100
+.Trashes
+
+
+#********** linux template**********
+
+.*
+!.gitignore
+*~
+
+# KDE
+.directory
+
+
+#********** emacs template**********
+
+*~
+\#*\#
+/.emacs.desktop
+/.emacs.desktop.lock
+.elc
+auto-save-list
+tramp
+.\#*
+
+# Org-mode
+.org-id-locations
+*_archive
+
+
+#********** vim template**********
+
+.*.sw[a-z]
+*.un~
+Session.vim
+
+
+#********** maven template**********
+
+target/
+
+#********** Travis CI **********
+
+!.travis.yml
+
+#********** IntelliJ files ******
+*.iml
+
+
+#********** Dependency files ********
+src/avro-schema-test-base

.travis.yml

@@ -0,0 +1,9 @@
+language: python
+python:
+  - 2.7
+branches:
+  only:
+    - master
+    - develop
+script:
+  - nosetests -v $VIRTUAL_ENV/src/avro-schema-test-base

CONTRIBUTING.md

@@ -0,0 +1,89 @@
+# How to contribute
+
+Thank you for taking the time to contribute. We appreciate it!
+
+There are two ways to contribute - via issues, which are used for discussion, and pull requests, which are concrete proposals of change.
+
+## Issues
+
+The project's [Issues Page](https://github.com/ga4gh/ga4gh-consent-policy/issues) is a forum to discuss both major and minor issues. It also serves as the means for collaborating with the group and discussing contributions that will ultimately lead to changes to the API. See the [Issue](#issue_resolution) section below for specifics on how issues are resolved by the community.
+
+## Pull Requests
+
+The way to contribute development effort and code to the project is via GitHub pull requests. GitHub provides a nice [overview on how to create a pull request](https://help.github.com/articles/creating-a-pull-request).
+
+Some general rules to follow:
+
+-   [Fork](https://help.github.com/articles/fork-a-repo) the main project into your personal GitHub space to work on.
+-   Create a branch for each update that you're working on. These branches are often called "feature" or "topic" branches. Any changes that you push to your feature branch will automatically be shown in the pull request.
+-   Keep your pull requests as small as possible. Large pull requests are hard to review. Try to break up your changes into self-contained and incremental pull requests.
+-   The first line of commit messages should be a short (<80 character) summary, followed by an empty line and then any details that you want to share about the commit.
+-   Please try to follow the [existing syntax style](#syntax_style).
+
+## Issue Resolution
+
+Once a pull request or issue have been submitted, anyone can comment or vote on to express their opinion following the Apache voting system. Quick summary:
+
+-   **+1** something you agree with
+-   **-1** if you have a strong objection to an issue, which will be taken very seriously. A -1 vote should provide an alternative solution.
+-   **+0** or **-0** for neutral comments or weak opinions.
+-   It's okay to have input without voting.
+-   Silence gives assent.
+
+A pull request with at least two **+1** votes, no **-1** votes, that has been open for at least 3 days is ready to be merged. We sometimes waive the 3 days for cosmetic-only changes -- use good judgment. If an issue gets any **-1** votes, the comments on the issue need to reach consensus before the issue can be resolved one way or the other. There isn't any strict time limit on a contentious issue.
+
+The project will strive for full consensus on everything until it runs into a problem with this model.
+
+## Syntax Style and Conventions
+
+The current code conventions for the source files are as follows:
+
+-   Use two-space indentation, and no tabs.
+-   Hard-wrap code to 80 characters per line.
+-   Use `UpperCamelCase` for object or record names.
+-   Use `lowerCamelCase` for attribute or method names.
+-   Use `CONSTANT_CASE` for global and constant values.
+-   Comments:
+    -   Comments should be indented at the same level as the surrounding code.
+    -   Comments should precede the code that they make a comment on. Documentation comments will not work otherwise.
+    -   Documentation comments, which are intended to be processed by avrodoc and displayed in the user-facing API documentation, must use the `/** ... */` style, and must not have a leading `*` on each internal line:
+
+            /**
+            This documentation comment will be
+            processed correctly by avrodoc.
+            */
+
+            /**
+            * This documentation comment will have a
+            * bullet point at the start of every line
+            * when processed by avrodoc.
+            */
+
+    -   Block and multi-line non-documentation comments, intended for schema developers only, must use the `/* ... */` style.
+
+            /*
+            This multi-line comment will not appear in the
+            avrodoc documentation and is intended for
+            schema developers.
+            */
+
+    -   All multi-line comments should have the comment text at the same indent level as the comment delimeters.
+    -   One-line non-documentation comments, intended for schema developers only, must use the `// ...` style.
+
+## Gitflow Workflow
+
+Our workflow is based on [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow), which defines a strict branching model designed around the project release. This workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. Aside from these two main branches, the workflow utilizes topic and release branches.
+
+### Topic Branches
+
+If you wish to collaborate on a new feature with other GA4GH members you can ask that a topic branch be created. Since Github does not allow pull requests against branches that do not yet exist, you will have to create an issue asking for the topic branch to be created.
+
+Once a topic branch exists, pull requests can be made against it in the usual way. It may also be brought up to date with new changes merged into develop by anyone with commit access, if the changes produce merely a fast-forward merge for each constituent branch. However, if changes from the develop branch create a new merge commit in or or more of the repositories, that commit needs to be reviewed in a pull request.
+
+Changes made in a topic branch can be merged into develop by creating and then [resolving in the normal way](#issue_resolution) a pull request against the develop branch.
+
+Topic branches that have been merged into develop and that are no longer being developed upon should be [deleted](https://github.com/blog/1335-tidying-up-after-pull-requests) (they will still appear in the git history).
+
+### Release Branches
+
+From time to time the group will make a release. This is achieved by creating a branch named "release-foo", where foo is the release name. Only bug fixes are allowed to release branches. To refer to a specific version of a release branch either the commit id can be used, or alternatively (better), a tag can be created (which should be replicated across repositories).

LICENSE

@@ -199,3 +199,4 @@
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
+

README.md

@@ -0,0 +1,19 @@
+# Consent Code Schemas [![Build Status](https://travis-ci.org/ga4gh/ga4gh-consent-policy.svg?branch=develop)](https://travis-ci.org/ga4gh/ga4gh-consent-policy) [![GitHub license](https://img.shields.io/badge/license-Apache%202-blue.svg)](https://raw.githubusercontent.com/ga4gh/ga4gh-consent-policy/develop/LICENSE)
+
+Data model for the data use conditions based on consent codes as introduced in [Consent Codes: Upholding Standard Data Use Conditions](http://journals.plos.org/plosgenetics/article?id=10.1371/journal.pgen.1005772).
+
+## How to contribute
+
+Guidelines for contributing to this repository are listed in the [CONTRIBUTING.md](CONTRIBUTING.md) document.
+
+## How to build
+
+Prerequisites: Maven 3+, Java 1.6+.
+
+To generate Java code, run `mvn package` and check the output in the `target` directory. 
+
+## How to test
+
+Prerequisites: Python 2.7 (incl. Pip 7+).
+
+Install dependencies with `pip install -r requirements.txt`. To run the test suite, use `nosetests -v`.