Help talk:Extension:FlaggedRevs

Since a lot of people editing this particular help page are not active on mediawiki.org generally, there are a few special considerations here that don't apply anywhere else. First and foremost, remember that the edits you make to the help page are released into the public domain, so anyone can use them for any purpose. If you don't want that, don't edit. Secondly, remember that this documentation must be "site-neutral": this is the main website for all X many thousands of wiki installations on the web, not just wikimedia, and not just wikipedia. As such, we need to avoid wikipedia-specific content: no links to en.wiki discussions, and avoid wikipedia-specific terminology, even things like NPOV and BLP: other wikis might not have the same considerations. This is supposed to be a completely neutral explanation of how the system works, not how it might be used.

By far the most important thing is to get the content actually on the page; style and presentation issues can be resolved later. Remember that this should be aimed mainly at the lay-user: an editor who is aware of how to edit but knows nothing of the intricacies of the MediaWiki interface. Obviously this general rule needs to bend a bit in cases: when talking about how FlaggedRevs affects the recent changes feed, naturally we assume that the reader of that section knows what the recent changes feed is. Similarly the section describing admin actions is aimed at administrators. But in general, pitch the documentation at the lowest level that's sensible.

Much can be gleaned from the implementations currently in operation on Wikimedia, including en.labs, test.wiki and de.wiki (although remember that all content, including screenshots should be in English). There is also loads of information available to those who can read the appropriate 'language', at the manual here, the source code on SVN, the Wikimedia config files, and all over en.wiki. Don't hesitate to raise any questions here or elsewhere; hopefully this can be a learning process for all of us.

Many thanks in advance for any assistance you can provide, Happy ‑ melon 19:03, 28 January 2009 (UTC)

en.labs
It is safe to say the the version of FlaggedRevs running of en.labs is the default MediaWiki version? Dbiel 21:37, 28 January 2009 (UTC)
 * Yes, certainly for now. Happy ‑ melon 22:21, 28 January 2009 (UTC)

