Wikipedia talk:Pending changes

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

My (North8000) 12/14/18 edit and reversion of it[edit]

Hello Nosebagbear (and others)

The original paragraph read: “Acceptance of an edit by a reviewer is not an endorsement of the correctness of the edit. It merely indicates that the edit has been checked for obvious problems as listed above.”

I changed it to: “Acceptance of an edit by a reviewer is not an endorsement of the edit. It merely indicates that the edit has been checked for obvious problems as listed above.”

With the following edit summary: “Removed qualifier to broaden the statement of what acceptance does not imply. What is not imp[lied goes far beyond just "correctness" “

You reverted with the following edit summary. “GF edit - but I would say we are endorsing one aspect at least - that it isn't vandalism (we're endorsing the reason it was protected). That is separate from endorsing the correctedness (whether factual or phrasing etc) of it.”

First, expanding on my original reasoning, I think it needs reinforcement that such acceptance is not the same as acceptance of an edit. I’ve seen many cases where a routine problematic edit was not given normal scrutiny because it had already been reviewed and accepted by somebody (but, only a “pending changes review) , where in fact it was reviewed ONLY for “obvious problems” delineated on this page. Now on to your edit summary for the reversion. First, I agree with what you said in your edit summary, (except for the implied statement that I’m discussing next) but IMO it does not support the reversion. The reason given was implying that my change removed saying “we are endorsing one aspect at least” but in fact that is clearly stated in the sentence which follows: That the acceptance "indicates that the edit has been checked for obvious problems as listed above.””

Sincerely, North8000 (talk) 20:52, 14 December 2018 (UTC)

@North8000: - Hi there. Sorry, I did read the whole edit but you're quite right that the second sentence covers that nicely. I can only blame the aftereffects of last night's Christmas social - please go ahead and redo your suggested edit. Nosebagbear (talk) 23:24, 14 December 2018 (UTC)
Cool and thanks. Sincerely, North8000 (talk) 14:33, 15 December 2018 (UTC)

Village pump idea lab discussion on merging reviewer role with others[edit]

For everyone's information, there is a discussion on merging the pending change reviewer role with other user groups at the Village pump idea lab. isaacl (talk) 16:35, 20 December 2018 (UTC)

Proposal to improve visibility of "Accepted" comment[edit]

I would like to propose a change to the pending review process or software, in order to improve the visiblity of comments entered in the summary field when accepting a pending change. Besides the fact that not exposing the comment hurts transparency, it also can lead to avoidable disruption in some cases.

When reviewing pending changes, I always leave a comment, whether I accept or revert changes. Currently, reverted changes are exposed in the History after the undo, as any revert would be. However, accepting changes merely triggers a modification to the already existing history item that is under review: where before, the history item had a brief bracketed indicator at the end of the summary line from [pending review] to [accepted by Username].

Sometimes, accepting a change is not a slam-dunk, and requires some thought, and one would like to expose the reasoning behind it. Here is one IP edit that could possibly be questionable, but which I accepted, under a rationale that is not visible at the edit summary for that change. In order to prevent WP:Review warring (oughta be a section somewhere in MOS), I felt the need to explain the acceptance, which I did in this dummy edit immediately following. However, not everyone knows how to do that, plus it's cumbersome to do so and many will avoid it for that reason.

We need to have some easy method of exposing the acceptance comment, either directly, or one click away. Currently, following an acceptance, the word accepted in the history tag of the accepted pending change is wikilinked to the revision permalink for that item. However, this is useless information as it simply duplicates the permalink underlying the timestamp for the edit, and imparts no additional information. What I'd like to see, is the following:

Proposal: for accepted revisions that have no "accept" comment, unlink the word accepted and make it plaintext. for accepted revisions that have an "accept" comment, link the word to the log that contains the comment. I know I've seen this log somewhere, but I can't find it now. That would make the tag in the history look like this: [accepted by Username ] .

