Description

[Filed by SteveDavison]

Changes to a page are no longer noted if that page is edited on a later date.

• -- another way to put it --

Recent changes shows only 1 day of changes for every page that is changed within the time period shown.

Comment: recent is not all. If you want another behaviour then please add a FeatureRequest, e.g. for AllChanges or a mode of RecentChanges and describe a bit how it should be implemented. I like the discussion about this features and how to implement it moved to its appropriate page. If such a page exists I will add some of my own experience with too much log entries.

• -- ReimarBauer 2007-09-10 14:11:29

Steps to reproduce

1. User A edits a page on Monday
2. User B then edits the same page, also on Monday
3. On Tuesday, user C edits the page as well.
4. Try to find the changes made by A and B.

Note that after B's edit, the change line for the page will show both A's and B's changes. And this will remain true through the next week (default time period) so long as nobody else edits it. But when C makes changes on a different day, the edits from A and B drop off the list completely.

Example

To make sure that this is actually occurring on the MoinMoin site, I made a very small change to MoinMoinBugs/1.6devActionInfoHitsOnUnknownPageBroken, on 2007-09-09. The result was that a significant change, made on 09-07, was no longer listed.

Component selection

• Macro RecentChanges

Details

Workaround

When reviewing recent changes, any time you see any change to a page, you have to go into the page history to figure out which changes were made by who, and whether they fall within the time period you care about.

All this extra clicking and looking is a big time waster. But if you can't trust the RecentChanges output, what else can you do?

Using bookmarks doesn't help a whole lot, depending on how you use the RecentChanges page.

Discussion

Whether it's an omission, or it's poor design, it is a problem. (Since there is no documentation at all for the RecentChanges page, that I could find, how can you tell the difference?) I see this as the intersection of two rules that the macro follows:

1. Aggregate changes so that no page appears in the RecentChanges output more than once. This is good in that it makes the page much less cluttered.

2. Under each day's heading, only show the changes for that day. This makes perfect sense if it weren't for rule #1, and to do otherwise adds a bit of complexity.

One of those rules needs to give, or else the whole reason for having the macro is defeated.

My argument is that in order for RecentChanges to fulfill its purpose (or at least the purpose that it mostly gets used for, which is actually finding recent changes...), there should be no way that a significant change can be obscured by any subsequent change, especially if it's a trivial change. Consider an admin. who scans all changes for problems or spam. Unless this is done faithfully every day, you may miss important changes.

Another illustration: Massive, and important, changes are made on a project page when the project lead is gone. The following day, someone corrects spelling, or a link, and says so in the comment. When the reviewer returns and scans for changes, he very well may see the 'spelling change', and skip the entry assuming nothing important changed. Even if he does decide to look at the page, it'll likely be a bit confusing because what he finds will not be what he was expecting.

This issue sounds very similar to MoinMoinBugs/RecentChangesIsBroken, but so many things were discussed there it wasn't clear what the core issue was or if the problem was really understood, or what the issue was that was closed. I'm hoping this will stay uncluttered and be recognized for the problem that it is.

-- SteveDavison 2007-09-10 04:14:21

Although RC did not work as you expected it, this is not a bug, but intended.

• OK, without any documentation at all for the page or macro, how does one judge how it is meant to work, or why? My justification is: if there is no documentation on how the feature is supposed to work, then the user's assertion that it's wrong has to be given the benefit of the doubt. So until I hear a good explanation for why it behaves so illogically, I'm sticking to my guns.

  • The code maintains a list of ignore_pages (page names that it has already shown), so this for sure is intended behaviour and not a bug.

    • The list of ignore_pages simply proves an intent to have a page show up only once in the list. No problem. But I'm not convinced it implies an intent to display an incomplete set of changes and drop the rest. If that was the intent, then there must have been a number of assumptions about how the page should be used, none of which are communicated to the user.

• But what it really comes down to is... if a change is shown for 7, 14, 30, or however many days you are viewing, why should a change disappear after a day or two if someone edits it since then? That's just not right. The illusion given by the page is that you can scan changes by date, author, and comment, and use that info. to decide whether to look at the changes more closely. If it can't do that reliably, then it shouldn't do it at all.

• To back up my claims of "no documentation", I did search pretty extensively, including: t:recent t:changes, t:help recentchanges, recentchanges bookmark, and macro recentchanges, and others. I also checked the RecentChanges.py file for comments.

IIRC, it is part of RC's design to not show duplicate pages on different days (and to bundle changes to same page on same day into one entry).

• I have no problem with aggregating changes, whether it's within the same day or across multiple days. My problem is with dropping changes for no good reason. "Out of sight, out of mind" (which, I would guess, is why more people have not complained). Everything about the layout, wording, and why a user would be using the page in the first place, implies to the user that entries will be shown for every edit within the timeframe. What's the point in displaying the authors, comments, and number of revisions made for some days if you don't do it for all days. Rather than give a false promise, it would be better just to display "updated" and let the user get the full disclosure elsewhere. What's the point in reading a set of notes that you know may be incomplete (assuming you actually know this), when you aren't even told if there is missing information or not. It's pointless.

