Wikipedia:Toby/Do

Purpose

This is a very rough outline of a possible Original Toby watch/forget algorithm. It's a purely practical scheme, and can be changed as needed to compensate for novel attacks or unexpected omissions.

Scope

Note that this draft only applies to Original Toby.

• The butt-simple Simple Toby watches all images, all the time -- very quick and easy to implement, a no-brainer. (It might well be possible to implement entirely in the user style sheet!)

• The really advanced model, Custom Toby, gives each user his very own Toby (and Toby-list); so there's not much good reason to have Toby forget anything (in this implementation). More interesting is the question of exactly how a new user gets his initial Toby-list; it wont' be much help if it starts out empty. There needs to be some exchange mechanism (which carefully avoids labeling of any kind?) -- this is far beyond the scope of this document.

Original Toby falls somewhere in the middle of this range.

General method

Users have always available to them a basic choice: Toby or not Toby. Users who do not choose to participate are not affected. Those who choose to be Toby-users are not shown content on Toby's watchlist.

Readers do not even have to reach the point of becoming anon IP editors in order to be able to add content to Toby's watchlist. Any reader, at any time, can tell Toby: Watch this.

Over time, Toby removes items from his watchlist according to a complex algorithm. This algorithm may be adjusted from time to time to ensure the highest possible degree of reader satisfaction.

There is no method by which any reader, ordinary editor, or admin can directly remove an item from Toby's watchlist. By definition, there is no such thing as inappropriate Tobying of an item. However, Toby is adjusted to forget quickly particularly idiosyncratic choices. If a very small proportion of readers Toby a popular item, Toby will not remember it long; if a large proportion of readers Toby an infrequently-visited item, Toby will remember it very well.

Effect

Entry into the Toby system is through sidebar icon. Clicking icon takes user to choice page: Toby or not Toby. User can choose one of several options; but the two most prominent are simply the choice to have Toby watch, or "no thanks".

Display of Toby in sidebar by default. Obviously, savvy users can go to Prefs for a wide range of display choices -- no Toby icon at all, ever; Toby always on, don't show me choice page; reset Toby; etc.

It is assumed that a user has Toby turned on for him. If not, then Toby has no effect whatever. A user can still alert Toby to selected content without asking him to filter the site -- but will see no effect from his actions until he asks Toby to watch out while this user views the Project.

Being a Toby-user -- in the Toby state -- asking Toby to "watch out for me" -- are equivalent terms. The state is highlighted for the user by display of a large, fixed-positioned Toby icon at all times.

If a link is clicked that leads to a Tobyed page, the user goes instead to the standard Toby choice page: Toby or not Toby. (This could be disabled, too: "Don't ask me again -- you can turn this back on in Prefs.") Agreeing to have Toby continue watching returns the Toby user to the page from whence he came. Asking Toby to stop watching for this user leads to the Tobyed page; the user exists the Toby-state and the fixed icon is removed.

If an image is Tobyed, it is replaced by a placeholder. (There is room for more than one response to a placeholder click -- Strict Toby just pops up and asks; Liberal Toby allows the click to pass through to the image description page where the actual image can be seen out of context. I lean toward Strict Toby; if the Liberal Toby model is followed, then clicking a placeholder and display of the Tobyed image must exit the Toby state without warning.)

If a template is Tobyed, it is simply not displayed at all. (Let the chips fall where they may.)

Initialization

Each page, in every namespace, begins with a certain initial Toby threshold score, S0. This is set very broadly, based on factors such as namespace and length of article.

For instance, we might begin by weighting Image namespace (and corresponding images themselves) very lowly. Wikipediaspace pages should get a low threshold, as they do not contain truly "public" content -- not in the same sense as mainspace, which would be set high. Template pages should have very high S0 -- and be watched by human editors all the more vigorously.

Userspace pages should get the lowest S0 of all; anybody who peeks into such pages may just have to exit the Toby system -- easily done at the click of the mouse, but otherwise, nada. Or we might decide, after some experiment, that userspace is not such a big problem, and raise its S0.

Short pages could be weighted more highly -- although we might find this weighting does not work for us, and decide to discard or reverse it.

Threshold modification

Newly created pages Y start with a low Sy := S0. The longer a page remains unmolested, presumably the less potentially questionable its content -- the nastiest garbage gets moved out the fastest (by whatever deletion method then in use). Thus, Sy rises in Real Time.

Each time a page is viewed, that may add slightly to Sy; each eyeball is a small warranty of quality. However, an unusual spike in viewing might be seen as an indicator of potentially questionable activity, and lower Sy.

Pages with a large number of edits by multiple editors should see their Sy rise rapidly -- the more editors who touch a page, the more acceptable we hope its content may become.

"What links here" might be taken into consideration. This is a processor-intensive task and cannot be done on the fly every minute; but periodically, the current Sm and Cm for each linked page M can be examined and used as an input to Sy.

