docs(community): update latest community documentation

config/edit-page-config.json

@@ -22,5 +22,9 @@
   {
     "value": "community/onboarding-guide",
     "href": "https://github.com/asyncapi/community/tree/master/docs/onboarding-guide"
+  },
+  {
+    "value": "community/styleguide",
+    "href": "https://github.com/asyncapi/community/tree/master/docs/styleguide"
   }
 ]

markdown/docs/community/onboarding-guide/ambassador-guide.md

@@ -0,0 +1,41 @@
+---
+title: Onboarding Guide for AsyncAPI Ambassadors
+weight: 110
+---
+
+
+Welcome to the AsyncAPI Ambassador Program! 
+
+We are happy you chose to join the ambassador program and make valuable contributions to promote AsyncAPI.
+
+Your tenure as an ambassador begins on the date you are accepted and shall be renewed annually. For example, if you were accepted as an ambassador on January 11, 2025, your tenure would end on January 10, 2026. At the end of your tenure, we will review your performance to determine if you can continue as an ambassador.
+
+
+As an ambassador, you are expected to make a minimum of four contributions per year. Contributions can include articles, talks, videos, podcasts, driving initiatives, and more.
+
+- Articles, videos, and podcasts can be published on the [AsyncAPI blog](https://www.asyncapi.com/blog) or other platforms. Please note that we do not encourage blogs or articles that promote/market certain other products or tools.
+- Talks and presentations should focus primarily on AsyncAPI.
+- Contributions to improve the visibility of the community.
+- Volunteering at booths during events.
+
+
+Examples:
+- If you publish three articles and propel one initiative about AsyncAPI in eight months, you will become an ambassador for the whole year.
+- If you make one presentation, write two articles, and propel one initiative about AsyncAPI, you will become an ambassador for the whole year.
+
+
+
+### Ambassador duties
+- Be in tune with AsyncAPI's mission and values.
+- Always respect the [code of conduct](https://github.com/asyncapi/.github/blob/master/CODE_OF_CONDUCT.md).
+- Be active in your role as an ambassador.
+
+### Ambassador benefits
+- Invitation to [AsyncAPI Initiative organization](https://github.com/orgs/asyncapi/people).
+- A special swag pack for Ambassadors.
+- Free entry to AsyncAPI conferences.
+- Community-wide recognition.
+- Our sincere gratitude and respect for your contributions!
+
+### Additional resources
+[AsyncAPI Ambassador Program](https://github.com/asyncapi/community/blob/master/AMBASSADOR_ORGANIZATION.md)

markdown/docs/community/onboarding-guide/maintainer-guide.md

@@ -0,0 +1,71 @@
+---
+title: Onboarding Guide for AsyncAPI Maintainers
+weight: 100
+---
+
+
+Welcome to the AsyncAPI Maintainer Onboarding Guide! 
+
+This document aims to provide comprehensive guidelines about everything you need to know to begin your journey as a maintainer within the AsyncAPI ecosystem. Maintainers are the backbone of any open-source project, helping with different activities that help the project stay on track and foster a healthy, productive community.
+
+Before we go into getting you started, let's try and clarify just *who* a maintainer is.
+
+## Who is an AsyncAPI Maintainer?
+
+A maintainer is an individual who plays a crucial role in overseeing and guiding the development and growth of an open-source project. As a maintainer for AsyncAPI, you'll be responsible for:
+
+- Overseeing the technical direction of the project
+- Helping with reviewing and resolving issues and pull requests (PR)
+- Managing workflows and GitHub Actions to automate tasks
+- Enforcing coding standards
+- Enforcing relevant and up-to-date documentation
+- Identifying and appointing new maintainers
+- Mentoring new contributors and helping them navigate their journey
+- Recognizing and rewarding contributions to foster community engagement
+
+But being a maintainer goes beyond these responsibilities—it’s about **ownership** and **leadership**. You’re not just merging code; you’re shaping the project’s future. This means stepping up to unblock contributors stuck on a PR, advocating for improvements in the roadmap, or leading releases to ensure smooth deployments. You’ll proactively identify risks, mediate discussions to align decisions with AsyncAPI’s vision, and celebrate wins to keep the community motivated.  
+
+Maintainers also **lead by example**. You’ll mentor others not just by answering questions but by teaching contributors *why* coding standards matter or *how* to structure a feature. You’ll balance technical rigor with empathy, ensuring decisions serve both the project’s goals and its people.  
+
+Essentially, you serve as a person who binds the project together and guarantees that everything runs smoothly.
+
+## Steps to becoming a Maintainer
+
+Before you can become a **maintainer**, you need to start as a **contributor**. The journey from contributor to maintainer is a rewarding one, and it involves the following steps:
+
+### 1. **Pick an Issue**
+
+- **Join existing PR reviews**: If you're not sure where to start, begin by reviewing open [PR](https://github.com/pulls?q=is%3Aopen+org%3Aasyncapi+sort%3Aupdated-desc+archived%3Afalse+) within the organization. This will give you a high-level understanding of the projects and where your contributions might fit in.
+
+- **Look for "*good first issue*" labels**: These [issues](https://github.com/issues?page=1&q=is%3Aopen+org%3Aasyncapi+sort%3Aupdated-desc+label%3A%22good+first+issue%22) are beginner-friendly and will help you get familiar with the project’s structure. Additionally, you can check out the [#97_bot-github-new-issues-prs](https://asyncapi.slack.com/archives/C01J06RL10X) channel on Slack for new issues and PRs.
+
+- **Participate in live streams**: AsyncAPI maintainers sometimes host [live streams](https://www.asyncapi.com/community/events) where they walk through parts of the project. You can request a session on the specific area you want to contribute to.
+
+> [!NOTE]
+> Make sure whatever issue you pick isn't marked "Do-not-merge," or else your PR won't be merged.
+
+### 2. **Open a PR**
+
+For a comprehensive guide on how to create a fork and start contributing, refer to the [AsyncAPI Git Workflow Guide](https://github.com/asyncapi/community/blob/master/git-workflow.md).
+
+- **Fork the repository**: Fork the repository you want to contribute to and create a new branch for your changes.
+
+- **Make changes**: Implement the changes required to resolve the issue you picked. Ensure your code adheres to the project’s coding standards.
+
+- **Submit a PR**: Once you’re done with the changes, submit a PR to the main repository. Make sure to include a detailed description of your changes.
+
+- **Participate in discussions**: Engage with maintainers and other contributors in the PR comments section. This will help you understand the project better and improve your contributions.
+
+### 3. **Get your PR merged**
+
+- **PR review process**: After submitting a PR, maintainers need to review it.
+
+- **Contact maintainers**: If a PR is not being reviewed (which is rare) or needs urgent review, contact maintainers on Slack or GitHub.
+
+- **Ensure smooth merge**: Ensure all checks (tests, style checks, etc.) pass before merging your PR.
+
+### 4. **Receive an invitation to become a Maintainer 🎉**
+
+- **Recognition**: After contributing consistently and demonstrating leadership — whether through code, reviews, mentorship, or strategic input — the maintainers will invite you to join the team. This invitation is a recognition of your ownership and dedication to AsyncAPI’s success.
+
+- If you haven't received an invitation despite contributing consistently, you can open an issue in the corresponding repository to discuss your contributions with the maintainers. You can see an example of such an issue [here](https://github.com/asyncapi/cli/issues/1616). 

markdown/docs/community/styleguide/_section.md

@@ -0,0 +1,4 @@
+---
+title: Style guide
+weight: 5
+---

markdown/docs/community/styleguide/accessibility.md

@@ -0,0 +1,43 @@
+---
+title: Accessibility
+description: This style guide explains how to include accessibility in the documentation.
+weight: 20
+---
+
+# Accessibility
+
+At AsyncAPI, we strive to make our documentation/content inclusive, accessible, and unbiased to everyone. We encourage all contributors to have diversity and inclusivity in mind when writing. To ensure this, we have provided an overview of general guidelines to follow that will help you write inclusive and accessible documents.
+
+## Language
+- Be clear and concise when writing. Avoid the use of complex language, technical jargon, and verbose explanations.
+- Keep paragraphs and sentences short, simple, and to the point.
+- Keep your sentences as crisp as possible, avoid having nested sentences. 
+- Always maintain a uniform structure. Use descriptive headings and subheadings to make navigation easy.
+- Use inclusive language and always keep the reader in mind when writing. 
+
+
+## Text
+- Use the appropriate heading hierarchy. H1 is used for the main heading while H2 to H6 are used for subsection headings. 
+- Properly align text for easy readability.
+- Avoid using camel case or any unnecessary fonts and formatting.
+- Define acronyms or abbreviations and always spell out any signs or symbols.
+- Structure your text in a uniform format. 
+
+## Links
+- Use descriptive and meaningful link text. For example, do not use phrases like *click here* or *follow this link* instead use *Read the accessibility guidelines* or *Explore best practices for inclusivity*.
+- Always use an external link icon if a link opens up in a new tab.
+- Make sure your links or URLs are valid and redirect to the correct/desired destination.
+
+## Multimedia
+- Alt text must be clear and descriptive. Not more than 50 characters.
+- Always use text rather than images, unless necessary.
+- Use SVG instead of PNG or JPEG. It retains quality.
+- Provide transcripts and captions for video content.
+- Make sure your captions can be translated into various languages.
+- Avoid auto-playing media, always provide controls.
+
+## UI 
+- Use the correct terminologies for UI elements.
+- Format tables correctly and keep the text within the grid.
+- Use basic HTML for button elements.
+- Add icons to describe a function. Use the aria-label attribute when unsure of the icon name.

markdown/docs/community/styleguide/content-buckets.md

@@ -0,0 +1,24 @@
+---
+title: Content Buckets
+Description: This style guide explains how and why we use content buckets in documentation.
+weight: 30
+---
+
+# Content Buckets
+To structure our documentation, we adopt a systematic approach from the Diátaxis framework. We ensure our docs are presented in a manner that is easy to understand by organizing and classifying them into content buckets.
+
+![Diátaxis framework](https://www.asyncapi.com/img/posts/changes-coming-docs/diataxis.webp)
+
+> Documentation structure based on the [Diátaxis framework](https://diataxis.fr/).
+
+At AsyncAPI our docs are classified into the following content buckets:
+
+- **Concepts** - This section is where we define various features and capabilities AsyncAPI offers. All docs pages under this bucket need to be accurate, easy to understand and accompanied by an engineering diagram. We utilize [Mermaid.js](https://mermaid.js.org/) syntax to create diagrams and visualizations.
+
+- **Tutorials** - Our tutorial section offers practical guidance to individuals who are beginners or new to AsyncAPI. Docs under this content bucket need to be hands-on and provide step-by-step guidance using real-world examples. The docs should be engaging and interactive to help users develop the required knowledge.
+
+- **Guides** - The guides section teaches individuals about higher-level AsyncAPI features. Content under this bucket helps users gain a deeper understanding and provide different ways to solve a problem. The tone should be concise. 
+
+  *You can think of guides as a recipe for cooking a meal.* 
+
+- **Reference** - This section provides detailed technical information about the specification. Under this bucket, you'll find release notes, API and internal documents such as function definitions and parameter descriptions. References need to be precise, straight to the point and accurate.

markdown/docs/community/styleguide/formatting.md

@@ -0,0 +1,93 @@
+---
+title: Formatting
+description: This guide illustrates the standards for formatting and writing our documentation.
+weight: 110
+---
+
+## Documentation formatting
+
+Documentation formatting refers to how the document appears on the page and how the content is organized, which includes font selection, font size, and presentation (such as bold or italics), spacing, margins, alignment, columns, indentation, and lists. Formatting helps the reader perceive the information and makes it more accessible. 
+
+### Notes and warning blocks
+
+Notes and warning blocks are used to draw attention to important information. Use the following markdown features when necessary:
+
+- Use a clear and concise heading to introduce the note or warning.
+- Use short paragraphs or bullet points to convey the information.
+- Keep the language simple and direct.
+- Use an `>` in markdown to indicate the nature of the note or warning. 
+- Use the following syntax to apply a style. Currently our documentation supports **Remember** `<Remember>`:
+  * Surround the text you want to style with an opening <Remember> tag and a closing </Remember> tag.
+  * Note that the word 'Remember' does not need to be included within the tags, as it automatically provides the necessary styling.
+  * Use the following syntax to apply a style:
+  ` <Remember> 
+  No need to add a prefix; the tag automatically provides one
+  </Remember>`
+
+  The output: 
+  <Remember> 
+  No need to add a prefix; the tag automatically provides one
+  </Remember>
+
+## Code blocks
+
+Code blocks are used to display code examples or snippets. 
+
+- In a Markdown document, use the `<CodeBlock>` tag and specify the language.
+  Use the following syntax to apply a code block:
+  ```
+  <CodeBlock language="bash">
+  {`npm start`}
+  </CodeBlock>
+  ```
+
+  The output:
+
+  <CodeBlock language="bash">
+  {`npm start`}
+  </CodeBlock>
+
+- Use code style for filenames, directories, and paths. For example: Go to the `/docs/tutorials` directory.
+- Choose a consistent number of spaces for indentation, such as 2 or 4 spaces, and use it consistently throughout the document.
+- Indent the code properly to show its structure and hierarchy. Each level of indentation should align with the appropriate scope.
+- Avoid using tabs for indentation, as they may not render consistently across different platforms or text editors.
+For example, when writing code in Markdown, use four spaces for each level of indentation:
+```
+function myFunction() {
+    if (condition) {
+        console.log("Condition is true.");
+    } else {
+        console.log("Condition is false.");
+    }
+}
+```
+- Use single backticks to enclose inline code. For example, `asyncapi new --example=tutorial.yml --no-tty`
+- Remove any trailing spaces in the code. Trailing spaces can disrupt the readability and formatting of the code, so ensure they are removed.
+- Use triple backticks to enclose YAML code blocks. Specify the language as "yaml" within the backticks. This syntax is specifically for displaying code blocks that contain YAML content.
+  * Use this syntax:
+  ` ```yaml
+  asyncapi: '3.0.0'
+  info:
+  title: Account Service
+  version: 1.0.0
+  ``` `
+
+  * The output:
+  ```yaml
+  asyncapi: '2.5.0'
+  info:
+  title: Account Service
+  version: 1.0.0
+  ```
+
+## Spacing
+
+Line spacing, or the vertical space between lines of text in a paragraph, can aid or hinder reading. Adequate line spacing helps readers navigate from the end of one line to the start of the next.
+
+- Leave a blank line between paragraphs to visually separate them. This helps readers distinguish between different sections of content.
+- For headings and subheadings, leave a blank line before and after them to provide clear visual separation.
+- Leave a single line spacing after bullet points or numbered lists to enhance readability.
+- Use consistent indentation to show the hierarchy of the content.
+- Indentation can be achieved with either 2 or 4 spaces, depending on your preference or the coding style guidelines of your project. Choose one and use it consistently throughout the document.
+- Use indentation to show nested content, such as code blocks, lists, or paragraphs within a list item.
+- Indent code blocks by an additional indentation level to differentiate them from regular text.