Move @djc to emeritus (#1359)

CONTRIBUTING.md

@@ -105,11 +105,11 @@ For a deeper discussion, see:
 https://github.com/open-telemetry/opentelemetry-specification/issues/165
 
 ### Error Handling
-Currently, the Opentelemetry Rust SDK has two ways to handle errors. In the situation where errors are not allowed to return. One should call global error handler to process the errors. Otherwise, one should return the errors. 
+Currently, the Opentelemetry Rust SDK has two ways to handle errors. In the situation where errors are not allowed to return. One should call global error handler to process the errors. Otherwise, one should return the errors.
 
-The Opentelemetry Rust SDK comes with an error type `openetelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`. 
+The Opentelemetry Rust SDK comes with an error type `openetelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`.
 
-For users that want to implement their own exporters. It's RECOMMENDED to wrap all errors from the exporter into a crate-level error type, and implement `ExporterError` trait.  
+For users that want to implement their own exporters. It's RECOMMENDED to wrap all errors from the exporter into a crate-level error type, and implement `ExporterError` trait.
 
 ### Priority of configurations
 OpenTelemetry supports multiple ways to configure the API, SDK and other components. The priority of configurations is as follows:
@@ -130,7 +130,7 @@ issues.
 
 * Run `cargo test --all` - this will execute code and doc tests for all
 projects in this workspace.
-* Run `cargo bench` - this will run benchmarks to show performance 
+* Run `cargo bench` - this will run benchmarks to show performance
 regressions
 
 ## Approvers and Maintainers
@@ -139,7 +139,6 @@ For GitHub groups see the [code owners](CODEOWNERS) file.
 
 ### Maintainers
 
-* [Dirkjan Ochtman](https://github.com/djc)
 * [Harold Dost](https://github.com/hdost)
 * [Julian Tescher](https://github.com/jtescher)
 * [Zhongyang Wu](https://github.com/TommyCpp)
@@ -152,6 +151,7 @@ For GitHub groups see the [code owners](CODEOWNERS) file.
 
 ### Emeritus
 
+* [Dirkjan Ochtman](https://github.com/djc)
 * [Jan Kühle](https://github.com/frigus02)
 * [Isobel Redelmeier](https://github.com/iredelmeier)
 
@@ -166,4 +166,4 @@ repo](https://github.com/open-telemetry/community/blob/master/community-membersh
 
 ## FAQ
 ### Where should I put third party propagators/exporters, contrib or standalone crates?
-As of now, the specification classify the propagators into three categories: Fully opened standards, platform-specific standards, proprietary headers. The conclusion is only the fully opened standards should live in SDK packages/repos. So here, only fully opened standards should live as independent crate. For more detail and discussion, see [this pr](https://github.com/open-telemetry/opentelemetry-specification/pull/1144).  
+As of now, the specification classify the propagators into three categories: Fully opened standards, platform-specific standards, proprietary headers. The conclusion is only the fully opened standards should live in SDK packages/repos. So here, only fully opened standards should live as independent crate. For more detail and discussion, see [this pr](https://github.com/open-telemetry/opentelemetry-specification/pull/1144).