Wikimedia Meta-Wiki

Talk:Flagged Revisions

Latest comment: 4 years ago by Voltairacus in topic RFC on stable vs. latest versions

discussions on other projects

edit
Latest comment: 14 years ago1 comment1 person in discussion

Have there been any discussion about this software on the other big Wikipedia like Italian, Chinese, Portuguese & Dutch? John Vandenberg 01:09, 1 October 2010 (UTC)Reply

Changing settings

edit
Latest comment: 12 years ago1 comment1 person in discussion

Hi, at he.wikisource we would like to change the settings of Flagged Revisions so that only for pages rated "excellent" in all categories does the user see the last approved version as default. Can anyone give us some advice for how to do this? (E.g. request at Meta, file a bug report requesting exactly what...)

Thanks, Dovi (talk) 12:12, 24 August 2012 (UTC)Reply

Comparison of some Wikipedias

edit
Latest comment: 10 years ago10 comments5 people in discussion
(copied from [2]) ruWP has Pending Changes (PC, or Flagged Revisions or Patrolled Revisions or Gesichtete Versionen or ...- i'll just call it PC) since 2009 (kind of, cp. Flagged_Revisions#Flagged_Revisions_on_Wikimedia_projects) and i don't think ruWP is a good example to follow. Much better example is polishWP and they are comparable to ruWP in both number of articles and number of active editors (see pl:Special:Statistics vs. ru:Special:Statistics). PC on plWP works quite good, like on deWP. PC on ruWP is terrible, on arWP too:
So, why the big differences?
1) Status assignment procedure. On plWP and deWP users get PC right automatically at some point (number of unreverted edits XYZ, I'll leave aside the difference of active or passive reviewers for now), plus users can request PC right for themselves or somebody else. On ruWP and arWP users have to ask for PC right, discuss and be eventually denied. Not surprising: There are far fewer users with PC right, and bigger delays. Reason for different procedure is a bigger (perceived?) vandalism problem on ruWP and arWP (well, egg/chicken first ... see RuWiki_History/English) Quite a power trip, denying PC status ^^.
2) Review policy. On deWP users with PC right only have to look out for vandalism. Not quality control, not "endorsing" edits, not reverting unsourced edits (except unsourced sensitive info on BLP). Users apply higher personal standards for their review anyway, but the rule is simple, low standard: just revert vandalism. Higher standards, more rules for PC -> less adoption, less users reviewing PC, higher delays. I read that ruWP applies higher standards for PC than deWP.
This is IMHO, of course. See also relevant analysis/ discussion on deWP: [3], [4] (mostly german, some english, you'll understand with googletranslate). Hope this helps. --Atlasowa (talk)
Indeed, FlaggedRevisions is severely broken on several Wikipedias; comparing more wikis will give you even more interesting results, in my experience. What's worrying is that nobody in the community seems to care and, also, a lot of effort (and money) is being spent on some of those projects (e.g. WMF on ar.wiki), without investigating whether FR is killing community health making all the rest pointless.
The 2010 analysis by Erik Zachte, simplifying, proved that there was no noticeable reduction of vandalism on de.wiki following FR implementation. However, the data is very old; hopefully we'll get Bug 46212 – Dump stats: update edit/revert stats monthly fixed soon and then the community will have more tools to understand what's going on. --Nemo 07:35, 19 March 2013 (UTC)Reply
  • fi:Special:ValidationStatistics: average review delay: 7 h 45 min; average review delay for IPs: 1 h 43 min; median: 18 min 35 s (937 user with PC (editor) right 262 with autoreview -right and 58% of articles are reviewed).
Status assignment procedure: right is mostly given to editor which edits are ok by administrator without any request or prior notification. Users can also request PC right for themselves or somebody else. Biggest problems with this are users which edits are generally good or very good, but they have also problematic edits too like copyright violations. Also the distribution of the editor/autoreview rights doesn't seem to run by itself and and somebody will need to specifically do it or too few users will get the right. (this is bad thing). Good thing is that with the non-automatic procedure admins can thank users for the good work and it seems that users like that. :) Manual procedure is also pretty accurate. 2) Review policy. Target is same as in dewiki; just revert vandalism. However as in dewiki users apply higher personal standards for their review anyway and there is statistical increase in reverts. I think that unsourced edits are reverted easier than before. Also in fiwiki there has been target that review backlog should be small so it will not start accumulate. This is main reason why review delay is so low in fiwiki compared to dewiki or plwiki. Zache (talk) 20:09, 19 March 2013 (UTC) Corrected the number of autoreviewers. --Pxos (talk) 20:29, 19 March 2013 (UTC)Reply
Thank you Zache, very interesting. I see that fiWP enabled PC in November 2011, relatively recent. How do you know about the statistical increase in reverts? (Link?) Regarding thanking new users/autoreviewers/editors when notifying of new rights: That is excellent, this is not done systematically on deWP, afaics. Regarding review backlogs, deWP sometimes does "review calls" on Kurier (Signpost), you can see the effects in the review stats. This works rather well, because the backlog does not grow beyond 10.000 articles (7-8.000 mean) and because every "editor" (user with active PC right, not just autoreviewer) has a backlog on his watchlist. And there are a couple of tools, like:
Deep out of sight unreviewed articles in chosen category, by Magnus Manske
Random out of sight 20 random unreviewed small edits, by Magnus Manske
Hannes’ Tool similar to Magnus' tool, more features
List of users by number of unreviewed edits by Hannes Roest
List of articles that have never been reviewed, by age by Hannes Roest.
This is the good stuff. --Atlasowa (talk) 14:22, 20 March 2013 (UTC)Reply
99,43 % of deWP articles are currently sighted/reviewed, 8.252 articles have an unreviewed edit (including ~500 articles never reviewed yet) --Atlasowa (talk) 14:32, 20 March 2013 (UTC)Reply

I think PC is a great tool. It's very, very effective against vandalism and spam. I read a study about enWP showing that "~10% of damaging edits are viewed by 100 persons. Deeper analysis shows that many of the associated survival times are quite short, and these are often the result of damage to extremely popular articles. ... While practical writings have often focused on the time to revert of damaging edits, we argue that the quantity of persons who view it is the more relevant metric. Vandalism that survives for days on an obscure article is effectively harmless if no one visits that article." This doesn't happen with PC, readers don't see unreviewed/vandal edits. Only logged users and the vandal (cookie) see the vandal edits, until they are reverted minutes later (or hours, days). This also means that the "recent changes" patrollers have less pressure and a less nervous "revert by huggle finger" - other editors will see the edit in their watchlist and will often be more competent on the article subject and on the merits of the edit. This is also very good for quality, articles get better, not worse. It discourages bad editors and POV pushers in practice. But it also frustrates good new editors, to some point, unfortunately. And yes, with long backlogs this is an even bigger problem on ruWP and arWP:

  • A german user about ruWP: "I sometimes make small edits in the Russian Wikipedia and PC there bugs me mightily. The PC backlog is long, long, and the requirements for PC are far higher (not just "no vandalism"). Therefore, it is almost a rule that pages that I am working on stay unreviewed for months if I did not explicitly ask for screening."
  • Another german user about ruWP:"For instance, although I had for a long time already collected more than 100 edits, I had to apply myself to get passive PC right there."
 
Results of Arabic Wikipedia Reader Survey 2012
  • A commentator about arWP in october 2011: "the main problem i have with Arabic Wikipedia is their stupid adoption of flagged revisions since 2009. They don’t have enough active members and editors to make this work. A lot of articles and great contributions are blocked because no one has the time to review them. I made a few edits back in 2010 and some more in 2011 and 90% are still pending and waiting for one of the few editors to take a look at them. I hope this issue will be discussed on some level at this meeting because on Arabic Wikipedia it is completely ignored by the admins. Apparently it pleases them to hold this kind of power and they refuse any sort of dialogue about it. Add to this, the fact that most editors/admins are from Egypt/KSA meaning that you have almost no chance to have your article approved if it concerns other Arab countries like Sudan, Tunisia or Morocco. Why? Because they simply don’t care about some historical event or some town in Sudan or Algeria."
  • arWP had a poll about flagged revisions in october 2011 with 77 users, and they decided in November 2011 to cancel the automatic grant of "editor" right.

Frustrating good new editors is indeed a problem, not just on ruWP and arWP, also on deWP. In this respect I think there is still a lot of room for improvement:

  • a) If a new user made at least 150 good edits in 30 days (for passive PC right: autoreview) and 200-300 good edits in 60 days and fulfills all conditions (many conditions! on deWP) he gets PC right automatically (editor). Do you think this user gets congratulations, an explanation of his new status, a welcome? No, he doesn't even get a notice about it. Nothing, unless some editor does it. Really. A dozen a day in the log, not even an automatic message.
  • b) Reviewers get a link on top of their watchlist, to a feed of "unreviewed edits of pages on your watchlist". You practically get a feed of newbies and IPs editing in your area of interest! Yet we're not using this systematically, there are only individual editors that make an effort to reach out to newbies through this.
 
