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

Tagging Platform Engineering for review

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

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

@Niharika @dbarratt any updates?

@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.

In T160233#5568022, @Niharika wrote:

@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?

In T160233#5568099, @DannyS712 wrote:

In T160233#5568022, @Niharika wrote:

@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?

In T160233#5568988, @DannyS712 wrote:

@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"?

In T160233#5569369, @DannyS712 wrote:

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 Platform Engineering . Correct?

Rettaging core platform team as a feature request to review (and hopefully approved)

So, this seems like the kind of feature that makes the most sense for Community Tech to review. @Niharika I'm untagging us from this ticket. Can you lead the community discussion necessary to decide whether and how to implement?

@DannyS712 thanks for doing this work. Seems like the code is in good shape, and you've had @Anomie's input. Now, let's make sure it's what the community is actually looking for.

@DannyS712 I've looked at the patch set. Please correct me if I'm wrong: as I see you've implemented the "make comment-only entries in block logs" proposal, that adds a new entry without modifying previous entries, thus only the user's visible block reason is changed. I don't see any changes to the block log (Special:Log/block) in the patchset, therefore the previous log entries (and the annotation entries) are all visible there, unmodified.

Sidenote: one of the motivations for the proposal was to "fix" mistaken entries that would give the impression of a bad history. This could be done by hiding the replaced (annotated) log entries in a details element, only showing those if the user clicks the replacing entry. I expect multiblocks (T194697) will become a highly requested feature in a few months / a year, necessitating an overhaul of the block log. Hiding annotated entries could be done in the same development.

@Niharika most of the oppose votes were a response to the original proposal of editing block log entries. That could be easily abused by mistake or intentionally to do history rewriting and practically impossible to detect or prove.
This was pointed out and the proposal was changed (1,2) to the solution endorsed by the support votes and implemented by DannyS712.

"History rewriting" is not possible with this solution: the changes are visible in the log, thus transparency is guaranteed. The same effect can actually be achieved with the currently available block tool by simply updating the block to change the email or talkpage access flags and also editing the block comment, therefore this implementation has no more abuse potential than the basic blocking tool.

Although seeking further feedback (testing the tool) would be appropriate, requesting community approval would be unnecessary bureaucratic processes on the scale of the partial block tool's months-long deployment. In my view, communities should be informed that the blocking tool was refined with a feature that is equivalent in power to the current tool (eg. changing email access) without actually changing the block itself. If there are significant concerns (probably from people who remember this feature as editing log entries), then a consultation or rfc could be done to properly communicate what this implementation enables.

@AronManning your above summary is accurate
@Niharika / @eprodromou any update on when this will be merged?

In T160233#5793388, @DannyS712 wrote:

@AronManning your above summary is accurate
@Niharika / @eprodromou any update on when this will be merged?

{{ping}} - having already written the code for this, is it going to go to waste?

In T160233#5905995, @DannyS712 wrote:

In T160233#5905976, @Masumrezarock100 wrote:

It's not stalled on anymore. Just waiting for a +2.

It was stalled awaiting product approval (i.e. should this be done at all)

And we have discussed in great detail that it does not add any extra powers or abuse potential. Blocking a user's email access then unblocking it (with some comment that the admin wants to be seen in the log) has almost the same result.

In T160233#5905997, @Demian wrote:

In T160233#5905995, @DannyS712 wrote:

In T160233#5905976, @Masumrezarock100 wrote:

It's not stalled on anymore. Just waiting for a +2.

It was stalled awaiting product approval (i.e. should this be done at all)

And we have discussed in great detail that it does not add any extra powers or abuse potential. Blocking a user's email access then unblocking it (with some comment that the admin wants to be seen in the log) has almost the same result.

Which is why I think this should have been uncontroversial. But until someone with +2 agrees...

In T160233#5905997, @Demian wrote:

And we have discussed in great detail that it does not add any extra powers or abuse potential.

I see that you've said that here, but could you link that discussion? The last I see here are two comments suggesting this needs further community buy-in, if it should even be done at all; was there a subsequent discussion off-ticket that didn't mentioned here?

In T160233#5906405, @Amorymeltzer wrote:

In T160233#5905997, @Demian wrote:

And we have discussed in great detail that it does not add any extra powers or abuse potential.

I see that you've said that here, but could you link that discussion? The last I see here are two comments suggesting this needs further community buy-in, if it should even be done at all; was there a subsequent discussion off-ticket that didn't mentioned here?

