Clarify the relationship between experimental and internal/public configs

[PHILO-HE]

PR #10659 is introducing experimental() in config builder to allow developers to mark some configs as experimental if they're not stable. The purpose of this discussion is to establish a clear convention to developers and users.

Previously, our convention is, we always mark experimental configs as internal, so in the document where only public configs are listed, those experimental configs are not included.

With this new method introduced, we are considering if it is good to make internal and experimental independent.

We can view internal configs as those intended for developers or advanced users only. They can also be experimental—for example, some unstable tracing configs for debugging can be experimental. On the other hand, not all experimental configs are internal. If they can be exposed to end users for early evaluation even though still under experimental, they shouldn't be marked as internal.

Possible rule

• Public/internal: Who should see/use it
• Experimental: How reliable it is (can be marked as either public or internal based on the first item)

Based on this rule, many experimental configs can be marked as public if they can be exposed to end users.

Discussion is welcome. Thanks.

[zhztheplayer]

Thank you for bringing up a detailed discussion.

I think user needs to view some experimental options anyway. So public + experimental options should be exposed in doc.

Public / Internal and experimental / non-experimental are better be two individual switches.

[zjuwangg]

I second this thoughts.

[PHILO-HE]

It makes sense. If accepted, we can follow this convention when adding new experimental configs.