[Wikitech-l] Re: Implementing Editing Revision Summaries--An idea

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