How can we incorporate the patching of issues found during protocol upgrade testing into the on-chain governance process?

So an “optimistic” algorithm that applies the way you voted (yay, nay, pass) for the first iteration of the non-patched proposal to any subsequent patches of that same proposal, unless you explicitly vote no. With a potential limitation that allows only the proposer of the original amendment to propose the patch.

I like the suggestion and I think it’s definitely worth discussing. I do wonder if limiting who can propose a patch is a benefit to security, maybe we can discuss further.