Proposal: Naming for features

[hdost]

After our discussions in the SIG yesterday and some prior conversations we should probably get some sort of alignement of feature naming.

The most recent example here:

maybe we should develop some convention saying, all experimental features must begin with "experimental-feature"?

Originally posted by @cijothomas in #1410 (comment)

I think some goals would be:

• Clarity of purpose - What aspect is it changing?
• Clarity of status - Is this an experiment or stable feature ?
• Simplicity - this is a bit harder to define, but let's try to be less wordy when possible.
• Minimal Defaults - default should contain core features or very few features

We know we should be using kebab-case. However we have a couple different dimensions to consider.

1. Is the specification for the feature experimental or stable?
2. Is the feature an unstable implementation of a stable spec?
3. Is the feature just an otherwise optional feature?

I know that @TommyCpp had mentioned just documenting things. Does that mean just putting in our documentation that a feature is experimental?
Someone else mentioned default being the marker for stable or not.

If we look to the rust compiler there's a concept of a nightly compiler which you can use and once you're using that you can enable features which are unstable but I think this may not map 100%.

Personally I see a couple ways, but I'd rather hear first from the rest of the group.

References:

• https://rust-lang.github.io/api-guidelines/naming.html#c-feature
• https://doc.rust-lang.org/cargo/reference/features.html#the-features-section

[hdost]

#1410 (comment)
Apparently this conversation happened all in this PR
@open-telemetry/rust-approvers for discoverability