meta: enable opt-in to auto version bump workflow

docs/plugin-maintainers-guide.md

@@ -8,6 +8,7 @@
     - [PR Reviews \& Merging](#pr-reviews--merging)
     - [Issue Triage](#issue-triage)
   - [Version Bumping](#version-bumping)
+- [Opt-in to Automatic Version Bump PRs](#opt-in-to-automatic-version-bump-prs)
   - [Maintaining and patching an older release line](#maintaining-and-patching-an-older-release-line)
     - [Patching an older release](#patching-an-older-release)
 
@@ -31,6 +32,16 @@ Plugin owners should triage issues related to their plugin as needed. The `@back
 
 Plugin owners are expected to run the Version Bump script for their workspace. The process follows the guidance outlined in the [Version Bumping Documentation](https://github.com/backstage/community-plugins/blob/main/docs/version-bump.md).
 
+# Opt-in to Automatic Version Bump PRs
+
+Plugin owners can opt in to automatic version bump PRs by creating an empty .auto-version-bump file in the root of their workspace (`workspaces/${WORKSPACE}/.auto-version-bump`). This signals that your plugin should be included in the batch version bump workflow, which is triggered manually by one of the `@backstage/community-plugins-maintainers` .
+
+These automated PRs are intended as a convenience to open the version bump for you. As the plugin maintainer, you would still be required to:
+
+- Review the PR
+- Make any necessary patches to adopt the upgrade
+- Merge the PR once it's ready
+
 ## Maintaining and patching an older release line
 
 It may be necessary to patch a prior release line of a plugin when users depend on an older, but stable version and while a newer, incompatible, major version of the plugin exists. Typically for these older releases, only major bugs and security issues will need to be remediated. Not every plugin will need this workflow.