Apply suggestions from code review

Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>

text/0000-named-tracers.md

@@ -1,5 +1,7 @@
 # Named Tracers 
 
+**Status:** `proposed`
+
 _Creating tracers using a factory mechanism and naming those tracers in accordance with the library that provides the instrumentation for a traced component._
 
 ## Suggested reading
@@ -15,7 +17,7 @@ This proposal originates from an `opentelemetry-specification` proposal on [comp
 
 The purpose of _Named Tracers_ is the ability to allow for a more fine-grained control of the amount of tracing data being generated by a library or application. Associating a name (e.g. _"io.opentelemetry.contrib.mongodb"_) with a tracer allows for a logical coupling of this tracer and a certain technology or library (like _MongoDB_ in this example).
 
-By using *Named Tracers* a library can enable / disable tracing of a specific library, which might be necessary in case:
+*Named Tracers* allow enabling and disabling tracing of a specific library, which might be necessary in case:
 * A library causes too much runtime or memory overhead.
 * A library has issues or bugs (e.g. does not call `span.end()` in every case).
 * "Double-Tracing" becomes a problem. This can be the case if a vendor (e.g. Dynatrace) might already have built-in auto-instrumentation for a certain library. In this case the vendor might want to decide (automatically or configuration-based) which of the implementations should be enabled or disabled.