Page MenuHomePhabricator

Enable administrators to update block logs
Open, Stalled, Needs TriagePublic

Description

Proposed in Community-Wishlist-Survey-2016. Received 28 support votes, and ranked #58 out of 265 proposals. View full proposal with discussion and votes here.

Problem

From time to time, editors are blocked, but subsequently it is decided that there is some sort of reason that the block should not be regarded as a "black mark" on that editor's contributions. Such editors often feel alienated by the experience, and this problem is harmful to editor morale and retention. Presently, unless the unblock entry states explicitly what the caveat associated with unblocking was, there is no good way to "correct" a block log subsequently. (Clearly, re-blocking briefly just to make a new block log entry is a bad solution.)

Who would benefit

In an immediate sense, this would benefit a subset of editors who have been blocked, but ultimately it will make work easier for administrators and assist in community processes (such as requests for additional permissions) by clarifying things that are otherwise unclear.

Proposed solution

Enable administrators to make comment-only entries in block logs, without blocking or unblocking.

More comments: Obviously, projects that elect to make use of this feature will also need to establish policies governing when an administrator may or may not modify an entry a decision made previously by another administrator.

Technical details

  • Create a new special page, Special:AnnotateBlockLog (name up for discussion)
    • Requires block rights to use
    • Has a field for Username or IP address, identical in functionality to Special:Block
    • Has a field for the comment
  • Create a new log type, block/comment, for the annotations
  • When saving a comment using the special page (or, eventually, the API) create a new ManualLogEntry with the comment

Proposer

Tryptofish

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 11 2017, 2:28 AM

@Aklapper could you help me add appropriate project tags for this task? thank you :)

DannyS712 updated the task description. (Show Details)
Restricted Application added a project: User-DannyS712. · View Herald TranscriptAug 23 2019, 7:39 PM
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Aug 23 2019, 7:39 PM

Change 531984 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] [WIP] [DNM] Create Special:AnnotateBlockLog to allow for updating block logs.

https://gerrit.wikimedia.org/r/531984

DannyS712 moved this task from Next to In progress on the User-DannyS712 board.Aug 24 2019, 12:12 AM
DannyS712 added a subscriber: Anomie.

Moving back to code review; overhauled per comments by @Anomie on the patch

Once this is actually merged, I'll add a patch for the release notes, noting:

  1. The creation of Special:AnnotateBlockLog
  2. The creation of the abstract class BlockLogSpecialPage
  3. The addition of the block/annotateblocklog log
  4. The deprecation of SpecialBlock::checkUnblockSelf in favor of SpecialBlock::validatePerformer

I'm not adding that to the original commit because release notes are changed frequently, and I'd like to avoid merge conflicts that cannot be automatically fixed by Jenkins

MJL awarded a token.Sep 5 2019, 2:00 AM
dbarratt added subscribers: Niharika, dbarratt.

I moved this onto the development board too eagerly. This needs product input from @Niharika. :)

Restricted Application added a subscriber: MGChecker. · View Herald TranscriptSep 11 2019, 3:30 PM
DannyS712 changed the task status from Open to Stalled.Oct 10 2019, 5:28 AM

Awaiting product input from @Niharika, per T160233#5483998

@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.

Taking a look at the Wishlist proposal and discussion, it is very clear that this is very much a community decision and 20 out of the 48 votes were Strong oppose/Oppose/Neutral to this idea. We should not be enabling this until there is a larger buy-in from the community about this. This proposal should go through an RfC on the wikis and the outcome of that should inform what is built.

As it stands, I don't think it is a good idea to build this functionality.

@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.
Taking a look at the Wishlist proposal and discussion, it is very clear that this is very much a community decision and 20 out of the 48 votes were Strong oppose/Oppose/Neutral to this idea. We should not be enabling this until there is a larger buy-in from the community about this. This proposal should go through an RfC on the wikis and the outcome of that should inform what is built.
As it stands, I don't think it is a good idea to build this functionality.

Well, I already wrote the code; what about having it be a configuration option that is disabled by default?

@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.
Taking a look at the Wishlist proposal and discussion, it is very clear that this is very much a community decision and 20 out of the 48 votes were Strong oppose/Oppose/Neutral to this idea. We should not be enabling this until there is a larger buy-in from the community about this. This proposal should go through an RfC on the wikis and the outcome of that should inform what is built.
As it stands, I don't think it is a good idea to build this functionality.

Well, I already wrote the code; what about having it be a configuration option that is disabled by default?

@DannyS712 Well the request might change based on the community decision. For example, one of the suggestions from the survey proposal comments is to have a pre-defined list of comments instead of a freeform field for what should be logged.
An RfC will be needed anyway to enable this - might as well hold off on merging the code until that has happened?

@Niharika I think this is the second time where I finished coding something, only to then be told it needed consensus/approval (see previously T207577). To ensure that developer time isn't wasted, is there a way to get approval before people begin work?

@Niharika I think this is the second time where I finished coding something, only to then be told it needed consensus/approval (see previously T207577). To ensure that developer time isn't wasted, is there a way to get approval before people begin work?

@DannyS712 Firstly, I want to say thank you to you for being a volunteer code contributor. Having been there, I know that it's not easy.

I would recommend that before taking on tasks, make sure there is a buy-in from both the community and the relevant WMF team for the feature. If you are looking for tasks to take on, I'd recommend the wishlist as being a good place to start. If you look at tasks high up on the wishlist (below the top 10), you'll often find that wishes have majority support from the community. So then all that is needed is approval from a product team or someone willing to bless it.
Also, often product teams have lists of tasks on their boards that they want to take on but don't have the time to do so. In that case you could ping the product owner on the task to seek their approval for the taking on the work. You could also easily get code review in that case because the team already wanted to do that work.

I hope this helps.

How do I identify the "product owner"?

How do I identify the "product owner"?

Good question. We have a fair number of teams and each team has a product owner. For some tasks it is obvious - tickets that touch on the reading experience probably belong to Reading Web team or tickets that touch upon editing experiences issues probably belong to Editing team. Although there are broad areas with no clearly defined product team or owner. In these cases it is hard to tell who gets to make the decision. I don't have a good answer for what you should do in these cases. Sometimes it's okay to go ahead and make a change without product approval but I would refrain if possible because then that product change does not have a designated maintainer.
In any case, making sure the community wants the change is always important.

@eprodromou If I am not mistaken, you are the product owner of Core Platform Team . Correct?