I disagree on several accounts. First, I disagree on the “when the user saves the post”. So you let the user work on the post without any warnings, and then when all the work is done, you tell them “too bad, your work was for nothing.” If the user can't post for whatever reason, that should be communicated before starting the post, ideally by not presenting the user with an edit box to begin with (with an explanation why there's no edit box).

Second, I disagree on the sum of received votes. There at least should be a threshold on how new the votes are; votes from years ago (in either direction) should not be relevant at all.

Third, I don't think any automatic criterion should be immediately on negative. Imagine the first post gets a single negative vote; that would instantly prevent the user from posting again, although a single vote is clearly not significant. A lower (more negative) threshold is mandatory.

And I honestly don't understand your last bullet point at all.

celtschk‭ As a basic design principle, validation will always need to happen at the point of saving. Validation prior to that is a UX optimization only; worthwhile, but can't be relied upon.

Exactly which votes to count for the purposes of this decision is certainly something that can be considered. I already allowed for that to some extent in the paragraph beginning with "We might want to look only at the sum of received votes for posts of the same type". As I said to Olin, I was aiming for predictability for the individual user, and the sum of received votes is already readily available.

A user wouldn't immediately be entirely blocked from posting by a single downvote; they would just have to let another post of the same type be posted first. But yes, the thresholds can be tweaked; that's probably the easiest part to all this.

I'll admit that the last bullet point was rather confusingly phrased; does it make sense now?

If they have to wait for something out of their control to happen, then they are entirely blocked. The duration of that block may be short, or not if the site has currently little traffic (e.g. mathematics.CD currently had the last post 5 days ago).

And yes, now the last bullet point makes sense.

On the point of validation: The web site certainly can re-validate on submission, but the re-validation has to be conditioned on the state when the page was opened. That is, downvotes in between should not count. The only acceptable deviation would be a (sufficiently long, say an hour) timeout, so that one cannot open a page far in advance in order to circumvent a possible future block.

celtschk‭, why is it critical to you that the current state of the world not be taken into account when the post is submitted? Wouldn't that leave this scheme wide open to, say, opening ten browser tabs for ten questions and copy-pasting pre-composed questions in quick succession? Why would the additional moderation burden of finding and manually dealing with cases like that be worth whatever benefit you see in using stale state?

Somewhere else I happened to compose answers to questions that others considered close-worthy. The result being that while I was working on my answer, the question was closed without me noticing anything, and only when I transmitted the answer, I noticed that all my work was for nothing. That sucks hard.

Now you're asking what is the relation with the issue at hand? Well, the issue is that especially for users with little activity yet those measures as described might trigger because of some bad votes that are not the fault of them. Even if there are few of them, any reduction of their number is worthwhile.

What is not worthwhile is increasing the chance in order to prevent things that are very unlikely to happen anyway. Also, the specific possibility you note could easily be handled with a rate limit if you are approaching the threshold.

Generally, I believe to presume maliciousness is wrong.

I think this is more like preventing double spending than presuming maliciousness, but we all see things our own way.

Anyway, what if the throttling only takes effect after the first post which would be subject to throttling? Basically, give each user a bit, and if the bit is unset, allow the post. If additionally the quality test (as described in this answer, say) is failed, set the bit and show a notice to the user that subsequent posts are disallowed until the community sees more activity. Set bits ‘expire’ back to unset when the conditions for throttling no longer apply. While the bit is set, disable the posting UI for that user. That prevents abuses of the sort I envisioned, since the first tab would set the bit and the other tabs would not be allowed to post; it also lets through posts by users who've worked for a while on a single post. And it's less arbitrary and indirect than rate limiting or warning users who are ‘approaching’ the threshold.

That would be much better.

r~~‭ I might well be missing something obvious, but what then happens if, say, the user closes the wrong browser tab, or their browser crashes, or they have a power outage, or anything else that causes their session (and possibly also their cookies) to disappear? Wouldn't that leave such a flag dangling?

Considering that this comment thread seems like either an argument against the whole concept of hobbling, or at the very least a distinct proposal for how to do it, I would really encourage either you or celtschk‭ to post a separate answer and let the community vote on it. As I said already in the question, I welcome alternative proposals (including arguments why the idea is a bad idea), but can we please keep them where they will be discoverable and votable?

Right on, I'll write up an answer shortly. I wanted first to determine if I understood @celtschk's objection well enough to offer an acceptable compromise.