1 click to accept or reject pending change in the diff. When rejecting you can give an edit summary explanation, but not when accepting the good edit
  • c) Newbies systematically get negative feedback through PC, not positive feedback: A new user makes 10 good edits. 9 good edits get reviewed and pass without edit comment by the reviewer (because he can't comment when accepting the edit, technically). 1 good edit lacks a citation and is rejected by the user with PC right with an edit summary explaining the incompetence of the new user. So this good new editor gets 9 x no feedback and 1 x negative feedback (assuming he sees the reviewers edit summary or just sees his edit disappeared). Frustrating. And this good newbie needs at least 150 good edits in 30 days to have passive PC right (autoreview), a long way to go... and did I mention that he won't even know about this big step, never mind get the inherent positive feedback? (->b)
  • d) What terrible things would happen if we relaxed conditions for PC rights, from 150 good edits to 80 (autoreview), or from 300 good edits to 150 (editor)? What good would it do? We don't know. Active editors immediately forget how things worked before they had PC rights. When PC started in 2009, deWP had 6500 users with PC rights, it's 13000 users now in 2013. Shouldn't this be more? Maybe this is OK on deWP, but on other WP, arWP? How to find out?

Again, I think PC is great, deWP would be worse without it. But it could be made even better. Regarding c), I'm actually working on a proposal for an EditLove button (or WikiLob, Edit-like, WikiThanks, whatever ;-) to give quick positive feedback to IPs and new users from the article diff.--Atlasowa (talk) 15:44, 20 March 2013 (UTC)Reply

Thanks for your thoughts. I had read that article on en.wiki pageviews, but it didn't calculate how many pageviews each vandalism likely got, it only esteemed aggregate results: punctual (?) stats would be very hard because we only have hourly stats and we can't know exactly what cached version a user was served (cache lasts 30 days for anonymous users, parsing time varies etc.). As for reverts, I think our amusing Finnish colleagues have their own statistical tools, if I remember correctly? But yes, we are all craving for better statistics. If you found some German user/dev interested in knowing more, maybe he could submit patches for WikiStats, or try and run the scripts on the dump alone. --Nemo 18:19, 20 March 2013 (UTC)Reply
BTW, regarding this idea for an EditLove button (or WikiLob, Edit-like, WikiThanks, whatever ;-), there is a new mw:Extension:Thanks#Usage, which is very similar (but unrelated development, tied to Echo). See also mw:Extension_talk:Thanks. Very good step, yet still bugs and not used.
 
What makes you less likely to edit?
60% of editors whose edits had been reverted without any explanation said that this made them less likely to edit, while only 9% of editors whose edits had been reverted with explanation felt less inclined to edit. (Videovortrag von Barry Newstead (WMF) hier anschauen, Wikimania 2011)
And regarding revert stats, Erik Zachte of Wikimedia is asking Which single Wikimedia metric would inspire you most? Revert stats may be not exactly inspiring, but very useful, seeing how much new users dislike unexplained reverts (arab readers above, and all WP readers). --Atlasowa (talk) 16:08, 16 April 2013 (UTC)Reply

Erik Zachte has produced new edit and revert stats, but I don't really see a correlation of revert ratio with the introduction of pending changes:

I'd love to hear some interpretation though! --Atlasowa (talk) 11:22, 29 July 2013 (UTC)Reply

