Rewrite the guide to remove "we"

Author: brunoocasali

resources/tiers.md

@@ -2,36 +2,36 @@
 
 The objective of Meilisearch's Integrations Team is to **ease Meilisearch usage to as many developers as possible**.
 
-Given this statement, **tiers** are nothing more than a __group of SDKs/integrations__ where the Integrations Team can fairly divide their attention. Unfortunately is not possible to keep all the SDKs 100% updated against the new Meilisearch releases all the time. The Integrations Team is a polyglot small team that maintains 30+ different integrations and tools, so it is humanly impossible to consistently meet the Meilisearch quality standards.
+Given this statement, **tiers** are nothing more than a __group of SDKs/integrations__ where the Integrations Team can fairly divide their attention. Unfortunately is not possible to keep all the SDKs 100% updated against the new Meilisearch features from Meilisearch releases all the time. The Integrations Team is a polyglot small team that maintains 30+ different integrations and tools, so it is humanly impossible to consistently meet the Meilisearch quality standards.
 
-The ultimate goal of introducing tiers is to allow the team to have more time to invest in new projects/integrations to impact more users.
+The ultimate goal of introducing tiers is to allow the team to have more time to invest in new projects/integrations to impact even more users.
 
-To measure the impact of an SDK, the data came from different places like [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and GitHub's stars, forks, and watchers.
+To measure the impact of an SDK, the data come from different places like [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and GitHub's stars, forks, and watchers.
 
-It is worth remembering that this priority is just a concept introduced by the team that aims to give a decision weight before investing time in some issues of the SDKs. So it does not mean we will never work on feature requests from the bottom tiers anymore, but it says we will prioritize the top tiers most of the time transparently.
+It is worth remembering that this priority is just a concept introduced by the team that aims to give a **decision weight** before investing time in some issues of the SDKs. So it does not mean they will never work on feature requests from the bottom tiers anymore, but it says they will prioritize the top tiers most of the time transparently.
 
-:warning: The team will still keeping all officially maintained SDKs **working**. :warning:
+:warning: The team will still keep all officially maintained SDKs **working**. :warning:
 
 ## Tier #1
 
-The SDKs in group #1 have total priority over the team's time. For example, issues are visited before issues are present in tier #2.
-It is worth remembering that this does not mean open issues are addressed and fixed promptly. Every issue needs time to be understood/confirmed/worked on, and consequently closed.
+The SDKs in group #1 have absolute priority over the team's time. For example, issues are visited before issues are present in tier #2.
+It is worth remembering that this does not mean open issues are addressed and fixed promptly. Every issue needs time to be understood/confirmed/worked on and consequently closed.
+
 All new Meilisearch features that make sense for those SDKs will be available on the release day.
 
 ## Tier #2
 
-Tier #2 SDKs are the emergent ones, we strongly believe they can move further, and we are betting on them.
-In any case, since they bring less value compared to tier #1 we only spend the amount of time required to keep it working and just do essential maintenance code and code cleanup.
-
-Only in urgent cases where, for example, the SDK is no longer working, issues from the SDKs in group #2 are prioritized over tier #1.
+Tier #2 SDKs are the emergent ones. The Integrations Team believes they can move further and are betting on them.
+In any case, since they bring less value than tier #1, the team will only spend the time required to keep these SDKs working and do the necessary maintenance code and code cleanup.
 
+Only in urgent cases where, for example, the SDK is no longer working issues from the SDKs in group #2 prioritized over Tier #1.
 
 ## Tier #3
 
 The SDKs in group #3 have relatively low user adoption compared to groups #2 and #1. They are probably new or have a small community behind the tech stack in the first place.
 As with tier #2, SDKs in this group are prioritized only in critical cases, and they are not going to receive active improvements or maintance from the integrations team.
 
-This is a very special group because we really need help from the community here.
+This is a very special group because the Integrations Team really need help from the community here.
 
 
 ## Tiers list
@@ -60,9 +60,9 @@ Gatsby | #3 |
 ## FAQ
 ### How are the tiers organized?
 
-The method used is mostly manual and subjective, where we use the data previously collected from the [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and Github to generate groups.
+The method used is mainly manual and subjective, using previously collected data from the [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and Github to generate the groups.
 
-To begin we only have 3 tiers, in the future, this number may change.
+Only 3 tiers were defined, but this number may change in the future, and this guide will be updated accordindgly.
 
 ### Is it possible for an SDK to move up a level?
 
@@ -81,4 +81,9 @@ It is possible by accessing the README.md of each repository. A tier badge is pr
 
 #### Why SDKs are present in a particular tier?
 
-Because those SDKs have the most active users. Not only from users using the Meilisearch Cloud. They have a larger community in general. Other principles could be used to move SDKs around if we think it is relevant.
+In general, because those SDKs have more and the most active users. By "active users," it means more activity in the repository, like contributions, watching (GitHub watchers), stargazers (GitHub stars), and forks (GitHub clones).
+
+Besides GitHub data, we track the importance of integration by constantly watching the data sent through the [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html). Note that data is ANONYMOUS, but we know the used client by looking at the `User-Agent`/`X-Meilisearch-Client` headers.
+We also give more weight when we know a particular SDK has more Meilisearch Cloud customers.
+
+PS: Other principles that are not written here may be used to move SDKs around if the team thinks it is relevant.