I think we have a loop hole here.
If I take for example the google case. The current state allows to add any new google integration without passing trough this procedure because everything is packed under 1 provider.

I think we should also specify handling case of adding new SDK under existed provider that extend the provider to a new service that wasn't part of it to begin with. If we take for example when we first added Tableau to the existed provider of Salesforce following the current policy states that there is no need for a mailing list thread which seems wrong?

I am not sure we have to go that deep. I am more concerned about requests to add a new provider/integration thn a new "dependency" to an existing provider. We already get "historically" some providers that we manage, and that's sometihing that is both - the strength of Airflow and weakeness (dependency). And in general, any committer might block merging a new dependency being added when we think it is a problem. We do not have specifically explain that as a process (I think). Or when we see that a new operator does not fit. And we can always start a discussion at the devlist.

The process for adding a new provider is slightly different, I think - this is mostly about new integration, potentially new team of people from a service interacting with us, and a huge risk that they want to "drop" maintenance on us and won't be contributing new things, hoping that people in the community will and they can just walk away.

I think when getting new PR in an existing provider we have, we have much better knowledge - will there be maintenance, will there be support in case of problem, what happens when there is a need to upgrade or when the service gets disabled. We are going through that with Google team and while a bit late, the make a huge effort to make their provider updated now. This is a good lesson for us.

So I think while we could describe it in more detail, I tihnk this is really more of an explanation for anyone "new" (like Huawei Cloud service people) players that need to understand what it means to add a new provider.

Does it make sense?

Also this is more a "default" behaviour. At any point, anyone can call for VOTE, LAZY CONSENSUS on just about anything, this is more like "what to expect" than "strict rules".

I think when getting new PR in an existing provider we have, we have much better knowledge - will there be maintenance, will there be support in case of problem, what happens when there is a need to upgrade or when the service gets disabled. We are going through that with Google team and while a bit late, the make a huge effort to make their provider updated now. This is a good lesson for us.

I'm not referring to the case that we have now.
I'm referring for a case that adding a new extension for a service that is not part of the original provider scope. If tomorrow Google acquire a company technically it allows them to add a new integration for it without violating this policy. I don't mean to cases where under google.cloud we add more services and improve the support there i'm referring to cases of adding a whole new service branch like: leveldb, looker etc...