As part of the request from the Norwegian community at Bokmål to set up Pending changes I dived into the configuration other projects are using. Some of the setups are really asking for troubles. Using the tool to block direct publication should be used sparingly and only on articles with real problems. If an article often get vandalized, then set it up for review before publishing but do not use it simply because you think the article is pretty or nice or important or whatever, but set it up for review only to block vandalism. It is no problem if you want additional quality metric, but don't use them to block direct publication.
If there is any change to a version, especially if that concerns visibility, then the user should be notified. That is in fact more important for positive actions than negative actions like an revert. Negative actions comes with rather massive reporting, positive actions not so much so. I know it is time consuming to write summaries, and often I simply don't do it myself, but they are still rather nice. Instead of manual edit summaries they could be made by some automatic means. That would probably be good enough as long as the edit isn't reverted.
You need autopromotion of users to editors and reviewers, but you also need a way to override this. The setup for autopromotions hould probably take the history of the user into account, but very few of the setups actually do so. I would really like to see some numbers on how various configurations affects the number of promoted editors, I'm not sure there are any stats on that anywhere.
I would say set $wgAutoConfirmDate and -Count to 7/20, set AutoPromotion to 31/150 for editor and 100/500 for reviewer. That would make the limits count and it will also be something that tells the user "hey, we are starting to depend on you".
Over time you will only see a minimal increase in reverts after introduction of pending changes on a project, but you will see a radical decrease in time before revert. Perhaps even better, you should use metrics for pageviews before revert in the case of vandalism. You should also note that reverting vandalism is a long tail effect, and as such you will run into problems if you try to take mean of the distribution, taking the mean of a long tail distribution fails.
I would also like to have much better quality assessment tools, I think most of what we have now is to simple, but that is another discussion. — Jeblad 14:45, 17 August 2014 (UTC)Reply
IMO the higher revert counts (in DE:WP) after the introduction of the FR is related to a more "revert vandalism by its edit" approach. Actually most edits are patrolled and confirmed or reverted individually while before the introduction of the FR a significant higher part of vandalism was found later, many only after other users already had edited the article, and throwing out such vandalism needed "classical" edits not reverts. That was also, IIRC, because the possibility of reverting older edits for non-sysops was enabled with the introduction of the FR only. --Matthiasb (talk) 13:21, 30 August 2014 (UTC)Reply

Rejecting norwegian and allowing chechen WP ?!?

edit
Latest comment: 10 years ago8 comments3 people in discussion

I really can't understand what on earth WMF people are thinking.

  • Bug 64726 - FlaggedRevs for Norwegian (bokmål) Wikipedia was filed by Jeblad, no.wikipedia made a reasonable decision for testing a moderate FlaggRevs Version and requested the activation on bugzilla. They demonstrated consensus, just as expected, and they even already translated the extension. And then WMF rejected this as RESOLVED WONTFIX ! And why? James Forrester: "I vaguely remember that we wanted to stop people using it as it didn't work out well for communities (making editing harder and scaring away far more people than it brought in), but I can't find anything from a quick search." to which Nemo replied "There wasn't any such discussion, only some "private" grumbling by people dissatisfied with its usage on mediawiki.org etc." So some WMF people decide based on hearsay, without knowing anything about norwegian WP vandalism, editor retention, recent changes patrol, without showing any knowledge at all about norwegian WP, and for all we know they don't even speak a word of Norwegian. But, they decide: No. WONTFIX. And no, they don't bother to come to no.wikipedia to explain or discuss (no:Wikipedia:Tinget#Implementering_av_pending_changes). Unbelievable. And besides RESOLVED WONTFIX, User:Eloquence/ Erik Moeller announces that they would need "some time (through August)" to give a reason and develop a policy...

And on the other side, the careful approach of noWP is rejected. Norwegian WP has about the size of Finnish WP, which handles FR very good, see above. User:Nsaa, Jeblad, Nemo, can anybody explain what is going on? --Atlasowa (talk) 19:41, 16 August 2014 (UTC)Reply

Whats really strange is that the project already does edit patrol in a rather clumsy way right now and this would have given us better tools. Blocking this change keeps a high burden on the users that do the patrolling, instead of easing the burden by giving them better tools.
I have heard an explanation and that says someone wants to make a better tool. After following some of the discussions for threaded discussions (mw:Extension:LiquidThreads, mw:Extension:Flow) and for page curation (mw:Page Curation) I seriously doubt that it is a wise move to await some future solution. (Threaded discussions are now up for yet another GrandScheme™) Pending changes exists and I can't see any valid arguments against its use as long as the community wants to try it out. — Jeblad 14:54, 17 August 2014 (UTC)Reply
Atlasowa, the explanation is rather simple. 1) The WMF doesn't care about ce.wiki while it cares about no.wiki because it's a bigger one. 2) A person or two at WMF dislike FlaggedRevs and did not learn how to use it, so getting rid of it on one more wiki has become a point of honor. But let's wait a bit, Erik promised some reasoning by the end of the month; we've long waited for tools to assess FlaggedRevs and if the WMF finally manages to produce something useful and convincing we can only be happy. --Nemo 14:43, 19 August 2014 (UTC)Reply
Thanks Nemo, that sounds like a plausible explanation. (...) --Atlasowa (talk) 13:25, 25 August 2014 (UTC)Reply
I cut off the rest for a new section/topic --Atlasowa (talk) 10:46, 29 August 2014 (UTC)Reply

Erik Moeller has now commented on the bug, "Reopening the bug since we're open to enabling it provided due diligence has been done." Go read the rest. I'm not sure he understands that noWP is asking for testing of pending changes only, not full scale flaggedrevs. Although, that wouldn't be a bad way towards full adoption, if noWP decides that they want to expand after testing. I just found another FlaggedRevs adoption that is not listed here on meta:

And Portuguese WP is using a "Pending changes" configuration, just what noWP wants too. [8]. Bugzilla does not even have a tracking bug for FlaggedRev implementations and bugs? --Atlasowa (talk) 11:00, 29 August 2014 (UTC)Reply