• Note from MoinMoinChat/Logs/moin-dev/2007-07-08, Alexanders Schremmer's comment (at least I think that's his ID... (If I ever join the IRC chat, I think I'll use <movax0> )

•    2007-07-08T00:35:45  <xorAxAx> yes, all edits are grouped together and shown at the newest place

• This shows that a key developer is under the delusion that all edits are listed under the most recent change date. But it's not true.

If you click on the icons (and have a bookmark set), you won't miss any change.

• Again, no documentation on how bookmarks work. Well, except for a user question here or there, but that's rather incomplete.

• But... even if you do use bookmarks, it still suffers from the same problem as the the non-bookmark behavior; there are entries only for the last day on which the page was edited. (set your bookmark to 9-5 and see that there's no mention of the edits you made on 9-7, to the page I mentioned in the example above. All that's shown is my stupid change on 9-9.) So you must rely on the link, and you pretty much have to click it for every page. And that just gives you the changes since your bookmark, all lumped together. That can be very unhelpful if there are a number of changes, by a number of people, across multiple days. There's no summary of who did what, and when. And the larger the time period, the larger the number of dropped entries.

• OK, sorry to rant. I just keep getting the impression that this problem is not being fully understood by the right people.

BTW, RecentChanges is a macro, macros are plugins. So it is rather easy to replace it by a custom one that matches your needs.

• Yes, I realize the time of the MoinMoin developers is limited. The patch supplied by MaxCampos is not a good solution because, as you mention on the other bug report, showing every change to every page on each day it was changed is usually too bloated and annoying. Anyway, I'm learning Python and the Moin codebase, but I'm not quite to the point where I can make those changes. Maybe soon.

• And while it is a plugin, it is a standard one that comes with the packages. So every wiki admin would have to 1) discover that there's a potential problem, 2) have the knowledge and time to change the macro, and 3) I'm thinking that since it's a standard macro on a standard page, it could require some attention with each upgrade. Multiply this by all the MoinMoin instances out there. Why make everyone deal with that?

What's "better behaviour" for RC depends on your assumption of user behaviour.

• Obviously the default RC implementation assumes that a reviewer clicks on a "updated" link if he sees any change to an interesting page. Then he will see all changes since his bookmark (even the ones RC did not display). So no change will go unnoticed. If the current "ignore_pages" feature would be removed, this reviewer would see some changes multiple times, because the same page with the same "updated" link gets shown under multiple days (updated link always shows <now - bookmark> diff).

  • Obvious to you, and now becoming obvious to me. But I'm coming at it from the perspective of a typical user, to which it will not be obvious at all. I do assume that users will generally think that all changes are shown, and I'm pretty confident in that assumption. The page layout and wording of the user interface create that false illusion, and for the most part you only discover the truth the hard way. Intent of the macro aside, I'm looking at things from the big picture, for someone who doesn't have a full understanding of how things are "supposed to be done". You describe a very specific methodology, which covers a single usage model. There's no help, no explanation, no hints that convey this specific way of doing things to the user. If there is a "correct" way to do it that gives reliable results, the user should at least be pointed in that direction.
• Your assumption about the reviewer is that he only clicks the updated links based on the comments. For that behaviour it would be better to not have the "ignore_pages" feature. But that would also need a different updated link behaviour to avoid seeing all stuff multiple times. Also note that the reviewer might get easily fooled by incorrect comments.

  • That is how I use RecentChanges, or at least how I did do it before I discovered this problem. Based on the page name and user, I can often decide whether it's worth looking. If a new user edits a certain page, I definitely would want to scrutinize the changes. But there are certain users I trust, and I pretty much leave them to do what they want, especially if it's a section of the wiki they "own", or manage. Other times I need to read the comment to make the decision; some people I trust to enter good comments, and I do rely on them. Others I may be more suspicious of, or they may not enter comments at all. These I check. My intent is not to look at every change to every page. I want to selectively review pages to get the most done in the least amount of time. I submit that what it takes to effectively administer the MoinMoin site, a large, public wiki that supports an open-source product, which it also runs on, is far from the typical user's case. So even though something works well or makes sense to the MoinMoin admins, perhaps a large number of users have a very different experience.

So what I'm really saying is the big picture is broken, not necessarily any one part. (Although IMHO the macro IS flawed, from a usability standpoint.) Maybe the fix would be 2 or 3 alternates to the default RC, maybe it will be a good all-around fix to the macro that could replace the default, maybe it's simply providing a good set of documentation on how to effectively use the page and how not to do it the "wrong way", no matter how much it may seem like it should work. (There's more than one way to use the page, and apparently some ways are more right than others. But nobody tells you that.) At a very minimum, the user should be informed that the changes shown may not be in the form they expect.

... as opposed to just dismissing the issue out of hand because it doesn't cause you any problems the way you use it.

To put my money where my mouth is... I'll draft some docs that hopefully will make it into the distribution (HelpOnRecentChanges?), and even try my hand at some macro solutions. I just think this is a big enough issue, that potentially effects so many people, it's worth having a main-stream solution rather than leaving it up to each wiki installer.

I'm no native english speaker, but maybe Steve you can help on this. In my eyes recent changes isn'nt a recent changes rather a latest changes: it shows only the newest, latest changes to a page. The word recent changes conveys some idea of a history or chronology. It shows all changes done to a page in the last weeks. On MoinMoinPatch/LessConfusingRecentChanges you can find a patch for a real recent changes. So my plead is to rename current RecentChanges in LatestChanges and add a real RecentChanges ('AllChanges') like given on MoinMoinPatch/LessConfusingRecentChanges and document these things on a new help page. -- OliverSiemoneit 2007-09-10 15:53:15

Plan

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinBug