From b630a25c46966e75103904ba180d649b8e641c91 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Tue, 6 Jul 2021 14:15:55 +0200 Subject: [PATCH 01/10] Adding initial suggestion --- CODE_OF_CONDUCT.md | 49 ++++++++++++++++++++++++++ README.md | 21 ++++++++++- charter.md | 40 +++++++++++++++++++++ git_workflow.md | 87 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 196 insertions(+), 1 deletion(-) create mode 100644 CODE_OF_CONDUCT.md create mode 100644 charter.md create mode 100644 git_workflow.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..58f0f4f --- /dev/null +++ b/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 <>. 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/ diff --git a/README.md b/README.md index aba00b7..b42b2af 100644 --- a/README.md +++ b/README.md @@ -1 +1,20 @@ -# json-schema-idl +

+ JSON Schema interface description language +

+

+ 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 +

+ +## 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! + diff --git a/charter.md b/charter.md new file mode 100644 index 0000000..e287ddd --- /dev/null +++ b/charter.md @@ -0,0 +1,40 @@ +# 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 are 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 help 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 is neither in or out of scope for the SIG, but it is not a high prioritization. + +## Section 2: Relationship with JSON Schema organization. + +The SIG is not involve with the actual JSON Schema specification, they are nothing more then a user of it. The JSON Schema organization may force this SIG group to comply with organization level code of conducts, workflow changes, etc. + +## Section 3: The Special interest group + +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 does not actively participate in discussions and maintain the repository within 30 days will be removed from the SIG list and be contributors. + +The working group is currently made up of the following individuals, and feel free to submit issue requested to be added. + +- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/)) +- Jason? + +## Section 4: Roles & Responsibilities + +The SIG members are no different from the regular community beside 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. + +## Section 5: 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 more complex ones it become apparent. +- **Data definition**, i.e. it defines the exact structure of the data. \ No newline at end of file diff --git a/git_workflow.md b/git_workflow.md new file mode 100644 index 0000000..8016355 --- /dev/null +++ b/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/asyncapi.git (fetch) + origin https://github.com/i000000/asyncapi.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/asyncapi/asyncapi.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. From 6e2590d2fad1f946970eca6ed3108861dc461ca9 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Tue, 6 Jul 2021 14:26:20 +0200 Subject: [PATCH 02/10] Updated docs --- README.md | 2 +- charter.md | 27 +++++++++++++-------------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index b42b2af..ab057f9 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@

## 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). +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). diff --git a/charter.md b/charter.md index e287ddd..4562ca3 100644 --- a/charter.md +++ b/charter.md @@ -1,40 +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. +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 are 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 help standardize the behavior improving the user experience. +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 is neither in or out of scope for the SIG, but it is not a high prioritization. +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 SIG is not involve with the actual JSON Schema specification, they are nothing more then a user of it. The JSON Schema organization may force this SIG group to comply with organization level code of conducts, workflow changes, etc. +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 -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. +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. -Any SIG members that does not actively participate in discussions and maintain the repository within 30 days will be removed from the SIG list and be contributors. +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. -The working group is currently made up of the following individuals, and feel free to submit issue requested to be added. -- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/)) -- Jason? +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. -## Section 4: Roles & Responsibilities +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 members are no different from the regular community beside it is their responsibility to understand all points of view of the community and push the project forward. +The SIG group is currently made up of the following individuals. Feel free to submit an issue requested to be added. -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. +- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/)) +- Jason? -## Section 5: Definitions +## 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 more complex ones it become apparent. +- **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. \ No newline at end of file From 933e1e77c711fab4348b44a5ec516b3c16f0c859 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Tue, 6 Jul 2021 14:33:18 +0200 Subject: [PATCH 03/10] Changed git_workflow to reflect this repo --- git_workflow.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/git_workflow.md b/git_workflow.md index 8016355..824df61 100644 --- a/git_workflow.md +++ b/git_workflow.md @@ -35,8 +35,8 @@ The result is as follows: ``` See the example: ``` - origin https://github.com/i000000/asyncapi.git (fetch) - origin https://github.com/i000000/asyncapi.git (push) + 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: @@ -45,7 +45,7 @@ The result is as follows: ``` See the example: ``` - git remote add upstream https://github.com/asyncapi/asyncapi.git + 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: From 4c06a47e9ad7d4aaf5a15f86aa401373691429ff Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Wed, 7 Jul 2021 12:16:01 +0200 Subject: [PATCH 04/10] Switched branch from master to main --- git_workflow.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/git_workflow.md b/git_workflow.md index 824df61..5e75c3d 100644 --- a/git_workflow.md +++ b/git_workflow.md @@ -47,22 +47,22 @@ The result is as follows: ``` 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: +3. Run the `git fetch upstream main` command to fetch all branches. +4. Set up the local `main` branch to track the remote `main` branch from the upstream repository: ``` - git branch -u upstream/master master + git branch -u upstream/main main ``` -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`. +Now, each time you rebase or check out the `main` branch, you refer to the `main` branch of the upstream repository. In other words, when you create a branch from local up-to-date `main` means creating a branch from latest upstream `main`. -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: +To verify that your local `main` branch points to the `upstream/main`, run the `git branch -vv` command. The result is similar to the following: ``` -* master c2226e0 [upstream/master] Update the README.md document +* main c2226e0 [upstream/main] 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. +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 `main `branch of your fork. ## Start Contributing @@ -76,7 +76,7 @@ Follow these steps: 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. + >**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 `main` branch. If you push local changes from the terminal to your remote fork for the first time, use this command: ``` @@ -84,4 +84,4 @@ Follow these steps: ``` 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. +4. Create a pull request from the branch of your forked repository to the `main` branch of the upstream repository and wait for the maintainers' review. From c0b2cd96b8d38456e4b2e3d803f13be71c80f280 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Fri, 9 Jul 2021 13:13:52 +0200 Subject: [PATCH 05/10] Update charter.md Co-authored-by: Jason Desrosiers --- charter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/charter.md b/charter.md index 4562ca3..62f2f91 100644 --- a/charter.md +++ b/charter.md @@ -29,11 +29,11 @@ Any SIG members that do not actively participate in discussions or maintain the 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? +- [Jason Desrosiers](https://github.com/jdesrosiers) ## 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. \ No newline at end of file +- **Data definition**, i.e. it defines the exact structure of the data. From 2baded141592127797d2686fa8a2d778d33cf9d2 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Sun, 18 Jul 2021 20:51:10 +0200 Subject: [PATCH 06/10] Update README.md Co-authored-by: Ben Hutton --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index ab057f9..cba1563 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@