Ah, there is a tracking bug for FlaggedRev implementations, Bug 29744 - FlaggedRev installation requests (tracking), Status: RESOLVED WONTFIX 2014-08-08 by James Forrester. :-( Anyway, it doesn't track: Bug 54828 - FlaggedRevs for Portuguese Wikipedia (enabled in October 2013); Bug 56408 - Enable FlaggedRevs extension on ce.wikipedia (enabled January 2014) --Atlasowa (talk) 13:18, 15 September 2014 (UTC)Reply

UPDATE

--Atlasowa (talk) 12:39, 15 September 2014 (UTC)Reply

Ignored bugs on FlaggedRevs for stats, "gesichtet"-notifications

edit
Latest comment: 10 years ago8 comments3 people in discussion

I cut this off the above section as a different topic --Atlasowa (talk) 10:46, 29 August 2014 (UTC)Reply

There used to be some tools for stats about German flagged revisions on the toolserver ([9]). Unfortunately WMF and WMDE decided to kill the toolserver, so this is dead now. I have collected some of the few available stats and data about flagged revisions, see de:user:Atlasowa/gesichtete Versionen.

Is this the brave new "superprotected" Wikipedia, with WMF devs deciding at will without boots on the ground? And without any assessment of flaggedrevs, for years? It makes me sick. --Atlasowa (talk) 13:25, 25 August 2014 (UTC)Reply
Well, I answered that the dedicated team (Growth) can likely provide a way better and informed answer than I can to your question "is editor engagement still a priority?" because I don't know all their plans and priorities. Did you ask them? Your constructive arguments on bug reports why certain problems should get more attention, in order to make developers and product management see the impact of the related problems, are welcome. --AKlapper (WMF) (talk) 15:44, 25 August 2014 (UTC)Reply
I see that Bug 52510 might be an important fix for the atmosphere in which newbies are growing into the community, I am appalled that this was ignored so far. --Matthiasb (talk) 13:44, 28 August 2014 (UTC)Reply
AKlapper (WMF), as a mw:Bugwrangler, your duties are to, among other things:
  • Work closely with product managers and developers to prioritize, categorize and assign bugs based on Mediawiki features and extensions
  • Work with members of the community who report bugs to clarify any ambiguity in the bug descriptions and get all the information required to reproduce the bugs
  • Manage expectations about deployment of fixes and communicate the status of major bugs to bug reporters
  • Work with product managers and developers to improve the process of bug submission and bug status workflow
  • Communicate widely and frequently via mailing lists, IRC, wikis, and bug tracker comments
Sorry, but: What did your working closely with product managers and developers do to prioritize those bugs? What did you do to improve the bug status workflow for Bug 52510? What should our "expectations about deployment of fixes" be, this year, next year, 2020, never ever? If you can't answer the question if editor engagement is still a priority, but send me on errands to the Growth team, that, too, is an answer... --Atlasowa (talk) 19:12, 1 September 2014 (UTC)Reply
Which specific bug reports don't have a value set in the Priority field? If you disagree with the priority value, feel free to provide good technical arguments in the bug report to convince Product Managers to give it a higher priority. Patches (no matter who provides them) normally speed up things. I'm not a speaker for all teams and cannot track closely everybody's plans for the next quarters (which should be publically available on wikipages like mw:Wikimedia_Engineering for anybody interested in the larger point of view, if something is planned in that area), so maybe the descriptions on mw:Bugwrangler are misleading and need to be clarified? bugzilla:52510 has the Priority field set to High and has an assignee set so not sure what else is requested here. Have you asked the assignee about how to proceed in the ticket? --AKlapper (WMF) (talk) 18:58, 3 September 2014 (UTC)Reply
  • bugzilla:52510 has not been touched in the last half year. Whatever its bureaucratic status may be. Go read the last bugzilla/gerrit comments.
  • You can see in bugzilla:52510 that i have pointed out repeatedly the importance of this bug already 1 year ago.
  • In october 2013 Fabrice Florin answered "Dear Atlasowa, thanks for following up on your request for a 'Flagged Revisions' notification. It's a very reasonable proposal, and you make a good point that it would provide much-needed positive feedback to offset edit reversions. But new feature development for Echo has now ended for this release. (...) We have added your request on our wish-list for future releases, as Quiddity points out above, but we don't expect any major developments until next year. (...) Thanks again for your thoughtful recommendation, which I endorse, but sadly cannot act on at this time, due to limited resources. Fabrice Florin (WMF) (talk) 21:25, 11 October 2013 (UTC) [10]"
  • I asked Erik Moeller for help, "@Atlasowa: Wir schauen, was machbar ist. Ablehnung einer Revision durch das FlaggedRevs-Interface sollte bereits eine Echo-Benachrichtigung auslösen [51] - was in der Tat unausgewogen ist. Danke für den Hinweis!--Eloquence (talk) 00:12, 1 November 2013 (UTC) @Atlasowa: Legoktm wird naechste Woche einen Versuch machen, weitere Benachrichtigungen fuer FlaggedRevs zu implementieren. Wir werden das wahrscheinlich noch nicht gleich beim Start haben, aber hoffentlich bald.--Eloquence (talk) 02:30, 14 November 2013 (UTC) [11]"
I haven't met a single person that says this is an unimportant, minor issue, all agree this should be done asap. But no progress at all, and bugzilla:52510 has been practically abandoned since half a year.
AKlapper (WMF), do i understand you correctly that you intend to do nothing at all to get this bug fixed? --Atlasowa (talk) 20:39, 4 September 2014 (UTC)Reply
My questions above were if you've recently asked the Growth team for an update and if you have asked in the bug report how to proceed with the request. I have done the latter now on the ticket. --AKlapper (WMF) (talk) 16:56, 9 September 2014 (UTC)Reply

Success in German Wikipedia

edit
Latest comment: 10 years ago19 comments8 people in discussion

As far as I know, Flagged Revisions by now is seen as a full success in the German Wikipedia. The continued use of "sighted versions" after the pilot phase was approved by the community in 2008 in the poll Weiterführung der gesichteten Versionen (and again in another poll in 2010). They are now deeply incorporated in our everyday workflow and the backlog of versions to sight is dealt with in a fairly efficient manner. It really helps fighting vandalism and has taken away quite some stress, I think, as vandalism isn't shown to the public. Probably there are also not as many semi-protections of pages needed as it were the case if we didn't have that feature. Although not directly connected, I also think that the fact that German Wikipedia still allows the creation of new articles by non-logged in (IP) users - as opposed to English WP - may be related to this: Although newly created articles are visible anyway, a generally less stressful fight against vandalism means people also can patrol new articles with less pressure. - So, after the good experience of German Wikipedia's community with sighted versions, I really can't understand why the Norwegian Wikipedia shouldn't be able to use it as well. It's quite ironic what the Wikimedia Foundation is currently doing, isn't it? On the one hand, a feature is activated even if people are strongly opposed (Media Viewer) and on the other hand, if people really want a feature (Flagged Revisions in Norwegian Wikipedia), they're denied its use! So, apparently, the WMF knows always better what's good for the community than the communites themselves? - What I certainly can say is that the anger in the German Wikipedia after the "superprotect" debacle would be nothing compared to the uproar if it were attempted to take the flagged revisions away from them after the community has repeatedly confirmed their use. Gestumblindi (talk) 20:41, 28 August 2014 (UTC)Reply

1. --Julius1990 (talk) 21:11, 28 August 2014 (UTC)Reply
1, definitely. → «« Man77 »» [de] 21:59, 28 August 2014 (UTC)Reply
It's indeed a shame that no scientific study was ever performed to assess/confirm the success of FlaggedRevs on de.wiki. We now face the risk that people without knowledge of FlaggedRevs make irreversible decisions about it. Complex features like FlaggedRevs were always community-driven (especially so on de.wiki; without WMDE, FlaggedRevs would never have happened) and what's good for de.wiki is not necessarily good for another. --Nemo 06:18, 29 August 2014 (UTC)Reply
Sure, but I believe there is noone better to decide what is good for a certain projekt than it's contributers. The Norwegians have thought this through and decided, and the WMF is just hitting them in their faces. When I see Jimbos naive questioning on his talkpage in en:wiki and his statement that the roll out would have been generally a failure, he shows neither a bit of understanding of the quality processes (and everyone should remember that the quality of our products is the biggest asset) nor respect for the community decisions made. --Julius1990 (talk) 06:47, 29 August 2014 (UTC)Reply
But please note that - if i understand Jeblad and noWP discussions correctly - the Norwegian WP wants to test the enWP "pending changes" setup (per article activation), not the deWP "gesichtete Versionen" (for 100% of articles). --Atlasowa (talk) 07:30, 29 August 2014 (UTC)Reply
The en.wiki-centric contributors have naturally a biased view of FlaggedRevs: as they invested a lot of effort and money in it, with no real outcome, they tend to reflect their own failure on the extension itself. This is very human, I wouldn't read too much into it. --Nemo 07:34, 29 August 2014 (UTC)Reply
Atlasowa, if you read my comment carefully then you see that i say that every editor community needs to decide what fits best to their needs. And Nemo, if you read the comments made by the Foundation staff on Jeblads request for activation then you will maybe understand why from my side (especially after all the mess of the last weeks) there is even less than no good faith to assume on side of the Foundation. --Julius1990 (talk) 07:50, 29 August 2014 (UTC)Reply
MeatBall:AssumeStupidityNotMalice. --Nemo 09:09, 29 August 2014 (UTC)Reply
I prefer this version: de:Hanlon’s Razor, but meatball is probably the more, uhm, actionable version :-) --Atlasowa (talk) 10:07, 29 August 2014 (UTC)Reply
Julius1990, my note was for general information (see Gestumblindis text), not specifically aimed at you. --Atlasowa (talk) 10:07, 29 August 2014 (UTC)Reply

