Draft documentation writing style guide

docs/docs/guides/contributing.mdx

@@ -90,6 +90,76 @@ It is important to keep the page structure consistent, this help developers easi
 
 The structure may vary depending on given feature. If the one above doesn't seem to be good fit for you, try to find similar feature and see how it is documented.
 
+### Documentation writing style guide
+
+more like guides than rules.
+The developers try find the solution to their problem as fast as possible. This is the reason we try to optimize the documentation for [skimming](https://www.linkedin.com/pulse/skimming-vs-speed-reading-whats-difference-paul-nowak#:~:text=Skimming%20is%20a%20method%20of,have%20to%20read%20every%20word.). making the documentation more developer friendly.
+
+##### Avoid passive voice
+
+Most of the sentences in a technical documentation should be in active voice. Sentences in the active voice are usually simpler than the ones in the passive voice.
+
+See the following examples:
+
+- The arguments **are provided to** the function.
+- A worklet **are generated by** a babel plugin.
+- UI thread **is being used by** Reanimated.
+
+which if we rewrite these sentences to active voice become simpler:
+
+- A babel plugin **generates** worklet.
+- The function **receives** the arguments.
+- Reanimated **runs** on the UI thread.
+
+We highly recommend reading a short tutorial in the Technical Writing One course by Google about [Active voice vs. passive voice](https://developers.google.com/tech-writing/one/active-voice). This article builds the intuition between the active and passive voice in a simple way.
+
+##### Prefer short, clear sentences
+
+don't worry about repeating
+
+sophisticated words
+
+choose to write a sentence shorter and simpler.
+
+The technical documentation isn't a novel. Most of the readers are not english native speakers and it's not the best place to show off your english writing proficiency.
+
+#### Avoid ambiguous pronouns
+
+```
+Worklets using the Hermes JavaScript engine. This allow us to run code on the UI thread.
+```
+
+What does **this** stands for in the following example?
+
+You can avoid ambiguity by repeating the subject.
+
+```
+
+```
+
+##### split paragraphs into bullet points
+
+##### Avoid acronyms and abbreviations
+
+Acronyms can often lead to confusion.
+
+In context of libraries while REA, RNGH, RNS acronym like RN can mean both React Native and React Navigation.
+
+Domain specific acronyms like JSI, JNI, JSC should be first introduced. For example, JSC (JavaScriptCore)
+
+The following rule doesn't apply for a globally established abbreviation like `UI` or `API`.
+
+##### limit technical jargon
+
+.
+define it in glossary
+
+#####
+
+##### put imports close to the used component
+
+If you have spare 2 hours, we highly recommend taking a free [Technical Writing One course by Google](https://developers.google.com/tech-writing/one). This is absolutely not required for contributing to the documentation but can elevate your career as a software engineer.
+
 ### Embedding interactive examples
 
 We try to make the examples as easy for the users as it gets. This is why good, interactive examples are crucial. To create great examples you can use `InteractiveExample` component. It takes `src` prop that expects source of a component that you can declare in `src/examples`, and a prop `component` that showcase given code.