docs: update Contribution Guide with Conventional Commit info (#1635)

.github/PULL_REQUEST_TEMPLATE.md

@@ -6,14 +6,22 @@ This code is leveraged to monitor critical services. Please consider the followi
 * Performance matters.
 * Features that are specific to just your app are unlikely to make it in.
 
-Please fill out the relevant sections as follows:
-* Proposed Release Notes: Bulleted list of recommended release notes for the change(s).
-* Links: Any relevant links for the change.
-* Details: In-depth description of changes, other technical notes, etc.
+Ensure that your Pull Request title adheres to our Conventional Commit standards
+as described in CONTRIBUTING.md
+
+Please update the Pull Request description to add relevant context or documentation about
+the submitted change.
 -->
+## Description
+
+Please provide a brief description of the changes introduced in this pull request.
+What problem does it solve? What is the context of this change?
+
+## How to Test
 
-## Proposed Release Notes
+Please describe how you have tested these changes. Have you run the code against an example application?
+What steps did you take to ensure that the changes are working correctly?
 
-## Links
+## Related Issues
 
-## Details
+Please include any related issues or pull requests in this section, using the format `Closes #<issue number>` or `Fixes #<issue number>` if applicable.

CONTRIBUTING.md

@@ -62,6 +62,30 @@ In general, we try to limit adding third-party production dependencies. If one i
 
 We use eslint to enforce certain coding standards. Please see our [.eslintrc](./.eslintrc.js) file for specific rule configuration.
 
+### Commit Guidelines
+
+We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to format commit messages for this repository. Conventional Commits provide a standardized format for commit messages that allows for automatic generation of changelogs and easy tracking of changes.
+
+When contributing to this repository, please ensure that your commit messages adhere to the Conventional Commit guidelines. Specifically, your commit messages should:
+
+* Start with a type, indicating the kind of change being made (e.g. `feat` for a new feature, `fix` for a bugfix, etc.). The types we support are:
+  * `build`: changes that affect the build system or external dependencies
+  * `chore`: changes that do not modify source or test files
+  * `ci`: changes to our CI configuration files and scripts
+  * `docs`: documentation additions or updates
+  * `feat`: new features or capabilities added to the agent
+  * `fix`: bugfixes or corrections to existing functionality
+  * `perf`: performance improvements
+  * `refactor`: changes that do not add new feature or fix bugs, but improve code structure or readability
+  * `revert`: revert a previous commit
+  * `security`: changes related to the security of the agent, including the updating of dependencies due to CVE
+  * `style` - changes that do not affect the meaning of the code (e.g. formatting, white-space, etc.)
+  * `test` - adding new tests or modifying existing tests
+* Use the imperative, present tense (e.g. "add feature" instead of "added feature")
+* Optionally, include a scope in parantheses after the type to indicate which part of the repository is affected (e.g. `feat(instrumentation): add support for Prisma Client`)
+
+Please note that we use the [Squash and Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits) method when merging Pull Requests into the main branch. We do not use the original commit messages from each individual commit. Instead, we use the Pull Request title as the commit message for the squashed commit, and as such, require that the Pull Request title adheres to our Conventional Commit standards. Any additional documentation or information relevant to the release notes should be added to the "optional extended description" section of the squash commit on merge.
+
 ### Testing Guidelines
 
 The agent includes a suite of unit and functional tests which should be used to