I think there are cases where the outcome of the event can be bound to the prediction. Also we should be looking for cases where:
> Every prediction with a stake is an incentive to alter the outcome of an event
...is a feature not a bug.
For instance, imagine if PR's on core infrastructure (like xz-utils, for instance) were first reviewed by a set of trusted maintainers, and--supposing they pass that gate--were later put into a sort of limbo where people can bet on whether they'll be merged. The maintainers then make a policy around betting that the PR will be merged. They're in charge of whether it actually gets merged or not, so most of the time this is a pretty good bet and they just recycle that money by winning and then re-betting it on the next PR.
Of course third parties can also bet in the same way--these would be stakeholders which are not maintainers, but who wish to "sweeten the pot" and encourage people to spend enough time with the pending code that they might find a reason to "bet against the house". No prior coordination between the maintainers and the stakeholders is necessary.
Suppose I notice some malicious code in one of these commits which is in the betting phase. (Maybe I do my own testing on pre-release versions as a stakeholder, or maybe I'm a bug bounty hunter.) I can bet that the PR won't be merged. The monetary value of that bet makes it clear that even though I'm a stranger, I'm not a spammer. That "buys" me the attention of the maintainers, and if I'm right about the code being malicious, the maintainers will decide not to merge the commit: I'll have successfully altered the course of events (bad commit doesn't get merged) such that I get paid for having been right.
> Every prediction with a stake is an incentive to alter the outcome of an event
...is a feature not a bug.
For instance, imagine if PR's on core infrastructure (like xz-utils, for instance) were first reviewed by a set of trusted maintainers, and--supposing they pass that gate--were later put into a sort of limbo where people can bet on whether they'll be merged. The maintainers then make a policy around betting that the PR will be merged. They're in charge of whether it actually gets merged or not, so most of the time this is a pretty good bet and they just recycle that money by winning and then re-betting it on the next PR.
Of course third parties can also bet in the same way--these would be stakeholders which are not maintainers, but who wish to "sweeten the pot" and encourage people to spend enough time with the pending code that they might find a reason to "bet against the house". No prior coordination between the maintainers and the stakeholders is necessary.
Suppose I notice some malicious code in one of these commits which is in the betting phase. (Maybe I do my own testing on pre-release versions as a stakeholder, or maybe I'm a bug bounty hunter.) I can bet that the PR won't be merged. The monetary value of that bet makes it clear that even though I'm a stranger, I'm not a spammer. That "buys" me the attention of the maintainers, and if I'm right about the code being malicious, the maintainers will decide not to merge the commit: I'll have successfully altered the course of events (bad commit doesn't get merged) such that I get paid for having been right.