docs: update component ownership guidelines and templates

.github/ISSUE_TEMPLATE/instrumentation_request.md

@@ -1,41 +1,36 @@
 ---
 name: Instrumentation request
-about: Create a report to add support for an instrumentation
+about: Create a request to add a new instrumentation
 labels: instrumentation-request
 ---
 
 <!--
-**NB:** Before opening an instrumentation request against this repo, please read [the contributing guidelines for new instrumentation](../../CONTRIBUTING.md#new-instrumentation).
+**NB:** Before opening an instrumentation request against this repo, please read [the contributing guidelines for new instrumentation](../blob/main/CONTRIBUTING.md#new-instrumentation).
 -->
 
-### Is your instrumentation request related to a problem? Please describe
+### Which library do you want to instrument?
 <!--
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+A clear and concise description of why this library should be instrumented. Ex. I'm always frustrated when [...]
 -->
 
-
-### Is it applicable for Node or Browser or both?
-
-
-### Do you expect this instrumentation to be commonly used?
-
-Weekly Downloads:
-
-### What version of instrumentation are you interested in using?
-
-Versions:
-
 ### Code Owners
 
 <!--
-New Instrumentation requests need at least 2 code-owners that will maintain the instrumentation long-term.
+New Instrumentations MUST have at least 2 code-owners that will maintain the instrumentation long-term.
+Any code-owners listed MUST fulfill all criteria laid out in the checklist below.
 -->
 
 - Owner 1
+  - [ ] I am a [member of the OpenTelemetry Organization](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#member)
+  - [ ] I have read [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) and understand the responsibilities of a component owner
+  - [ ] I agree to follow and uphold the [mission, vision and values](https://github.com/open-telemetry/community/blob/main/mission-vision-values.md) of the OpenTelemetry project
+  - [ ] I understand that the component may be subject to the [OpenTelemetry Semantic Conventions](https://github.com/open-telemetry/semantic-conventions) and agree to follow the rules set out therein
 - Owner 2
+  <!-- instruct any co-owners to complete the checklist above and comment it on this issue -->
+  - [ ] Commented the checklist below and has fulfilled the criteria for becoming a component owner
+<!-- continue listing co-owners if you have more than two -->
 
 ### Additional context
 <!--
 Add any other context or screenshots about the instrumentation request here. Is there a reference you could point for the well-defined lifecycle methods?
 -->
-

.github/ISSUE_TEMPLATE/ownership_request.md

@@ -5,7 +5,7 @@ labels: type:ownership-request
 ---
 
 <!--
-**NB:** Before opening a component ownership request against this repo, please read [CONTRIBUTING.md](../../CONTRIBUTING.md#component-ownership) and its subsections first.
+**NB:** Before opening a component ownership request against this repo, please read [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md#component-ownership) and its subsections first.
 -->
 
 ### Which component are you requesting ownership of?
@@ -17,7 +17,7 @@ Put a link to the component here.
 ### Related Work and Qualifications
 
 <!--
-List here why you're qualified to take ownership of the component, see [CONTRIBUTING.md](../../CONTRIBUTING.md#becoming-a-component-owner) for details.
+List here why you're qualified to take ownership of the component, see [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md#becoming-a-component-owner) for details.
 
 Examples:
 - I am working on <related open-source-project> and have deep knowledge of the instrumented package.
@@ -28,7 +28,8 @@ Examples:
 
 ### Checklist
 
-- [ ] I have read [CONTRIBUTING.md](../../CONTRIBUTING.md) and understand the responsibilities of a component owner.
+- [ ] I am a [member of the OpenTelemetry Organization](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#member)
+- [ ] I have read [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) and understand the responsibilities of a component owner.
 - [ ] I agree to follow and uphold the [mission, vision and values](https://github.com/open-telemetry/community/blob/main/mission-vision-values.md) of the OpenTelemetry project
 - [ ] I understand that the component I'm requesting ownership of may be subject to the [OpenTelemetry Semantic Conventions](https://github.com/open-telemetry/semantic-conventions) and agree to follow the rules set out therein.
 

CONTRIBUTING.md

@@ -140,16 +140,18 @@ When two or more approaches must be compared, please write a benchmark in the be
 This repository contains many components which are maintained by more than the typical set of JS maintainers and approvers.
 Each component in this repository SHOULD have a component owner who is responsible for maintaining it.
 The README.md for each component SHOULD contain its owner, but the source of truth for component ownership is in [.github/component_owners.yml](.github/component_owners.yml).
+
 Component owners are generally given authority to make decisions relating to implementation and feature requests for their components,
 provided they follow the best practices set out by the maintainers and the [mission, vision and values](https://github.com/open-telemetry/community/blob/main/mission-vision-values.md)
-of the OpenTelemetry Project.
+of the OpenTelemetry Project. To facilitate independent triage of issues pertaining to the owned component, component owners are assigned
+[the Triager role](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#triager).
 
 Component owners MUST do their best to maintain a high level of quality, security, performance, and specification compliance within their components.
 Maintainers may override the decisions of component owners, but should only do so when they feel one or more of these traits is compromised.
 
 ### Becoming a Component Owner
 
-To become a component owner, contributors MUST be a member of the OpenTelemetry GitHub organization.
+To become a component owner, contributors MUST be a [member](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#member) of the OpenTelemetry GitHub organization.
 To become a member, follow the steps in the [community guidelines for membership requirements](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#requirements).
 
 To become a component owner, contributors SHOULD demonstrate prior knowledge of the instrumented package or the concepts therein.
@@ -270,6 +272,7 @@ please ping ([@open-telemetry/javascript-approvers](https://github.com/orgs/open
 
 - Approved by
   - at least one component owner if one is defined in [.github/component_owners.yml](.github/component_owners.yml)
+    - upon approval, the component owner SHOULD apply the `has:owner-approval` label to signal to maintainers that the PR is ready to merge.
   - OR one maintainer
   - OR at least one approver who is not the approver merging the pull request
     - A pull request for small (simple typo, URL, update docs, or grammatical fix) changes may be approved and merged by the same approver
@@ -295,8 +298,11 @@ The size of the OpenTelemetry JavaScript developer community is not large enough
 Therefore, to reach our goal, we have the following recommendations for where instrumentation packages should live.
 
 1. Native to the instrumented package
-2. A dedicated public repository
-3. Here in the opentelemetry-js-contrib repository
+2. Close to where maintenance of the instrumented library takes place. For example:
+   1. in a repository that is part of the organization that maintains the instrumented library
+   2. in the same repository as the instrumented library
+3. A dedicated public repository
+4. Here in the opentelemetry-js-contrib repository
 
 If possible, OpenTelemetry instrumentation should be included in the instrumented package.
 This will ensure the instrumentation reaches all package users, and is continuously maintained by developers that understand the package.