True, but the comment itself is not really part of that audit trail, it's just a note that came along for the ride. The majority of comments in the wiki that I administer are blank, if people wanted to go and add a comment, I'd be all for that... cheers, -Nick Brion Vibber wrote:

Perhaps a useful compromise would be, if Nick P is willing, to add another flag, which specifies whether users can edit their own edit summaries, or whether this is reserved for SysOps only. For my intranet use of Mediawiki, I would leave it open to all, for something like wikipedia, the wikipedia administrators could enforce that this be used only by SysOps. In any case, I'd like to see this merged back into the HEAD tree, even if Wikipedia and family don't use it. regards, -Nick T John Lee wrote:

On Nov 25, 2004, at 10:03 AM, Nick Triantos wrote: I would not accept it in the tree. -- brion vibber (brion @ pobox.com)

Brion Vibber <wikitech-l(a)wikimedia.org> writes: But Nick Triantos <wikitech-l(a)wikimedia.org> writes: I happen to believe that the comments go along for the ride. The *real* audit trail, on low volume wikis anyway, is the Recent Changes log and I am definitely not proposing changing that. The problem with the main Wikipedia sites is that the volume of recent changes is so vast that the Recent Changes log is barely usable. There are changes to an article you can make now, that are NOT reflected in the History. If you move an article, there is no clue, in the History, that an article once had another name. Here, the Recent Changes file is the keeper of the fact that the move took place. John Lee <wikitech-l(a)wikimedia.org> writes: This is a very good point, at least for Wikipedia. Enabling this feature could start a whole new form of flame wars! I have an idea of how to modify this feature that would address the very valid concerns that Brian and John Lee have about turning this feature on. The main reason I have implemented this feature is to allow people who omitted a comment or made an error in it, to correct it. The secondary reason was to allow Sysops to add a comment where one is needed and, perhaps, to remove offensive language. 1) What if I add a variable $wgUserEditCommentTimeout, which specifies a *time limit*, in minutes, and specifies the amount time a user has to modify a comment before the comment "becomes permanent"? Most users discover any error they've made almost immediately on saving a revision. Allowing them a limited amount of time in which they can modify a comment would allow them the opportunity to fix their comment without opening up comments to rampant violations of etiquette. I could allow values of 0, don't allow users to make any changes to comments, which would satisfy Nick Triantos's request, or -1 to allow a user all the time in the world to modify a comment. For Wikipedia, one might set $wgUserEditCommentTimeout to a low value, like 5 or even 0 until 2), below were implemented. Most sites that use this software would probably institute more liberal change policies. 2) Comment changes should be logged in Recent Changes. Recent Changes is the most accurate audit trail now and should have note of these changes. A brief look at the definition of the table 'recent changes' suggests to me that it may need modification to record these changes. This should be made as a separate CVS change, perhaps made by someone more expert in this area than myself. 3) One could, as a future enhancement, create a db table and actually log comment changes and optionally, hopefully, show such changes in the History. But I think this may be more bookkeeping than is required. The vast majority of users, I'm sure most would agree, are conscientious, and would welcome the opportunity to adjust their summary comments. The history is less valuable if it is full of omissions and errors. Remember, normally only the user who submitted a revision is allowed to change the comment by this feature. I spent a fair amount of time implementing this feature, and making it as bulletproof as possible because I do think it will prove to be a quite valuable on most wiki sites. There are many valuable features in the MediaWiki software, that it is not practical to turn on for Wikipedia though I think it will prove useful there to. Just as one wants to make the articles as accurate as possible, one would like the History to be as accurate as well. Nick P.S. A test by me shows that users' Watch Lists show the comments from the actual revisions, not the Recent Changes log.--NP

On Dec 3, 2004, at 3:28 AM, Nick Pisarro wrote: Well, it often will work on a lightly used wiki. On a heavily used wiki, though, certainly no. But then you'd never see 30 days' worth of edits anyway on a really busy wiki, since the numeric limit will be hit long before. The recentchanges table is purely an optimization hack. Originally, Special:Recentchanges pulled data directly from the cur and old tables, but this was very inefficient: first, at the time we were on MySQL 3.x which couldn't optimize descending sorts using an index (eg, the timestamp field). This meant that hits had to pull a bunch of rows from cur and old and sort them each in a temporary table. More generally, slogging cur and old rows around meant an extra burden because they carry the full article text. Putting edit notifications into a smaller table as well meant that they could be pulled out much more quickly, with less copying and sorting and merging of large records. We later added the inverse_timestamp fields to cur and old to provide for descending sort optimization for other features (such as Special:Contributions and page history), and MySQL 4.x I believe can do a descending sort efficiently, so the table is not as important anymore. In the next major revision we'll also be splitting the edit history bits from the page text parts of cur/old, so pulling directly from the revisions database will be much more efficient than pulling from cur and old now would be. We have extended the recentchanges table a little bit, specifically in regards to its 'epemeral' nature: "bot" edits are specially marked to be temporarily hidden from view, and we store IP addresses of editing users temporarily (they are not logged permanently, but having the information for recent edits assists in tracking down vandalism problems). None of this is permanent -- the permanent records of editing is in the cur and old tables. Perhaps. -- brion vibber (brion @ pobox.com)