Aaron's message is very good. I just added a few comments, especially on the part "no one commits to check text when editing". <br>Luca<br><br><div class="gmail_quote">On Dec 2, 2007 11:13 AM, Aaron Schulz <
<a href="mailto:jschulz_4587@msn.com">jschulz_4587@msn.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<i>Bah, I meant to send this here, not to just one person...</i><div class="Ih2E3d"><br>
<br>
OK, in order to talk about pros vs. cons, we need to consider the uses first. Some main tasks are:<br>1) selected an unvandalized version (for AT, this will do "worse part" checks and such)<br>2) selecting a quality, fact-checked version (German Wikipedia wants this)
<br>3) selecting a consensus version/marking featured pages<br>4) selecting the best version and displaying it be *default*<br> <br><b>Selecting an unvandalized version</b><br>Flagged Revisions (pros):<br>1) Templates and images are part of the review process, so vandalism to them will not show for reviewed pages
<br>2) Users with review rights get the gratification of setting the latest unvandalized/"sighted" version<br></div>3) New users can look forward to getting these rights in short order, after being considered trusted
<div class="Ih2E3d"><br>4) Edits by reviewers can be autoreviewed if they are to a page where the stable and current are synced.<br>5) If 4 above is not possible, a diff of the changes to the stable are shown after edit to reviewers with a review form with the tags preselected. It shouldn't take long at all to glance over the changes and click "review".
<br> <br>Flagged Revisions (cons)<br></div>1) Initial review takes noticeable time for non-stub pages<div><div></div><div class="Wj3C7c"><br>2) Revisions can fall out of date if not maintained, so people clicking to see a stable version may get a really old one. This is integrated with the RC patrolling system and with the autoreviewing/quick diffs to help, but it is still a possibility.
<br> <br>Article Trust(pros)<br>1) No workload added, all automatic. This is very nice.<br>2) Fast and fluid since calculations for the sighted version are done on every edit without anyone having to do anything<br>3) Accounts for consensus, so no rouge reviewer can easily flag garbage. Still, a "trusted" user can go rouge and add garbage, even in several edits to bump the trust.
<br> <br>Article Trust(cons)<br>1) Template and image vandalism is still a problem<br>2) Bot and AWB edits flying through pages automatically make the trust of large chunks of text increase</div></div></div></blockquote><div>
<br>True, but it would not be hard to fix this in the code. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><div class="Wj3C7c">
<br>3) No direct control over it by anyone -> incentive loss<br> <br><b>Selecting a quality, fact-checked version</b> <br>Flagged Revisions (pros):<br>1) Trusted users, who have some respect for consensus as well, can directly mark off solid revisions
<br> <br>Flagged Revisions (cons):<br>1) If the user goes rouge they can flag garbage. Not as bad as rouge admins, likely rare, but something to think about...<br>2) A roughish user may ignore consensus and reasonable fact disputes. This could result in a small user or cabal having a monopoly over the "best version". Good policy standards and respect should be enforced to avoid this.
<br> <br>Article Trust(pros):<br>1) Nearly all "white" pages have a good chance of being reasonable accurate<br>2) No work required<br>3) Harder to form cabals/monopolies over the "best version"<br> <br>
Article Trust(cons):<br>1) Again, bots and such</div></div></div></blockquote><div>Again, bots are not so hard to remedy. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div><div class="Wj3C7c"><br>2) You cannot edit anything without vouching for it (bad for fixing typos) and the text around it. Either people get afraid to edit or dubious text gets more and more "trusted"</div>
</div></div></blockquote><div><br>Yes, this is indeed a problem. Any suggestion? One could add a checkbox, when committing an edit, that says "I checked the content"; If one does not check it, the trust of the text would increase much more slowly. I have no idea how using this idea would change the overall trust distribution of the text, we would have to try it on a live wiki so see how it works.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><div class="Wj3C7c"><br>3) No one necessarily committed to having fact-checked anything
<br> </div></div></div></blockquote><div>Yes, indeed; see above. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><div class="Wj3C7c">
<br><b>Selecting a consensus version/Marking feature pages</b><br>Flagged Revisions (pros):<br>1) Trusted reviewers (higher flagging rights than normal reviewers), like bureaucrats, look at debates and see if a consensus for a community selected version exists
<br>2) As long as the trusted reviewer acts like most "bureaucrats" on Wikipedia and just measure consensus, it is not easy to game<br> <br>Flagged Revisions (cons):<br>1) Rouge trusted reviewer...blah...could end up at arbcom
<br>2) Not automatic...I mean look at how slow WP:FA stuff is...<br> <br>Article Trust(pros):<br>1) It would take a lot of users to try to edit war to push the "consensus version" around since it is automatic, and that would just make a bunch of red text to the current revision which would cause it not to be selected.
<br>2) Automatic, account for all edits, not just those "voting" on some talk page<br>3) Generally waaay faster<br> <br>Article Trust(cons):<br>1) If there is consesus for a version clearly demontrated on a talk page, a small group of editors can still edit war over it and drop the trust. It would be nice for some trusted reviewer to be able to see this and expediently flag it.
<br> <br><b>Selecting the best version and displaying it be *default*</b><br>Flagged Revisions (pros):<br>1) Again, template/image vandalism won't be such a problem since those are set for each reviewed revision based on how it was when reviewed.
<br>2) For bios of living people, we can easily and immediatly set the stable version without having to fiddle around getting it autotrusted.<br></div></div>3) The incentive issue again, reviewer can set this, and editors can look forward to becoming reviewers.
<div class="Ih2E3d"><br> <br>Flagged Revisions (cons):<br>1) Rouge trusted reviewer...blah...could end up at arbcom <br>2) Spelling/grammar errors can get stuck if no one is around to review corrections (though reviewers spelling fixes could be autoreviewed sometimes)
<br> <br>Article Trust(pros):<br>1) The default is BY FAR the most important revision, so giving direct control over gives incentives to form evil cabals :)<br>2) As this is important, it helps to stay up to date with the workload, this requires none...so that's pretty easy...
<br> <br>Article Trust(cons):<br>1) Spelling/grammar errors can get stuck since it's hard to directly control</div></div></blockquote><div><br>You mean, the article that is automatically selected can still contain a grammar/spelling mistake which escaped attention of previous visitors? True.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Ih2E3d"><br>2) The "highest least trusted" and "max age" and other heurestics will be confusing to new users. Default page selection will feel kind of random
<br></div></div></blockquote><div><br>Yes, true, there will be a lot of people who will wonder "why was A rather than B selected", and more importantly, who will try to influence which of various equivalently high trust versions happens to be selected. I hope this would not instigate "selection wars" or schemes to game the system, but I admit I don't know.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Ih2E3d"><br>This is still an imcomplete list probably...I should probably save this somewhere and build on it.
</div></div></blockquote><div><br>Great idea. Also, I am very interested in ways to improve article trust, and its uses, so I am open to all suggestions (and the code will be available this week). <br><br>Luca<br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Ih2E3d">Also, for default revisions selection on page view, I am just comparing the methods of selection by the two extensions. We could have it where Flagged Revisions does the overriding of the default revision, but that it grabs the Article Trust "most trusted" version rather than some reviewed one. This would just be to avoid duplicated code though.
<br><br>-Aaron Schulz<br><br><br><hr></div>Connect and share in new ways with Windows Live. <a href="http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007" target="_blank">Connect now!</a></div>
<br>_______________________________________________<br>Wikiquality-l mailing list<br><a href="mailto:Wikiquality-l@lists.wikimedia.org">Wikiquality-l@lists.wikimedia.org</a><br><a href="http://lists.wikimedia.org/mailman/listinfo/wikiquality-l" target="_blank">
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l</a><br><br></blockquote></div><br>