The german Wikipedia shows definitifely that Flagged Revisions are not demotivating. In opposite! They are motivating because a lot of new users actually want get this right and working for gaining it. It is a right that gives them more accountability for the content and the project. This helps to keep them inside the project. The idea that Flagged Revisions are demotivating for new users is only a prejudice. - In addition the Flagged Revisions do actually what they are meant for: They help to protect the project against vandalism. Actually the readers will not see a version which is vandalised in the german Wikipedia. So maybe it would be good survey to ask the reader themself if they prefer an encyclopedia where edits of registered users are supervised by experienced users or if they rather have an encyclopedia where the content can be in any bad condition and you will never know what you get when you access an article. Which would be more trustfully for them? --Micha (talk) 08:33, 29 August 2014 (UTC)Reply

Micha: "... shows definitifely that Flagged Revisions are not demotivating. In opposite!" "The idea that Flagged Revisions are demotivating for new users is only a prejudice." I disagree, it is definitely frustrating for new users. See my text above, #Comparison of some Wikipedias. That doesn't mean that the advantages do not outweigh the disadvantages (they do, IMHO), or that we can't make gesichtete Versionen more newbie-motivating (we should). But being in complete denial about the negative side effects really doesn't help, neither the discussion, nor the extension gesichtete Versionen. Can we agree on that? --Atlasowa (talk) 10:16, 29 August 2014 (UTC)Reply
Well, IIRC there was/is some conflict in the RU:WP. It may be politics, certainly some POV issue why the backlog in RU:WP is extreme. Perhaps similar reasons with AR:WP? --Matthiasb (talk) 12:58, 30 August 2014 (UTC)Reply
Hi Matthiasb, i wonder if my interpretation of the russian FlaggedRev backlog is mistaken. Since readers by default see the non-patrolled version (all edits go directly live), except for some chosen articles where only the "stabilized"/gesichtete Version is shown to readers. Compare some unreviewed russian article logged-in/logged-out. Maybe the russian FlaggedRevs are even better than deWPs? Russian FlaggedRevs was switched on 5.08.2008, second after the German Wikipedia and Patrolling interface switched on for all autoconfirmed users 25.09.2009. Polish and German WP have a different FR setup, compare below. --Atlasowa (talk) 17:13, 30 August 2014 (UTC)Reply
Atlasowa: "I disagree, it is definitely frustrating for new users." No, it's not. I work as a Wikipedian in Residence in the National Library of Switzerland and I asked the new user which have now begun to write a lot of article if they think the FlaggedRev are demotivated. No they think FlaggedRev are a good idea. A lot of people following my presentation were surprised that FlaggedRev are only implemented in the german Wikipedia and not also in the english and french Wikipedia. That are the fact if you really listening to the people. --Micha (talk) 22:06, 31 August 2014 (UTC)Reply
And for the statistics you shows us. I agree with you: For IPs which do vandalism or are just spaming the FlaggedRev are really demotivating. That shows the statistic very impressive. --Micha (talk) 22:11, 31 August 2014 (UTC)Reply
The idea, that IP edits are same the same like new users edits, is wrong. IP edits can also be edits from experienced user. So there are many ways to explain a reduction of IP edits. The first is that it is believed that new users are demotivated because they have to wait some minutes or hours until their edits are seen by others. But that doesn't explains it. Some people which edit anonymously are actually demotivated. And that are first of all spammers and vandals. For example: Students stting in the class room and they have to read about a historic topic. So it is funny to write "Melissa stinks" in an Wikipedia article Melissa might soon read on her laptop. If they find out, that this edit will never be read by Melissa the fun is gone and they will not edit again in this way. So actually FlaggedRev demotivates the right way here. This demotivation is actually wanted. Another explanation for the reduction is that users which have edited anonymously in the past because they found an account is not necessary have now begun to edit with an account to gain the rights. So you see only a shift from anonymous edits to logged-in-edits. For the community it is a positive effect if people open an account. It is easier to recognize such users and talk to them via their talk page. - So if you try to find out statistically if the FlaggedRev have an effect on motivation then don't compare only the anonymous edits. Compare the article growth, the new users growth and the change of the edits in total instead. --Micha (talk) 22:39, 31 August 2014 (UTC)Reply
 