FlaggedRevs software and MediaWiki
Is FlaggedRevs currently running on MediaWiki? It would be helpful to be able to link to some pages to show some of the default views as they relate to FlaggedRevs. Dbiel 22:07, 28 January 2009 (UTC)
 * Unfortunately not, so the special pages eg Special:OldReviewedPages, don't exist here. Screenshots would be very helpful; there are quite a few already uploaded - have a look at the manual page and see what we can pinch; you can link images from commons here too so we can use anything from over there. Happy ‑ melon 22:21, 28 January 2009 (UTC)
 * As an update to this old discussion... Here on MediaWiki.og we are now using FlaggedRevs, and you can see Special:OldReviewedPages (or Special:PendingChanges as it's now called) -- Harry Wood (talk) 10:38, 9 May 2013 (UTC)

This is difficult
Since everything is customizable, it may not be possible to write this to the level of the average user and remain "site-neutral". You have to use examples, which by their basic nature are not "site-neutral".

I have attempted to list some terms used, but am finding that the terms themselves are not "site-neutral". Dbiel 03:07, 29 January 2009 (UTC)

User Groups
Since user groups appear to be site specific it is hard to come up with non site specific names

The following is copied from http://en.labs.wikimedia.org/wiki/Special:ListGroupRights

Reviewers

 * Automatically mark revisions as sighted (autoreview)
 * Automatically mark revisions in non-main namespaces patrolled (autopatrolother)
 * Edit semi-protected pages (autoconfirmed)
 * Mark others' edits as patrolled (patrol)
 * Mark revisions as sighted (review)
 * View list of unreviewed pages (unreviewedpages)

Uber-Reviewers

 * Mark revisions as sighted (review)
 * Mark revisions as validated (validate)

autoreview

 * Automatically mark revisions as sighted (autoreview)

New copy
I have decided to work on a copy at http://en.labs.wikimedia.org/wiki/Help:FlaggedRevs where I can be site specific, link to pages and actually test things to make sure it makes sense which just can not be done here or in en.Wikipedia at this time as the software is not running in either of those two wikis at this time. Dbiel 04:30, 29 January 2009 (UTC)
 * That's probably a good idea; as you point out above, being able to link to the special pages etc is very helpful. And en.labs needs documentation anyway, and there it needs to be site-specific.  Would you mind releasing your edits there into the public domain so any relevant material can be copied between these two pages? Happy ‑ melon 14:29, 29 January 2009 (UTC)


 * I was under the assumption that all edits were automaticly released into the public domain unless stated otherwise as in the case of fair use images; but just in case that is not true, I do so grant release of any of my edits into the public domain. Dbiel 00:44, 30 January 2009 (UTC)

Editor - Reviewer
Editor (sighting) & Reviewer (Quality), more logical would be Sreviewer and Qreviewer, call a spade a spade, no problem to convert it on a dev level, its confusing. Mion 14:37, 29 January 2009 (UTC)
 * This does not relate to this page, as you are talking about site specific implementations. This is an attempt to document the basic software only, independant of site specific issues. I am personally finding that very difficult to do, so have moved over to en.labs. There the documentation is to be site specific. But even there, it is not the right place to talk about changes, that needs to be done in en.Wikipedia. The documentation as it will be written for en.labs will be very different from that written for en.Wikipedia. For example in en.labs IP users see the draft version, not the stable version. Dbiel 00:44, 30 January 2009 (UTC)

Surveyors (administrators)
Strange group. As it is written now, it seems indistinguishable from ' '. Ruslik0 18:39, 29 January 2009 (UTC)
 * w:en:Wikipedia:Flagged_revisions/Sighted_versions, yes Mion 10:40, 31 January 2009 (UTC)
 * There is more strange :Added rights (from Extension:FlaggedRevs)


 * review, autoreview, validate, stablesettings, patrolother, movestable,feedback
 * Mion 22:57, 29 January 2009 (UTC)


 * Actually this is not strange at all. You are still thinking about the discussions from en.Wikipedia. The list above is the actual software rights that relate to the extension. When working here we need to totally forget about anything being discussed or implemented in en.Wikipedia as it just does not relate. Dbiel 00:53, 30 January 2009 (UTC)
 * The example is taken from 2 current practices (DE and PL) of course new examples can be added, what is the function of "patrolother" ? Mion 10:09, 31 January 2009 (UTC)

Enabling / disabling FR on articles or categories
I know you can make FR available per namespace. However, on our wiki we would ideally like to enable it only for one or more specific categories. I haven't been able to figure out how to do that...is there a way?

Failing that, we're left with a situation in which any article in the main namespace comes under revision control as soon as a reviewer rates/reviews it. Sometimes, a reviewer will mistakenly rate/review an article that shouldn't be under FR, so we'd like to be able to remove it from revision control. Is there a way to do that? I know an admin can set it to display the draft revision by default (which effectively bypasses FR), but we'd like to remove it from FR control altogether. Is there a way to do that?

Thanks! --Crandmck 18:06, 26 August 2009 (UTC)

I don't understand $wgFlaggedRevTags
How do settings in $wgFlaggedRevTags relate to the terms described here? I find this page is clear, readable and understandable, but I don't see how to relate the concepts here to the required settings in $wgFlaggedRevTags. For example, from the man page:


 * - An associative array with keys corresponding to each flag type and values that are arrays of three settings - 'levels','quality', and 'pristine. 'levels' controls the number of review levels, while 'quality' decides what level the tag must be for a revision to be 'quality'. The same goes for 'pristine'.

''For example, for the tag configurations, suppose one wants to have "accuracy", "depth", and "tone" tags, with 3 levels each. The admin also want revisions with at least "accuracy" and "depth" of the 2nd levels to count as "quality". The following settings will do that:'' #

What is 'quality' and 'pristine' above, and how does it relate to the 'stable' and 'non-stable' page aliases?

Cheers, --Dmb 08:15, 1 October 2009 (UTC)

Notification banners too obscure
The notification banners (shown here as images) for the current version (top), and the stable version (bottom) seem to me impossibly obscure. They require the reader to understand technical specifics of the underlying Wiki implementation. While this many not violate any implementation guideline, it is very confusing to the casual reader, who may need to know only that this is the stable version or the latest but unreviewed version of the page. Why not put the technical information and links on a separate page, where it won't confuse the reader, or omit it entirely? David spector 00:30, 5 January 2010 (UTC)

Changing the output
Is there a way to change the output, given from language/FlaggedRevs.i18n.php without editing the file?

for example: 'revreview-accuracy-2'        => 'Accurate',

I want to change this output to 'foo'. Is there a way to redefine that value in the LocalSettings.php? If i change it in the i18n-File, I must do it after every update of that extension. --213.214.18.64 07:58, 14 January 2010 (UTC)
 * All message keys, like 'revreview-accuracy-2', have a MediWiki page, like MediaWiki:revreview-accuracy-2 that can be edited. Aaron 21:31, 14 January 2010 (UTC)
 * Thanks, that helps a lot :) --213.214.18.64 08:06, 15 January 2010 (UTC)

