[chore] Add guidelines for Makefile development (#16497)

CONTRIBUTING.md

@@ -198,8 +198,46 @@ Sometimes a component may be in need of a new or additional Code Owner. A few re
 If you would like to help and become a Code Owner you must meet the following requirements:
 
 1. [Be a member of the OpenTelemetry organization.](https://github.com/open-telemetry/community/blob/main/community-membership.md#member)
-2. (Code Owner Discretion) It is best to have resolved an issue related to the component, contributed directly to the component, and/or review component PRs. How much interaction with the component is required before becoming a Code Owner is up to any existing Code Owners. 
+2. (Code Owner Discretion) It is best to have resolved an issue related to the component, contributed directly to the component, and/or review component PRs. How much interaction with the component is required before becoming a Code Owner is up to any existing Code Owners.
 
 Code Ownership is ultimately up to the judgement of the existing Code Owners and Collector Contrib Maintainers. Meeting the above requirements is not a guarantee to be granted Code Ownership.
 
 To become a Code Owner, open a PR with the CODEOWNERS file modified, adding your GitHub username to the component's row. Be sure to tag the existing Code Owners, if any, within the PR to ensure they receive a notification.
+
+### Makefile Guidelines
+
+When adding or modifying the `Makefile`'s in this repository, consider the following design guidelines.
+
+Make targets are organized according to whether they apply to the entire repository, or only to an individual module.
+The [Makefile](./Makefile) SHOULD contain "repo-level" targets. (i.e. targets that apply to the entire repo.)
+Likewise, `Makefile.Common` SHOULD contain "module-level" targets. (i.e. targets that apply to one module at a time.)
+Each module should have a `Makefile` at its root that includes `Makefile.Common`.
+
+#### Module-level targets
+
+Module-level targets SHOULD NOT act on nested modules. For example, running `make lint` at the root of the repo will
+*only* evaluate code that is part of the `go.opentelemetry.io/collector` module. This excludes nested modules such as
+`go.opentelemetry.io/collector/component`.
+
+Each module-level target SHOULD have a corresponding repo-level target. For example, `make golint` will run `make lint`
+in each module. In this way, the entire repository is covered. The root `Makefile` contains some "for each module" targets
+that can wrap a module-level target into a repo-level target.
+
+#### Repo-level targets
+
+Whenever reasonable, targets SHOULD be implemented as module-level targets (and wrapped with a repo-level target).
+However, there are many valid justifications for implementing a standalone repo-level target.
+
+1. The target naturally applies to the repo as a whole. (e.g. Building the collector.)
+2. Interaction between modules would be problematic.
+3. A necessary tool does not provide a mechanism for scoping its application. (e.g. `porto` cannot be limited to a specific module.)
+4. The "for each module" pattern would result in incomplete coverage of the codebase. (e.g. A target that scans all file, not just `.go` files.)
+
+#### Default targets
+
+The default module-level target (i.e. running `make` in the context of an individual module), should run a substantial set of module-level
+targets for an individual module. Ideally, this would include *all* module-level targets, but exceptions should be made if a particular
+target would result in unacceptable latency in the local development loop.
+
+The default repo-level target (i.e. running `make` at the root of the repo) should meaningfully validate the entire repo. This should include
+running the default common target for each module as well as additional repo-level targets.