Alternative UX: sometimes it's hard to see a link that's only one word long. To make it more obvious when there is or isn't an accept comment, add another token (why, reason, log, or some such) to the acceptance tag, and link that, instead. Thus, no-comment acceptances would have three words ([accepted by Username]), and commented acceptances would have four: ([accepted by Username (reason) ]). In this alternative, you could keep the duplicate wikilink underlying accept as it is now, if desired. Mathglot (talk) 20:27, 13 April 2019 (UTC)

Hm; given the section above this one, I wonder if this would be better placed at VPP? Maybe I should move it? Mathglot (talk) 21:07, 13 April 2019 (UTC)
I would just suggest skipping VPP etc. and file a task in Phabricator instead, as this seems like a common-sense proposal. You might check there to see in fact if there is a proposal there already. --Izno (talk) 21:42, 13 April 2019 (UTC)
Good idea, thanks. Done. Mathglot (talk) 17:52, 18 September 2019 (UTC)

Proxy IP Pending changes blocks[edit]

After the question of school blocks was recently raised at Wikipedia:Requests for adminship/HickoryOughtShirt?4, a question was asked at the idea lab Village Pump about whether instead of blocking Proxy IPs, such as at schools or libraries, if they should be subject to pending changes instead to filter out vandalism from constructive edits (Except for those owned by the Church of Scientology, per Wikipedia:Requests for arbitration/Scientology. The reasoning behind the proposal is that while blocking such IPs prevent vandalism, it also blocks out any constructive edits from such IPs, which there are, and pending changes would give them a fair chance at making constructive edits while blocking out vandalism. Any thoughts on this, and whether such a proposal would be technically feasible? Thanks for your input. DrewieStewie (talk) 16:24, 1 May 2019 (UTC)

I think it'd be a useful change. I'm concerned it might fill our backlog to a mile high, though. Or maybe monitor it for a percentage of vandalism vs. constructive edits for a while and toggle the filter via that reading? I don't know nearly enough to comment on the technological feasibility of such an implementation. Elfabet (talk) 12:03, 16 May 2019 (UTC)

Q: Why are some changes accepted or reverted with a single click and some have an additional page of confirmation[edit]

Apologies if this isn't the place to ask, I'll strike and move it if directed to a better one. I'm fairly new to the tool and am wondering why some changes are accepted with a single click, and sometimes there's an additional confirmation page. Thanks! Elfabet (talk) 12:31, 2 May 2019 (UTC)

Pending change review fails to recognize edit conflicts[edit]

The review process fails to recognize partial edit conflicts, and passes through a reject even if an intervening edit by another editor has taken place since the review process started. This should be fixed by altering the review pending edit process to employ standard edit conflict procedures.

In this case at Paris, two pending edits by Wkedit004 (talk · contribs) were under review by me. I examined them using the pending change review process, decided that each of the two needed to be reverted, and added an explanatory message in the pending review input box explaining the reason for each (one was about POV statements; the other was about the incorrect replacement of the word manufacture), and hit the Submit button. While I was going through the process, SiefkinDR (talk · contribs) addressed the POV issue and reverted that one (here), unbeknownst to me. (I fully agree with their revert, which was for the exact same reason that I wished to revert it.) I must have hit the submit button right afterward, as the hour and minute on our two edits are identical.

SiefkinDR's submit was accepted, as well it should have been, because it came in first. However, my submit was also accepted, and it should not have been, because my input text, which was added to the process-generated edit summary, was now inaccurate, being based on a situation in the article which no longer existed. Someone doing a diff between SiefkinDR's edit and mine (diff) would see a diff rejecting "POV statements" in the edit summary which were incorrect; they would appear to attribute a simple replacement of the word "manufacture" as "POV", which is ridiculous. No "POV statements" existed at the point of my submit; they had already been taken care of. This Submit should not have been allowed to proceed.

The review process should have rejected my submit with an edit conflict notice, and required me to reload the current version, reexamine the new situation, and rewrite the review summary if a reject was still needed based on the new evidence. The current behavior of the review process is incorrect, and should be fixed. Mathglot (talk) 18:49, 9 September 2019 (UTC)

Seems right - if it can't be fixed sooner, we need to add it to this year's attempt to fix Pending Changes into the top 10 at the wishlist. Nosebagbear (talk) 18:53, 9 September 2019 (UTC)
  • This is not a problem with Pending changes, it's the default Mediawiki behavior and the extension that handles the conflict interface. Basically "edit conflict" occurs only when the software tried and could not resolve the issue itself. Imagine a page with these three lines:
    Line A
    Line B
    Line C
  • Then you open the editor and remove Line A and Line C. In the intervening period before you save, another editor removes Line C. Then there's no conflict here, the software is able to handle this. What normally happens is that you, (the second editor to save) you're actually only removing Line A from your revision. That's it.
  • Imagine another page with these two lines:
    Line A
    Line B
  • You open the editor and remove both Line A and Line B. Before you save another editor removes also Line A and Line B. By your logic, the software should report edit conflict to you when you now try to save, but that's waste of time and (inefficiency in terms of the software). So the correct thing to do (and what you'll see if you test above examples) is the software will just silently resolve the issue. It will show you the conflict interface when it fails to resolve it. What you're proposing is, unfortunately going backward. – Ammarpad (talk) 19:54, 9 September 2019 (UTC)