Sure. The comment above (T160233#5730506) addresses the concerns at Survey 2016 #Enable_administrators_to_update_block_logs
Followed by a short discussion on user_talk: https://www.mediawiki.org/wiki/Topic:Vd021yh9g3rgmkgs
Unfortunately, there was no response from @Niharika whom - I assumed - makes the call.

Thanks — I had thought you meant someone else was involved, so that's good to know. And yes, I'd agree that T160233#5568022 still seems to be the operating state.

In T160233#5907414, @Amorymeltzer wrote:

Thanks — I had thought you meant someone else was involved, so that's good to know. And yes, I'd agree that T160233#5568022 still seems to be the operating state.

Indeed and I wonder how the discussion at Enable_administrators_to_update_block_logs could be revisited. It's clear that the opposes mostly (all I think) address the original proposal, which asked that previous log entries can be modified. That truly has concerns of similar weight as oversighting log entries.

The proposal was however updated to avoid those concerns - by only adding new comment entries - and Danny implemented that solution. I wonder how that acceptance poll could be redone, or if it would be only an unnecessary bureaucratic round, as the opposes are all based on the original proposal's abuse potential, that's been mitigated.

To hopefully mitigate some of the concerns, I have hidden the entire feature behind $wgEnableAnnotateBlockLog - projects can opt out of using it. @Niharika can you take another look please?

@DannyS712 @Demian I'm sorry, I missed this ticket. I took a look at the Survey conversation and there are a lot of Oppose votes to this proposal. That makes me wonder if this is a good idea. Can I propose opening an RfC with a big community on the wiki (enwiki works) and if there is consensus, we can move forward on this? The survey is from 2016, so it's possible some of the concerns raised have dissipated.
Sorry about adding more process to this but honestly, pushing changes without community approval has not landed well in the past so I'm being extra cautious.
The RfC will also serve as a way to let the community know about this change which is important. Thanks for all your hard work here. I appreciate it.

In T160233#5907969, @Niharika wrote:

@DannyS712 @Demian I'm sorry, I missed this ticket. I took a look at the Survey conversation and there are a lot of Oppose votes to this proposal. That makes me wonder if this is a good idea. Can I propose opening an RfC with a big community on the wiki (enwiki works) and if there is consensus, we can move forward on this? The survey is from 2016, so it's possible some of the concerns raised have dissipated.
Sorry about adding more process to this but honestly, pushing changes without community approval has not landed well in the past so I'm being extra cautious.
The RfC will also serve as a way to let the community know about this change which is important. Thanks for all your hard work here. I appreciate it.

Is it possible to push the change, but use the feature flag to disable it pending consensus, so that other sites can opt in even if enwiki doesn't, and/or non WMF wikis can use it

In T160233#5908093, @DannyS712 wrote:

In T160233#5907969, @Niharika wrote:

@DannyS712 @Demian I'm sorry, I missed this ticket. I took a look at the Survey conversation and there are a lot of Oppose votes to this proposal. That makes me wonder if this is a good idea. Can I propose opening an RfC with a big community on the wiki (enwiki works) and if there is consensus, we can move forward on this? The survey is from 2016, so it's possible some of the concerns raised have dissipated.
Sorry about adding more process to this but honestly, pushing changes without community approval has not landed well in the past so I'm being extra cautious.
The RfC will also serve as a way to let the community know about this change which is important. Thanks for all your hard work here. I appreciate it.

Is it possible to push the change, but use the feature flag to disable it pending consensus, so that other sites can opt in even if enwiki doesn't, and/or non WMF wikis can use it

The question is whether or not this is a feature useful to end users. And in this case "users" isn't an individual, it's a community. I understand that the code is written and hard work has gone into it. I respect that. But if code is merged and it's not eventually being used, that's essentially adding tech debt to an overly bloated MediaWiki. Hence I really want us to ensure this would be used before we get it in. I hope that's okay. Again, I'm sorry for adding more work to your plate. Ideally a product owner should have consented to this before the code was written but I did not know of this until after the work was done.

In T160233#5908100, @Niharika wrote:

In T160233#5908093, @DannyS712 wrote:

In T160233#5907969, @Niharika wrote:

@DannyS712 @Demian I'm sorry, I missed this ticket. I took a look at the Survey conversation and there are a lot of Oppose votes to this proposal. That makes me wonder if this is a good idea. Can I propose opening an RfC with a big community on the wiki (enwiki works) and if there is consensus, we can move forward on this? The survey is from 2016, so it's possible some of the concerns raised have dissipated.
Sorry about adding more process to this but honestly, pushing changes without community approval has not landed well in the past so I'm being extra cautious.
The RfC will also serve as a way to let the community know about this change which is important. Thanks for all your hard work here. I appreciate it.

Is it possible to push the change, but use the feature flag to disable it pending consensus, so that other sites can opt in even if enwiki doesn't, and/or non WMF wikis can use it

The question is whether or not this is a feature useful to end users. And in this case "users" isn't an individual, it's a community. I understand that the code is written and hard work has gone into it. I respect that. But if code is merged and it's not eventually being used, that's essentially adding tech debt to an overly bloated MediaWiki. Hence I really want us to ensure this would be used before we get it in. I hope that's okay. Again, I'm sorry for adding more work to your plate. Ideally a product owner should have consented to this before the code was written but I did not know of this until after the work was done.

So why does a large community need to agree? If just (eg, no idea) itwikiquote would find it useful, it would be used. Its also easier to demonstrate the benefits if examples can be shown (eg partial blocks rollout)

In T160233#5908112, @DannyS712 wrote:

So why does a large community need to agree? If just (eg, no idea) itwikiquote would find it useful, it would be used. Its also easier to demonstrate the benefits if examples can be shown (eg partial blocks rollout)

It doesn't have to be so large - my intention was for the RfC to be discussed and agreed upon by a diverse pool of users who can chime in with their different experiences to weigh in on the pros and cons of doing this. Enwiki is an ideal candidate because there are a lot of users performing varying activities and they would have a well-rounded knowledge of why this is or isn't a good idea.

In T160233#5908133, @Niharika wrote:

In T160233#5908112, @DannyS712 wrote:

In T160233#5908100, @Niharika wrote:

The question is whether or not this is a feature useful to end users. And in this case "users" isn't an individual, it's a community. I understand that the code is written and hard work has gone into it. I respect that. But if code is merged and it's not eventually being used, that's essentially adding tech debt to an overly bloated MediaWiki. Hence I really want us to ensure this would be used before we get it in. I hope that's okay. Again, I'm sorry for adding more work to your plate. Ideally a product owner should have consented to this before the code was written but I did not know of this until after the work was done.

So why does a large community need to agree? If just (eg, no idea) itwikiquote would find it useful, it would be used. Its also easier to demonstrate the benefits if examples can be shown (eg partial blocks rollout)

It doesn't have to be so large - my intention was for the RfC to be discussed and agreed upon by a diverse pool of users who can chime in with their different experiences to weigh in on the pros and cons of doing this. Enwiki is an ideal candidate because there are a lot of users performing varying activities and they would have a well-rounded knowledge of why this is or isn't a good idea.

@Niharika if this means that you can find some time to start an RfC similar to the proposal's, where there were 28 support votes requesting this feature, then that's a solution.

Imho that might be more than necessary time spent on bureaucratic rounds, as the benefit of this feature is clear to me and to those who voted for it. On the other hand, it would be a nice introduction of the feature to the community. So pros and cons. If you feel the need to do it and find the time for it, or could help Danny with the details for how to conduct it, that would be a step forward.

@DannyS712 I appreciate the work that you put into improving the logging of blocks. I agree with @Niharika that there needs to be a target wiki(s) that are interested in implementing this change. Through a Rfc or other type discussion, they will need to weight the pros and cons of this design and be ready to put into place by updating their their local policies about logging blocks. Special:Block is a widely used feature and it is important to have very broad input about the benefits of making the change.

@Demian @DannyS712 In addition to a Rfc style discussion, there also needs to be clearly written communication about this feature to active wikis so that that they can prepare the local updates to policy and procedures. If this doesn't happen then local documentation and policies becomes outdated and inaccurate.

In T160233#5568988, @DannyS712 wrote:

@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?

Ah. I see you have now become a true MediaWiki dev ;)

