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 :D. 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)

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 'reviewers'. Ruslik0 18:39, 29 January 2009 (UTC)
 * , yes Mion 10:40, 31 January 2009 (UTC)
 * There is more strange :Added rights (from )


 * 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)