You're right that the edit conflict resolution procedure resolved the problem: that can be seen in the part of the revert edit summary cleverly constructed by the process: "Rejected the first 2 text changes (by Wkedit004) that followed revision 914752473 by El C:", that is, it explicitly recognized that it was not rejecting the subsequent revert by SiefkinDR. (Let's ignore the fact for now, that it only rejected one, and not "2 text changes" in that revert; that's small potatoes.)
However, that only means that the locus of the problem is perhaps not the edit conflict resolution procedure, but there is nevertheless still a problem that needs to be addressed. Consider the following scenario:
  1. Unconfirmed User:DevilTroll comes to Boris Johnson, and makes five edits, containing POV, violations of BLP, massive OR, vandalism, and finally, a typo, where they change colour to color (not necessarily in that order).
  2. User:GoodIntent sees this on the queue, begins reviewing. Makes up a detailed edit summary mentioning POV, BLP, OR, and V by name. Doesn't mention the typo in the summary; it hardly seems worth it amidst all the serious problems.
  3. User:FastTypist comes along moments later, edits the article outside the RPC process (possibly without clicking Undo), spots all the same things, quickly writes it up, and reverts the POV, BLP, OR, and V. In a sign of AGF towards DevilTroll (and maybe because FastTypist is a Yank), they leave "color" in place, even though the majority of the article is in UK English. They hit Submit, and DevilTroll's edits are all gone, with the exception of color, which remains.
  4. User:GoodIntent completes the process moments later, hits Submit. The RPC process appends GoodIntent's comment to the RPC-autogenerated version, creating the following edit summary:
    "Rejected the first 4 text changes (by DevilTroll) that followed revision 987654321 by PreviousUser: Reverted your blatant POV, BLP violations, Original Research, and vandalism in four sections of the article. Keep it up, and you're headed for a BLOCK."
  5. User:StillKindaNew comes along, notices what seems to be a long and rabid edit summary by User:GoodIntent for a change that is listed as "+1" byte from the previous version, and does a diff, to see what caused all the commotion. StillKindaNew sees from that diff, that GoodIntent merely changed the word color to colour. StillKindaNew takes GoodIntent to ANI, in their very first posting there, for misleading edit summaries, biting the newbies, lack of good faith, and casting aspersions at other users for things they never did. This seems like a slam-dunk.
  6. More experienced users at ANI point out what actually happened. StillKindaNew embarrassed and put off. GoodIntent embarrassed, grumpy, and annoyed, but realizes it's not really StillKindaNew's fault; wary about doing any more pending change reviews. Experienced users grumpy about yet another pointless discussion at ANI.
