Page MenuHomePhabricator

Allow marking blocks that were made in error
Closed, DuplicatePublic

Description

Author: North80000

Description:
The final version of proposal at Village Pump Policy has been open for approximately 25 days and has received unanimous support (12 "supports", 0 neutrals, 0 opposes). The exact proposal was/is:

"When the the administrator who made a block subsequently determines that the block was in error, let's create the ability and expectation that that administrator can and will mark the block as being in error in a way that makes it very clear. This can be via a mark on that block itself, or the ability to create an additional log entry (without creating an additional block) This ability to mark the log shall only be used by an admin to mark their own block as being in error. The "expectation" will be created by some new wording in Wikipedia:Blocking policy. The idea of a system for the community to do this without agreement by the blocker is acknowledged and can be discussed later but (for simplicity) is not included in this proposal."

Could you implement this? If it is possible to make it so that when this feature is used a message comes up that says "This feature is to be used only by an administrator to note that a block made BY THEM was in error.

Sincerely,

North8000 (Wikipedia)
North80000@gmail.com


Version: 1.21.x
Severity: enhancement
URL: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=538467506#Proposal:Create_a_capability_and_process_to_expunge_a_block_from_someone.27s_record_when_all_agree_that_it_was_an_error

Details

Reference
bz44759

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:40 AM
bzimport set Reference to bz44759.
bzimport added a subscriber: Unknown Object (MLST).

How "the ability to create an additional log entry (without creating an additional block)" is different from the current practice of 1-second annotation blocks?

North80000 wrote:

Oops. I responded to the email notification but didn't realize (until now) that that doesn't show up here. The response was/is:

I am not an admin but I think I know what you are asking and that our discussions covered that. I'm assuming that you are referring to the current ability to create an additional block and then undo it as a way to make annotations. With respect to the responses at the proposal, the existence of this current capability was covered and taken into consideration by the respondents who still supported the ability to add (specifically) a log entry.

My own answers to your question would be:

-This does not require creating an additional block and unblock simply for the purpose of making a note that a block was in error.
-This does not require "creative mis-use" of a different capability to make the entry. Having it where "creative mis-use" is the only way to do it discourages it from happening and massively reduces it.

Sincerely,
North8000 (Wiki)

robert_horning wrote:

I've got to add that blocking for one second and then annotating is precisely what this proposal is trying to correct. Essentially it is the same thing and perhaps just a matter of semantics here, but it does illustrate a shortcoming in the MediaWiki software. All that is being asked here is to give an administrator/sysop level user the ability to add an additional "administrative" entry into logs that could be used for annotation purposes and wouldn't actually be logged as yet another block or some other potentially negative commentary on the part of the user where the annotation is being sought.

I agree with North800 here that the "creative misuse" of some admin tools doesn't preclude the fact that there is a real need here and something that needs to be tweaked in the MediaWiki interface. There are other hacks and work-arounds that have been used over the years for sysops trying to get around limitations in the software. This is justifiably a bug, and one that has even been discussed at length on the Wikipedia Village Pump as something serious enough that it should be shown to have broad community support to be made as a priority bug to at least look at and try to find a solution.

See also: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#Proposal:Create_a_capability_and_process_to_expunge_a_block_from_someone.27s_record_when_all_agree_that_it_was_an_error

So basically you want an extension that adds another log subtype which can be added through a special page and adds it to the users block log?

That seems like a waste of time when MaxSem's solution works just fine.

