Initial release

Author: ph4m

CONDUCT.md

@@ -0,0 +1,82 @@
+An open-source and open community project is one in which participants choose to work together, and in that process experience differences in language, location, nationality, and experience. In such a diverse environment, misunderstandings and disagreements happen, which in most cases can be resolved informally. In rare cases, however, behavior can intimidate, harass, or otherwise disrupt one or more people in the community, which this project will not tolerate.
+
+A **Code of Conduct** is useful to define accepted and acceptable behaviors and to promote high standards of professional practice. It also provides a benchmark for self evaluation and acts as a vehicle for better identity of the organization.
+
+This code (**CoC**) applies to any participant in this project's community – developers, participants in meetings, teleconferences, mailing lists, conferences or functions, etc. Note that this code complements rather than replaces legal rights and obligations pertaining to any particular situation.
+
+## Statement of Intent
+
+This project is committed to maintain a **positive** [work environment](#work-environment). This commitment calls for a workplace where [participants](#participant) at all levels behave according to the rules of the following code. A foundational concept of this code is that we all share responsibility for our work environment.
+## Code
+1. Treat each other with [respect](#respect), professionalism, fairness, and sensitivity to our many differences and strengths, including in situations of high pressure and urgency.
+1. Never [harass](#harassment) or [bully](#workplace-bullying) anyone verbally, physically or [sexually](#sexual-harassment).
+1. Never [discriminate](#discrimination) on the basis of personal characteristics or group membership.
+1. Communicate constructively and avoid [demeaning](#demeaning-behavior) or [insulting](#insulting-behavior) behavior or language.
+1. Seek, accept, and offer objective work criticism, and [acknowledge](#acknowledgement] properly the contributions of others.
+1. Be honest about your own qualifications, and about any circumstances that might lead to conflicts of interest.
+1. Respect the privacy of others and the confidentiality of data you access.
+1. With respect to cultural differences, be conservative in what you do and liberal in what you accept from others, but not to the point of accepting disrespectful, unprofessional or unfair or [unwelcome behavior](#unwelcome-behavior) or [advances](#unwelcome-sexual-advance).
+1. Promote the rules of this Code and take action (especially if you are in a [leadership position](#leadership-position)) to bring the discussion back to a more civil level whenever inappropriate behaviors are observed.
+1. Stay on topic: Make sure that you are posting to the correct channel and avoid off-topic discussions. Remember when you update an issue or respond to an email you are potentially sending to a large number of people.
+1. Step down considerately: Members of every project come and go, and the Hyperledger Project is no different. When you leave or disengage from the project, in whole or in part, we ask that you do so in a way that minimizes disruption to the project. This means you should tell people you are leaving and take the proper steps to ensure that others can pick up where you left off.
+
+## Glossary
+#### Demeaning behavior
+is acting in a way that reduces another person's dignity, sense of self-worth or respect within the community.
+
+#### Discrimination
+is the prejudicial treatment of an individual based on criteria such as: physical appearance, race, ethnic origin, genetic differences, national or social origin, name, religion, gender, sexual orientation, family or health situation, pregnancy, disability, age, education, wealth, domicile, political view, morals, employment, or union activity.
+
+#### Insulting behavior
+is treating another person with scorn or disrespect.
+
+#### Acknowledgement
+is a record of the origin(s) and author(s) of a contribution.
+
+#### Harassment
+is any conduct, verbal or physical, that has the intent or effect of interfering with an individual, or that creates an intimidating, hostile, or offensive environment.
+
+#### Leadership position
+includes group Chairs, project maintainers, staff members, and Board members.
+
+#### Participant
+includes the following persons:
+* Developers
+* Anyone from the Public partaking in this project's work environment (e.g. contribute code, comment on our code or specs, email us, attend our conferences, functions, etc)
+
+#### Respect
+is the genuine consideration you have for someone (if only because of their status as participant in Hyperledger Project, like yourself), and that you show by treating them in a polite and kind way.
+
+#### Sexual harassment
+includes visual displays of degrading sexual images, sexually suggestive conduct, offensive remarks of a sexual nature, requests for sexual favors, unwelcome physical contact, and sexual assault.
+
+#### Unwelcome behavior
+Hard to define? Some questions to ask yourself are:
+* how would I feel if I were in the position of the recipient?
+* would my spouse, parent, child, sibling or friend like to be treated this way?
+* would I like an account of my behavior published in the organization's newsletter?
+* could my behavior offend or hurt other members of the work group?
+* could someone misinterpret my behavior as intentionally harmful or harassing?
+* would I treat my boss or a person I admire at work like that ?
+
+_Summary_: if you are unsure whether something might be welcome or unwelcome, don't do it.
+
+#### Unwelcome sexual advance
+includes requests for sexual favors, and other verbal or physical conduct of a sexual nature, where:
+* submission to such conduct is made either explicitly or implicitly a term or condition of an individual's employment,
+* submission to or rejection of such conduct by an individual is used as a basis for employment decisions affecting the individual,
+* such conduct has the purpose or effect of unreasonably interfering with an individual's work performance or creating an intimidating hostile or offensive working environment.
+
+#### Workplace Bullying
+is a tendency of individuals or groups to use persistent aggressive or unreasonable behavior (e.g. verbal or written abuse, offensive conduct or any interference which undermines or impedes work) against a co-worker or any professional relations.
+
+#### Work Environment
+is the set of all available means of collaboration, including, but not limited to messages to mailing lists, private correspondence, Web pages, chat channels, phone and video teleconferences, and any kind of face-to-face meetings or discussions.
+
+## Incident Procedure
+
+To report incidents or to appeal reports of incidents, contact the Project maintainers. Please include any available relevant information, including links to any publicly accessible material relating to the matter. Every effort will be taken to ensure a safe and collegial environment in which to collaborate on matters relating to the Project. In order to protect the community, the Project reserves the right to take appropriate action, potentially including the removal of an individual from any and all participation in the project. The Project will work towards an equitable resolution in the event of a misunderstanding.
+
+## Credits
+
+This code is based on the [Hyperledger Project's CoC](https://github.com/hyperledger/hyperledger/wiki/Hyperledger-Project-Code-of-Conduct), [W3C’s Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc) with some additions from the [Cloud Foundry](https://www.cloudfoundry.org/)‘s Code of Conduct.

CONTRIBUTING.md

@@ -0,0 +1,66 @@
+### Welcome
+
+We welcome contributions to the Constrained Exploration and Recovery from Experience Shaping Project in many forms, and there's always plenty to do!
+
+First things first, please review the Constrained Exploration and Recovery from Experience Shaping Project's [Code of Conduct](CONDUCT.md) before participating. It is important that we keep things civil.
+
+### Reporting bugs
+If you are a user and you find a bug, please submit an [issue](https://github.com/IBM/constrained-rl/issues). Please try to provide sufficient information for someone else to reproduce the issue. One of the project's maintainers should respond to your issue within 24 hours. If not, please bump the issue and request that it be reviewed.
+
+### Fixing issues and working stories
+Review the [issues list](https://github.com/IBM/constrained-rl/issues) and find something that interests you. You could also check the ["help wanted"](https://github.com/IBM/constrained-rl/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) list. It is wise to start with something relatively straight forward and achievable. Usually there will be a comment in the issue that indicates whether someone has already self-assigned the issue. If no one has already taken it, then add a comment assigning the issue to yourself, eg.: ```I'll work on this issue.```. Please be considerate and rescind the offer in comments if you cannot finish in a reasonable time, or add a comment saying that you are still actively working the issue if you need a little more time.
+
+We are using the [GitHub Flow](https://guides.github.com/introduction/flow/) process to manage code contributions. If you are unfamiliar, please review that link before proceeding.
+
+To work on something, whether a new feature or a bugfix:
+  1. Create a [fork](https://help.github.com/articles/fork-a-repo/) (if you haven't already)
+
+  2. Clone it locally
+  ```
+  git clone https://github.com/yourid/constrained-rl.git
+  ```
+  3. Add the upstream repository as a remote
+  ```
+  git remote add upstream https://github.com/IBM/constrained-rl.git
+  ```
+  4. Create a branch
+
+  Create a descriptively-named branch off of your cloned fork ([more detail here](https://help.github.com/articles/syncing-a-fork/))
+  ```
+  cd constrained-rl
+  git checkout -b issue-nnnn
+  ```
+  5. Commit your code
+
+  Commit to that branch locally, and regularly push your work to the same branch on the server.
+
+  6. Commit messages
+
+  Commit messages must have a short description no longer than 50 characters followed by a blank line and a longer, more descriptive message that includes reference to issue(s) being addressed so that they will be automatically closed on a merge e.g. ```Closes #1234``` or ```Fixes #1234```.
+
+  7. Pull Request (PR)
+
+  When you need feedback or help, or you think the branch is ready for merging, open a pull request (make sure you have first successfully built and tested your changes.
+
+   _Note: if your PR does not merge cleanly, use ```git rebase master``` in your feature branch to update your pull request rather than using ```git merge master```_.
+
+  8. Did we mention tests? All code changes should be accompanied by new or modified tests.
+
+  9. Any code changes that affect documentation should be accompanied by corresponding changes (or additions) to the documentation and tests. This will ensure that if the merged PR is reversed, all traces of the change will be reversed as well.
+
+After your Pull Request (PR) has been reviewed and signed off, a maintainer will merge it into the master branch.
+
+## Coding guidelines
+
+### Becoming a maintainer
+Projects or sub-projects will be lead by a set of maintainers. New projects can designate an initial set of maintainers that will be approved by the Technical Steering Committee when the project is first approved. The project's maintainers will, from time-to-time, consider adding a new maintainer. An existing maintainer will post a pull request to the [MAINTAINERS.txt](MAINTAINERS.txt) file. If a majority of the maintainers concur in the comments, the pull request is then merged and the individual becomes a maintainer.
+
+### Legal stuff
+We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach—the [Developer's Certificate of Origin 1.1 (DCO)](DCO1.1.txt)—that the Linux® Kernel [community](http://elinux.org/Developer_Certificate_Of_Origin) uses to manage code contributions.
+We simply ask that when submitting a pull request, the developer must include a sign-off statement in the pull request description.
+
+Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
+
+```
+Signed-off-by: John Doe <[email protected]>
+```

DCO1.1.txt

@@ -0,0 +1,25 @@
+Developer's Certificate of Origin 1.1
+
+       By making a contribution to this project, I certify that:
+
+       (a) The contribution was created in whole or in part by me and I
+           have the right to submit it under the open source license
+           indicated in the file; or
+
+       (b) The contribution is based upon previous work that, to the best
+           of my knowledge, is covered under an appropriate open source
+           license and I have the right under that license to submit that
+           work with modifications, whether created in whole or in part
+           by me, under the same open source license (unless I am
+           permitted to submit under a different license), as indicated
+           in the file; or
+
+       (c) The contribution was provided directly to me by some other
+           person who certified (a), (b) or (c) and I have not modified
+           it.
+
+       (d) I understand and agree that this project and the contribution
+           are public and that a record of the contribution (including all
+           personal information I submit with it, including my sign-off) is
+           maintained indefinitely and may be redistributed consistent with
+           this project or the open source license(s) involved.

HEADER

@@ -0,0 +1,3 @@
+Copyright (c) <%= owner %> <%= years %>. All Rights Reserved.
+Project name: <%= name %>
+This project is licensed under the MIT License, see LICENSE