The problem may not be in the edit conflict resolution procedure, as it seems to have correctly resolved the conflict, as you pointed out. However, in that case, the problem is in the RPC process, which must not allow the procedure to continue, without a review of the edit summary. Failure to do this, means blind-siding the good-faith user into making a Submission without all necessary information, and subjecting them to at the very least, misunderstanding, appearing foolish, or possibly malevolent. That cannot be the desired outcome in a case like this. Mathglot (talk) 21:12, 9 September 2019 (UTC)
Hmm, it seems your problem is with the edit summary because it referenced something (that was removed in earlier revision, unbeknown to you). Since you understand my explanation of the edit conflict, I hope you'll understand that, there's no way for the software to know the relationship between the edit summary and the content you're removing. The only solution (that would work for you) was for the software to not save your edit (and reports edit conflict, so that you can amend your edit summary?) but I already showed why this is going backward in terms of the software's capabilities. There was no "conflict." There was nothing to hinder saving your edits. explicitly recognized that it was not rejecting the subsequent revert by SiefkinDR
The software was able to detect the revert by SiefkinDR because it can detect intermediate reverts, but it could not know the relationship of what he reverted and your edit summary. Only human can do that. To understand this more, imagine your edit did not have any edit summary.
However, I can agree with you that there's a problem (which may or may not necessarily be because of your case). In fact there are several problems with the Flagged review extension to the extent that its further deployment to any Wikimedia wiki is now halted. Worse more, is that even removing the extension is not easy. (I know there are many people on English Wikipedia who wish it could be disabled). And to be fair, even me, I shy away from any page where there's several unreviewed revisions plus reverts, intermediate edits and whatnot; it's a total mess there.
The issue you described above can only be remedied with WP:AGF and simple discussion now; until such time when the software can read edit summary which says "remove 3 words" and compare it with the actual edit which adds 5 words and reject the edit with the message: "Stop hand nuvola.svg Error: edit not saved, your edit summary is not accurate description of the edit". I will leave you to guess when this will happen. – Ammarpad (talk) 21:57, 9 September 2019 (UTC)
Yes, the problem is an edit summary, now invalid, due to intervening activity that I wasn't aware of. I understand your PoV entirely, because I have been involved in sw dev as well as the biz/functional side of things. Part of the problem when discussing such issues, it's that it's easy for conversations to become muddy or at cross-purposes, as one shifts hats from simply discussing functionality (it ought to work *this* way; it ought not to work *that* way), to commenting on design elements (*this module* is at fault; *that module* ought to be improved). I'm guilty of this, and probably started out all wrong at the top, saying what "PCR" "fails to do", or what "edit conflict procedure" ought to do. I shouldn't have done that.
Can we both take off the dev hats, and try a reboot? A more appropriate way to portray this, is by user experience: "I was using PCR, and had an unexpected and unfortunate result, when another user came along in the interim, and saved before I did. What can we do to improve this process?" and then see where that leads. I don't dispute anything you say above, it all sounds right to me. (As to the "guess when this will happen", my reply is: "around the time that MT is accurate.") It may well be that other procedures or constraints might improve that situation. I need to think about it.
My first thoughts, are wondering if allowing Pending review to automatically revert all contiguous edits by a user is part of the problem or not. As you say, you shy away from those. Have to think some more about this. In the meanwhile, would be interested in your thoughts, both with your UX hat, as well as your Dev hat (in highly contrasting colors and shapes, of course; I'm thinking maybe, a black, Lincoln top hat or "Freddy" (from My Fair Lady) formal gray for the UX hat, and a tricolor plush harlequin or Cthulhu hat (or take your pick) for the dev hat). Let me know. Thanks, Mathglot (talk) 23:01, 9 September 2019 (UTC)

Confirmed editors's edits not always automatically accepted[edit]

I've noticed recently that some edits by long-term editors are showing up pending review when it should be automatically accepted (they didn't edit on top of a pending review edit). Anyone know what's going on? Schazjmd (talk) 00:38, 10 December 2019 (UTC)

@Schazjmd: phab:T233561 DannyS712 (talk) 01:32, 10 December 2019 (UTC)
Thanks, DannyS712! Schazjmd (talk) 01:42, 10 December 2019 (UTC)