Evolution of anonymous edits (IP) in 6 Wikipedias, Felipe Ortega [1]
Sorry for not writing before, but I had to take a break and do some other stuff. I don't think FlaggedRevs in either configuration demotivates good editors, but it might very well demotivate bad editors. A good editor would get a feeling that someone checks her edits, and when they are approved the editor will get a good feeling as her edits are good enough. I don't think those effects are bad, I think it is just what we want.
The proposed setup on nowiki was to allow edits to go live as fast as possible, but still provide our present patrollers with better tools. I don't think the tools are very good, but they are better than the ones the patrollers have right now. Patrollers are what we call reviewers in the current setup. The patrollers at nowiki are really efficient and try to go trough all the changes each day. This is exactly what FlaggedRevs was made for.
There are a number of improvements that I think should be made (There is a long list of bugs for FlaggedRevs)
Tracked in Phabricator:
Bug 70452
  • Changes should not go live for some mask of addresses given by the editors IP-address before it is patrolled. A cookie should keep track of the editors own machine and let him see his own edit, while other users that does not hold this cookie will not see the edit. That would make it impossible for students to write "Melissa stinks" when the purpose of that is to show that to Melissa.
Tracked in Phabricator:
Bug 70453
  • Patrollers should be able to hide revisions with contagious content, or they should be able to tag it so an admin can later hide it. Now we keep such material in the history, but in a lot of jurisdictions that is actually illegal – it must be removed from public access.
Tracked in Phabricator:
Bug 70456
  • The number of pending changes that must be patrolled should somehow be weighted against the number of active patrollers. If the number of patrollers drops below a certain limit warnings go off and informs the patrollers that the situation is about to get out of control.
Tracked in Phabricator:
Bug 70457
  • The number of pages protected such that they must be patrolled for all changes should be limited to a number reflecting the mean number of patrollers. If the number of pages goes above a certain limit it should not be possible to protect any more pages. If that number is to high the unpatrolled edits will start to accumulate, but the number could be dynamically estimated from the number of pending changes.
Tracked in Phabricator:
Bug 45222
  • Something similar to the previous two can be done as a timeout, possibly also as a dynamic timeout.
Tracked in Phabricator:
Bug 70458
  • Ordinary users should be able to tag contagious edits. If an edit is tagged in such a way it should be removed from public view and temporary put in the list of protected pages needing review.
  • It is important that an user has a progress through new, confirmed, editor and reviewer. That can be done by setting up the Autoconfirm/Autopromote accordingly. This is very important as it gives the new user a feeling of trust and participation. As it is now the user is given very little feedback about such changes in the rights. It is extremely important that she gets such feedback.
Tracked in Phabricator:
Bug 52510
  • It is very important that the user gets feedback on the edits, no matter how insignificant. This is only the patrolled edits and it will not be that many of them. I think template-based feedback is sufficient as long as it is text-feedback and not icons galore.
  • actually I think the new pages triage is a good idea, but slightly off. There should be a new pages triage and a new editors triage. If either the page or the user is new there is a need for more feedback than usual. In fact it can be argued that whats needed is new editors triage and not new pages triage.
Tracked in Phabricator:
Bug 49770
  • AbuseFilter integration. I really thought this worked…
As it stands right now I think FlaggedRevs creates an opportunity to better the quality, even if it is not quite what it should be. — Jeblad 18:26, 5 September 2014 (UTC)Reply

Vandalism in Google infoboxes

edit
Latest comment: 9 years ago6 comments2 people in discussion
File:Wikipedia vandalism in Google infobox from flagged revisions stabilized article 25.2.2015.png
screenshot of Google search with vandalism from Wikipedia

Today morning when I reverted some vandalism I noticed that the vandalism which I just reverted was visible also in Google's Knowledge Graph (see screenshot, vandalism is marked by red arrow). Second thing what i noticed was that Google is using latest version even when the source page of the information in wikipedia is stabilised to stable revision and new changes were pending.

Technically what happened was next:

25.2.2015 06.48‎ AM
some IP added text "patrik on homo" (translation: Patrik is gay) to stabilised page Suomi. revid of vandalism: 14701781
25.2.2015 06.54 AM
I reverted it. (revid of revert: 14701787)
25.2.2015 06.54 - 06.59 AM
I checked the google result for keyword "Suomi" with my iPad to see if the Flagged revision infobox of Suomi was included to search results after CSS change.(we had some problems with visibility of the FR notifications in search results when FR was enabled) It wasn't so everything was as expected. However I noticed that the vandalism was in the Google's infobox which I didn't expect.
25.2.2015 06.59 AM
I checked also the search results for keyword "Suomi" with my computer and it was clean (Knowledge Graph was already updated?)
25.2.2015 07.16 AM
I reloaded the web page in iPad and it's search results was also clean from vandalism.

Anyway it would be nice that if Google would index only the stable versions like what Google News is with Wikinews doing (see Wikinews:User:Brian_McNeil/Google_News), but I don't know how this should be done or if it is possible. So my questions is do anybody know how this is handled in other Wikipedia's or have any ideas how to solve this? --Zache (talk) 08:33, 25 February 2015 (UTC)Reply

