Quick Changes Discussion

This is a discussion related to the QuickChanges page.

And the best feature: the most recent change is on top. May the LazyRecentChangesJunkies go wild. -- CliffordAdams

Cliff and I experimented with more elaborate versions of this script last fall. I decided not to distribute them because I was afraid that they would change wiki into a chat room. Junkies, please be careful to keep the signal to noise ratio high. Thanks. -- WardCunningham

I enjoy wiki'ing with lynx (text mode is very suitable for the wiki, and it seems faster). It used to be very nice to just use the arrow keys to scroll up and down through RecentChanges or QuickChanges, but when there are multiple hyperlinks per entry, one can easily get a parity error while trying to double-arrow. Would it be possible to get a version of quick changes that had one hyperlink per line (to the summary might be nice, but the other way would be fine too) with links from the page or the summary to the other view? Would it be more likely to happen if I sent Ward some patches? Thanks...

I retracted the feature briefly. I wasn't liking the way it looked myself. I tried browsing in lynx and it was obnoxious. But then I got more criticism so I put it back. -- WardCunningham

The One True Way to use lynx: Turn the "Number Links" option on. Use PgUp/PgDn and Insert/Del to scroll. This fixes the above-mentioned problem without having to do anything special with the HTML.

QuickChanges is now my preferred entry point to Wiki, not to up my dose as a RecentChangesJunkie (although that's nice), but because QC recaptures the anonymity of changes that RC lost when

I learned to recognize other junkies' domain names
the UserName was introduced

I have this feeling that UserName is somehow contrary to WikiNature... -- KeithBraithwaite

The non-uniformity is what I would question most now. Two policies at least are worth experimenting with:

nobody can make an edit without declaring their UserName, from the start of the community (a little late for PPR)
just reverse DNS lookup (or no system info at all on editors)

The MentalModel that each reader and writer has affects the way the community views itself. Simplicity and uniformity help cohesion? FreedomOfChoiceConsideredHarmful? -- RichardDrake

If the above point 1 were implemented, I would use two UserNames -- VickiKerr

WithFreedomComesResponsibility? or do I miss the point?

The Wiki PQA for PalmVII is now available for alpha testing. See WikiForPalmSeven? for details. -- JohnBrewer

Another interesting use for QuickChanges is to see how much RealWorld time has elapsed since you've been away (maybe lost elsewhere in Wiki) - by noting the delta on pages you recognize from the last refresh!

Question: why do pages show up as "(New)" when they are just being (re-)edited? Is it because Wiki hasn't "registered" them somehow yet?

Answer: see NewNotification.

Suggestion: maybe the revision number could be put after the page name instead of the (new) mark? The (new) doesn't really add anything - actually, it kind of distracts (at least on quickChanges). -- a new QuickChangesJunkie

Has anyone else noticed a small bug when using the default link?

http://c2.com/cgi/quickChanges -- for a half day

The last item is not properly sorted with the rest of the list.

QuickChanges pulls info from RecentChanges and keeps it in that ordering. If you look on RecentEdits, you'll find that, while BogoMeter? was edited yesterday according to RecentChanges, it was edited today as a MinorEdit. Hence the apparent discontinuity.

I'd like to see a QuickChanges format page with usernames. I like seeing who's writing. This does of course make it larger and less appropriate for mobile devices. I'm often on a slow link and RecentChanges is too big - 12 hour QC loads much faster - but I miss usernames. =( -- TorneWuff

Moved from SizeChange

Q: Is there a place herein to see WhatGrew? and WhatShrunk? (and by how much!) without those pages being a HandEdit??

Discussion follows

I think the differencing engine needs to use the -b qualifier to ignore differences in WhiteSpace?. -- ChrisGarrod

Actually, *some* whitespace differences are ignored by the QuickDiff script. For instance, if you alter "Size Change" to "SizeChange?" (and make no other edits) I won't see any output on the diff file. (This is hard to test, since differences from the previous editor are shown.) I'd rather see all the differences, than wonder what changed.

If you use QuickChanges and click on the update times, it's easy to see when only a little text was changed, or when a large section was added/deleted.

I propose QuickChanges be disabled as that would place a natural restriction on the rate certain problematic people can reply before PeerReviewers can get to the text. -- SunirShah

I vote against that change, as certain problematic people would just use RecentChanges (which is harder on the server) instead. -- anon

First, the speed bump imposed by RecentChanges will change behaviour accessing the site. Second, RecentChanges is throttled by the main wiki.pl script, using the obsolete 75 accesses out of a 100 rule, whereas QuickChanges is not throttled. This limit could be changed to be temporal, which if pushed, could automatically result in a IP ban. Alternatively, we could throttle QuickChanges. Note that throttling --> IP bans will also break scripts that hammer the site to 'lock' pages, which is also beneficial. -- SunirShah

You think the problem is severe enough to need IP bans? Also, I don't think extra load on the server is a good way to slow refreshes down. Incidentally, the new MozillaBrowser/MozillaFirefox browsers let any page be set to automatically refresh at a specified interval. I would think an IP ban on posting(rather than on refreshing QuickChanges/RecentChanges) would be much more effective to prevent the super-fast-poster(if such a measure is even needed). . . . I partially agree on the script prevention, except some people use page rippers(i.e. rip your UserName page, along with 1 level deep of pages) for offline reading - which doesn't affect posts, and although it's a minor burden on the server, it should still be allowed. --anonfornow

First, I would just ban AOL outright just for being such poor net.citizens. Second, I think we need a SurgeProtector that automatically cuts off parts of the internetwork from accessing the server for periods of time if a high amount of traffic is requested through that section, so that it isn't a socially negotiable (and therefore blamable) process. I actually would do a router ban, rather than an IP ban, as IP bans aren't very tight. I would normally suggest it only for edits, and use mod_throttle for overall bandwidth, but since Ward is notoriously against complicated code, I propose simple changes that over time become the same thing. There already is a SurgeProtector on WikiWiki for read and write access, so we can just use that. Also, unlike normal negotiations, when I ask Ward to apply a small two-line patch, he responds by writing a whole new script, but if I write a whole new script, he will only apply a small two-line patch. -- SunirShah

One reason why I suggest throttling is important is that Robert is aware his IP is dynamic, so we would have to ban all of AOL. Once we do that, he will get a new ISP to continue to attack the site. If the script had automatic defenses, it would be able to quickly and automatically block entire ISPs. Robert's mission in "life" is to gain attention by demonstrating he's smarter than all our social defenses; so we move on to technical defenses. -- SunirShah

I'd rather see throttling (for both QuickChanges and RecentChanges). The hyper-fast QuickChanges refreshing (which I'm just as guilty of as anyone) also tends to result in a lot of ThreadMess. Limiting the page to updating every hour or so wouldn't really prevent real content from being added, but it would put a big dent in ThreadMode, ForestFires, OffTopic pages, and many other problem effects. This has benefits beyond our current pest. -- JonathanTang

The only problem I have with this is that it would make it harder to respond to both new users and spamming in a timely manner.

How about adding a killfile feature to QuickChanges? It could store a list of ip numbers in a cookie and filter out those entries in the user's displayed list of changes coming from any of those ips? It wastes a lot of time to see that an interesting file has been changed only to find out it's just more useless blather from x. I have found that lately wiki has become tiresome. --

That would be handy. Would it be too complicated to code?

The QuickChanges we have now is pretty good. I just click on the times indicated to see the changes. If it's interesting, I look at the whole page.