<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This PR adds a guideline about how metrics'/attributes' addition should
take place in (some) coordination with the Semantic Conventions project.
This addition does not introduce a hard requirement for now but rather
suggests how such coordination with Semantic Conventions can be
achieved.
If this gets merged I plan to extend Contrib's guidelines as well (i.e.
84f1030339/CONTRIBUTING.md (adding-metrics-to-existing-receivers))
to link back to this guideline.
<!-- Issue number if applicable -->
#### Link to tracking issue
Part of
https://github.com/open-telemetry/opentelemetry-collector/issues/13076
/cc @open-telemetry/collector-contrib-approvers
@open-telemetry/collector-approvers
Note: It's still to be defined how Semantic Conventions will affect
components' stability as described at
https://github.com/open-telemetry/opentelemetry-collector/issues/11878,
however prior to the stability concern this PR suggests to update our
contribution guidelines to cover for this treating it as a "soft"
requirement already.
---------
Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Add guidelines for naming Go modules
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Reworks breaking changes section to include information about our
approach to feature gates.
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Use h2 (hN-1) titles for h2 (hN-1) sections instead of h3 (hN)
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
- Documents when to split into separate modules, including general rules
as well as specific conventions we are currently using
- Rephrases the wording on #11836 to add it into a general list.
- Documents how to split into separate modules.
<!-- Issue number if applicable -->
#### Link to tracking issue
Follows #11836, Fixes#11436, Fixes#11623
---------
Co-authored-by: Jade Guiton <jade.guiton@datadoghq.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Works towards #11553. Unifies information about component stability in a
single document.
#### Link to tracking issue
Fixes#11571
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Reflects existing practice in coding guidelines.
#### Link to tracking issue
Relates to #6767, fixes#9428
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Moves coding guidelines to a separate document where we can work on
expanding them. This is the largest part of the contributing document
and it was making it a bit difficult to work with and scary-looking for
newcomers.
Christos Markou
Pablo Baeyens
Dmitrii Anoshin