the term "sighted" is obscure and misleading
Summary: "sighted" is in-group jargon. Change it to something understandable.

This extension's use of the word "sighted" is obscure. Seeing "sighted page" with an eye icon (on Manual:Configuration, "manual" page), I assumed that this meant I was looking at the normal version of the page for sighted users, and that there was another version optimized for screen-readers, magnifiers, and/or other access tools for blind users and those with limited vision.

When clicking on the link brought me to this page, I was still puzzled for a while. The lead paragraphs give no clue, and in fact the word is not mentioned at all in the article, only in the table of flags, leaving the user to guess at what it might mean. Well, I guessed pretty quick: The first appearance is on the scale of Accuracy: Obviously it was a misspelling of "cited", meaning either
 * 1) Unapproved
 * 2) Sighted
 * 3) Well sourced
 * 4) Accurate
 * 5) Featured
 * a) that someone else had used the page as a reference or
 * b) that it includes references

Except that (a) would be a poor basis for approval, and (b) is not the usual meaning of "cited". But of course, as it turns out, it's neither of these. It means approximately "Some reviewer has seen the page".

This is a very poor basis for putting this word in a position of prominence as a user's first point of contact with these ratings. After 40 years in research and academia, here's one universal I've learned about communication: Whether you're a researcher or a programmer, whenever you talk about your work, whoever you're talking to, you have to use language they understand. In the English-speaking world at large, "sighted" means Yes, it's also a form of the verb "to sight", but that's not what comes to mind.
 * having sight ('clear-sighted' 'a sighted person'). (Merriam-Webster)

Maybe "reviewed" implies a higher level of approval than you want, but it would still be better than "sighted". Or say "seen".

--Thnidu 21:47, 20 January 2010 (UTC)
 * That term is already being phased out (though german wikipedia will keep using it). Aaron 17:59, 22 January 2010 (UTC)
 * That's a relief; thank you. What word is replacing it? (n English, that is; the ambiguity is specifically in English. --Thnidu 22:45, 25 January 2010 (UTC)

get a kind of wikipedia Featured behaviours ?
I hope this is the right place to ask my question. I installed flaggedRevs on our wiki and I want to have a simple way to get all the "featured article", I mean all the pages with a certain level of quality, in order to display one of them on the index page. Is that king of functionaly has been already implemented or how can we simply have that by a sql query ?

Thank you in advance

--Melliol 08:41, 22 January 2010 (UTC)

Page show wrong level
I can't get it right. My settings are: 'accuracy' => array( 'levels' => 3, 'quality' => 2, 'pristine' => 3 ), 'depth'   => array( 'levels' => 3, 'quality' => 2, 'pristine' => 3 ), 'style'   => array( 'levels' => 2, 'quality' => 2, 'pristine' => 2 ), But when i review a page to level 3, 3 and 2 everything seems to goes well. But when i refresh the page, the review levels always show, level 2, 2 and 2? Is there some default values ore something?

It lookes like the level that is saved is always one level lower that that i've selected.

