PersonalWatchList is an idea to combat WikiVandals. It is not currently implemented on this wiki - it is just one of the proposed WikiVandalismSolutions. PersonalWatchList is a replacement for RecentChanges that should curb some of the vandalism. In this page, "RecentChanges" refers to RecentChanges, QuickChanges, and NewRecentChanges.
There has been some discussion about RecentChangesConsideredHarmful, RecentChangesIsNotTheWiki, and TooManyRecentChanges.
WardCunningham wrote the following on AdvoGato:
-
- "I recently wrote a history of wiki that got even me thinking of the good old days. I'm in the mood to do something new. Wiki traffic is about 3x now what it was when it was last judged noise free. I'd like to find something that will take it to 30x or 300x. I've received many suggestions of things to add. Instead I'm looking for something to take out."
It is clear to some that the "something to take out" is
RecentChanges.
What does RecentChanges accomplish today? (see RoleOfRecentChanges for discussion)
- Lets people know when there is a change to a page they are interested in: This is the main reason for RecentChanges to exist. Notice the words interested in. That is the key. If a user comes to wiki for information about subject xyz, then presumably they are interested in hearing more about xyz as it becomes available.
- Facilitate ThreadMode conversations: Thread-mode conversation can happen faster if the participants are able to see when it is their turn.
- Lets people know when there is a new page created: Similar to the first accomplishment, this allows an individual to see when there is more information about a topic of interest.
- Alternative to RandomPages (often more useful than RandomPages): Let's face it, wiki's RandomPages page is not very useful - only a small number of links are given out of wiki's 30,000 pages. RecentChanges allows an individual to jump to completely random pages (random from their perspective).
- Easily identify WikiSpam: NewRecentChanges in particular, allows a user to visually identify edit patterns that are likely to be WikiSpam. This is critical to today's manual WikiSpamSolutions (following behind the spammer and reverting his changes).
- Provide a way to monitor activity level: Wiki's activity level presumably has some connection to its ability to grow and maintain a community of contributors. If nobody else is contributing, then why waste your time?
Where does RecentChanges fail today?
- Encourages bystanders to make useless edits to recently edited pages: This is related to the RandomPages accomplishment. Individuals are likely to see random pages fly by RecentChanges, and feel inclined to jump in and state their two cents. Contrast this to the primary change-notification accomplishment of RecentChanges. The difference here is that the user edits a page which he generally has no interest in. This should probably be discouraged, since it is not likely to increase the signal-to-noise ratio of those pages.
- Allows vandals to annoy others and bring them down into a battle: RecentChanges is generally the first page a WikiZen will load in a given day. Vandals know that. To achieve maximum retaliation, the vandals intentionally flood RecentChanges. By doing so, they co-opt more people into the battle.
See
CompellingIrritant for discussion of why the vandals do what they do. For now, suffice it to say that the primary motivation is attention (wiki is an
AttentionEconomy). In wiki, attention comes in the form of retaliatory edits.
Why is RecentChanges central to the vandals' ability to harass wiki? Because vandals are encouraged by immediate feedback. Without RecentChanges, the vandal has a very limited ability to do these two things:
- Bring others into the war quickly
- Annoy the innocent bystanders
If you cut off the ability for vandals to bring others into the war, then presumably the vandal will eventually lose interest and go away. While he is still here figuring out that nobody is going to stoop to his level, we have cut off his ability to annoy the rest of us.
Naturally, we don't want to throw the baby out with the bath water. RecentChanges is central to the vandalism problem, but it also provides vital services.
How can we modify RecentChanges to fix these two problems?
Replace RecentChanges with PersonalWatchList. PersonalWatchList is intended to have features that are isomorphic to the accomplishments of RecentChanges, while also avoiding its failures.
As the name implies, the personal watch list is personalized for each user.
A user starts out with an empty watch list. Some users may choose to keep it that way, which is isomorphic to never visiting RecentChanges.
Upon visiting a page, the user may choose to add that page to his watch list. In the terminology of the accomplishments list, this is how a user indicates his interest in a page. If the page was already on his watch list, the user may choose to remove that page from his watch list.
There is a way for a user to view his complete watch list, and remove pages from it.
However, the user wouldn't normally view the complete list. Instead, he would view only the list of pages which have been modified.
"Modified" is determined separately for each user, based on the last edit date, and the last view date. The last view date is specific to each user.
The modified list is sorted so that the most recently modified pages are on top. After viewing the modified version of a page, that page is removed from the modified list (but it is still present on the user's watch list).
That's it. Suggestions for an implementation are given in PersonalWatchListImplementation.
Does this replace all of the functionality in RecentChanges?
Let's revisit the accomplishments list and see.
- Lets people know when there is a change to a page they are interested in: Yes, this one should be covered.
- Facilitate ThreadMode conversations: Also covered.
- Lets people know when there is a new page created: This one is trickier, but it works out. PersonalWatchList doesn't tell you directly when someone creates a page. However, the page's author will presumably add backlinks to other pages. If the page is related to one of your interests, you should see the new link added. Following the new link will lead you to the new page.
- Alternative to RandomPages (often more useful than RandomPages): Nope. We'll have to make a real RandomPages. Bummer.
- Easily identify WikiSpam: No. If PersonalWatchList is implemented, one of the WikiSpamSolutions will need to be implemented simultaneously or first.
- Provide a way to monitor activity level: No. It could be argued that this is not very important, but I think it will have a subtle effect on the feeling of community. I don't know what can be done to replace this functionality of RecentChanges, other than a simple "activity meter", or some traffic graphs.
Additional comments
Instead of manually adding pages to the watch list, what if we manually add them to an un-watch list? That way you wouldn't miss out on stuff.
- That would just amount to a glorified killfile - like LetsWithdrawIntoSolipsism; it's really a different approach. You can't count on users to ReadTheWholeWiki and sort out what they are interested in. At best, they will do it very gradually. To cut down on spontaneous trolling, we should have the list be normally-exclusive.
But doesn't the new
RandomPages provide just as many opportunities for spontaneous trolling?
- At the surface, it may appear to. But if you look closer, the crucial difference is time. With recent changes, I am assured that another user is interested in this page right now. As a troll, if I go in and delete his comment, I can expect an immediate retaliation. Contrast with random pages, where there is not likely to be an immediate retaliation. The lack of immediate retaliation is central to the whole idea.
You mean I have to add thousands of pages to my watch list? That is a lot of work!
- As suggested by DanMuller, this is a great opportunity for categories to help. The watch list should have the ability to specify a "depth". With that feature, you could watch an entire category.
But this requires user accounts! It destroys the wiki spirit of openness!
AutoPcn
? implements most of the
PageChangeNotification features listed above.
- Agreed, but AutoPcn? is a sort of bailing wire and duct tape add-on today. This is a very similar (actually derivative) idea, but it would be more legitimate as an actual script on the site. Also, it doesn't have any real troll-fighting power unless RecentChanges is gone.
Without
RecentChanges, I will feel claustrophobic or out of control.
- The idea takes some getting used to. It does take away some control, so it makes sense that you would feel out of conrol. That is the desired outcome. We want to take control away from the vandals, and unfortunately that means taking some control away from everyone. The claustrophobic feeling is probably similar to what a new wiki user experiences before learning about RecentChanges. Think back to when you were new to wiki. Did you enjoy the experience more or less after discovering RecentChanges? See also RecentChangesIsNotTheWiki.
MediaWiki (i.e.
WikiPedia) already has this, called by the same name. It would be worthwhile to study the effects and implemention there for inspiration.
It looks like this proposal, along with the others, will not be implemented any time soon. See GaveUpOnRecentChanges for a reasonable interim solution. -- MichaelSparks
I waffle back and forth on this proposal in my mind. I think it could help, but I'm not sure it would help enough. More and more, I fear that an authentication system will be needed at some point in order to tie responsibility to a recognizable (and, sadly, a bannable) entity. (Is there already a page that discusses this idea?) Wiki would lose something thereby, but it would also lose something if I give up the chance to see reasonable, mildly off-topic contributions in an unfiltered RecentChanges. -- DanMuller
There is some discussion of logins at PersonalIdentification. Briefly, the problem I see with logins is that unless you require people to travel to Portland to submit a DNA sample, the determined vandals will find ways to create multiple accounts. WikiNeedsTrustMetrics and EditsRequireKarma are both good ways to limit access on an individual basis, without the multiple-account vulnerability. -- MichaelSparks
I'm thinking more in terms of freely available and unverified login identities, but with a significant time delay between application and granting, and the usual tests against automated signups. Not something that would be perfect, nor even something that could shut out an individual for good, but something that is a somewhat limited resource that can be revoked when necessary. Even if someone stored up a bunch of login identities and used them all at once, authorized caretakers could shut them all down pretty quickly, limiting the size and duration of an attack. There are no perfect solutions, but this one would be more helpful than IP blocking, I think. -- DanMuller
I agree that logins would be a good stopgap, at least initially. Also, I agree that something would be lost if RecentChanges goes away. But, I think there is something better to be gained. This may not work on you since you have been around a long time, but here is an experiment to try. Pick any page from RecentChanges. Find a link on that page you have either never heard of, or never payed much attention to. Follow the link. Find the link on that page you know the least about. Repeat this process until you wander into completely unfamiliar territory. Whatever page you end up on, read it. Pretend it is on RecentChanges right now. Pretend that the last comment on the page was posted only moments ago. (Really do it! :-) Now, aside from immediate feedback from other users, what do we lose by doing this? The thing that is gained, is that you now know what is on that page. With normal RecentChangesJunkie browsing, you wouldn't. -- MichaelSparks
CategoryWikiMaintenance CategoryWikiProgress
Personal Watch List