├── .github ├── CODEOWNERS ├── FUNDING.yml └── ISSUE_TEMPLATE │ ├── doc-template.md │ └── spec-template.md ├── LICENSE └── README.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Lines starting with '#' are comments. 2 | # Each line is a file pattern followed by one or more owners. 3 | 4 | # More details are here: https://help.github.com/articles/about-codeowners/ 5 | 6 | # The '*' pattern is global owners. 7 | 8 | # Order is important. The last matching pattern has the most precedence. 9 | # The folders are ordered as follows: 10 | 11 | # In each subsection folders are ordered first by depth, then alphabetically. 12 | # This should make it easy to add new rules without breaking existing ones. 13 | 14 | # Global rule: 15 | * @zbeyens 16 | * @dylans 17 | -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | github: zbeyens 2 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/doc-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Doc template 3 | about: Structured list of specs with optional description. 4 | title: '' 5 | labels: doc 6 | assignees: '' 7 | 8 | --- 9 | 10 | ### Description 11 | 12 | 13 | 14 | ### Specs 15 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/spec-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Spec template 3 | about: Given an input, when an action occurs, then expect an output 4 | title: '' 5 | labels: spec 6 | assignees: '' 7 | 8 | --- 9 | 10 | ### Given 11 | 12 | - 13 | 14 | ```tsx 15 | 16 | ``` 17 | 18 | ### When 19 | 20 | - 21 | 22 | ### Then 23 | 24 | - 25 | 26 | ```tsx 27 | 28 | ``` 29 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2022 Udecode 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Editor Protocol 2 | 3 | The Editor Protocol is an open standard for building a rich text editor. Editors developed in accordance with the protocol allow you to develop applications following the state of the art. The protocol aims to cover all use-cases as there is no clear definition of what the standard should be. The choice is yours. 4 | 5 | - UI/UX 6 | - Data structure 7 | - Editor operations 8 | - Collaboration 9 | - Technical architecture 10 | - Comparison between many existing editors 11 | - ... 12 | 13 | ## Getting Started 14 | 15 | - The [Protocol](https://github.com/udecode/editor-protocol/issues/1), Docs and Specs format is using issues to leverage the activity log. 16 | - The Protocol is composed of Docs. 17 | - Each Doc is a list of Spec related to a subject (e.g. paragraph). 18 | - Each Spec should be mappable to one Unit Test (_"when..., it should be..."_), not less, not more. 19 | - Anyone can create Docs and Specs by opening an issue. 20 | - Maintainers will link the new Docs and Specs to the Protocol Docs. 21 | - If a Doc gets too big, it will be split into smaller Docs. 22 | 23 | ## Usage 24 | 25 | [Plate](https://github.com/udecode/plate) is an example framework that will follow the Editor Protocol. 26 | 27 | ## Roadmap 28 | 29 | _We’ll be publishing a public roadmap for the Editor Protocol soon._ 30 | 31 | 32 | 33 | ### Documentation-Driven Development 34 | 35 | The Editor Protocol follows Documentation-Driven Development principles. 36 | 37 | The philosophy behind Documentation-Driven Development is a simple: **from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.** 38 | 39 | - Document the feature *first*. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes. 40 | - Whenever possible, documentation should be reviewed by users (community) before any development begins. 41 | - Once documentation has been written, development should commence, and test-driven development is preferred. 42 | - Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail. 43 | - When a feature is being modified, it should be modified documentation-first. 44 | - When documentation is modified, so should be the tests. 45 | - Documentation and software should both be versioned, and versions should match, so someone working with old versions of software should be able to find the proper documentation. 46 | 47 | ## Contributing 48 | 49 | The Editor Protocol is an open-source standard, and community contributions are what make open-source such an amazing place to learn, inspire, and create. Any contributions you make are **greatly appreciated**. 50 | 51 | Steps to follow for new Docs and Specs: 52 | - Editor Protocol (Documentation-driven development): 53 | - Open an issue documenting the new Doc or Spec. 54 | - Mention the issue where the new Doc or Spec should be linked to. 55 | - _Semantic versioning – after beta_ 56 | - Application (Test-driven development): 57 | - Open a PR testing the corresponding Editor Protocol Spec(s), mentioning the Spec issue(s). 58 | - Develop the feature in that PR so that the unit test(s) pass. 59 | - Review then merge. 60 | - Release. 61 | 62 | 🌟 Please consider **starring** the project and watching it on GitHub, to be kept abreast of future developments and show your appreciation. 63 | 64 | 📥 If you’ve got an idea for a new Spec, would like to make a suggestion that improves the protocol itself, or want to contribute to a better developer experience for users of the protocol, please comment the existing issues or open a new issue. 65 | 66 | 67 | 68 | [Become a Sponsor!](https://github.com/sponsors/zbeyens) 69 | 70 | Find us on [Slack](https://slate-js.slack.com/messages/plate), we will take the time to guide you. 71 | 72 | ## License 73 | 74 | [MIT](https://github.com/udecode/editor-protocol/blob/main/LICENSE) 75 | --------------------------------------------------------------------------------