@DannyS712 thanks for working on this! I tested the patch using http://patchdemo.wmflabs.org. <!-- see T76245#5788579 for more info about this webservice --> I successfully added a comment in block logs of a user. It was working flawlessly! Comment: I only checked the special page (Special:AnnotateBlockLog), not sure what is the status of other functions though. Feel free to test it out there.

->next so that I remember to start that RfC...

I've started drafting a survey at https://en.wikipedia.org/wiki/User:DannyS712/RfC - tweaks and clarifications are welcome, but please don't move it to project space and start it yet :)

I never really understood the fascination with having a "clean block log" or being able to annotate blocks that expired as incorrect or something. But a lot of people do, and here we are. I think it's important to recognize that adding this feature to MediaWiki will cause a social change - I'd expect significantly more people who feel slighted by blocks that weren't 100% solid to now appeal for someone to annotate their block log accordingly (not saying more review/accountability is a bad thing, just that things will change).

The request to have some more recent RfC for this feature is mostly so we're not merging some feature into core, have it not go used and rot away, adding to our maintenance burden without providing any user value.

I also think this is a niche feature that most wikis really don't need, and hence I'd recommend putting this into an extension instead. This would allow your code to be merged without actually being deployed yet (aka disabled by default).

If we were going to have some general log annotation feature, I think that would fit in core. But I also can't really think of use cases in which you'd want to do that...it's just blocks.

In T160233#6276234, @Legoktm wrote:

If we were going to have some general log annotation feature, I think that would fit in core. But I also can't really think of use cases in which you'd want to do that...it's just blocks.

There is T218872: Allow editing of own comments in deletion log