Define what's in scope for OpenTelemetry Logs GA (post traces and met…

…rics 1.0 GA) (#130)

* Define what's in scope for OpenTelemetry Logs 1.0 GA

Clearly defined scope is important to align all logs contributors and to make
sure we know what target we are working towards. Note that some of the listed
items are already fully or partially implemented but are still listed for
completeness.

* Address PR comments

Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>

text/logs/0130-logs-1.0ga-definition.md

@@ -0,0 +1,63 @@
+# Logs GA Scope
+
+This document defines what's in scope for OpenTelemetry Logs General
+Availability release.
+
+## Motivation
+
+Clearly defined scope is important to align all logs contributors and to make
+sure we know what target we are working towards. Note that some of the listed
+items are already fully or partially implemented but are still listed for
+completeness.
+
+General Availability of OpenTelemetry Logs is expected after OpenTelemetry 1.0
+GA (which will only include traces and metrics).
+
+## Logs Roadmap Items
+
+### Specification and SDK
+
+- Write guidelines and specification for logging libraries to support
+  OpenTelemetry-compliant logs.
+
+- Implement OpenTelemetry logs SDK for Java that support trace context
+  extraction from the current execution context.
+
+- Show full OpenTelemetry-compliant implementation of an "addon" to one of the
+  popular logging libraries for Java (e.g. Log4J, SLF4J, etc). Use OpenTelemetry
+  SDK to automatically include extracted trace context in the logs and support
+  exporting via OTLP.
+
+- Implement an example Java application that shows how to emit correlated traces
+  and logs. Use the supported popular logging library together with
+  OpenTelemetry SDK, and export logs using OTLP.
+
+- Add Logs support to OTLP specification.
+
+### Collector
+
+- Implement receiver and exporter for OTLP logs in Collector.
+
+- Implement "array" value type for in-memory data structures (it is already part
+  of OTLP but is not supported by the Collector yet).
+
+- Implement log exporters in Collector for a few vendor formats from
+  participating vendors.
+
+- Implement Fluent Forward protocol receiver to receive logs from
+  FluentBit/FluentD.
+
+- Add support for log data type to the following processors: `resource`,
+  `batch`, `attributes`, `k8s_tagger`, `resourcedetection`.
+
+- Add end-to-end performance tests for log forwarding (similar to existing trace
+  and metric tests) at least for OTLP and Fluent Forward protocols.
+
+- Test operation of Collector together with at least one other logging agent
+  (e.g. FluentBit), allowing to read file logs as described here. Publish test
+  results (including performance).
+
+- Implement an example that shows how to use OpenTelemetry Collector to collect
+  correlated logs, traces and metrics from a distributed microservices
+  application (preferably running in a cloud-native control plane like
+  Kubernetes)