No I wouldn't. The queue would start getting filled up by good edits in case everyone who uses huggle would disconnect or stopped using it. The current system as it is clearly isn't sufficient for this. We need to cherry-pick the bad edits, not good edits. Current system allows only to flag good edits as "don't need review" which isn't really useful for anything... On Thu, Sep 26, 2013 at 7:30 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: > That's a problem in the client, not in MediaWiki. To implement that with > current code, you can patrol everything that is not suspicious and you'll > get what you describe; if your patrolling bot is error-prone you may > hypothetically need an "unpatrol" feature, but then just fix the bot. > > > Nemo > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I used to just revert them automatically when such changes appeared on my watchlist. If someone changes the population of Denmark or the formation enthalpy of carbon tetrachloride, without providing any reference or any suggestion that it is a revert, the chances that the new information is more accurate than the old information is extremely low.

----- Original Message ----- My first 2 edits at TV Tropes had this property: not only were they reverted, they were both reverted with snotty comments about procedure, and *the second one was me doing what the first one had yelled at me for not doing*. And I got yelled at the second time for following instructions. I gave up. It's fun to read, but not worth my time to contribute to. I concur with MZM: We don't want to become that. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, 27 Sep 2013 11:51:34 +0200, Petr Bena <benapetr(a)gmail.com> wrote: Really, you have just described FlaggedRevs. It could be enabled by default for all articles and would solve all of your problems. Many large Wikipedias already use it, including pl.wp and de.wp. -- Matma Rex _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, 27 Sep 2013 12:39:46 +0200, Petr Bena <benapetr(a)gmail.com> wrote: Is it possible to "flagging as bad"? Do you mean reverting? I just don't see what you are trying to accomplish. Sorry.

-- Matma Rex ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

>> Is it possible to >>> enable them in reverse-mode so that all edits are flagged as good, but >>> editors can flag them as bad? If not, I can't see how it could be >>> useful for this purpose... >>> >> >> "flagging as bad"? Do you mean reverting? >> >> I just don't see what you are trying to accomplish. Sorry. >> >> >I think he's looking to flag as suspect, not to revert as bad. Are you >really not following, or just not agreeing? > >A possibility is to use a maintenance template, like {{cn}} or

>but this solution shares with using flagged revs for it - which would be

>great solution - that it might be viewed as negative by the en.wp

I thought FlaggedRevs prevented the newest version of the page from being

"Flagged Revisions allows for Editor and Reviewer users to rate revisions

I think he also wants the edit to go through and be visible right away.

I'm not entirely sure that FlaggedRevs is the best solution here.

Not really, I can't see how tags help at all in here. We are talking about any kind of edit (nothing that can be matched by regex) which seems suspicious to vandal-fighter (human) but who can't make sure if it's vandalism or not. Nothing like abuse filter nor patrolled edits can help here (unless we mark every single edit as patrolled and these people who see such a suspicious edit would mark it as un-patrolled or something like that)

I've got to say that this problem seems pretty straightforward. Essentially, we need something lighter than 'revert' for edits that need a second set of eyes. What we really want is a queue of suspect revisions that allows Wikipedians to flag new revisions, query current flagged revisions and remove revisions from the list after review. I see two clear options: *3rd party tool. *A queue of suspect revisions can be created as a 3rd party tool (e.g. webapp + API running on labs). Then gadgets and other 3rd party tools make use of the API to add, remove, update & query the set of flagged edits. I worry about this option due to the lack of good identity sharing between Wikipedia and 3rd party wiki tools, but otherwise, it seems trivial to implement. *Make use of infrastructure in MediaWiki. *We can either build on top of the features currently deployed or on top of new features in the pipeline. - Current MW: Someone brought up the example of adding a template to articles who have recent revisions needing review. Such templates could appear on the talk page so as to not clutter the article. I've got to admit that this sounds messy, but the user warning level system employed by Huggle, ClueBot NG, Twinkle, etc. is equally message. - New Features: If arbitrary tags could manually be added to revisions and queried from the MediaWiki (preferably, the API), the functionality of a third party tool described above could be captured without need for accessing an external tool. This might require a little bit of gadget support for common actions taken on the "suspicious edit queue". On Fri, Sep 27, 2013 at 8:59 AM, John Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I thought FlaggedRevs prevented the newest version of the page from being shown until it has been approved? "Flagged Revisions allows for Editor and Reviewer users to rate revisions of articles and set those revisions as the default revision to show upon normal page view. These revisions will remain the same even if included templates are changed or images are overwritten." I think he also wants the edit to go through and be visible right away. I believe that he is trying to assume good faith in these types of edits. Trust, but verify, if you will.

On Fri, 27 Sep 2013 11:51:34 +0200, Petr Bena &lt;benapetr(a)gmail.com&gt; wrote: Really, you have just described FlaggedRevs. It could be enabled by

If you use Huggle and see something ok (= not to be reverted), Huggle

just store somewhere the suspect list

All this is unnecessary complication. If you use Huggle and see something ok (= not to be reverted), Huggle must mark it patrolled; if you're unsure, you should be able to tell so to Huggle and it will be left unpatrolled. If you're emotionally attached to the idea of doing the opposite, you can still do so with patrolled edits: just store somewhere the suspect list and periodically mark as patrolled all the edits at the bottom of the queue (say, $wgRCMaxAge - 72 h) for manual revision. Nemo ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

I think a few different concepts are being muddled here. Flagged revisions (and its variant, pending changes, on enwiki) is applied to individual articles to hold *all* edits from certain user classes for review. What Petr is looking for is a way to flag *individual edits* to an article (not the whole article) for review. Flagging edits for review through either method means creating an expectation that someone else will review the edit. The use of FR/PC is (to date) only enabled following community discussion and usually community determination of the applicable rules for its use. I suspect that enabling a means to flag individual edits would also require some sort of community consensus for its desirability before it is enabled; however, someone's going to have to write the code first before that happens.

This does come back to basic socialization of the editing/reviewing process, and likely some (project specific) rules of thumb for when to revert and when to take a few minutes and research the new data would be worthwhile. For example, I'd probably not revert the result of a sporting match held within the past 48 hours, but I'd probably revert the same edit if the sporting match was six years ago. Dates of birth are particularly sensitive and changes to them should always either be sourced or the prior consensus verified. It's often better to review fewer changes and verify information (most of which is usually available somewhere online) than to get as many edit reviews as possible done. I can't tell you how many times I used to get edit-conflicted by people using review tools when I used to manually review (and fix) recent changes. Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l