Aligned with eiffel-community repository guidelines

CODE_OF_CONDUCT.md

@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team via [Ericsson Eiffel architects distribution list](mailto:PDLEIFFELA@ericsson.com). 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.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team via the [repository maintainers](mailto:eiffel-protocol-maintainers@googlegroups.com). 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.
 

CONTRIBUTING.md

@@ -15,15 +15,15 @@
    limitations under the License.
 --->
 
-# Contributing to Eiffel
-Thank you for contributing to the Eiffel protocol and its implementations!
+# Contributing to Eiffel Community
+Thank you for contributing to the Eiffel Community!
 
-The following is a set of guidelines for contributing to the Eiffel protocol or any of its implementations.
+The following is a set of guidelines for contributing to this repository.
 
 ## How to Propose Changes
-Anyone is welcome to propose changes to the Eiffel protocol by creating a new [Issue](https://github.com/Ericsson/eiffel/issues) ticket in GitHub. These requests may concern anything contained in the repo: changes to documentation, changes to definitions, requests for additional information, additional event types, requests for additional examples et cetera.
+Anyone is welcome to propose changes to the contents of this repository by creating a new [Issue](https://github.com/eiffel-community/eiffel/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 defining a shared protocol is often an exercise in finding workable compromises between multiple and often conflicting needs. In particular, pay attention to the following:
+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?
@@ -33,7 +33,7 @@ When posting a new issue, try to be as precise as possible and phrase your argum
 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 [Eiffel team](https://github.com/orgs/Ericsson/teams/eiffel). This can happen in various ways, for varying reasons:
+An Issue can be closed by any member of [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-protocol-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.
@@ -42,19 +42,18 @@ An Issue can be closed by any member of the [Eiffel team](https://github.com/org
 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. See [How to Propose Changes](./how-to-propose-changes.md) for further information.
+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 [Eiffel team](https://github.com/orgs/Ericsson/teams/eiffel). There is a certain protocol to adhere to, however, as well as expectations on membership.
-1. All members of the Eiffel team are expected to make the effort to participate in the review of Pull Requests. Every member 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. Eiffel team members 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. Anyone can participate in reviews, not only Eiffel team members.
-1. A Pull Request should be approved by at least two Eiffel team members (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 member to make the decision.
+Pull requests can be merged by members of the [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-protocol-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

README.md

@@ -1,5 +1,5 @@
 <!---
-   Copyright 2017 Ericsson AB.
+   Copyright 2017-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");
@@ -15,16 +15,24 @@
    limitations under the License.
 --->
 
-# Eiffel
-The Eiffel framework enables technology agnostic enterprise scale continuous integration and delivery with maintained 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.
+<img src="./images/eiffel-protocol-logo.png" alt="Eiffel Protocol" width="350"/>
 
-This repository contains the Eiffel framework vocabulary, descriptions, guides and schemas along with links to relevant implementation repositories. For news, discussions and questions, please visit the [Eiffel Community Google group](https://groups.google.com/forum/#!forum/eiffel-community).
+# Eiffel Protocol
+The Eiffel protocol enables technology agnostic enterprise scale continuous integration and delivery with maintained 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.
 
-Eiffel is licensed under the [Apache License 2.0](./LICENSE).
+This repository contains the Eiffel protocol vocabulary, descriptions, guides and schemas. For implementations, implementations, architecture and community resources, visit the [Eiffel Community](https://eiffel-community.github.io).
 
-__IMPORTANT NOTICE:__ The contents of this repository currectly 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.
+# About this repository
+The contents of this repository are licensed under the [Apache License 2.0](./LICENSE).
 
-## Contents
+To get involved, please see [Code of Conduct](./CODE_OF_CONDUCT.md) and [contribution guidelines](./CONTRIBUTING.md).
+
+# 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.
+
+Visit [Eiffel Community](https://eiffel-community.github.io) to get started and get involved.
+
+# Contents
 1. [Introduction](./introduction/introduction.md)
    1. [How to Propose Changes and Contribute](./CONTRIBUTING.md)
    1. [Code of Conduct](./CODE_OF_CONDUCT.md)
@@ -71,12 +79,5 @@ __IMPORTANT NOTICE:__ The contents of this repository currectly reflect a __DRAF
 1. Customization
    1. [Custom Events](./customization/custom-events.md)
    1. [Custom Data](./customization/custom-data.md)
-1. Implementations
-   1. [Event Persistence](./implementations/event-persistence.md)
-   1. [Event Aggregation and Analysis](./implementations/event-aggregation-and-analysis.md)
-   1. Activity Orchestration
-   1. Event Transport and Routing
-   1. [Event Dispatch](./implementations/event-dispatch.md)
-   1. [Visualization](./implementations/visualization.md)
 1. Extensions
    1. [Eiffel Operations Extension](https://github.com/Ericsson/eiffel-operations-extension)