Trigger Plugin Monorepo Consolidation Proposal

[fibonacci1729]

Trigger Plugin Monorepo Consolidation

Summary: Consolidate the standalone trigger plugin repositories (spin-trigger-sqs, spin-trigger-mqtt, spin-trigger-cron, spin-trigger-command) into a single monorepo, refresh the maintainer roster per governance policy, and archive the original repositories.

Background

The Spin project currently maintains four trigger plugins as separate repositories under the spinframework GitHub organization:

Repository	Current Maintainers
spin-trigger-sqs	Caleb Schoepp, Ivan Towlson, Kate Goldenring, Vaughn Dice
spin-trigger-mqtt	Suneet Nangia, Brian Hardock, Radu Matei
spin-trigger-cron	Brian Hardock, Ivan Towlson, Karthik Ganeshram, Radu Matei
spin-trigger-command	Karthik Ganeshram, Radu Matei, Thorsten Hans, Vaughn Dice

Having each trigger in its own repository has led to:

1. Duplicated CI/CD infrastructure — each repo carries its own GitHub Actions workflows, release tooling, and spin-pluginify configuration with largely identical structure.
2. Fragmented dependency management — Spin core and Wasmtime version bumps must be applied independently to each repo, increasing the surface area for version drift and missed updates.
3. Scattered issue tracking — bugs and feature requests are spread across four separate issue trackers, making it harder for contributors and users to discover existing work.
4. Maintainer sprawl — per our governance policy, project maintainers who are unresponsive for more than 3 months lose maintainership. A review of contribution activity across these repositories shows that several listed maintainers have not been active for well over 3 months.

Proposal

1. Create a new spin-trigger-plugins monorepo

Create a new repository spinframework/spin-trigger-plugins containing one Cargo workspace with the following crate layout:

spin-trigger-plugins/
├── Cargo.toml           # workspace root
├── Cargo.lock
├── GOVERNANCE.md        # symlink or reference to spinframework/spin GOVERNANCE.md
├── MAINTAINERS.md
├── LICENSE
├── CODE_OF_CONDUCT.md
├── README.md
├── crates/
│   ├── trigger-sqs/     # migrated from spin-trigger-sqs
│   ├── trigger-mqtt/    # migrated from spin-trigger-mqtt
│   ├── trigger-cron/    # migrated from spin-trigger-cron
│   └── trigger-command/ # migrated from spin-trigger-command
├── templates/           # consolidated Spin templates
├── examples/            # consolidated example apps
└── .github/
    └── workflows/       # unified CI/CD

Each trigger crate retains its own Cargo.toml, plugin manifest (spin-pluginify.toml), and release metadata but shares the workspace lockfile and CI infrastructure.

2. Refresh the maintainer roster

Per the Spin governance document:

"Project maintainers MUST remain active on the project. If they are unresponsive for > 3 months, they will lose project maintainer-ship, unless the remaining project maintainers of the given project and the Spin Governance Committee agree to extend the period to be greater than 3 months."

A review of contribution activity (commits, reviews, issue triage) across all four trigger repositories shows that the following maintainers have been inactive for more than 3 months:

Name	GitHub	Previously Maintained
Caleb Schoepp	calebschoepp	spin-trigger-sqs
Karthik Ganeshram	karthik2804	spin-trigger-cron, spin-trigger-command
Radu Matei	radu-matei	spin-trigger-cron, spin-trigger-command
Thorsten Hans	ThorstenHans	spin-trigger-command
Suneet Nangia	suneetnangia	spin-trigger-mqtt

These maintainers will be moved to Emeritus Maintainer status in the new monorepo's MAINTAINERS.md, as defined by governance. Per governance, emeritus maintainers are welcome to return to active maintainership — the path back is nomination by an existing maintainer followed by agreement among the maintainer group, consistent with the standard process for adding new maintainers.

The new monorepo's MAINTAINERS.md will be:

Current Maintainers

Name	GitHub Username
Brian Hardock	fibonacci1729
Ivan Towlson	itowlson
Kate Goldenring	kate-goldenring
Vaughn Dice	vdice

Emeritus Maintainers