Hi Zache, german Wikipedia had a similar experience a year ago, it made several news headlines ^^:
I don't know what the situation is currently, check:
I saved the links some time ago, which is lucky because phabricator is a mess when you're trying to find something. 6 bugreports for the same thing, and apparently WMF is doing absolutely nothing, for years. Ping User:Erik Moeller (WMF). --Atlasowa (talk) 19:14, 25 February 2015 (UTC)Reply
Thanks for the links. One intresting information was that Wikipedia uses <meta name="robots" content="noindex,nofollow" />-tag to prevent indexing of the pending versions of the stabilised pages. About the bugs; To get forward I think the real question in this case is how the notification of the updates to the Google index and Google Knowledge graph is done. Is Wikipedia/Wikimedia sending notifications to the Google after the change or is the Google pulling the changes from Wikipedia via mediawiki API or RSS and what kind of the information it is using. After there is some information about how system works it can be discussed what to do about it. However thing is that it seems that only ones who can answer to this is somebody from WMF or Google. --Zache (talk) 07:58, 26 February 2015 (UTC)Reply
Hi Zache, i believe that Google is pulling the Wikipedia changes via API, but not sure and i have no link, sorry. Also interesting is en:User:FacebookBot (en:Wikipedia:Bots/Requests_for_approval/FacebookBot, Apr 19, 2010 Re: Heads up: Wikipedia on Facebook, en:User_talk:Philippe (WMF)/Archive_6#Facebook_updates_of_Wikipedia_articles) but i haven't really seen any more facebook community pages with automatic Wikipedia content lately (maybe facebook only pulls images from Wikipedia by now: [12][13][14]). HTH. --Atlasowa (talk) 09:44, 26 February 2015 (UTC)Reply

Bug 17475 - Index (for search) sighted revisions only on de-wp Last comment Jan 17 2014: "We'll add a hook to FlaggedRevs to support it." - which nobody does, instead in nov 2014: "Chad lowered the priority of this task from "Normal" to "Lowest"." --Atlasowa (talk) 11:02, 26 February 2015 (UTC)Reply

T71430 - Hovercard extract should not display an unflagged revision Inkowik created this task Aug 12 2014, Jaredzimmerman-WMF triaged this task as "Low" priority Dec 3 2014 --Atlasowa (talk) 09:44, 10 March 2015 (UTC)Reply

Phab workboard / Bugzilla: FlaggedRevs = abandonware?

edit
Latest comment: 9 years ago5 comments3 people in discussion

Hi all (ping Zache, Jeblad, Nemo, excuse me for being bold). Could someone with access to phabricator please go through the bug/phab lists above and add them to phab workboard: mediawiki-extensions-flaggedrevs? (see also FlaggedRevs list at old-bugzilla, search for "flagged" at old-bugzilla, search for "pendingchanges" at old-bugzilla). Not even T31744 - FlaggedRev installation requests (tracking) is on the list, and its status is "Closed, Declined"? Is Flaggedrevisions now officially abandonware by WMF? --Atlasowa (talk) 10:55, 10 March 2015 (UTC)Reply

T31744 does not belong to that component, because it's not about the extension code but about configuration. The extension has not been in active development for over 5 years, I think. That said, unlike most of MediaWiki code it does have an assigned maintainer, according to [15]: I suggest that you ask him whether he confirms said status. --Nemo 17:13, 10 March 2015 (UTC)Reply
Thanks for the link, Nemo, i didn't know there are assigned maintainers. --Atlasowa (talk) 10:42, 11 March 2015 (UTC)Reply
Atlasowa: Did you ask Aaron what is the status of the flagged revisions? --Zache (talk) 19:08, 23 March 2015 (UTC)Reply
No, i didn't. I started to search for "Aaron Schulz" and forgot about it. --Atlasowa (talk) 19:46, 23 March 2015 (UTC)Reply

Autoreview autopromote

edit
Latest comment: 9 years ago7 comments4 people in discussion

Hi, we are currently discussing in Finnish Wikipedia our Flagged Revision settings so that the autoreview would be autopromoted. Currently we are granting the autoreview rights by hand which is highly accurate system. Problem with it is that it is manual work and too few users tend get the right which also means that there is more edits in the pending change queue. In example if we are comparing fiwiki and dewiki then in dewiki there is a 82.3% of ns0 edits and 50.7% of editors are automatically reviewed. For fiwiki numbers are 69.1% of edits and 27.9 % of editors and one big reason for that the dewiki is doing better is that the users are getting autoreview right faster because the autopromote system.

Anyway i am asking (@Atlasowa:, @Nemo:) if somebody have experiences what kind of settings would be good and what caveats there is? Currently the target is something like what is in in use in dewiki (30d minimum age, 50-150 edits etc) see flaggedrevs config here) --Zache (talk) 14:19, 4 August 2015 (UTC)Reply

