https://bugzilla.wikimedia.org/show_bug.cgi?id=64726
--- Comment #27 from jeb...@gmail.com --- 1) Discussions at WP:Tinget (virtually WP:Parliament) will end in a decision if there is sufficient consensus or there is a final vote. If people does not involve themselves they do know it will have implications for themselves. We have another forum WP:Torget (virtuall WP:Bazar) which is more like a QA, or a Vallage Pump -page. Discussions have been on-going about FlaggedRevs for a long time https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-23#Patruljering_og_pending_changes (one month long discussion leading up to this request) https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-33 (note about this thread) Some other threads https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2009-07#FlaggedRevs https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2010/januar#Flagged_Revisions:_Your_questions_answered.21 https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2010-10#Stabile_versjoner https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2010-24#.C2.ABPending_changes.C2.BB_eller_det_som_er_kjent_som_.C2.ABflagged_revisions.C2.BB_tas_i_bruk_p.C3.A5_en-wp https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2009-35#Nytt_system_for_redaksjonell_kvalitetssikring_av_artikler_p.C3.A5_engelsk_Wikipedia https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2009/oktober#Kvalitetssikring It is a long time since we set up patrolling as a replacement for FlaggedRevs https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2007-41#Utvidelse_av_RC-Patrol_.28inntil_vi_evt._f.C3.A5r_stabile_versjoner.29 At nowiki we have had patrolling for a long time, here is our page for information about this process https://no.wikipedia.org/wiki/Wikipedia:Patruljering 2) Because we already have patrolling in place I can't see any big changes in the present process if we switch to FlaggedRevs, especially with the configuration we want, as this will create a process very close to the present one. Some of the limits we want is although a bit strange, they are set fairly high for Autopromote, but that is because of present consensus on what should be used as limits for patrollers and autopatrollers. The configuration we want is a minimum footprint where we only block access to unpatrolled pages when the situation is highly troublesome, and then only for å very limited number of pages. I guess that will be pages that intersect with themes from public school. Normally we do not protect pages at nowiki to avoid vandalism, we block the vandals. The number of patrollers are declining, even if it is still pretty high. https://no.wikipedia.org/w/index.php?title=Spesial:Brukerliste&offset=&limit=500&username=&group=patroller I would like to signal very clearly to editors that they get additional features as they build trust in the community, and let the FlaggedRevs be one of those additional features they gain access to. I think that can motivate people to become reviewers and perhaps also to stay active. There is a problem that we have to little metrics/stats on the impact of this extension. Even so I don't think nowiki should solve those problems, I think that is something for WMF. One way to do this could be to classify user actions, and then formulate a total workload the community is able to handle. This has implications not only for patrolling (or page review) but also for other actions like categorization or spell checking. I have looked at how we could better track the number of unrevied pages, as a kind of quick and dirty metric, and how to better match that against the number of reviewers. One option could be as simple as setting a fraction (num active reviewers / num unreviewed pages) and if it becomes to high a visible marker will be set somewhere on the reviewers webpage. That should be fairly simple and should be sufficient to keep control on the number of unreviewd pages, and if that does not work we can simply remove pages from flagged review. A configuration change like this is not the proper place to discuss additional development work, but it could perhaps be a place to identify the problems and to initiate new bugs that describe new product features. It is correct as Erik write in his last note, we want $wgFlaggedRevsOverride to be set to false so we avoid the huge buildup of unreviewed changes. Whether this is sufficient we do not know, but we hope it will be. As such it is more like what they use on fiwiki. Our intention was to "keep what we knew work at our present patrol scheme, but add additional tools". -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
