Update CONTRIBUTING.md to mention creating a PR

CONTRIBUTING.md

@@ -8,3 +8,5 @@
 * [Test an integration](https://www.elastic.co/guide/en/integrations-developer/current/testing.html)
 * [Publish an integration](https://www.elastic.co/guide/en/integrations-developer/current/_publish_an_integration.html)
 * [Developer workflows](https://www.elastic.co/guide/en/integrations-developer/current/developer-workflows.html)
+
+To improve your chances of getting your Pull Request merged, ensure you follow all of the steps outlined in [Publish an integration](https://www.elastic.co/guide/en/integrations-developer/current/_publish_an_integration.html) prior to making your Pull Request.

docs/extend/_publish_an_integration.md

@@ -8,24 +8,51 @@
 When your integration is done, it’s time to open a PR to include it in the integrations repository. 
 Before opening your PR, make sure you have:
 
-1. Pass all checks
-Run:
-```bash
-elastic-package check
-```
+1. **Run pre-submission checks**
+Run `elastic-package check` to validate formatting, build, and linting. Run `elastic-package format` if files need reformatting.
 
-This command validates that your package is built correctly, formatted properly, and aligned with the specification. Passing this `check` is required before submitting your integration.
+2. **Add a changelog entry**
+Include a `link:` field pointing to your PR. Use the correct type: `enhancement`, `bugfix`, or `breaking-change`.
 
-2. Added a new entry into `changelog.yml`
-Update the package’s `changelog.yml` with a clear description of your changes for the new version.
+3. **Update CODEOWNERS** (new integrations only)
+Add your package to `.github/CODEOWNERS` with the format: `packages/<package_name> @elastic/<team-name>`.
 
-3. Bumped the package version
-If you are releasing new changes, increment the version in your manifest.yml file. This is required for the package to be published.
+4. **Include test coverage**
+Run `elastic-package test` before submitting. Generate `sample_event.json` using `elastic-package test system --generate`.
 
-4. Wrote clear PR title and description
-- Use a concise, descriptive title (e.g., `[New Integration] Add Acme Logs integration`).
-- In the PR description, summarize what your integration or change does, list key features or fixes, reference related issues, and provide testing instructions.
-- Ensure your documentation, sample events, and tests are included and up to date.
+5. **Bump the package version appropriately**
+Use patch version bumps for backward-compatible bug fixes and documentation-only changes. Use minor version bumps for backward-compatible new features.
+
+6. **Document breaking changes**
+Use `breaking-change` type in changelog and clearly describe impact on existing users. Breaking changes require a major version bump.
+
+   The following changes are considered breaking:
+
+   - **Field type changes**: Changing a field's data type (e.g., `keyword` to `long`, `long` to `keyword`) causes mapping conflicts for existing users
+   - **Field removal**: Removing fields that users may depend on in dashboards, alerts, or queries
+   - **Field renaming**: Renaming fields breaks existing references (dashboards, saved queries, detection rules)
+   - **ECS field collisions**: Removing non-ECS fields from ECS namespaces or changing ECS field mappings
+   - **Event value changes**: Changing standardized values (e.g., `event.outcome` from `"Succeeded"` to `"success"`)
+   - **Configuration changes**: Requiring new credentials, changing authentication methods, or modifying required settings
+   - **Data stream changes**: Splitting, merging, or restructuring data streams
+   - **Transform destination changes**: Modifying transform destination indices (requires updating `fleet_transform_version`)
+   - **Default behavior changes**: Changing defaults that alter data collection (e.g., deduplication settings, data stream datasets)
+
+   **Minimizing risk from breaking changes:**
+
+   Breaking changes can affect content inside and outside this repository. Before introducing a breaking change:
+
+   - **Search for dependent content in this repository**: Use `grep` or search tools to find dashboards, transforms, and other assets that reference the fields you're changing.
+   - **Check the `security_detection_engine` package**: Security detection rules may depend on your integration's fields. Search in `packages/security_detection_engine/` for references to affected fields.
+   - **Coordinate with other teams**: Other Elastic repositories (e.g., `detection-rules`, `kibana`) may contain content that depends on your integration's fields. Reach out to relevant teams before merging breaking changes.
+   - **Consider deprecation first**: Instead of immediately removing or renaming fields, consider a deprecation period where both old and new fields are populated, giving users time to migrate.
+   - **Update dependent assets**: If dashboards or other assets in this repository reference changed fields, update them in the same PR or coordinate the changes.
+
+7. **Add error handling to ingest pipelines**
+Include `tag` fields on processors and use `on_failure` handlers. Follow the standard error message format with `_ingest.on_failure_*` fields.
+
+8. **Write a clear PR title and description**
+Use a concise, descriptive title (e.g., `[New Integration] Add Acme Logs integration`). Summarize changes, reference related issues, and ensure documentation is up to date.
 
 ::::{tip}
 A well-written PR with clear documentation, versioning, and testing instructions will speed up the review and publishing process!