new ping for @Nemo bis: --Zache (talk) 14:19, 4 August 2015 (UTC)Reply
I'm not aware of specific discussions on de.wiki, I can't tell whether they're happy with the outcome. I notice however that some wikis (like pl.wiki?) have stricter configurations; I don't know if there are specific reasons.
The de.wiki configuration seems sensible, what statistics could give some insight? Perhaps a SQL query can count how many autopromoted users get "unreviewed" or even demoted, would that be useful? --Nemo 16:05, 4 August 2015 (UTC)Reply
That actually was good idea, though i do not know what to think about results. If my SQL query is correct then after 2012-01-01 in dewiki 82 users with autoreview right and 28 with editor right have ever lost their autoreview and editor rights. 17 users with editor right is changed to autoreview. Numbers for plwiki is 6, 111, 9. Numbers for fiwiki are 17,17,289. However numbers are skewed in fiwiki we have removed the editor rights from passive users and correct number seems to be more like 20. --Zache (talk) 15:53, 5 August 2015 (UTC)Reply
Can you put those numbers on a statistics table on fi-wiki (Zache/stats/temp...)? --Pxos (talk) 16:02, 5 August 2015 (UTC)Reply
Hi Zache, good question. Afaics there are no big discussions about gesichtete Versionen recently or in the last years. There are some returning discussions about implementation (see de:Wikipedia_Diskussion:Gesichtete_Versionen), some people want higher standards/rules for review ("no vandalism edits" -> "no bad edits") but this would need a successful Meinungsbild (and chances for that are minimal). There is still a very small minority that is opposed to gesichtete Versionen on principle. But the majority considers gesichtete Versionen a success (see #Success in German Wikipedia above). I think we should actually discuss lowering the conditions for automatic Sichterrechte (see stats de:Wikipedia:Fragen_zur_Wikipedia/Archiv/2013/Woche_43#Anzahl_Benutzer_mit_Sichterrechten_in_de-WP) but this is not really happening. Since the discussions in 2012 that i linked to above ([16] [17]) there is very little change. If anything, then i think the loss of toolserver-statistics about gesichtete Versionen had the effect of less attention/awareness of backlogs, and i don't remember any recent "gesichtete Versionen backlog drive" calls at Wikipedia:Kurier.
The only new and interesting (short) discussion was IMHO about gesichtete Versionen and ConflictOfInterest/paid editing (de:Wikipedia_Diskussion:WikiProjekt_Umgang_mit_bezahltem_Schreiben/Archiv/2014/2#PR-Accounts_mit_Sichterrechten?, de:Wikipedia_Diskussion:Gesichtete_Versionen/Archiv/2014#PR-Account_mit_Sichterrechten). We have "verified accounts" on dewiki, which are mostly COI users (but not only those), and the discussion was about making exceptions for them and not giving them Sichterrechte as usual. (This "verified accounts" concept developed over time: A username "Angela Merkel" or "Siemens-PR Manager" would be blocked or renamed per enwiki policy, per dewiki policy they would be asked to confirm by OTRS-email or be blocked. There is a "verified account" template, a cat and some tools, but very little control/patrolling by dewiki volunteers) The rules weren't changed, see discussions why. --Atlasowa (talk) 09:29, 5 August 2015 (UTC)Reply

Will the autopromote keep adding the bit also to users who have been demoted by hand? What if we don't want some users to be promoted automatically, how can this be avoided? --Pxos (talk) 14:55, 5 August 2015 (UTC)Reply

Statistics

edit
Latest comment: 9 years ago3 comments2 people in discussion

--- discussion is splitted from "Autoreview autopromote" topic by Zache --Zache (talk) 13:59, 5 August 2015 (UTC)Reply

I really love your stats fi:Käyttäjä:Zache/merkityt_versiot_tilasto_201506, http://tools.wmflabs.org/fiwiki-tools/fr_stats_report_9.html! Awesome! I don't remember seeing that, i need to look at this more closely :-) and make some screenshots! Also, i now refound toolserver tools by de:Benutzer:Hannes_Röst: https://tools.wmflabs.org/hroest/ , cool! And the toolserver tool valstat by User:Dapete is noted as Work in progress (porting old ~dapete/valstat Toolserver tool), so there is hope. And i have seen some interesting quarry queries by you and others: http://quarry.wmflabs.org/Atlasowa.

Re: "what kind of settings would be good and what caveats there is?" I would recommend dewiki-settings, but start with lower entry barriers. It is easier to readjust for higher standards than for lower. dewiki-settings can be very hard. Check/compare the numbers of new "editor" and new "autoreviewer" over time for different WP settings? --Atlasowa (talk) 09:29, 5 August 2015 (UTC)Reply
Thanks. There is also fr_stats_report_9.html data as json. About those numbers: I have fetched all the for different wikis with same SQL-queries and i have expected that there is "reviewer", "editor" and "autoreview" usergroups in use (like in fiwiki and dewiki). However there is other configurations too. In huwiki in example there is group like "trusted" for autoreview and editors are editor sysop's but my code counts only "autoreview" and "editor" users.
I also could also point something which may or may not be interesting. In finnish Wikipedia we have gadget which creates a link "Odottavat muutokset" with number of the length of pending change queue under the recent changes link in the left menu bar. (I added editor rights for you Atlasowa and Nemo if you like to check it out and it should be enabled by default). At middle of February we changed our system so that the link started to point to pending changes of the important articles only. I also made gadgets which users could use to select the categories which they wanted to follow. Reason for the change was that we though that if users could select the things which they are interested they would be better reviewers. (and not just revert the changes) Also we tried to slow down the handling of the pending changes so that users could find the pending changes via their watchlist. One expected result was that the number of pending changes would be lower because user would be reviewing more changes at once.
It didn't work out too well. Generally positive outcome was that review speed was slowed down and number of pending changes increased so that there was always something to review, there was also more reviewers and number of the reviews per day was down around 20% as expected. However the bad thing was that the reviewing of important articles which was linked under the recent changes was also slowed down. In the editor point of view before the change the number of editors was growing and after the change number of editors dropped to last year level and in Erik Zachte's revert graph there is also spike for the reverts of the anonymous edits which doesn't exist in my graph. I do not know if it is error in my or Zachte's graph. At mid june there was discussion about how "seulonta" doesn't work any more. At end of the june i rebooted (by reviewing the pending changes queue daily to zero) the pending change queue cycle back to the one day. July was full month with fast reviewing but there is also seasonal effects to the editor counts so I cannot yet say what is effect of that. After this month i will plan to revert the link change too to see if it will restore the reviewers. :)

In the below is graphs about the change in different directions --Zache (talk) 13:59, 5 August 2015 (UTC)Reply

  •  
    Fiwiki edit trends 2015-06-10
  •  
    Fiwiki edit trends 2015-06-10
  •  
    Review distribution of whole time
  •  
    30d median of daily edits 201212 - 201507
  •  
    30d median of daily editors 201212 - 201507
  •  
    30d median of daily edits year to year difference
  •  
    30d median of daily editors year to year difference
  •  
    number of montly editors year to year diff

RfC Flagged revisions deployment

edit
Latest comment: 8 years ago1 comment1 person in discussion

user:Dereckson added a comment to phab. Thu, May 12, 2:28 PM To get feedback from the global community on the FlaggedRevs deployment opportunity, I've launched a RfC on meta.

--Zache (talk) 15:42, 12 May 2016 (UTC)Reply

RFC on stable vs. latest versions

edit
Latest comment: 4 years ago1 comment1 person in discussion

2020 RFC on stable vs. latest versions on certain Wikipedias: Requests for comment/Flagged revisions should display latest versions Voltairacus (talk) 20:53, 6 December 2020 (UTC)Reply

All pages are not approved

edit

Hi there, After updating the mediawiki version from 1.15 to 1.35 I have a problem. All pages are marked as requiring approval. Changes are shown in the page history, but the page is not validated. Any idea what to do?

Add topic
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Flagged_Revisions&oldid=22848307"
Return to "Flagged Revisions" page.