chore: add community files (not to be merged)

pages/docs/community/README.md

@@ -0,0 +1,3 @@
+## Community Documentation
+
+The community documentation directory helps the community collaboratively maintain a collection of helpful community-related documentation. From becoming an AsyncAPI contributor to becoming a TSC member, and beyond.

pages/docs/community/how-changes-in-the-spec-are-introduced.md

@@ -0,0 +1,73 @@
+
+## How spec changes are introduced
+AsyncAPI Initiative always concentrates on the problems rather than the solution. This is because you are generally rather single-minded when you already have a solution in mind to a problem instead of fully diving into the issue, seeing alternatives, and finding the best solution. 
+
+### RFCs & champions
+Some changes, however, are "substantial," We ask that these be put through a bit of a design process and produce a consensus among the AsyncAPI contributors/maintainers. The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.
+
+#### What is an RFC? 
+RFC is a document that proposes an idea and serves as high-level documentation of the concept and its thinking.
+
+AsyncAPI finds this valuable because it makes prototyping an idea with words easy and flexible rather than immediately diving into an idea. RFCs force champions to explore the idea, document it and create a proposal for bringing it to life.
+
+#### Who is a champion?
+A Champion takes ownership of an idea and follows the proposed process to make the idea a reality.
+
+## Spec changes lifecycle
+The motivation for the Changes process is to raise the visibility of planned changes and make coordination and planning efforts easier. It is nearly impossible to follow all changes in a big project such as AsyncAPI spec. By providing a mechanism for sharing changes, it is easier for contributors to know what is coming and to ensure that we can address the impacts of changes well before the release date. The spec changes lifecycle consist of 2 parts, as seen below.
+
+### Change process
+
+- The author submits the change proposal by creating a discussion about the proposed changes. The person or group proposing the change is responsible for providing the first draft of the changes. Ideally, it's preferable to make this draft available as a pull request before submitting the Change proposal so the community can evaluate the change. However, starting with an issue is also permitted if the full details are not worked out.
+
+- The contributors/maintainers reviews the proposed change request. The goal of this check is to prove or disprove a problem and guide the discussion toward either rejection or a preferred solution. 
+
+- Implement the change. The author doesn't have to be the one to implement the change proposed but keep in mind that it might take a while before someone else does.
+
+- Possibly iterate/refine as the community gets experience with your proposed changes. There may be some additional feedback about design choices that might be adjusted.
+
+- Test implementation to gain confidence. When your change implementation is baked enough, and the solution seems desirable, there will be a compliant implementation with the AsyncAPI libraries and a test to gain confidence.
+
+### How changes are introduced in spec: example
+
+#### feat: added server variable object as a reusable object
+Let's see how Daniel Kocot proposed and championed a feature for the next spec release. 
+- He started a discussion on why his proposal was made.  [#707](https://github.com/asyncapi/spec/issues/707)
+- He opened a PR for his proposed change, which was reviewed by the contributors/maintainers. [#717](https://github.com/asyncapi/spec/pull/717)
+- After review and potential improvement, he did a compliant implementation of his feature with [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas/pull/250) simply because it's a critical requirement.
+- Since the implementation was a success, his proposed change got approved and made it to the next release.
+
+Check out our [how to contribute guide](https://github.com/asyncapi/spec/blob/master/CONTRIBUTING.md) to learn more.
+
+### Release process 
+This part of the lifecycle aims to describe all details of the process so that any community member can jump in and help coordinate.
+
+- We have four cycles a year for release, and they have a single coordinator.
+-  Your contribution is made against the `next-spec` branch in 3 repositories.
+- The coordinator at the beginning of the cycle checks if there are any release candidates. You know, like PRs that are in the advanced stage and have potential.
+- The coordinator keeps a closed watch on what is merged, documents it in release notes, and engages contributors and maintainers of the spec to collaborate on a release.
+- Maintainers trigger release when ready, release notes are published, and the world of open source won again.
+
+Learn more about the [release process](https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md#what). 
+
+### Release process visual
+The image below visualizes the whole process of how changes are introduced to the spec in a single glance. 
+
+```mermaid
+sequenceDiagram
+    Contributor->>+Specification: Propose RFC as an issue/PR
+    Maintainers-->>+Contributor: Initial review and request for Champion
+    Community-->>+Contributor: Initial review and request for Champion
+    Contributor->>+Specification: Further contribution through different stages to different repositories
+    Maintainers-->>+Contributor: Possible multiple review rounds
+    Community-->>+Contributor: Possible multiple review rounds
+    Contributor->>+Specification: Potential improvement and compliant implementation
+    Maintainers-->>+Contributor: Proposal acceptance and preperation for next release
+    Maintainers->>+Community: Request for a release coordinator volunteer
+    Release Coordinator ->>+ Community: Notify Community that new release cycle starts
+    Release Coordinator-->>+Specification: Review of possible release candidates
+    Release Coordinator-->>+Contributor: Indicate what is missing to have things release in current cycle
+    Release Coordinator->>+Maintainers: Ping maintainers so they are aware of the release candidates
+    Maintainers-->>+Specification: Publish Release
+    Release Coordinator ->>+ Community: Notify Community about new release
+```

pages/docs/community/onboarding-guide/_section.md

@@ -0,0 +1,4 @@
+---
+title: Onboarding guide
+weight: 10
+---

pages/docs/community/onboarding-guide/docs-community.md

@@ -0,0 +1,27 @@
+---
+title: 'AsyncAPI docs community'
+weight: 50
+---
+
+Join OPEN docs community meetings via Zoom, a regular space for docs contributors to meet and help each other.
+
+- Add the AsyncAPI calendar [in the AsyncAPI events page](https://www.asyncapi.com/community/events) to get docs meetings automatically added to your calendar of choice.
+- Watch past AsyncAPI docs meetings on the [AsyncAPI YouTube channel](https://www.youtube.com/AsyncAPI).
+- [Schedule your own docs meetings](https://github.com/asyncapi/community/blob/master/MEETINGS_ORGANIZATION.md).
+
+### Docs and education community discussions
+Visit the [public AsyncAPI Docs & Education discussion board](https://github.com/orgs/asyncapi/discussions/categories/docs-education) to discuss docs-related issues and propose improvements.
+
+## AsyncAPI Slack workspace and docs channels
+Join the [AsyncAPI documentation Slack channel](https://join.slack.com/share/enQtNjUxNTY1NTU1MDk0NS1mYjNhODFhZDI3ZDRjODA1ZWRkZTZlYmM4ZTNjNzZjNTg5NTBiYjNmNTkwYzRlYzY4ZjQ4M2RhMDYzMjI3N2U5) to meet other technical writers:
+
+- **#13_docs:** A space for all technical writers to start discussions, ask questions, share new ideas, and request `good first issues.`
+
+## AsyncAPI documentation roadmap 2024
+Stay tuned for new opportunities on our [Docs’ Community discussions](https://github.com/orgs/asyncapi/discussions/categories/docs-education) or reach out in the AsyncAPI Slack channel **#13_docs**.
+
+| Docs Roadmap | Ongoing Docs Projects | Timeline | Contribution Type |
+|--------------|-----------------------|----------|---------------------|
+| AsyncAPI Style Guide | [AsyncAPI Style Guide](https://github.com/asyncapi/website/issues/1240) | Ongoing | Regular contribution |
+| AsyncAPI Tools’ Docs | <li>[Modelina Docs](https://github.com/asyncapi/modelina/tree/master/docs) </li>  <li>[Parser Docs](https://github.com/asyncapi/parser-js/tree/master/docs) </li> <li>[GitHub Actions Docs](https://github.com/asyncapi/github-action-for-generator)</li> <li>[Studio Docs](https://github.com/asyncapi/studio/tree/master/doc/adr)</li> <li>[Generator Docs](https://github.com/asyncapi/generator/tree/master/docs)</li> <li>[CLI Docs](https://github.com/asyncapi/cli/tree/master/docs)</li> | Ongoing | Regular contribution |
+| Technical Writer Onboarding Guide | Onboarding Guide for new docs contributors | Ongoing | Regular contribution |

pages/docs/community/onboarding-guide/docs-onboarding-checklist.md

@@ -0,0 +1,22 @@
+---
+title: 'Docs onboarding checklist'
+weight: 30
+---
+## AsyncAPI docs onboarding checklist
+
+As an open-source initiative with a global community, technical writer contributors should learn about our governance documents, documentation processes, and communication channels. 
+
+Complete in order the following onboarding tasks:
+
+- [ ] Read the [AsyncAPI Code of Conduct](https://github.com/asyncapi/community/blob/master/CODE_OF_CONDUCT.md).
+- [ ] Read the [AsyncAPI Slack etiquette](https://github.com/asyncapi/community/blob/master/slack-etiquette.md). 
+- [ ] Join [the AsyncAPI Slack workspace](https://asyncapi.com/slack-invite).
+- [ ] Add the AsyncAPI calendar found in [the AsyncAPI events page](https://www.asyncapi.com/community/events).
+- [ ] Read the list of [technical writer contributor responsibilities](/docs/onboarding-guide/technical-writer-contributor-responsibilities.md).
+- [ ] Read and familiarize yourself with the [prerequisite knowledge topics](/docs/onboarding-guide/prerequisite-knowledge.md).
+- [ ] Familiarize yourself with the _work-in-progress_ [AsyncAPI Style Guide](https://github.com/asyncapi/community/pulls?q=is%3Apr+is%3Aopen+style+guide).
+- [ ] Read all docs under the following content buckets: `Concepts`, `Tutorials`, `Reference`. (Take the time to go through each tutorial.)
+- [ ] Set up your local environment following our instructions for the [AsyncAPI git workflow](https://github.com/asyncapi/community/blob/master/git-workflow.md).
+- [ ] Introduce yourself in AsyncAPI Slack in the `#01_introductions` channel and the `#13_docs` channel. Ask docs-related questions in #13_docs.
+- [ ] Request a good first docs issue in the [`#13_docs` Slack channel](https://asyncapi.com/slack-invite).
+- [ ] Attend [OPEN docs meetings](https://www.asyncapi.com/community/events) to chat with other maintainers, ask docs questions, and request help on docs blockers. 

pages/docs/community/onboarding-guide/index.md

@@ -0,0 +1,22 @@
+---
+title: 'Introduction'
+weight: 10
+---
+## Technical writer onboarding guide
+
+The AsyncAPI technical writer onboarding guide teaches new community members how to contribute to our documentation effectively. 
+
+> For a comprehensive understanding of the various ways you can contribute to the AsyncAPI Initiative, please consult the [AsyncAPI contributing guidelines](https://github.com/asyncapi/community/blob/master/CONTRIBUTING.md).
+
+The goal is providing docs contributors with the necessary tools and knowledge to:
+
+* Understand our documentation tools, technologies, and processes.
+* Comprehend our documentation target audiences.
+* Connect with teammates and subject matter experts (SMEs).
+* Report documentation bugs via issues.
+* Implement and propose updates to our documentation.
+* Obtain and incorporate reviewers' feedback.
+* Publish changes successfully.
+
+
+

pages/docs/community/onboarding-guide/prerequisite-knowledge.md

@@ -0,0 +1,36 @@
+---
+title: 'Prerequisite knowledge'
+weight: 40
+---
+
+The prerequisite knowledge section highlights the key technologies, concepts, and skills our technical writers need for working with AsyncAPI documentation. You must understand the main concepts behind our documentation processes, content classification, and the AsyncAPI specification.
+
+## Diátaxis framework and content buckets
+AsyncAPI adopted the [Diátaxis](https://diataxis.fr/) framework to meet our specific needs, classifying our documentation into content buckets (categories). 
+
+- `Concepts` define the concepts of AsyncAPI features.
+- `Tutorials` teach beginner processes with AsyncAPI by doing, taking you step-by-step from Point A to Point B.
+- `Tools` documents the AsyncAPI tools ecosystem.
+- `Guide` teaches troubleshooting and understanding AsyncAPI's capabilities at a high level.
+- `Reference` documents the AsyncAPI specification.
+- `Migration` guides how to upgrade to a newer AsyncAPI version.
+- `Community` explains our documentation processes, guidelines, and resources to community members.
+
+## Markdown syntax and `mermaid.js` diagrams
+AsyncAPI's docs are written in [Markdown syntax](https://www.markdownguide.org/basic-syntax/).
+
+Our diagrams are created with [Mermaid markdown syntax](https://mermaid.live/) thanks to the [mermaid.js](https://mermaid.js.org/) dependency.
+
+## AsyncAPI concepts
+Before contributing to the documentation, you should understand [the purpose of AsyncAPI](https://www.asyncapi.com/docs/tutorials/getting-started) and essential [AsyncAPI concepts](https://www.asyncapi.com/docs/concepts) _(i.e., servers, producers, consumers, channels, messages, etc.)_.
+
+You should also fundamentally understand [the AsyncAPI specification](https://www.asyncapi.com/docs/reference/specification/latest). 
+
+## JSON and YAML
+Because an AsyncAPI definition can be written in JSON and YAML, you must learn how to read, write, and validate these formats. 
+
+## Understanding Event-Driven Architecture
+[Event-Driven Architecture (EDA)](https://www.asyncapi.com/docs/tutorials/getting-started/event-driven-architectures/) uses events to trigger and communicate between services. (AsyncAPI is an open-source initiative that seeks to improve the current state of EDAs.) 
+
+## Protocols used with AsyncAPI
+AsyncAPI supports several protocols, such as Kafka, AMQP, MQTT, and more. You will benefit from acquiring a [basic understanding of protocols most used with AsyncAPI](https://www.asyncapi.com/docs/concepts/protocol), including their use cases and how they work with AsyncAPI. 

pages/docs/community/onboarding-guide/technical-writer-contributor-responsibilities.md

@@ -0,0 +1,14 @@
+---
+title: 'Technical writer contributor responsibilities'
+weight: 20
+---
+
+In the AsyncAPI community, technical writers collaborate with other technical writers, Subject Matter Experts (SME), designers, engineers, and core maintainers. 
+
+Technical writer contributor responsibilities include: 
+
+* Create quality, easy-to-use, clear, and accurate documentation for all audience levels.
+* Collaborate with other contributors to propose, create, and maintain documentation.
+* Support fellow technical writers and community members.
+* Engage in documentation review processes and incorporate feedback.
+* Join documentation community meetings/streams to connect with the community.