Ploegvde 09:05, 17 June 2010 (UTC)

undo "approval" and "reviewed"
Hello,

Is there an easy way to 'undo' approval/review. An article that has been erroneously marked 'quality' can be reset to 'reviewed' or even 'draft' but keeps getting listed op Special:OldReviewedPages - Arent 11:10, 4 January 2011 (UTC)

changing the language
Hello,

where can i change the language? It is german and englisch at the same time. Is there an constant?

Is there a function to show which user have reviewed?
Hello,

I want to edit the systemtext: MediaWiki:Revreview-basic, that the follow text will be generated:

"This is the stable version, checked by Testuser on 14 May 2012. 1 pending change awaits review."

→ It is possible? --80.149.179.2 15:04, 15 May 2012 (UTC)

Only revisions flagged to a certain level are the default view
Hi, in the introduction to this help page it states:


 * "It is possible, however, to configure pages so that only revisions that are flagged to a certain level are visible when the page is viewed by readers"

At Hebrew Wikisource, we would like to reconfigure the extension so that only pages at the very highest approved level will be viewed as the default, while for pages flagged at lower levels the default will be the current version.

Is this possible and if so how can it be accomplished? Thanks, Dovi (talk) 19:34, 25 August 2012 (UTC)

Stabilisation action tab not shown
I'm struggling with the impenetrable jargon and low standard of English used all over this project, but this paragraph struck me as especially obtuse:


 * Some group on the wiki, usually administrators, have the ability to use the special page Special:Stabilization to override the default display for unregistered users. Administrators can set a page to display the stable version by default, and can also control how the stable version is selected, choosing which marker is preferred.


 * 1) The paragraph does not explain that the page is accessed via an action tab at the top of each reviewable page. I had to dig through the code to discover this rather essential piece of information.
 * 2) The tab does not appear to a sysop under the default setup, or any other set-up that I can identify. This makes knowing about it particularly useless.
 * 3) The default display is not for 'unregistered users' it is for non-reviewers, as is made clear elsewhere. Sloppy language is one of the main causes of support issues.
 * 4) There is apparently no configuration setting to set the global default level at which a non-reviewer will see the stable version instead of the current one. It seems to be a per-page setting, which is no use to me.

Automatic unapproval of pages for periodic revision
Hi all,

I love this extensions. Hopefully someone can help me with a question.

I want to be able to set a time period after which a previously approved version will become unapproved (eg after 1 year). This will lead to the page needing to be re-approved by a reviewer. The idea is to be able to use flaggedRevs as a means for scheduling annual reviews.

In my wiki, once the pages have developed into a stable form there will not be frequent edits, and annual reviews will only be required.

How would one go about implementing this? Any ideas or suggestions?

Cheers Tony


 * Do you mean pages or revisions? --Nemo 16:33, 27 August 2015 (UTC)


 * Hi Nemo. Thanks for the reply. I mean revisons.
 * I am thinking about a automatic annual unapproval process for stable versions, to support scheduling reapprovals.


 * I am guessing a function would be required to constantly check the approval date of approved pages, and then remove the approved status when a year has passed.


 * I am new to MediaWiki and any ideas would be gratefully received.


 * If all old revisions are unapproved, the page stops using FlaggedRevs and users will always see the latest revision. Hence unapproving all old revisions has the same effect as approving all latest revisions, in the short term.
 * The easiest way for you to ask a new review is probably to add a new revision: you can run a bot that just adds a space somewhere, then users with that page in watchlist will receive various notices that there are revisions waiting review. All this makes sense only if you have 100 % pages reviewed though. --Nemo 10:54, 28 August 2015 (UTC)

Electronic Signature / Password Required for Approvals
Hello,

I was wondering if there was a method that requires an approver to electronically sign and enter in a password for each approval they make? This is a requirement for the regulatory body that I am working with.

Thanks,

-Bao


 * This could be achieved with a ConfirmEdit extension adding a "captcha" which actually asks for such a signature. If the password is always the same for everyone, you could just use QuestyCaptcha. Nemo 20:52, 28 April 2016 (UTC)