Updated to align with eiffel-community repository template.

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,18 @@
+<!--
+Filling out the template is required. Any issue that does not include enough information may be closed at the maintainers' discretion.
+-->
+
+### Description
+<!-- Describe the proposed or requested change, and explain the type of change. Is it a change to the protocol, to the documentation, or something else? -->
+
+### Motivation
+<!-- Why would you like to see this change? -->
+
+### Exemplification
+<!-- Can you think of a concrete example illustrating the impact and value of the change? -->
+
+### Benefits
+<!-- What would the benefits of introducing this change be? -->
+
+### Possible Drawbacks
+<!-- What are the possible side-effects or negative impacts of the change, and why are they outweighed by the benefits? -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,51 @@
+<!--
+Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
+Any pull request must pass the automated Travis tests.
+-->
+
+### Applicable Issues
+<!-- Reference any relevant issues here. Every pull request must reference at least one issue to be considered (as per contribution guidelines) -->
+
+### 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 sources addressed by this PR recently, so please walk us through the concepts. -->
+
+### Alternate Designs
+<!-- Explain what other alternates were considered and why the proposed version was selected -->
+
+### Benefits
+<!-- What benefits will be realized by the change? -->
+
+### Possible Drawbacks
+<!-- What are the possible side-effects or negative impacts of the change? -->
+
+### Sign-off
+<!-- Sign the below certificate of origin, using your full name and e-mail address. -->
+<!-- The certificate is copied from https://developercertificate.org/ -->
+
+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.
+
+Signed-off-by: <!-- <Your full name> <[email protected]> -->

CODE_OF_CONDUCT.md

@@ -0,0 +1,45 @@
+# 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 via the [repository maintainers](mailto:[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

CONTRIBUTING.md

