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/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.

markdown/docs/community/styleguide/inclusive-language.md

@@ -0,0 +1,80 @@
+---
+title: Inclusive Language style guide
+description: This style guide outlines the guidelines for using inclusive language in documentation.
+weight: 60
+---
+
+# Inclusive Language
+
+While writing documentation, we are directly speaking to thousands of people all around the globe. 
+Thus, we must ensure our diverse audience can connect with our information. 
+
+## 1. Culturally inclusive language
+
+Certain phrases and words are commonly used in specific regions of the world. Avoid using region-specific language in the documentation. 
+Some examples of region-specific language are -
+- “It’s not rocket science” is commonly used in the USA, and non-US people might not be able to relate to it as intended.
+- Phrases written in regional languages instead of English.
+- “It’s a piece of cake” is commonly used in the USA, and non-US people might be unable to relate to it as intended.
+- Terms like "gypsy" is considered derogatory in Romani community, "eskimo" is considered offensive in artic community.
+- Terms like "tipping point" is considered offensive in African American cultures.
+
+## 2. Gender neutral language
+
+Some phrases and words target men or men/women specifically, resulting in other gender groups feeling left out while reading our documentation. Using only male pronouns also make women in technology feel excluded or overlooked.
+Similarly, we should also try to include nonbinary groups of people in our writing.
+Some examples of gender-neutral language are -
+- Using “they/them” instead of “his/him” or “she/her”.
+- Using “Hello everyone” instead of “Hello guys”.
+- Using “Chairperson” instead of “Chairman” or “Chairwoman”.
+- Using "people", "guests" or "folks" instead of "ladies and gentlemen".
+- Using "Mx" or "Ms" instead of using "Mr" or "Mrs".
+- Using "humankind" instead of "mankind".
+- Avoid using stereotypes such as linking "male" with "strength", "women" with "care work", or "male homosexuality" with "sensitivity".
+
+## 3. Accessibility and Disability 
+
+The placement of the word “People” matters a lot when writing documentation. 
+Using the word “People” in the beginning makes it more pleasant as the problem is not displayed initially.
+The phrasing of sentences should not be in a manner that depicts Ableism or discrimination against individuals with disabilities or 
+the assumption that people with disabilities are inferior to those without disabilities.
+
+Some examples of gender-neutral language are -
+- Using “People with a mental health condition” instead of “Mentally Unstable People”.
+- Using “Deaf” instead of “Person with deafness”.
+- Using "People with a disability" instead of "Disabled people".
+- Using "Wheelchair Users" instead of "Wheelchair bound".
+- Using "People experiencing homelessness" instead of "Homeless people"
+- Avoid using derogatory terms that refer to people with disabilities like "crazy", "retarded", spaz, and "lame".
+- Try using phrases like "overlook" or "ignore" instead of "turn a blind eye", or using "unheard" or "unnoticed" instead of saying "falling on deaf ears".
+
+## 4. Slang-free language 
+
+While framing the documentation, we must ensure that we are not including any vulgar language, even if it is included indirectly in our work. We should be mindful of inadvertently including slang words within phrases that may have unintended or inappropriate connotations.
+Some examples include -
+- Using “simple” or “easy" instead of “no-brainer”.
+- Using "simple" or "straightforward" instead of "easy-peasy".
+- Avoid using any racist, sexist, or any discriminatory language like "stupid" or "retarted".
+- Use "easy" or "simple" instead of "piece of cake".
+- Using "excellent" or "impressive" instead of "dope"
+
+## 5. Ageism-free language   
+
+When constructing the documentation, avoiding words or phrases that may disproportionately emphasize a specific age group is important, as this can make other age groups feel excluded.
+Some examples include -
+- Avoid mentioning the exact age like “60 years” old.
+- Using "experienced" instead of "old-timer"
+- Avoid phrases like "you are too old to understand" or "you are too young to understand"
+- Using “lively” instead of “young”.
+- Avoid making assumptions about a person's abilities or interests based on their age, like assuming an older adult will not be tech-savvy.
+
+## 6. Knowledge level assumption-free language
+
+While building the documentation, we should always ensure that we don’t presume the knowledge level of the readers. 
+Assuming that our readers are highly skilled or have advanced experience, we might inadvertently skip explaining or linking some important concepts. Also, we should avoid labelling some steps as “easy” 
+because this might make some readers question their technical abilities.
+Some examples include -
+- Using “fixing the navbar is good to start with” instead of “fixing the navbar is very easy”.
+- Linking complex topics that most of our audience won’t understand.
+- Avoid phrases like "As you already know, the Fourier series is a mathematical method used to represent periodic functions."
+- Avoid including phrases like "You're probably familiar with the concept of compound interest so that I won't go into too much detail about it."

markdown/docs/community/styleguide/punctuation.md

@@ -0,0 +1,78 @@
+---
+title: Punctuation style guide
+description: The style guide outlines the guidelines for using punctuation in the documentation.
+weight: 100
+---
+
+# Punctuation
+
+Writing documentation is important because it allows us to communicate indirectly with many people around the world. Punctuation is a crucial part of writing because it helps us make our message clear and consistent. To ensure our documents follow the same standards and are consistent with others in the industry, it's important to use the style guides that have already been recognised.
+
+## 1. Period (.)
+
+Use a Period to end a declarative sentence or a statement.
+Some examples include:
+- "I went to the store."
+- "The cat is sleeping."
+
+## 2. Comma (,)
+
+Use a Comma to separate items in a list (including the Oxford comma).
+Some examples include:
+- "She bought apples, oranges, and bananas."
+- "He went to the store, picked up some milk, and returned home."
+
+Note: The **Oxford comma** is the optional comma before the conjunction in a list of three or more items. Its usage can vary based on style guides or personal preference.
+
+## 3. Semi-colon (;)
+
+Use a semicolon to separate two independent clauses that are closely related but could be separate sentences.
+Some examples include:
+- "She finished her work; then she went home."
+- "I need to buy groceries; I'm running out of food."
+
+## 4. Colon (:)
+
+Use a Colon to introduce a list, explanation, or an example.
+Some examples include:
+- "Please bring the following items: a pen, a notebook, and a calculator."
+- "There are three primary colours: red, blue, and yellow."
+
+## 5. Dash (— or -)
+
+An em Dash (—) indicates a sudden break or interruption in a sentence or provides emphasis.
+Some examples include:
+- "She went to the store—despite the rain—to buy some groceries."
+- "She received an unexpected gift—a brand new car!"
+
+A **hyphen** (-) joins compound words or prefixes.
+Example:
+- "The well-known actor starred in the movie."
+
+## 6. Question Mark (?)
+
+Use a Question mark at the end of a direct question.
+Some examples include:
+- "What time is the meeting?"
+- "What is your favourite movie?"
+
+## 7. Exclamation Point (!)
+
+Use an Exclamation point to show strong emotion, emphasis, or surprise.
+Some examples include:
+- "Congratulations on your success!"
+- "Happy birthday!"
+
+## 8. Quotation Marks (" ")
+
+Use Quotation marks to indicate direct speech or to enclose a quote.
+Some examples include:
+- She said, "I will be there by 5 o'clock."
+- He asked, "Can you lend me a hand?"
+
+## 9. Ellipsis (...)
+
+Use an Ellipsis to indicate the omission of words or a pause in speech.
+Some examples include:
+- "I can't believe you..."
+- "The best is yet to come..."