Name	GitHub Username
Caleb Schoepp	calebschoepp
Karthik Ganeshram	karthik2804
Radu Matei	radu-matei
Thorsten Hans	ThorstenHans
Suneet Nangia	suneetnangia

All affected maintainers (current and emeritus) will be tagged on the PR that introduces this change for visibility.

3. Archive the original repositories

After migration is complete and the monorepo is publishing releases:

1. Update each original repository's README to point to the new monorepo.
2. Archive each original repository via GitHub's archive feature (read-only, preserving history and existing issues/PRs for reference).

4. Update governance repository list

The Triggers section of GOVERNANCE.md in spinframework/spin will be updated to replace the four individual entries with:

- Triggers:
    - [Spin Trigger Plugins](https://github.com/spinframework/spin-trigger-plugins)

Migration Plan

1. Create the monorepo with the proposed directory structure and unified workspace Cargo.toml.
2. Migrate source code and git history for each trigger using git subtree or a similar history-preserving approach.
3. Consolidate CI/CD — unify GitHub Actions workflows for build, test, and release across all four triggers.
4. Consolidate release tooling — adapt spin-pluginify configuration to produce individual plugin artifacts from the monorepo (one release artifact per trigger).
5. Update the Spin plugins index (spinframework/spin-plugins) to point at the new monorepo's releases.
6. Open a MAINTAINERS.md PR in the new repo with the proposed roster, tagging all affected maintainers.
7. Update GOVERNANCE.md in spinframework/spin via PR.
8. Archive original repositories after a transition period to allow in-flight issues/PRs to be migrated or closed.

Rationale

• A unified workspace means a single cargo build validates cross-trigger compatibility and a single lockfile ensures consistent dependency versions.
• Fewer repositories reduces the operational burden for version bumps, security patches, and CI maintenance.
• A consolidated maintainer team with demonstrated recent activity improves review velocity and accountability.
• Archiving (rather than deleting) the original repos preserves history and avoids breaking existing links.

[fibonacci1729]

cc/ @calebschoepp @karthik2804 @radu-matei @ThorstenHans @suneetnangia

[kate-goldenring]

@fibonacci1729 thank you for writing this all up. This all sounds good to me to proceed with. Do you know if triggers must always be written in rust? May be something to consider in the design of the repo.

[fibonacci1729]

@kate-goldenring I think it would make sense for new triggers written in rust to be added here but I wouldn't expect this to be a dumping ground for new triggers in other languages. Would it help if the repo was called spin-trigger-plugins-rust?

[itowlson]

@kate-goldenring At the moment, yes, in practice, custom triggers are Rust-only. The reason is they have to link to the spin-core crate and factors system, usually via the spin-trigger and spin-runtime-factors crates and their cronies. (I suppose in principle things could be written in other languages via some combination of translating Spin code and FFI shenanigans, but this would be high effort and high maintenance - given that this is specifically a Spin Framework project repo, I can't see us taking on that burden.)

@fibonacci1729 I would vote for leaving the proposed name as is, and if some hypothetical future language provides an attractive alternative, we can figure out whether to rename / reorganise / shrug at that time.

[vdice]

👍 LGTM

Update the Spin plugins index (spinframework/spin-plugins) to point at the new monorepo's releases.

I was thinking existing trigger release manifests in the spin-plugins repo could continue to exist unaltered, as the release assets will continue to be available/downloadable even when the repos are archived. Otherwise, we'd need to copy over all of the previous releases. Meanwhile, subsequent releases after moving to the monorepo should just have the new/updated GH release URLs.

Speaking of release mechanics, I'm assuming we'll follow a git tag (and thus GH release name) convention of <trigger-name>-<version> eg trigger-sqs-v0.13.0 (or even omit the trigger- prefix?)

[fibonacci1729]

@vdice I agree regarding the release mechanics. I was thinking the same (using prefixed tags to trigger the workflows for each trigger). I don't see much sense in including the trigger-; i think <trigger-type>-<version> is sufficient.

[fibonacci1729]

https://github.com/spinframework/spin-trigger-plugins has been created. Steps 1 & 2 are effectively done.

[fibonacci1729]

This has been completed now that the governance doc has been updated with the location of the new repo.