@@ -0,0 +1,78 @@
+<!---
+   Copyright 2018 Ericsson AB.
+   For a full list of individual contributors, please see the commit history.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   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.
+--->
+
+# Contributing to Eiffel Community
+Thank you for contributing to the Eiffel Community!
+
+The following is a set of guidelines for contributing to this repository.
+
+## How to Propose Changes
+Anyone is welcome to propose changes to the contents of this repository by creating a new [Issue](https://github.com/eiffel-community/eiffel-remrem/issues) ticket in GitHub. These requests may concern anything contained in the repo: changes to documentation, bug fixes, requests for additional information, additional event types, requests for additional examples, new featuers et cetera.
+
+When posting a new issue, try to be as precise as possible and phrase your arguments for your request carefully. Keep in mind that collaborating on software development is often an exercise in finding workable compromises between multiple and often conflicting needs; this is particularly true for defining a shared protocol such as Eiffel. In particular, pay attention to the following:
+1. What type of change is requested?
+1. Why would you like to see this change?
+1. Can you provide any concrete examples?
+1. Which arguments in favor can you think of?
+1. Which arguments against can you think of, and why are they outweighed by the arguments in favor?
+
+Also, keep in mind that just as anyone is welcome to propose a change, anyone is welcome to disagree with and criticize that proposal.
+
+### Closing Issues
+An Issue can be closed by any member of [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-remrem-maintainers). This can happen in various ways, for varying reasons:
+1. Issues without conclusion and no activity for at least 14 days may be closed, as a mere housekeeping activity. For instance, an Issue met with requests for further clarification, but left unanswered by the original author, may simply be removed.
+1. Issues may simply be rejected if found unfeasible or undesirable. In such cases they shall also be responded to, providing a polite and concise explanation as to why the proposal is rejected.
+1. Issues may be closed because they are implemented. Following the successful merging of a pull request addressing an Issue, it will be closed.
+
+## How to Contribute
+While we welcome requests for changes (in the form of Issues), we absolutely love ready solutions (in the form of Pull Requests). The best requests are the ones with Pull Requests to go along with them.
+
+Contributions can be made by anyone using the standard [GitHub Fork and Pull model](https://help.github.com/articles/about-pull-requests). When making a pull request, keep a few things in mind.
+1. Always explicitly connect a pull request to an Issue (as indiciated by the Issue template).
+1. Make sure you target the correct branch. If you are unsure which branch is appropriate, ask in the Issue thread.
+1. Pull Requests will be publicly reviewed, criticized, and potentially rejected. Don't take it personally.
+
+### Reviewing and Merging Pull Requests
+We use the Squash and Merge model, which means that all commits in a Pull Request get squashed into a single commit in the target branch. In other words, the revision history will look like a string of single commits corresponding one-to-one with Issues.
+
+Pull requests can be merged by members of the [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-remrem-maintainers). There is a certain protocol to adhere to, however, as well as expectations on membership.
+1. All maintainers are expected to make the effort to participate in the review of Pull Requests. Every maintainer may not review everything in detail, but everyone can make the effort to chime in on some. Remember that expedient high quality reviews are crucial to the long term survival of any open source project.
+1. All community members, maintainers or not, are strongly encouraged to participate in reviews even if they do not feel entirely qualified to assess the pull request. Looking at changes and participating in review discussions is one of the best ways to learn, and presents an excellent opportunity to ask questions. And remember, participating in a review is not the same as having to make the final decision.
+1. A Pull Request should be approved by at least two maintainers (including the one doing the merging). For this to function well, the above point on participation is critical.
+1. Do not feel any pressure to merge Pull Requests. Unless you feel confident about what you are doing, don't press that big green button. Instead, ask a more senior maintainer to make the decision.
+1. When squashing and merging, ensure that the description reflects the change. Detailing every individual commit in the Pull Request is unnecessary, as they are squashed anyway. Instead, describe the change as a single thing. That description should always include an Issue reference, and should focus on WHY the change was made, to provide the reader with context. See [this excellent guide](https://chris.beams.io/posts/git-commit) on writing good commit messages.
+
+### License Management
+To be accepted into the repository, contributions must be licensed under the Apache License 2.0. Consequently, a license notice shall be included in suitable comment syntax where applicable. This license notice shall state the copyright holder(s) and point to the commit history for a full list of individual contributors, on the following format:
+
+> Copyright <Year(s)> <Copyright holder of original contribution [and others].>  
+> For a full list of individual contributors, please see the commit history.
+
+The copyright holder is either the individual contributor if they act on their own behalf, or any organization on whose behalf they contribute. When multiple copyright holders have contributed to the same file, the copyright notice shall be appended "and others". The copyright year(s) shall reflect the year(s) of contribution(s) and be updated accordingly when new contributions are made to the file. To exemplify, the copyright notice of an original contribution made by Jane Doe acting on behalf of Ericsson AB may read:
+
+> Copyright 2018 Ericsson AB.  
+> For a full list of individual contributors, please see the commit history.
+
+When John Doe, acting on his own behalf, makes a subsequent addition to the same file, the notice will be updated accordingly:
+
+> Copyright 2018 Ericsson AB and others.  
+> For a full list of individual contributors, please see the commit history.
+
+When John Doe makes a subsequent contribution the following year, the notice will again be updated:
+
+> Copyright 2018-2019 Ericsson AB and others.  
+> For a full list of individual contributors, please see the commit history.

README.md

@@ -1,10 +1,36 @@
+<!---
+   Copyright 2018 Ericsson AB.
+   For a full list of individual contributors, please see the commit history.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   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.
+--->
+
+<img src="./images/logo.png" alt="Eiffel RemRem" width="350"/>
+
 # Eiffel REMReM Generate
 
-[![Build Status](https://travis-ci.org/Ericsson/eiffel-remrem-generate.svg?branch=master)](https://travis-ci.org/Ericsson/eiffel-remrem-generate)
-[![Coverage Status](https://coveralls.io/repos/github/Ericsson/eiffel-remrem-generate/badge.svg?branch=master)](https://coveralls.io/github/Ericsson/eiffel-remrem-generate?branch=master)
-[![](https://jitpack.io/v/Ericsson/eiffel-remrem-generate.svg)](https://jitpack.io/#Ericsson/eiffel-remrem-generate)
+[![Build Status](https://travis-ci.org/eiffel-community/eiffel-remrem-generate.svg?branch=master)](https://travis-ci.org/eiffel-community/eiffel-remrem-generate)
+[![Coverage Status](https://coveralls.io/repos/github/eiffel-community/eiffel-remrem-generate/badge.svg?branch=master)](https://coveralls.io/github/eiffel-community/eiffel-remrem-generate?branch=master)
+[![](https://jitpack.io/v/eiffel-community/eiffel-remrem-generate.svg)](https://jitpack.io/#eiffel-community/eiffel-remrem-generate)
+
+Eiffel REMReM Generate takes a partial message in JSON format, validates it and adds mandatory fields before outputting a complete, valid Eiffel message. Further documentation is provided at the following link: [http://ericsson.github.io/eiffel-remrem-generate/](http://eiffel-community.github.io/eiffel-remrem-generate/).
+
+# About this repository
+The contents of this repository are licensed under the [Apache License 2.0](./LICENSE).
+
+To get involved, please see [Code of Conduct](./CODE_OF_CONDUCT.md) and [contribution guidelines](./CONTRIBUTING.md).
 
-## Documentation
-Further documentation is provided at the following link: [http://ericsson.github.io/eiffel-remrem-generate/](http://ericsson.github.io/eiffel-remrem-generate/).
+# About Eiffel
+This repository forms part of the Eiffel Community. Eiffel is a protocol for technology agnostic machine-to-machine communication in continuous integration and delivery pipelines, aimed at securing scalability, flexibility and traceability. Eiffel is based on the concept of decentralized real time messaging, both to drive the continuous integration and delivery system and to document it.
 
-__IMPORTANT NOTICE:__ The contents of this repository currently reflect a __DRAFT__. The Eiffel framework has been used in production within Ericsson for several years to great effect; what is presented here is a revision and evolution of that framework - an evolution that is currently ongoing. In other words, anything in this repository should be regarded as tentative and subject to change. It is published here to allow early access and trial and to solicit early feedback.
+Visit [Eiffel Community](https://eiffel-community.github.io) to get started and get involved.