
Last year, JSON Schema proudly participated in Google Summer of Code (GSoC) 2024, a global program designed to bring fresh talent into open-source communities. Through this initiative, we tackled some of our most exciting projects yet, creating opportunities for contributors to make meaningful impacts while gaining valuable experience.

We’re thrilled to share the highlights of this journey and the incredible work our contributors and mentors achieved together.

## A Unique Start: Setting the Stage for Success
For JSON Schema, GSoC 2024 wasn’t just about welcoming contributors but about setting a high standard. Before selection, applicants underwent a qualification test, allowing us to assess technical skills and alignment with project goals. This ensured each participant had the tools and mindset to thrive.

Here’s what stood out in our journey:

* 8 projects completed across diverse aspects of JSON Schema.
* A record number of applicants, with a community brimming with enthusiasm.
* Returning mentors and contributors, bringing experience and new perspectives.

## Transformative Projects and Talent Contributors

### 1. Bowtie-Trend: Long-Term Reporting With Bowtie

* Contributor: [Adwait Godbole](https://github.com/adwait-godbole)
* Mentors: [Julian Berman](https://github.com/Julian), [Agnivesh Chaubey](https://github.com/AgniveshChaubey)
* [Idea on GitHub](https://github.com/json-schema-org/community/issues/607)

The project aims to enhance [Bowtie](https://github.com/bowtie-json-schema/bowtie), a meta-validator for the JSON Schema specification that coordinates the execution of validator implementations and reports their results. While Bowtie already generates compliance reports accessible [here](https://bowtie.report), this project introduces a mechanism to track compliance metrics over time. The goal is to enable graphing and querying of how test results evolve as implementations fix bugs or new tests are added. Key outcomes include a new bowtie trend command to aggregate results into trend reports and a dedicated webpage displaying graphs of failed tests over time, providing deeper insights into long-term compliance trends.

### 2. Bowtie-Perf: A Performance Tester for JSON Schema Implementations

* Contributor: [Dhruv Singh](https://github.com/sudo-jarvis)
* Mentors: [Julian Berman](https://github.com/Julian), [Agnivesh Chaubey](https://github.com/AgniveshChaubey)
* [Idea on Github](https://github.com/json-schema-org/community/issues/605)

The project enhances [Bowtie](https://github.com/bowtie-json-schema/bowtie), a meta-validator of the JSON Schema specification. Bowtie provides universal access to JSON Schema implementations, enabling users to validate instances and identify bugs or gaps in functionality. Currently, Bowtie supports validating instances against schemas and comparing implementations based on correctness. This project expands its capabilities by developing a performance tester integrated within Bowtie. This addition provides a critical dimension for performance optimization and enables more comprehensive comparisons across JSON Schema implementations.

### 3. Setting up the CI/CD Pipeline for the JSON Schema Website

* Contributor: [Alok Gupta](https://github.com/aialok)
* Mentor: [Benjamin Granados](https://github.com/benjagm)
* [Idea on Github](https://github.com/json-schema-org/community/issues/603)

The Improved CI/CD Workflow for the [website](https://github.com/json-schema-org/website) project with GitHub Actions project focuses on enhancing the existing CI/CD pipelines by adding essential features like linting, formatting, unit testing, UI testing, broken link checks, and build processes. The project involves streamlining workflows for pull requests, pushes, and issues, with special emphasis on first-time contributors. Key deliverables include creating and optimizing workflows such as PR workflows, push workflows, issue workflows, stale issue and PR reminders, unauthorized file detection, and CodeQL for security analysis. Additionally, the project aims to provide clear documentation on workflow roles and guidelines for updates, ensuring smoother community operation integration and more efficient code management.

### 4. Building a New Version of the JSON Schema Tooling Page

* Contributor: [DV](http://github.com/darhkvoyd)
* Mentor: [Benjamin Granados](https://github.com/benjagm)
* [Idea on Github](https://github.com/json-schema-org/community/issues/602)

The JSON Schema [Tooling Page](https://json-schema.org/tools) plays a vital role in helping developers explore the ecosystem of JSON Schema tools and implementations. However, its current design presents usability challenges that hinder adoption. This project aims to rebuild the tooling page using a data-driven approach while adhering to the updated UI/UX standards of the JSON Schema website. By improving accessibility, simplifying navigation, and enhancing clarity, the revamped tooling page will make JSON Schema implementations more discoverable and user-friendly, ultimately reducing friction and encouraging broader adoption within the developer community.

### 5. JSON Schema Language Server Contributions

* Contributor: [Diya Solanki](https://github.com/diyaayay)
* Mentor: [Jason Desrosiers](https://github.com/jdesrosiers)
* [Idea on Github](https://github.com/json-schema-org/community/issues/601)

The project focuses on enhancing the [Language Server Protocol (LSP)](https://github.com/hyperjump-io/json-schema-language-tools) for JSON Schema, enabling improved support for various editors and IDEs. Unlike the existing VSCode integration, which lacks support for recent JSON Schema versions and struggles with performance for large schemas, this project aims to expand functionality. Key improvements include inline diagnostics for invalid schemas, semantic highlighting for JSON Schema and deprecated keywords, support for multiple drafts (04/06/07/2019-09/2020-12), and enhanced configuration management. The project also focuses on adding code completion for $schema, making JSON Schema development more efficient and accessible across platforms.

### 6. Define Upgrade/Downgrade Language-Agnostic Declarative Transformation Rules for all JSON Schema Dialects

* Contributor: [Suprith KG](https://github.com/suprith-hub)
* Mentor: [Juan Cruz Viotti](https://github.com/jviotti)
* [Idea on Github](https://github.com/json-schema-org/community/issues/599)

The project addresses the challenges of maintaining software compatibility across different schema versions. It focuses on creating declarative, language-agnostic rules to streamline the process of [upgrading or downgrading JSON Schemas](https://github.com/json-schema-org/upgrade-downgrade-rules). This is crucial for users working with high-level languages like Python, managing large documents, or navigating diverse network communication setups such as HTTP, WebSocket, microservices, or IoT. By simplifying schema transformations and introducing standardized procedures, this project aims to save time, ensure reliability, and improve JSON Schema’s versatility across various implementations and use cases.

### 7. Source Generation Analyzer Powered by Corvus.JsonSchema (.NET)

* Contributor: [Pranay Joshi](https://github.com/pranayjoshi)
* Mentors: [Matthew Adams (Endjin)](https://github.com/mwadams), [Greg Dennis](https://github.com/gregsdennis)
* [Idea on Github](https://github.com/json-schema-org/community/issues/614)

The project focuses on creating a source generator that integrates seamlessly with [Corvus.JsonSchema](https://github.com/corvus-dotnet/corvus.jsonschema). This tool will automatically generate code from JSON Schema files within a .NET project at compile time, streamlining the development process. The ultimate goal is to foster collaboration and consistency across software development teams using diverse technology stacks by establishing JSON Schema as a unified source of truth for data modeling. This ensures that generated code adheres to a standardized data structure, improving efficiency and alignment within organizations.

### 8. A Tour of JSON Schema

* Contributor: [Zeel Rajodiya](https://github.com/JeelRajodiya)
* Mentors: [Bence Eros](https://github.com/erosb), [Benjamin Granados](https://github.com/benjagm)
* [Idea on Github](https://github.com/json-schema-org/community/issues/645)

The [Tour of JSON Schema](https://github.com/json-schema-org/tour) project is an interactive learning platform designed to help beginners quickly grasp JSON Schema concepts and best practices. Through step-by-step lessons and hands-on exercises, users can learn by doing, using a simple interface and built-in code editor. The platform provides practical examples, real-time validation of JSON Schema, and immediate feedback, making the learning process engaging and effective. By following structured lessons, users will gain the confidence to create and work with JSON Schemas independently.

## Mentorship: A Two-Way Learning Process

The success of GSoC 2024 for JSON Schema wouldn’t have been possible without our dedicated mentors. They not only guided contributors but also gained fresh perspectives from working closely with emerging talent.

## Watch the Journey

Want to hear more about the contributors’ stories? Watch our [YouTube presentation](https://www.youtube.com/watch?v=2V9k1Hqhgnw) where contributors reflect on their challenges, successes, and learning moments.

## Looking Forward

GSoC 2024 has left an indelible mark on JSON Schema. From automation to tooling, each project has strengthened our ecosystem and laid a foundation for continued innovation.
We are excited about the future and invite developers from around the world to join us in shaping it.

## Ready to contribute?
Explore our [GitHub repository](https://github.com/json-schema-org), get involved in discussions, and be a part of the JSON Schema community!

Background photo by <a href="https://unsplash.com/@jessbaileydesigns?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Jess Bailey</a> 
on <a href="https://unsplash.com/photos/colored-pencil-lined-up-on-top-of-white-surface-l3N9Q27zULw?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>


Onyedikachi Hope Amaechi-Okorie

Celebrating JSON Schema’s Google Summer of Code 2024 Journey


Many of you may have noticed a lot of changes happening around the JSON Schema community.  This website has had a facelift, we've started appearing at developer conferences, and we even participated in Google's Summer of Code & Summer of Docs programs.  But many of you may be asking, "What's happening with the spec?"

In this post I'll be providing an update on specification development and our new publication process.

## Publication Process

In a [previous post](./json-schema-joins-the-openjsf), we announced that we were no longer publishing our specifications through the IETF.  At the time, the intent was to join the OpenJS Foundation, however for multiple reasons, the onboarding process was not able to be completed.  As such, currently we are independent.  In the future, we may again seek to join a foundation (we may even try OpenJS again), but for now, independence seems to be the best place for us.

When we last published a specification, we used the IETF's [Internet-Draft Publication Process](https://authors.ietf.org/en/rfc-publication-process).  This meant that our documents were required to retain the "draft" moniker, even though we considered them fully fledged and ready for use in production systems.  Publishing independently, we're no longer bound by this requirement, however it does mean that we can no longer rely on the IETF document publishing infrastructure.  We have to build our own.

The foundation of our publication process is built on several ideals, and I'll cover the major ones in the next few sections.  By focusing on these pillars, we can ensure a safe and easy upgrade path for our users as the specification continues to evolve.

### Minimize Backward-Incompatible Changes Between Releases

One of the primary complaints we received about releasing a new specification over the last few iterations, particularly between Drafts 2019-09 and 2020-12, is the lack of consideration for backward compatibility.

Just to highlight a few of the breaking changes introduced with the latest version:

- `$recursiveRef` / `$recursiveAnchor` became `$dynamicRef` / `$dynamicAnchor`
- Array-form `items` became `prefixItems`
- `additionalItems` was removed; use schema-form `items` now

These changes meant that a schema written for Draft 2019-09 could validate completely differently when processed under Draft 2020-12 rules.  This creates a very poor upgrade experience.

In defending our decision to include these breaking changes, we hid behind our own advice to schema authors to include the `$schema` keyword, which identifies the dialect (specification version), instead of designing a [pit of success](https://blog.codinghorror.com/falling-into-the-pit-of-success/) that allowed them to continue their current behavior in a system that "just works".

**_Moving forward, upgrade compatibility is our #1 concern when developing a new release._**

That doesn't mean that a breaking change will _never_ happen, but we will make every effort to ensure that it doesn't.

### Maximize Forward Compatibility

**_We need to protect ourselves from potential future changes that would harm or prevent backward compatibility._**

Ironically, this means introducing a breaking change.  (I had [posted](./the-last-breaking-change) about this a couple of years ago, and the reception wasn't awesome, which led to a [follow-up post](./custom-annotations-will-continue).)

In short, to preserve future compatibility, we need to ensure that schemas can't contain extra properties which may one day be proposed as legitimate keywords.  This means that extra data in schemas can no longer be acceptable.  To accommodate our users' need to include meta-data and other values in their schemas, the specification will define a convention or namespace for property names that are to be ignored, and we guarantee that no future proposed keyword may follow this convention in order to keep the namespace protected.

As it stands today, the convention is that your property name should start with `x-`.  If you like, you can read about alternative ideas and how we decided on this approach in [the ADR](https://github.com/json-schema-org/json-schema-spec/blob/main/adr/2023-04-sva-prefix.md).

### Formally Define a Feature Proposal Process

In the past, new features would just be added to the specification and released with the next version.  We held it as acceptable that a feature may not be fully finished when we released the specification.  We expected to receive feedback, and the feature would be updated in the next version.

However, this approach puts a large burden on tooling maintainers who want to support multiple versions of the specification, which is basically all of them.  They'd have to support many different behaviors, sometimes for the same keyword.

The perfect example of this is Draft 2019-09's `$recursiveRef` & `$recursiveAnchor`.  The idea was solid and had a lot going for it.  In 2019 when we were working on it, we developed the concept as best we could, but we needed actual user feedback, so we added it to the specification, knowing that it wasn't quite complete.  Prior to releasing the specification, a few of us who had implementations also added it as an optional feature to let our users try it out.  But after the specification was released, we found that many users were confused as to how it should work, and we identified several ways that we could make it better.  Those improvements became `$dynamicRef` & `$dynamicAnchor` in Draft 2020-12.  Even though the "recursive" keywords weren't part of the latest specification, many implementations wanted to support Draft 2020-12 while continuing to support Draft 2019-09.  Furthermore, schemas which contained the "recursive" keywords couldn't be processed under the Draft 2020-12 rules, which takes us back to the backward compatibiility problem.

**_We need a feature proposal process that encourages tool support while also allowing continued feature development._**

By introducing a feature proposal process, all tooling maintainers can add support as they elect to do so.  And because these proposals aren't considered a hard requirement of the specification, we can continue to iterate on them (including breaking changes).  Finally, by actively encouraging tooling support, we can obtain the real-world feedback that we need to ensure that the feature is the best it can be before we officially integrate it into the specification.

## Compatibility with Draft 2020-12

To close this out, and with all of the above in mind, I want to cover what the upcoming release will entail as it stands now.

First, the incompatibilities:

- As mentioned before, we won't be supporting arbitrary properties anymore.  Any extra data you wish to include will need to use the `x-` property name convention.
- The `$dynamicRef` / `$dynamicAnchor` referencing system will be completely disjoint from the `$ref` / `$id` / `$anchor` system.  In Draft 2020-12, `$dynamicRef` could sometimes fall back to a normal `$ref` behavior.  This has been very confusing, so we've just isolated the two referencing systems.  This is _technically_ a breaking change, but we're pretty certain no one ever used `$dynamicRef` expecting it to work like `$ref`.
- `format` will validate by default.  There was a lot of [discussion](https://github.com/json-schema-org/json-schema-spec/issues/1520) on this topic, but the deciding factor was that users generally expect it to validate, and we wanted to meet that expectation.
- Vocabularies are being demoted to a feature proposal.  This was one of those ideas that wasn't completely finished when it was added to the spec in Draft 2019-09.  It's likely that this feature will change substantially before being merged back into the specification.  As a proposal, the feature can still be supported as development continues, but it's not a hard requirement.

Additionally, but not breaking:

- The recommended output format introduced in Draft 2019-09 has been extracted to its own specification.  The two driving factors for this decision were that different output formats could be more beneficial to different consumers and having the output versioned separately from the specification would more easily allow them to evolve independently.
- Many keyword interaction behaviors were defined by the annotations that were produced at various levels of evaluation.  This led to some confusion and unnecessary requirements, so we've loosened the language around this to allow tooling to figure out how they want to implement the behavior rather than prescribing a particular approach.
- General clean-up and clarifications to more accurately define behavior.

Beyond that, we still have a lot to do, but not nearly as much as we had this time last year, and we still have to figure out the actual publication piece, i.e. how we want it on the website.  We have the IETF-published documents mirrored here, and the new ones will likely go up next to those.  It's just another thing we need to do.  You can track our list of items on the [GitHub project board](https://github.com/orgs/json-schema-org/projects/15/views/1).

It's been four years since we published a new version, but we're getting really close, and I'm very excited.  Stay tuned!

_Cover image is of Mt. Taranaki in New Zealand, by [Sophie Turner](https://unsplash.com/@sophie_turner) on [Unsplash](https://unsplash.com/photos/mountain-near-body-of-water-during-daytime-LZVmvKlchM0)._


Greg Dennis

Moving Toward a Stable Spec

## Introduction
[Apidays Paris](https://www.apidays.global/paris/), the flagship event of the apidays family, returned this year with a focus on "The Future API Stack for Mass Innovation." This annual gathering of API enthusiasts, developers, and industry leaders brought together experts to discuss the latest trends and best practices in API design, API development, and API management.

This year's agenda highlighted the increasing role of AI in API development, exploring how AI can be used to automate tasks, improve API design, and enhance API performance.
Continuing our successful partnership with [AsyncAPI](https://www.asyncapi.com/en) and [OpenAPI](https://www.openapis.org/), this year's event marked a significant milestone with the inaugural JSON Schema conference track. This dedicated track, sponsored by [Octue](https://www.octue.com/), delved deep into the world of JSON Schema, exploring its role in API design, validation, and documentation.

## The first JSON Schema conference

The inaugural [JSON Schema conference track](https://conference.json-schema.org/) at apidays Paris 2024 was a resounding success. As part of the larger conference theme "The Future API Stack for Mass Innovation," the track showcased JSON Schema's crucial role in modern API development and data contract design. 

<figure className='flex flex-wrap justify-center items-center gap-4 w-full'>
    <img className='max-w-400 px-20' src='/img/posts/2024/apidays-paris-2024-recap/json-schema-team.jpg' alt="Five people standing at a booth labeled 'Standards'. They are smiling and looking at the camera. From left to right, their names are Benjamin Granados, Thomas Clark, Andreas Eberhart, Juan Cruz Viotti, and Ben Hutton."/>
    <figcaption class="text-center text-gray-600 text-sm">Community members at the standards booth shared with AsyncAPI, OpenAPI, and GraphQL. From left to right: Benjamin Granados (community manager), Thomas Clark (Octue CEO), Andreas Eberhart (JSON Schema ambassador), Juan Cruz Viotti (TSC member), and Ben Hutton (TSC member).</figcaption>
</figure>
<br>

[Ten comprehensive presentations](https://conference.json-schema.org/sessions/) spanned the spectrum of JSON Schema applications, from foundational concepts to cutting-edge implementations. The list of talks included:

- JSON Schema for data design and contract, client and code generation by Tom Collins (DVLA, UK Gov)
- IEC standards: Toward digital standards with JSON Schema by Thomas Clark (Octue CEO, conference sponsor)
- Introducing Strands - a JSON Schema repository by Thomas Clark
- JSON Schema: powering FINOS architecture as code by James Gough (Morgan Stanley)
- Generic and extensible web of things manager using JSON Schema and AI by Andreas Eberhart (Dashjoin, JSON Schema ambassador)
- High-performance JSON Schema validation in .NET by Matthew Adams (Endjin, TSC member)
- JSON schema and relational databases: bridging the gap by Loic Lefèvre (Oracle)
- Applying software engineering practices to JSON Schemas by Juan Cruz Viotti (Sourcemeta CEO, TSC member)
- The state of JSON schema by Benjamin Granados (Celonis, TSC member)
- Unlocking dynamic frontend development through JSON Schema by Neha Singla (Apple)

Three major themes recurred throughout the track: data design and standardization, tooling infrastructure, and modern application integration. Particularly notable was the emphasis on JSON Schema's role in AI integration and automated API development, aligning perfectly with the broader conference focus on AI's increasing importance in the API landscape.

Octue's sponsorship significantly bolstered the track's success, demonstrating their commitment to the JSON Schema community. This support enabled a diverse range of speakers to share their expertise and experiences.

Audience engagement exceeded expectations. Attendees from various industries and organizations - such as fintech, renewable energy, IT, and government - participated in robust Q&A sessions after each presentation. The discussions revealed both the growing adoption of JSON Schema across different sectors and the community's hunger for more knowledge about its practical applications.

<figure className='flex flex-wrap justify-center items-center gap-4 w-full'>
    <img className='max-w-400 px-20' src='/img/posts/2024/apidays-paris-2024-recap/loic-lefevre-talk.jpg' alt="Loic Lefevre presenting on stage at the APIDays Paris 2024 conference. The audience is seated in rows of chairs, facing the stage."/>
    <figcaption class="text-center text-gray-600 text-sm">A room full of people listening to Loïc Lefèvre’s engaging presentation on utilizing JSON schemas to manage relational databases.</figcaption>
</figure>
<br>

Looking ahead, this first dedicated track has laid a strong foundation for future JSON Schema events. The feedback highlighted the need to further showcase JSON Schema's versatility across different use cases, and plans are underway to expand and enhance next year's track. This successful launch not only validates JSON Schema's importance in modern API development but also signals the beginning of a new chapter in the community's growth and evolution.

## Collaboration with organizations

The success of the JSON Schema track at apidays Paris 2024 highlighted the vital role of community collaboration in our growth. It also demonstrated how organizations collaborating with JSON Schema gain more than just visibility - they become part of a broader movement toward standardized, high-quality API development. 

Here's how your organization can benefit:
- **Standardization & interoperability**: Ensure seamless data exchange and API integration.
- **Improved data quality**: Minimize errors with robust data validation.
- **Enhanced API design**: Streamline development with clear and concise schemas.
- **Increased productivity**: Automate tasks and boost efficiency with JSON Schema tools.
  
Here’s how you can become part of the initiative:
- [Be an ambassador](https://github.com/json-schema-org/community/tree/main/programs/ambassadors): Share your JSON Schema expertise and champion its adoption.
- [Become a sponsor](https://json-schema.org/overview/sponsors): Gain visibility and support the standard's growth.
- [Contribute to the project](https://github.com/json-schema-org): Help us shape the future of JSON Schema development.
- [Join our Slack workspace](https://json-schema.org/slack): Connect with the vibrant JSON Schema community.


Together, we can build a more robust and interoperable API ecosystem. 

A final thank you to Octue for sponsoring the conference, apidays Paris for hosting it, the organizers for their dedication and hard work, and the attendees for your valuable input and insightful questions. On behalf of JSON Schema, we look forward to seeing you again next year!

Acknowledgments: The author would like to thank Onyedikachi Hope, Ben Hutton, and Benjamin Granados for their valuable feedback, which enhanced the quality of this article. 


Valeria Hernandez

JSON Schema conference: A milestone event at Apidays Paris 2024


## The JSON Schema documentation project

The main goal of JSON Schema's [documentation project](https://github.com/orgs/json-schema-org/discussions/687) is to create a scalable documentation architecture that is clear, consistent, and comprehensive. To achieve this through Google Season of Docs (GSoD), we focused on:

- **[Restructuring the specification docs](https://github.com/json-schema-org/website/pull/823)**: The specification docs need a structure that helps all [personas](https://github.com/json-schema-org/community/issues/336#personas) understand how JSON Schema has evolved across different releases and the features introduced in each version.
- **[Revamping the information architecture](https://github.com/json-schema-org/website/issues/790)**: The documentation needs a new information architecture that better aligns with the [documentation developer journey](https://www.figma.com/board/TRjQUw33K93y8RlJMSRkJs/JSON-dev-journey?node-id=0-1&t=fF2pJ8IwpJvbFzDU-1) and organizes content based on the [diataxis framework](https://diataxis.fr/). The new information architecture's goal is to improve the onboarding experience and content findability.

## The GSoD project accomplishments

Since May, the team ([Valeria Hernandez](https://www.linkedin.com/in/valeriahhdez/), [Blessing Ene Anyebe](https://www.linkedin.com/in/anyebe-blessing-ene-kwennb/), [Dhairya Amrish Majmudar](https://www.linkedin.com/in/dhairya-majmudar/), and [Benjamin Granados](https://www.linkedin.com/in/benjagranados/)) has been working hard to achieve these goals. On the part of documentation, we have completed the following: 

- Conducted a thorough content audit
- Mapped out the [developer experience journey](<(https://www.figma.com/board/TRjQUw33K93y8RlJMSRkJs/JSON-dev-journey?node-id=0-1&t=gYkdGtHk2sKrCQM0-0)>)
- Implemented the [keywords page](https://json-schema.org/understanding-json-schema/keywords)
- Restructured the [specification docs](https://github.com/json-schema-org/website/pull/823)

The team has also introduced changes to the website, like a table of contents and a [Next-Previous](https://github.com/json-schema-org/website/pull/807) component that aim to improve content scannability and navigation. 

## The road ahead

So, what's pending? We're currently working on the [JSON Hyper-Schema](https://github.com/json-schema-org/website/issues/896) and [Migration pages](https://github.com/json-schema-org/website/issues/897), which are part of the specification docs. 

We're also documenting [guidelines for docs contributions and text formatting](https://github.com/json-schema-org/website/pull/902), documenting missing keywords (see issues [951](https://github.com/json-schema-org/website/issues/951), [952](https://github.com/json-schema-org/website/issues/952), and [961](https://github.com/json-schema-org/website/issues/961)), and writing step-by-step guides (see issues [180](https://github.com/json-schema-org/website/issues/180), [950](https://github.com/json-schema-org/website/issues/950), and [954](https://github.com/json-schema-org/website/issues/954)). 

## Conclusion

Our documentation efforts are expanding daily, and your contributions can improve them. There are several ways you can help, including:

- Breaking down large documents to improve the overall structure of the documentation website
- Creating missing documentation for the Troubleshooting and Scaling stages of the developer journey
- Contributing to the Migration page

Our docs meeting is held bi-weekly every Tuesday at 3:00 PM (UTC). You're welcome to join the #gsod24 channel in the JSON Schema [Slack workspace](https://json-schema.org/slack) and send us a message with your email address so we can add you to the meeting.

We appreciate your interest in the JSON Schema documentation project and look forward to your contributions and their benefits to the wider developer community.

**The JSON Schema's Google Season of Docs Team.**

Photo by <a href="https://unsplash.com/@miinyuii?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Duy Pham</a> on <a href="https://unsplash.com/photos/people-holding-shoulders-sitting-on-wall-Cecb0_8Hx-o?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>
  

Blessing Ene Anyebe

Dhairya Amrish Majmudar

Benjamin Granados

Update from the Google Season of Docs 2024 Project


## Ambassadors program?

You may have noticed our new Ambassadors Program! If not, don't worry—we're here to explain what it is and how you can get involved.

I'm personally very excited to see this program come to life. Recognizing our community champions in a meaningful and sustainable way has always been a goal. The Ambassadors Program is our first step in publicly supporting our most experienced and helpful members.

We have many community members who frequently help others, provide feedback, answer questions, and debug schemas and code. They also assist newcomers in avoiding basic misconceptions. JSON Schema wouldn't be where it is today without this support.

## The time is right - we are growing

For the past few years, a small team has worked full time on JSON Schema, focusing on ongoing projects. Now, we have the capacity to launch new initiatives, including this Ambassadors Program. We want to better recognize and support those who are giving back to our community.

We are better placed today than we ever have been to support and empower our existing ambassadors, and build a program which recognizes and supports them to further their efforts. It's always encouraging to see others as excited about JSON Schema as you are.

<Regularquote>
  _"The new website, and assorted outreach programmes have started to connect the huge JSON Schema user base, and we've really started to see the benefit in terms of the number of people actively participating." - **Matthew Adams** - Founder at [Endjin](https://endjin.com) - Candidate Ambassador._
</Regularquote>

## How we benefit, from today

When thinking about our programs, two aspects we should consider are how they will impact the project overall, and the community. These are not the only aspects, but ones I want to touch on in this context.

### As a Project

Having ambassadors not only recognizes individual contributions but also benefits JSON Schema. It will increase visibility and encourage positive community engagement.

Despite JSON Schema's presence, many still see it as part of another standard. By promoting JSON Schema through various channels, we enhance its recognition and usage. This increased visibility can attract more sponsorships, funding further programs like the Ambassadors Program and fostering a better ecosystem. It's a positive cycle; once we start, momentum will help us grow.

As the project thrives, so too does our community. The Ambassadors Program brings several benefits specifically for our community.

<Regularquote>
  _"The community is very friendly, welcoming, and extremely smart. I already learnt a LOT by participating in it. I want the JSON Schema ecosystem to grow, as it will likely power my business as a result. The Ambassadors Program is a great opportunity to recognise key contributors and encourage them to continue being involved." - **Juan Cruz Viotti** - Founder and CTO at [Intelligence.AI](https://intelligence.ai) - Candidate Ambassador_
</Regularquote>

### As the Community

The project and the community both benefit from the Ambassadors Program. Ambassadors will contribute valuable content, enhancing learning and engagement. To keep their ambassador status each year, ambassadors will be expected to make a number of contributions that benefit the community, such as articles, videos, podcasts, or even talking or running a workshop at a conference.

Given the prominence of the ambassadors, we will, collectively, check any and all published work they produce, making sure it's accurate. If you work with code, you've probably seen your fair share of poorly documented projects, and you know the impact that can have. High-quality, up-to-date content makes it easier for both newcomers and veterans to learn and stay current.

Further, we don't require or even expect that all the content ambassadors produce will go onto the project's website. No. There's actually improved reach by ambassadors using their existing channels to reach their community, hopefully expanding the JSON Schema community in addition to educating other spaces.

## A portrait of an Ambassador

We've long planned the Ambassadors Program and have identified initial candidates. (You can nominate yourself or others!) Here are the qualities we seek in ambassadors.

Firstly, an ambassador has to be with the community. This means in the slack server, on Github, and occasionally on calls or other places representing or being a recognised expert or source of knowledge for JSON Schema.

Critically, we expect ambassadors to be aligned with the JSON Schema project's mission and values, be respectful of our code of conduct, and continue to be active in the community.

## Recognising our Ambassadors from the community

We easily identified several community members to invite into the Ambassadors Program. The TSC and the Community Team spend a LOT of time in our community spaces, so even if we don't always reply or comment, we do notice those who are active and helpful.

When I first started the JSON Schema Slack server, the numbers were very few. Gradually, it grew. The core team answered most of the questions. I recall the feeling when I came back in the morning to find other people had answered questions from the community while I'd been asleep. I've previously [recognised](https://words.benhutton.me/2023-05-23-two-words-big-win) that saying "thank you" can be a big win, but I also know that we can do several magnitudes better.

We already have several members of our community who have become ambassadors for JSON Schema, just without any sort of formal recognition. Recognising, supporting, and further enabling these individuals, and new ambassadors, is going to have a positive impact, and I can't wait to see what it unlocks for JSON Schema in the future.

There's a swag kit for all accepted into the Ambassadors Program, and I can't wait to meet the individuals excited and proud to be wearing the exclusive swag at events and conferences in the future. We see you, ambassadors!

## How to apply today

OK, OK. If you've read all the above, maybe you haven't yet made it to the [Ambassador Program documentation](https://json-schema.org/ambassadors) file in our community repo. That would be your next stop if you're thinking about applying to become an ambassador.

We will be looking for existing contributions from individuals who have already been in our community for a while. If you're brand new to JSON Schema, becoming an ambassador is probably not something immediately in your reach, and that's OK. If you have some experience with JSON Schema, go write about it, apply to talk at events and conferences, or make videos. Be part of our community, answer questions. Then your application is much more likely to be accepted.

As I mentioned, we have a number of people in mind already, and I'd love to introduce a few of them to you today. If you're in our community spaces, you've probably seen them around.

"As a small team ourselves at Endjin, we live by the mantra 'helping small teams achieve big things'. I believe we can have a disproportionate positive impact by working on JSON Schema as it is so widely adopted, across so many different disciplines and industry verticals." - Matthew Adams

"JSON is the world's most popular data format, and it's impossible to not work with it in some way or another. Once you want to embrace JSON, JSON Schema is the most powerful and expressive schema language for it, elegantly enabling a wide variety of use cases." - Juan Cruz Viotti

## You (yes, you!) can help support and expand Ambassadors and other programs

If this program sounds great and you want to support it, you can! Being part of our community is a great first step. Our Slack server may sometimes get busy, but you could mute it and only get notified of announcements, if you wanted. We actively use and monitor GitHub Discussions, so if Slack isn't your thing or you have one too many already, that's going to be a space for you. We're also more active on LinkedIn over this past year, and it seems to be increasing in popularity with professionals; We love to hear how JSON Schema is used in industry.

Sharing content from the JSON Schema project and community promotes growth and enhances your professional credibility. With ambassadors contributing more content, they may even seek ideas from you!

We are sending out swag at our expense, and we have a little money saved in our Open Collective budgeted and set aside for doing so. However, we would love to be able to support ambassadors to cover the expenses involved in getting to the larger conferences, including our own in the future. If your organization supports open source projects, please consider financial donations, especially if you use JSON Schema in production. We also support GitHub Sponsors.

If that's easy, great, but we do appreciate it's not always attainable. What might be more possible is to get your organization added to our Adopters list. You can read all about that in our community repository.

I'm thrilled to see our Ambassadors Program get off the ground, and I'm positive it will have a really impactful effect on the project, the community, and the ambassadors that take part. Join us, get involved, and let's see what we can achieve together!

Photo by <a href="https://unsplash.com/@goian?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Ian Schneider</a> on <a href="https://unsplash.com/photos/two-person-standing-on-gray-tile-paving-TamMbr4okv4?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>


Welcome to the
JSON Schema Community

Join the Community to learn, share ideas, ask questions, build JSON Schema tooling, and get involved in the future of the specifications.

Ambassadors Program

The JSON Schema Ambassadors Program recognize the people who drive adoption, innovation and knowledge sharing in the JSON Schema community.

Join the JSON Schema Slack workspace!

Join our Slack to ask questions, get feedback on your projects, and connect with +5000 practitioners and experts.

JSON Schema Community Meetings & Events

We hold monthly Office Hours and weekly Open Community Working Meetings. Office Hours are every first Tuesday of the month at 15:00 BST, and by appointment. Open Community Working Meetings are every Monday at 14:00 PT.

Upcoming events

Welcome to
the JSON Schema Blog!

Want to publish a blog post? Check out the guidelines and submit yours!

Celebrating JSON Schema’s Google Summer of Code 2024 Journey

Welcome to theJSON Schema Community

Join the Community to learn, share ideas, ask questions, build JSON Schema tooling, and get involved in the future of the specifications.

Ambassadors Program

The JSON Schema Ambassadors Program recognize the people who drive adoption, innovation and knowledge sharing in the JSON Schema community.

Join the JSON Schema Slack workspace!

Join our Slack to ask questions, get feedback on your projects, and connect with +5000 practitioners and experts.

JSON Schema Community Meetings & Events

We hold monthly Office Hours and weekly Open Community Working Meetings. Office Hours are every first Tuesday of the month at 15:00 BST, and by appointment. Open Community Working Meetings are every Monday at 14:00 PT.

Upcoming events

Welcome tothe JSON Schema Blog!

Want to publish a blog post? Check out the guidelines and submit yours!

Celebrating JSON Schema’s Google Summer of Code 2024 Journey

Welcome to the
JSON Schema Community

Welcome to
the JSON Schema Blog!