docs: initial documents

CODE_OF_CONDUCT.md

@@ -0,0 +1,49 @@
+
+> Copied mostly from the [AsyncAPI Git-workflow](https://github.com/asyncapi/.github/blob/master/git-workflow.md)
+
+# 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 lead <<EMAIL TO BEN???>>. The project team will review and investigate all complaints, and will respond in a way that it deems 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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

README.md

@@ -1 +1,20 @@
-# json-schema-idl
+<h2 align="center">
+  JSON Schema interface description language
+</h2>
+<p align="center">
+  <em>Help and clarify how JSON Schema can be interpreted from validation rules to data definition. This extends to how those data definitions can be represented in any programming language</em>
+</p>
+
+## Charter
+To help explain the process, the project, the SIG and the community, in terms of how they all relate, please refer to the [charter](./charter.md).
+
+## Code of Conduct
+Respect each other. Choose empathy over judgement. Act according to the [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+## Contributing
+In case contributions are for changing content on git, please refer to [git workflow](./git_workflow.md).
+
+Any contributions that changes the content of this repository MUST go through pull requests.
+
+We use [All Contributors](https://allcontributors.org) specification to handle recognitions. You can help us out in many different ways. Just check out [this](https://allcontributors.org/docs/en/emoji-key) list of possible contributions. All of this is a contribution! 
+

charter.md

@@ -0,0 +1,39 @@
+# JSON Schema IDL charter
+The purpose of this charter is to give a brief introduction to the project, the SIG, and the community how they all relate.
+
+## Section 0: Guiding Principles
+
+Because of the nature of JSON Schema, you don't define the data structure but the validation rules that data should comply with, trying to interpret these rules definitions is a pain point for many. Providing a clear description of how this can be achieved would help not only the developer that uses JSON Schema in this area, but also helps standardize the behavior improving the user experience.
+
+## Section 1: Scope
+
+Help and clarify how JSON Schema can be interpreted from validation rules to data definition. This extends to how those data definitions can be represented in any programming language. To accommodate the JSON Schema spec and the interpretation process a code generation vocabulary will be created.
+
+Implementations are neither in nor out of scope for the project, but it is not a high prioritization.
+
+## Section 2: Relationship with JSON Schema organization.
+
+The project is not involved with the actual JSON Schema specification, they are nothing more than a user of it. The JSON Schema organization may force this project to comply with the organization-level code of conduct, workflow changes, etc. 
+
+## Section 3: The Special interest group
+
+The SIG members are no different from the regular community besides it is their responsibility to understand all points of view of the community and push the project forward. 
+
+The community can get involved by jumping into discussions in issues, pull requests, etc, as long as the [Code of Conduct](./CODE_OF_CONDUCT.md) and [git workflow](./git_workflow.md) is adhered to.
+
+
+SIG memberships are not time-limited. There is no maximum size of the SIG. It is expected that the SIG members actively participate in discussions and maintain the repository, otherwise they will remain a contributor.
+
+Any SIG members that do not actively participate in discussions or maintain the repository within 30 days will be removed from the SIG list and return to being contributors.
+
+The SIG group is currently made up of the following individuals. Feel free to submit an issue requested to be added. 
+
+- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/))
+- Jason?
+
+## Section 4: Definitions
+
+Definitions that should be clarified to align meaning.
+
+- **Validation rules**, i.e. a JSON Schema as such `{type: string}` define that data should validate against a string, it does not define that the data is a string. For small validation rules, there is almost no difference, but with more complex ones it becomes apparent. 
+- **Data definition**, i.e. it defines the exact structure of the data.

git_workflow.md

@@ -0,0 +1,87 @@
+> Copied mostly from the [AsyncAPI Git-workflow](https://github.com/asyncapi/.github/blob/master/git-workflow.md)
+
+This document is the best practice guide that contains the rules to follow when working with the repository.
+
+### Basic rules
+
+Each contributor must follow this workflow:
+
+* Work on forked repositories.
+* Create branches on the fork and avoid working directly on the `main` branch.
+
+## Prepare the fork
+
+A fork is a copy of the repository from which you raise pull requests to propose changes to the original repository.
+
+The unified contribution workflow that bases on forks allows both SIG members and contributors to contribute code and content through the same process. This keeps the main repositories branches clean as contributors create branches only on the forked repositories.
+
+## Configure your fork
+
+The document refers to the original repository as the upstream repository and to the forked repository as the origin repository. We assume you already have a fork of the upstream and you `git clone` it already.
+
+### Working on a Fork on local
+
+> If you perform such configuration for the first time, it is recommended to do it manually to understand all the steps. Next time you do it you can write a script for it or use something like [this](https://gist.github.com/derberg/87319e9c486e4a6c9bef5b629ab0d386)
+
+Configure a `remote` repository that points to the upstream repository. This allows you to synchronize changes you make on the fork with the original repository.
+
+In the terminal, navigate to the location of your fork and perform the following steps:
+
+1.  Run the `git remote -v` command to list the current configured remote repository for your fork.
+The result is as follows:
+    ```
+    origin  https://github.com/{your-username}/{your-fork}.git (fetch)
+    origin  https://github.com/{your-username}/{your-fork}.git (push)
+    ```
+    See the example:
+    ```
+    origin	https://github.com/i000000/json-schema-idl.git (fetch)
+    origin	https://github.com/i000000/json-schema-idl.git (push)
+    ```
+
+2. Specify a new remote upstream repository to synchronize with the fork:
+    ```
+    git remote add upstream https://github.com/{original-owner}/{original-repository}.git
+    ```
+    See the example:
+    ```
+    git remote add upstream https://github.com/json-schema-org/json-schema-idl.git
+    ```
+3. Run the `git fetch upstream master` command to fetch all branches.
+4. Set up the local `master` branch to track the remote `master` branch from the upstream repository:
+    ```
+    git branch -u upstream/master master
+    ```
+
+Now, each time you rebase or check out the `master` branch, you refer to the `master` branch of the upstream repository. In other words, when you create a branch from local up-to-date `master` means creating a branch from latest upstream `master`.
+
+To verify that your local `master` branch points to the `upstream/master`, run the `git branch -vv` command. The result is similar to the following:
+```
+* master           c2226e0 [upstream/master] Update the README.md document
+```
+
+### Working on a Fork in GitHub UI
+
+In case you are a contributor who suggests minor changes using GitHub UI, it is recommended to use a [Pull bot](https://probot.github.io/apps/pull). This bot keeps your fork up to date by creating and merging a pull request with latest changes into the `master `branch of your fork.
+
+## Start Contributing
+
+After you set up your fork, start contributing code and content.
+
+Follow these steps:
+
+1. Create a branch on your fork.
+
+2. Commit changes. Always provide clear commit messages to track commit changes easier.
+
+3. Push the changes to the remote forked repository.
+
+    >**NOTE:** Before you push local changes, make sure you are on the branch you are currently working on. Do not push any changes from the `master` branch.
+
+    If you push local changes from the terminal to your remote fork for the first time, use this command:
+    ```
+    git push -u origin {branch-name}
+    ```
+    Use the `git push` command to push any further commits made on your local branch to a remote repository.  
+
+4. Create a pull request from the branch of your forked repository to the `master` branch of the upstream repository and wait for the maintainers' review.