I'm not sure if this task is worth the time and complexity it would involve. I see some people have subscribed and awarded tokens -- do you think this type of block would be widely used, and that it would be helpful in addressing bad behavior?

What currently happens in such cases is: You set a block to stop a user who's usually not responding to previous communication attempts and ask them to reply on their user talk page and indicate that they've read (and are willing to follow) a certain message or policy page. Once they reply, the block usually gets lifted.

The requested feature would be nice to have, as it saves admins some work to revisit talk pages of blocked users. But it's certainly not the most important feature request compared to multi-blocks, multi-layer page protections or other admin tools which are currently being worked on or which need work.

In T18447#10591667, @Johannnes89 wrote:

What currently happens in such cases is: You set a block to stop a user who's usually not responding to previous communication attempts and ask them to reply on their user talk page and indicate that they've read (and are willing to follow) a certain message or policy page. Once they reply, the block usually gets lifted.

The requested feature would be nice to have, as it saves admins some work to revisit talk pages of blocked users. But it's certainly not the most important feature request compared to multi-blocks, multi-layer page protections or other admin tools which are currently being worked on or which need work.

(Speaking with my Volunteer admin hat on)

One issue I have with this feature request is that we are assuming a user will actually read a page when they open it. I don't think this would be the case for a large number of these users. I could see any of the following happening:

1. The user opens the page but does not read it, because they opened it accidentally, didn't see the blocked notice, etc.
2. If the page is their user talk page, they may open the page and not see the reason for the block as it's further down the page. However, opening the user talk page still got them unblocked and they continue on
3. There are browser extensions and other tools that will open a page for a preview. Given that this would be pages that are a "GET" request, it seems possible that the browser could open the page for the user in the background and then cause the unblock without the user even seeing the page content
4. It would be very easy for unapproved bot operators to get their bots unblocked if they were blocked with a block such as this, because the page to load would only require one GET request

While requiring an edit to their user talk page could work, I don't think that this would change much:

• A user could reply to a different and unrelated comment to be unblocked
• Any bot controlled account could still just make any kind of edit to be unblocked

In general, I'm not sure that this automatic removal mechanism would be useful and that even if the administrator wants this kind of block it seems better to still have a human do the final check before removing the block.

At Wikidata we have a constant stream of new users who gather warnings on their talk page but never response or (apparently) improve. It's as if they never learn about talk pages and cannot see the notifications. Usually we try to communicate with them for weeks or months before finally reluctantly blocking them. Commonly we then have to go back and delete every item they have created. It's a waste of our time as volunteers, and a waste of their effort as would-be editors. Anything that would make it easier to force such editors to engage with feedback would be helpful.