docs: new style guide - Grammar

pages/docs/community/_section.md

@@ -0,0 +1,4 @@
+---
+title: 'Community'
+weight: 6
+---

pages/docs/community/index.md

@@ -0,0 +1,24 @@
+title: Overview
+weight: 2
+---
+
+## Community: Guidelines and resources around community.
+
+Welcome to AsyncAPI **Community**! Our Community section documents the community guidelines and resources.
+
+<Remember>
+
+## Contribute to the AsyncAPI Community section
+Code isn't the only way to contribute to OSS; Dev Docs are a **huge** help that benefit the entire OSS ecosystem. At AsyncAPI, we value Doc contributions as much as every other type of contribution. ❤️
+
+To get started as a Docs contributor:
+1. Familiarize yourself with our [project's Contribution Guide](https://github.com/asyncapi/community/blob/master/CONTRIBUTING.md) and our [Code of Conduct](https://github.com/asyncapi/.github/blob/master/CODE_OF_CONDUCT.md).
+2. Head over to our [AsyncAPI Docs Board](https://github.com/orgs/asyncapi/projects/12).
+3. Pick an issue you would like to contribute to and leave a comment introducing yourself. This is also the perfect place to leave any questions you may have on how to get started. 
+4. If there is no work done in that Docs issue yet, feel free to open a PR and get started!
+
+### Docs contributor questions
+Do you have a documentation contributor question and you're wondering how to tag me into a GitHub discussion or PR? Never fear!
+
+Tag me in your AsyncAPI Doc PRs or [GitHub Discussions](https://github.com/asyncapi/community/discussions/categories/docs) via my GitHub handle, [`alequetzalli`](https://github.com/alequetzalli) 🐙.
+</Remember>

pages/docs/community/styleguide/grammar.md

@@ -0,0 +1,67 @@
+---
+title: Grammar
+description: This document provides grammar usage guidelines for clear and effective technical writing.
+---
+## Grammar
+
+
+## Abbreviations and acronyms
+
+When you use an abbreviation or acronym for the first time, spell it out and include the shortest form in parentheses. 
+
+Abbreviations are meant to be used to save the reader’s time. They make your documentation look clean. However, using abbreviations may come with some downsides. Abbreviations add a layer of abstraction to text, which requires the reader to spend some mental energy to expand. Thus, it is best to add abbreviations in case of words that have been repeatedly used throughout your document. Abbreviations or acronyms, once defined in a document, should be used consistently to ensure clarity and avoid confusion for readers.
+
+Here are some examples of abbreviations:
+- ‘Event-driven architecture’ can be abbreviated as ‘EDA’.
+- ‘Producer Consumer Model’ can be abbreviated as ‘PCM’.
+
+Here are some examples of acronyms:
+- ‘Artificial Intelligence’ can be acronymized as ‘AI’.
+- ‘Application Programming Interface’ can be acronymized as ‘API’.
+
+## Active voice
+
+Use active voice over passive voice whenever possible. Active voice makes writing easier to read and understand. When combined with short sentences, it makes it easy to convey an idea to the reader.
+
+Passive: ‘The documentation is being read by Charlie.’
+Active: ‘Charlie is reading the documentation.’
+
+Passive: ‘APIs are leveraged by developers to save time while building software.’
+Active: ‘Developers leverage APIs to save time while building software.’
+
+Passive: ‘Clear instructions and explanations are provided for users by technical documentation.’
+Active: ‘Technical documentation provides clear instructions and explanations for users.’
+
+## Capitalization
+
+Follow standard capitalization rules for American English. Avoid using unnecessary capitalization, and never capitalize for emphasis.
+
+Here are some examples of when capitalization should be used:
+- All proper nouns.
+- The first letter of any sentence should be capitalized.
+- Trademarked words that include capital letters.
+- Names of programming languages or frameworks.
+- References within a document.
+
+
+## Spelling
+
+Prefer American English over its counterparts. 
+
+A few examples:
+- Use 'color' instead of 'colour'.
+- Use 'analyze' instead of 'analyse'.
+- Use 'skillful' instead of 'skilful'.
+
+## Verb tense
+
+Stick with the present tense wherever possible. However, in some cases, using the future tense might be unavoidable. The present tense is more appropriate when speaking about facts, while the future tense might be needed when referring to experiments or improvements that are yet to come.
+
+The present tense is more appropriate when speaking about facts.
+‘An AsyncAPI document is a file that defines and annotates the different components of a specific Event-Driven API.’
+
+Future tense might be needed when referring to experiments or improvements that are yet to come.
+‘We will incorporate user feedback to address any problems in the documentation.’
+
+Past tense is used while talking about events that have previously occurred:
+‘Tutorials were added to the documentation as an entry point for new users.’