However, Sy merely establishes a threshold for the page in question. No matter how low it is, Toby takes no action on a given page. (Or, maybe we will find Toby works so well we decide to set a threshold for Sy below which Toby automatically puts that content on his watchlist. We'll see. For now, no.)

Trigger

At some point in time Tx, User:x alerts Toby to a given page P. User must be viewing the page in question at the time; user must click the Toby icon and then click on Toby, watch this page. Alternately, user may click off items on a list of transcluded content, such as templates and images.

Immediately, Toby places the page on his watchlist. All Toby users, across the system, now fail to see the watched page. The user is shown a standard confirmation message, followed by a timed redirect back to the recently-Tobyed page. If the Tobying user is in Toby-state at the time, he is returned instead to a default page.

Triggering Toby for a page P increments its Toby-counter, Cp. Multiple triggers (by distinct users) continue to increment Cp.

If we discover problematic attacks by users who successfully simulate a wide range of distinct users, all multiply Tobying the same content, we simply reduce or eliminate the weight given higher values of Cp.

We can also weight the increment to Cp caused by trigger N by the length of time elapsed since Tn-1. If multiple triggers in a short period of time have little effect, it will be very hard to mount a completely spurious Toby "attack".

Decay

The Toby counter for a given page P, Cp, decays over time -- that is, it slowly decrements. We can experiment with several schemes.

• Real Time causes Cp to decrement -- in a straight line, logarithmically, what have you. I suspect we'll want it to fall off very rapidly at first -- perhaps with a half-life of 5 minutes.

• Page views cause Cp to decrement. The presumption is that the more eyeballs are on the given page who fail to increment Cp, the more likely it is that some average reader will find that page acceptable for viewing. Thus a single Toby triggering can last a long time on an infrequently-viewed page; that same triggering will fizzle out very quickly on Main Page.

• Besides raising the long-term threshold Sy of a page, the action of editing should immediately lower Cp. This statement might be adjusted so that a given edit E lowers Sp temporarily at the moment the edit transaction concludes as it lowers Cp. As Real Time passes and Te receeds, Sp recovers and rises again to its pre-edit value, Sy; while the decrement to Cp remains.

Threshold comparison

Whenever any Toby-user requests a page, Toby makes a simple, on-the-fly test of Cp against Sp. If the test fails, Toby disallows the page; if the test succeeds, Toby allows it.

We can either play that as soon as counter drops below threshold, the counter is zeroed; or we can retain the residual count in anticipation of the next trigger event.

It may not be clear that a single trigger invariably drives score over threshold and suppresses page P. We choose all our constants wisely, so that this is so. Having overcome threshold and invoked suppression, score may fall very rapidly, and according to all manner of complicated decay rules. But at the moment of triggering, that's it -- basta.

Cached Toby

Pages on Toby's watchlist may, of course, be cached like any others. They simply are not served to Toby-users.

Pages containing Tobyed templates will have to be re-created. There should be little occasion to Toby a template; even if it's junk, it's unlikely to be offensive. In the event, it's quite likely that the target page will be Tobyed anyway.

Pages containing Tobyed images are not a problem at all. The exact same cached page is served. When the browser starts to request the images, it receives placeholders.

Dressy Toby

It's possible to forget all about caching and modify every page served to a Toby-user, by checking every outbound link on the page and converting it to a redirect to the Toby-choice page.

Besides plain gray box placeholders, generic images can be served instead. I do not advance Toby as the placeholder poster boy! But images are already categorized; rough-and-ready silhouettes based on these categories could give Tobyed pages some visual feel.

Dressy or not, Toby placeholders should hold their places and occupy the same space on the page as the images they replace.

Tobyfans

The phrase "Toby vandalism" ought never be considered. We don't ask why a user Tobys content; so it can never be "wrong". We might, however, think that certain users are Tobying a great deal of content. Such are Tobyfans.

It is counterproductive to generate lists of Tobyfans, or to flag them for admin perusal. Developers ought never yield to any request to identify a user as a Tobyfan. Tobyfans may or may not be performing a service. No penalty is ever imposed against a Tobyfan.

However, we may discover that Toby-users are complaining much too loudly that too much is being Tobyed. We juggle the decay and threshold constants, and discover peculiar patterns of Tobying. We aren't permitted to question these patterns directly -- Toby does not judge us, so we cannot judge Toby. But we can ask the question: Are a small number of Tobyfans exercising disproportionate control over Toby? If so, we'll want to discourage this.

There are at least half a dozen ways to meet this challenge, and I'm tempted to say, Let's not borrow trouble. But we can set out some basic principles for dealing with it, should the situation arise.

1. Never try to identify a Tobyfan as a specific user. If Toby is paying too much attention to one user, that's Toby's fault. We'll fix Toby, not the user.

2. Never try to isolate the Tobying pattern of a Tobyfan down to individual pages. If some pages are getting a lot of Tobys, maybe they're more offensive to more people than we think.

3. It is completely acceptable, however, to do statistical analysis of Toby. Users can be identified by purely random Toby-handles, and the pages on his watchlist can similarly be reported by arbitrarly assigned Toby-handles. Thus, a record of Tobying behavior can be generated completely free from bias -- a truly blind report.

4. In combination with user complaints, we can then ask the question if the blind report indicates Tobyfans in general may be problematic.

5. Then, any number of Toby-methods can be adjusted to discourage Tobyfans, if necessary.

For obvious reasons, I'm not going to go into further detail here. Any good programmer with a smattering of insight into human nature can think of a few ways to sharply reduce the influence of Tobyfans -- or promote it, if this seem beneficial. We can also think of many ways to circumvent some of these controls. If we think a little longer, we can devise Tobys that are extremely difficult to subvert.

Algorithm modification and adjustment

Since Toby is potentially controlled by a large number of adjustable constants, perhaps the best way to adjust them is heuristically.

Allow reader to comment directly to Toby: Toby, I like you. -- Toby, you're not watching hard enough. -- Toby, you're watching the wrong things. Don't offer too many comment buttons, but accumulate the results.

Then, simply set all Toby constants free within certain reasonable ranges, and employ goal-seeking to obtain I like you max.

Summary

So long as we hold the keys to the rack room, we can always steer the Project in the direction of our cornerstone goals and, along the way, keep Toby-users reasonably quiet, if not always happy. — Xiong熊talk* 23:17, 2005 September 3 (UTC)