I was told by several users that this was not the case before last configuration update of Flagged revs.
Can we please go back to "Pending changes" tab being active when a page with unreviewed edits loads?
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Re-apply wgFlaggedRevsOverride = false on ukwiki | operations/mediawiki-config | master | +1 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T225144 Flagged Revs configuration may be broken | |||
| Resolved | Reedy | T227260 Last reviewed revision is shown to logged-out users in ukwiki instead of last revision |
Event Timeline
Comment Actions
Setting as high priority because it break Ukrainian Wikipedia patrolling workflow.
When we requested to enable Flagged Revisions to Ukrainian Wikipedia in T35273 we explicitly requested that:
- All users (including unregistered) see latest version of article
Since 2012 our workflow was built based on this assumption. We have relatively strong patrolling criteria which go higher than only vandalism/non-vandalism. For example, if a newbie adds a bunch of text which is neither vandalism nor copyvio but lacks sources, we will probably not patrol immediately and wait for a patroller who knows the topic. This works when all users still see this version, as newbies are happy to see their edits live.
Since June 2019 newbies cannot see the latest version because of T225144 . Since then we receive very negative feedback from new editors, for instance, from a professor who added highly-specialised content to a popular article but who was very unhappy that his students could not see this change. This badly impacts our capacity to attract new users as they cannot show their edits to others.
Can this be fixed ASAP please? We have raised this issue two months ago, and it breaks our FlaggedRevisions framework.
If this is not resolved for months we will have to change patrolling rules, but we are really, really not willing to do it.
Comment Actions
@Reedy @Quiddity
Is anything being done on this?
It has been two months since we raised the issue, and three months since it was broken.
We have a school year starting this Monday (2 September), and all our education initiatives will end up in a fail: new users improving existing articles will not be able to show their edits to each other.
Could you please explain where is the delay coming from? If this is Declined, than please tell this so that we adapt our patrolling framework accordingly (e.g. assigning patrolling rights to all education programme trainers). If this can be done, what is the blocker?
Comment Actions
Hmm, problem may be just because 'ukwiki' => false is missing from wgFlaggedRevsOverride setting in InitialiseSettings.php ?
Comment Actions
@NickK No, just a report exists. The fact that there are problems with flaggedrevs was announced via tech news. I know it doesn't help much, but FlaggedRevs is a very complicated extension, highly customizable, and for that reason, not a lot of people know in detail what all the variables mean. For instance, I know in detail how much of site configuration works (and is loaded), and know why a configuration option can look to not take any affect, but not how many extensions works internally, including FlaggedRevs. In another words, this is possible to fix, should be investigated, just no one did the work yet. Please expect this to take weeks to months, not days or weeks. I understand it is a problem for you, but this has relatively low impact globally speaking. Anyway, most stuff can be done by anyone, without any special rights. You can look if this is bug in flaggedrevs, in configuration loading process (and where exactly there) or just because flaggedrevs changed meaning of a variable and configuration is now wrong. The fastest way to get something fixed is to help fixing yourself. Not sure how much technical knowledge you have, just mentioning for completeness.
As a rule of thumb, if someone is working on a task, he or she will say so as a comment and/or set themselves as an assignee. Before that happens, no one did anything other than saw a report. The same happens when someone formally declines a change. That is rarer, but happens.
Comment Actions
Yes, I think so. We clearly did have 'ukwiki' => false in wgFlaggedRevsOverride , see, for instance, P6964 . I am pretty sure this got lost at https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/ce6fc704629e95836fc04113b9d63661727f8030%5E%21/#F0 but I don't know why.
@Urbanecm I don't have any dev access on Wikimedia so I can't fix this myself. I do think that @Zache made a reasonable suggestion. Can you or @Zache please look at it? Thanks!
P.S. This has already taken months, two months to be more specific.
Comment Actions
https://github.com/wikimedia/operations-mediawiki-config/commit/3889520408d133cb49d82b000836478a7d647577#diff-e5cc5cd3aad93462d5d6a1249360a419 is the commit that removes that block of code from flaggedrevs.php
If we look at the flaggedrevs.php file from the revision before that...
It wasn't set in the big if statement, where for example it was for ruwiki - https://github.com/wikimedia/operations-mediawiki-config/blob/3889520408d133cb49d82b000836478a7d647577~1/wmf-config/flaggedrevs.php#L91
It was there at the start of the year... https://github.com/wikimedia/operations-mediawiki-config/blob/a157d142da6f915259e3794007fe8a9507bc7b4f/wmf-config/flaggedrevs.php#L654
I remove it from the copied callback in https://github.com/wikimedia/operations-mediawiki-config/commit/8c7e6a016bc8164927c9f12bc5199bc49d32612e#diff-e5cc5cd3aad93462d5d6a1249360a419 which means I erroneously didn't copy it in https://github.com/wikimedia/operations-mediawiki-config/commit/f30c50e2ffaa3f9b370527016b5272368918ae8a#diff-e5cc5cd3aad93462d5d6a1249360a419
Comment Actions
Change 534185 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Re-apply wgFlaggedRevsOverride = false on ukwiki
Comment Actions
Change 534185 merged by jenkins-bot:
[operations/mediawiki-config@master] Re-apply wgFlaggedRevsOverride = false on ukwiki
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2019-09-03T15:55:40Z] <reedy@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T227260 (duration: 00m 54s)
Comment Actions
I do want to apologise for breaking the extension for ukwiki, but this is kinda the crux of the issue. It's a complicated extension that not many people understand, but people are left to maintain it. And we are human, so mistakes happen
The feature you report as being broken isn't naturally mapped in their head as to which config it may reflect to. While the fix is evidently easy, and wasn't too difficult to track down where it went missing, until you (or someone else) had narrowed it down to said config flag, it's kinda hard to diagnose and fix
Comment Actions
@Reedy I think that we are happy that you are maintaining it and thank you for fixing the configuration.
Btw. i catched the configuration bug because the ukwiki's and fiwiki's configuration should be more or less same. Configuration still worked in fiwiki so I checked what was the difference.