- JSON Schema interface description language + JSON Schema interface description language vocabulary

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 @@ -17,4 +17,3 @@ In case contributions are for changing content on git, please refer to [git work 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! - From 3fb9fc47cc9c3f8c4f364cdbb5bfe4efc62069f6 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Sun, 18 Jul 2021 20:51:38 +0200 Subject: [PATCH 07/10] Update charter.md Co-authored-by: Ben Hutton --- charter.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/charter.md b/charter.md index 62f2f91..8a07cdf 100644 --- a/charter.md +++ b/charter.md @@ -13,7 +13,9 @@ Implementations are neither in nor out of scope for the project, but it is not a ## 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. +The project is not directly involved with the actual JSON Schema specification development, however contributors may be contributors of both. The JSON Schema organization and community may provide guidance and review on vocabulary proposals and proposed releases. It is expected that this project and resulting artifacts will be maintained by teams other than those part of the JSON Schema organization. + +The JSON Schema organization will force this project to comply with the organization-level code of conduct if required, and may require other project level changes such as workflow changes. ## Section 3: The Special interest group From a586825e715df32cd2768447437e0c3acdb59c96 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Thu, 22 Jul 2021 21:59:14 +0200 Subject: [PATCH 08/10] Added review suggestions --- CODE_OF_CONDUCT.md | 4 +++- README.md | 12 ++++++++++++ charter.md | 2 ++ 3 files changed, 17 insertions(+), 1 deletion(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 58f0f4f..2f0b7de 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -37,7 +37,9 @@ 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 lead <>. 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. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project lead report@jsonschema.dev. + +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. diff --git a/README.md b/README.md index cba1563..8de6f9d 100644 --- a/README.md +++ b/README.md @@ -5,12 +5,24 @@ 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

+ +**The project is only first getting started** + ## 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). +## Getting involved +If you want to review changes, creating documentation, help form suggestions or take charge in figuring out a specific task, we welcome any way you want to get involved. + +If you find an issue you would like to work on you can drop a comment, ask questions or discuss the approaches. Or if you see we are missing specific things feel free to create new issues. + +We have a dedicated slack channel in the JSON Schema slack - join here: https://json-schema.slack.com/archives/C028A3HTY2X. + +You can use this channel if you don't know where to get started, want to hear peoples upon on dilemmas, or in general hang out. + ## Contributing In case contributions are for changing content on git, please refer to [git workflow](./git_workflow.md). diff --git a/charter.md b/charter.md index 8a07cdf..ab1cb10 100644 --- a/charter.md +++ b/charter.md @@ -11,6 +11,8 @@ Help and clarify how JSON Schema can be interpreted from validation rules to dat Implementations are neither in nor out of scope for the project, but it is not a high prioritization. +A test suite is expected to be produced along side the work, to better discuss and formulate specific cases. + ## Section 2: Relationship with JSON Schema organization. The project is not directly involved with the actual JSON Schema specification development, however contributors may be contributors of both. The JSON Schema organization and community may provide guidance and review on vocabulary proposals and proposed releases. It is expected that this project and resulting artifacts will be maintained by teams other than those part of the JSON Schema organization. From 629b85e76692848181735b6e0d7d82cc45faa8df Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Thu, 22 Jul 2021 22:59:59 +0200 Subject: [PATCH 09/10] Updated status --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 8de6f9d..500a331 100644 --- a/README.md +++ b/README.md @@ -5,8 +5,11 @@ 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

+## Status -**The project is only first getting started** +While the project is only first getting started, the initial agenda is: +1. Define a processing model for interpreting JSON Schema to data definitions. + * Define code generation vocabulary as needed, while the processing model is being defined ## 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). From 84c0b2a81c4634e6d87114e80b09f19ddc17c007 Mon Sep 17 00:00:00 2001 From: Jonas Lagoni Date: Fri, 23 Jul 2021 10:42:13 +0200 Subject: [PATCH 10/10] Updated readme --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 500a331..0ef4c82 100644 --- a/README.md +++ b/README.md @@ -22,9 +22,9 @@ If you want to review changes, creating documentation, help form suggestions or If you find an issue you would like to work on you can drop a comment, ask questions or discuss the approaches. Or if you see we are missing specific things feel free to create new issues. -We have a dedicated slack channel in the JSON Schema slack - join here: https://json-schema.slack.com/archives/C028A3HTY2X. +We have a dedicated slack channel `#vocab-idl`- in the JSON Schema slack, join the JSON Schema slack here: https://json-schema.org/slack. -You can use this channel if you don't know where to get started, want to hear peoples upon on dilemmas, or in general hang out. +You can use this channel if you don't know where to get started, discuss specifics of issues, get updates, or in general hang out. ## Contributing In case contributions are for changing content on git, please refer to [git workflow](./git_workflow.md).