(In reply to comment #0)

The final version of proposal at Village Pump Policy has been open for
approximately 25 days and has received unanimous support (12 "supports", 0
neutrals, 0 opposes).

Got a link?

I think the underlying problem is more the long-term social stigma of years-old blocks. That may need a proper examination more than anything.

robert_horning wrote:

(In reply to comment #5)

I think the underlying problem is more the long-term social stigma of
years-old
blocks. That may need a proper examination more than anything.

It may be a social stigma that applies here, where somebody with several blocks is presumed guilty until proven innocent beyond a reasonable doubt in matters of future blocks or editor disputes. It doesn't matter if the blocks were done entirely in error or by administrators mis-using the tools. Adding yet another block when the block was done in error just increments the block count even further.

Perhaps this should be solved socially, but adding an annotation into the logs seems like a prudent thing to do.

(In reply to comment #7)

Adding yet another block when the block was done in error just increments
the block count even further.

Right. So perhaps alternate solutions (such as auto-expunging block logs after several years) would be better to look at here.

Perhaps this should be solved socially, but adding an annotation into the logs
seems like a prudent thing to do.

Hmm, you've lost me. An additional 1-second block _is_ an annotation.

I think the whole approach being attempted here may be misguided. The issue, as I see it, may be that Wikimedians have a strange attachment to preserving records indefinitely, when perhaps not all records need to be kept indefinitely. Is there a reason to not auto-prune block log entries older than, say, five years? Probably the subject of a separate bug, but definitely worth investigating, I think.

robert_horning wrote:

(In reply to comment #8)

(In reply to comment #7)

Adding yet another block when the block was done in error just increments
the block count even further.

Right. So perhaps alternate solutions (such as auto-expunging block logs
after
several years) would be better to look at here.

Perhaps this should be solved socially, but adding an annotation into the logs
seems like a prudent thing to do.

Hmm, you've lost me. An additional 1-second block _is_ an annotation.

Note that the 1-second block is recorded as a block. It is saying that whatever it is that the user was doing is seen as something that should be blocked and thus has a negative connotation for potentially ramping up additional much longer blocks than what a user would be getting for doing essentially the same thing. Yes, this is a social thing, and perhaps "administrators" should be better educated about looking carefully at the record logs before they do knee jerk reactions and performing perma-blocks on users effectively banning them from Wikipedia altogether.

As for preserving records indefinitely.... that is a whole separate issue that has no relevance here and is a huge can of worms better taken to the Village Pump and to the Wikimedia Commons as well as other mailing lists. I think you would have a raging discussion on your hand if you start to suggest anything be deleted from any of the logs. It is irrelevant because the reasons why an administrator would be marking the log would not be present several years later with extraordinary exceptions.

Regardless, the resistance I'm seeing here is simply because there is a hammer that can be used like a screwdriver, thus you think there is no need for a screwdriver. It gets the job done, but it is a less than elegant solution.

The discussion that led to this bug also raised the point that a log entry for a block placed in error is sometimes useful for identifying a misbehaving admin. While I agree strongly that erroneous block log entries have the power to cause misunderstandings years down the line and should be removed, that point is a valid one. If a bad block log entry is expunged completely, valid evidence for a future conduct investigation could be lost.

Suggestions were made in the associated discussion that admins could have subpages listing the blocks they've made that have been expunged from the log, but that's clumsy and messy. Consequently, I would suggest that a private log be created for each user, to which expunged block entries would be moved. Access to view these logs should be strictly limited - I would suggest users with the oversight flag only.

(In reply to comment #8)

I think the whole approach being attempted here may be misguided. The issue,
as
I see it, may be that Wikimedians have a strange attachment to preserving
records indefinitely, when perhaps not all records need to be kept
indefinitely. Is there a reason to not auto-prune block log entries older
than,
say, five years? Probably the subject of a separate bug, but definitely worth
investigating, I think.

There are at least a hundred thousand accounts on English Wikipedia, if not more, that are blocked indefinitely and will always remain so, and many of them have been blocked indefinitely for more than 5 years; eventually, all of these accounts will have been blocked for more than 5 years. Their block logs must remain so that admins and users in the future will be able to confirm that they're blocked, why, and when they were blocked.

I think this is a very good example of a bug that's been filed when people have brainstormed ideas to make someone feel better when that person felt they were inappropriately blocked; in other words, a classic example of hard cases making bad law. Over time a reasonable and workable process can be worked out, but this sudden "something must be done!" process isn't helpful in guiding developers in determining what would genuinely be useful.

Risker, this has been a known issue for years. The discussion on the policy pump is the first major one regarding it that I can recall, and has been going for a month - I also note that you have not been involved in it, yet you feel able to weigh in here, where most Wikipedia users will not see it.

It is _not_ helpful for you to try to shut this down by dismissing a constructive attempt at progress as panicked squawking.

(In reply to comment #12)

Risker, this has been a known issue for years. The discussion on the policy
pump is the first major one regarding it that I can recall, and has been
going
for a month - I also note that you have not been involved in it, yet you feel
able to weigh in here, where most Wikipedia users will not see it.

It is _not_ helpful for you to try to shut this down by dismissing a
constructive attempt at progress as panicked squawking.

Believe it or not, you DO NOT need to participate in English Wikipedia discussions to be able to discuss/support/oppose MediaWiki software changes.

Young man, check your attitude at the door.

This software change request does not exist in some kind of MediaWiki conceptual vacuum. It is a direct consequence of that discussion, which has policy implications for the whole project, and as a result any implementation must be based on wide consensus, which is not obtained or rejected in a obscure off-site forum such as a Bugzilla comment thread.

(In reply to comment #14)

Young man, check your attitude at the door.

That wasn't called for at all.

This software change request does not exist in some kind of MediaWiki
conceptual vacuum.

Umm, that's exactly where we are right now. This is a conceptual request because there is an idea of a possible software feature ("marking blocks that were made in error") that doesn't have a clear implementation strategy.

It is a direct consequence of that discussion, which has
policy implications for the whole project, and as a result any implementation
must be based on wide consensus, which is not obtained or rejected in a
obscure off-site forum such as a Bugzilla comment thread.

Ok so please point me to the consensus that this should be implemented in MediaWiki core for all projects. That's where this bug was filed and that's the expectation of any developer who comes and takes a look at it.

Oh and if you think Bugzilla is an obscure place, maybe spend some more time here and hack on a few bugs. [[mw:How to contribute]] is good place to start.

(In reply to comment #14)

Young man, check your attitude at the door.

I suggest you do. You seem to be under the illusion that the English Wikipedia can dictate MediaWiki development. It can not.

(In reply to comment #14)

This software change request does not exist in some kind of MediaWiki conceptual vacuum.

It does, considering we're on Bugzilla's MediaWiki product, not an English Wikipedia discussion page. It certainly does not exist in some kind of enwiki vacuum.

implementation must be based on wide consensus, which is not obtained or rejected in a obscure off-site forum such as a Bugzilla comment thread.

No it does not have to be made based on consensus on the English Wikipedia. It can be rejected by us (the developers) in Bugzilla, public mailing lists, in the Gerrit code review system, after discussions on IRC, and probably elsewhere.

(In reply to comment #15)

Ok so please point me to the consensus that this should be implemented in
MediaWiki core for all projects. That's where this bug was filed and that's
the expectation of any developer who comes and takes a look at it.

If there is a special place for changes that only relate to the English Wikipedia, then modify this bug appropriately. It has been clear since the start that this is an issue specifically relating to that project.

if you think Bugzilla is an obscure place

Bugzilla is obscure to normal editors on the English Wikipedia, in comparison to places like the various sections of the village pump. The vast majority of people there will never participate here. That's all.

robert_horning wrote:

(In reply to comment #15)

(In reply to comment #14)

This software change request does not exist in some kind of MediaWiki
conceptual vacuum.

Umm, that's exactly where we are right now. This is a conceptual request
because there is an idea of a possible software feature ("marking blocks that
were made in error") that doesn't have a clear implementation strategy.

The "clear implementation strategy" was discussed in the Village Pump thread. What is proposed is a MediaWiki software change to replace the "1-second block" with something that simply adds a line in the block log with administrator comments.... that can be used for anything including explaining that previous blocks were done in error. It could insert a link to a larger discussion or even a URL.

The goal to this request is explicitly to avoid marking a bad block by performing yet another block on the user. It is possible that one way to implement this is simply to treat 1 second blocks as administrative actions and to not have them be displayed formally as a block, but instead to have any commentary listed explicitly as an annotation. In other words, it would be mostly a redesign of the user interface that the administrators view when looking at user information. That seems like a very minor and mostly cosmetic change to MediaWiki, but I would hope that those who maintain the software would offer feedback on this issue.

What I really don't understand is why this request will be completely ignored and admins encouraged to used the kludge which is the 1-second block. IMHO this is a bug, even if it is a cosmetic issue rather than a major functional problem. Regular users of MediaWiki software (on en.wikipedia.... the highest profile project using this software) have suggested a change, which is what this request is all about.

There might be other ways to implement this as well, so feedback is certainly requested. That a feature like this may be of interest to administrators on projects other than en.wikipedia is also further justification for raising this here. Besides, changes done because of issues raised by users on en.wikipedia have often been beneficial to other MediaWiki users. That is furthermore why I think discussions of cleansing block logs after five years (or some other very arbitrary time span) or anything else tangential really is irrelevant to the discussion at hand.

The main issue at hand, to cut to the chase, really is about a way to express from one administrator to another that a user block was done in bad faith or in error. Sometimes through either neglect or simply human failings the unblock action is insufficient to accommodate this explanation.

(In reply to comment #18)

(In reply to comment #15)

(In reply to comment #14)

This software change request does not exist in some kind of MediaWiki
conceptual vacuum.

Umm, that's exactly where we are right now. This is a conceptual request
because there is an idea of a possible software feature ("marking blocks that
were made in error") that doesn't have a clear implementation strategy.

The "clear implementation strategy" was discussed in the Village Pump
thread.
What is proposed is a MediaWiki software change to replace the "1-second
block"
with something that simply adds a line in the block log with administrator
comments.... that can be used for anything including explaining that previous
blocks were done in error. It could insert a link to a larger discussion or
even a URL.

So whats wrong with my solution in comment 4 then?

This feature is now being discussed on the talk page of the Arbitration Committee on the English Wikipedia. A participant there has requested a link be made to it from this discussion.

https://en.wikipedia.org/wiki/Wikipedia_talk:Arbitration_Committee#Block_log_revdel_suggestion

What is the status of this report?

(In reply to comment #21)

What is the status of this report?

Unconfirmed. It says so in capital letters at the top of the window.