This is a proposal for a refinement of Canina's proposal, or any proposal substantially like it, in response to one of celtschk's objections in the comments.

Canina assumed, and I agree, that the software should execute an algorithm when a post is submitted, using as input any of the data available at the time, with the output determining whether or not the post is allowed at that time. The software could also use the same algorithm to preemptively disable posting UI for users who would not be allowed to submit. celtschk's objection is that any changes to the inputs of the algorithm between the time that a user starts writing a post and the time that the post is submitted could cause a post to get rejected, and that the experience of seemingly being allowed to write a post but then having it be rejected due to causes outside one's control is an unnecessarily demoralizing one, to be avoided.

My proposal is to use an additional bit in the database for each user to store whether a user is currently being ‘hobbled’. The ‘hobbled bit’, or ‘hobbit’ if I may, is checked before a page render to determine whether to disable posting UI, and also checked when a submission is posted to determine whether to allow the post. When a post is allowed, the software additionally executes whatever underlying algorithm is used to determine if a user is allowed to post, on all the data available at the time. If the algorithm yields a negative result, the hobbit is set, and a notice is displayed to the user that subsequent posts won't be accepted until the community sees more activity, or whatever message is appropriate given the underlying algorithm.

A user's own post would be the only way to set their hobbit, so there is no concern about some action outside the user's control causing the user's work to be discarded. The only way for a user to submit a post that would be rejected, assuming normal use of the UI, would be to start two posts in parallel, submit one, ignore the notice that would be displayed after the submission is accepted, and then submit the other.

(Note that the hobbit is not a mutex and is not client-side or connected to session state or cookies; if a user starts writing a post and then closes the tab, their hobbit is not affected nor are any other post drafts in any other tabs. Only submitting a post can set the hobbit, and it is set server-side, checked by any subsequent GETs or POSTs.)

Hobbits should be reset once the underlying algorithm no longer forbids posts, based on time, votes, other user activity, or whatever else the algorithm takes as an input. Implementation of the reset depends on the specific algorithm chosen and on performance concerns; I would think it'd be acceptable to only reset hobbits hourly or even daily, if it came to that. Again, this functionality would only affect set hobbits; the only way to change a user's hobbit from unset to set should be for that user to submit an accepted post, while failing to meet the criteria specified in the algorithm.

Some final notes: throughout, I talk about one hobbit per user, but if the algorithm is written (as Canina's is currently) to consider different post types differently, there would be a hobbit for each post type per user, or a hobbit for each post type and category per user, or however many hobbits are logically needed. Also, if it would make sense to implement hobbits as abilities that are granted and revoked instead of a custom bit (or bitset) column, that might have advantages—I don't really know enough about the ability system to say.

posted about 3 years ago

CC BY-SA 4.0

3y ago

r~~‭

4 9 46 8