Define conventions for Registry types.

[austinlparker]

I'm working on Registry enhancements (see open-telemetry/opentelemetry.io#103 (comment) for a WIP image) that requires a quick consensus on a few names. We'll have the ability in the registry to filter by both language and 'type'. Here's my proposed types -

• API
• SDK
• Instrumentation
• Collector
• Exporter

Open questions:

1. Should API and SDK be combined? They're separate because some SIGs have a separate API and SDK implementation, but I'm not entirely convinced that's the best option. A potential change here would be to combine API and SDK into 'Implementations' and allow for multiple URLs for this type (so you could link to API and SDK independently if they are in independent repositories)
2. Are we happy with 'Instrumentation' to be a catch-all for instrumentation plugins? Is this terminology confusing to new users? We can also just display it as 'Instrumentation Plugin' and keep the underlying type key 'instrumentation'
3. Should 'Collector' be a type or a language (or both?) The current taxonomy makes collector exporters kinda weird, as they're exporters (so they should be tagged exporter) but they're for the collector (so they should be tagged collector).
4. Is there anything missing?

Thanks in advance for feedback.

[austinlparker]

After noodling on this a bit, I'm thinking about combining API and SDK into 'Core', so we'd have 'Core', 'Collector', 'Exporter', and 'Instrumentation'.