Nick Pisarro here...after disappearing into the woodwork since the Spring...
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision. Assuming I still have the proper access rights to 'phase3' on SourceForge, I would like to merge my feature into the head branch and upload it assuming enough of you find the feature worthwhile.
The purpose of the feature is to allow people to correct errors they may have made in a summary or to add one when the may have forgotten to--a problem I have personally all the time. Sysops have the option to clean up offensive language in summaries.
I have attached screen shots of the feature in action. I don't know if the mailing list program will forward them.
Features. * The feature is controlled by a flag in Default/LocalSettings. * You may only edit the summaries of revisions you have made, except for SysOps, who may edit any summary. (Summaries are referred to in the PHP code as "comments".) Anonymous users, and hence users not logged in, may not edit summaries. * In the History listing and Contributions listings I have put a small icon next to the summary on lines a user may edit the summary of. * Clicking on the icon will bring up a page titled after the article being edited and subtitled "Editing summary of revision...". The page has an edit field and check box for adjusting the summary and/or changing the Minor Edit flag. A user my click "Save" or "Cancel". * A double check is done as part of making the database update, that the user is still logged in and that they are the author of the revision, if they are not a SysOp. This is done to thwart any evil robots spoofing a submit of the edit page. * The page is refreshed with a confirmation or cancellation message and a link back into the History or Contributions page the user came from. After ten seconds the user is flipped back automatically in a way that is similar to Login/Logout. * The edit page is implemented by a new file--EditComment.php. Internally I modified the function OutputPage::returnToMain() to allow flipping back to exactly where you came from, rather than always to a main article page.
Issues: Because there are no histories of summaries and hence no 'reversions' I thought there were too many security risks in letting anonymous users edit their summaries (which may not actually be theirs), or letting logged in users edit summaries other than there own.
Changing a summary will NOT change its listing in Recent changes. This is because this is a log of past events and is a copy of the original summary, not an actual reference to it. I thought it might cause too big of a performance hit to try to fix up the Recent changes log, and perhaps, philosophically not a good idea.
Future enhancement: Log changing the summary in Recent changes. This might require a database format change, so I did not want to attempt it.
If desired, I could convert this message to an article on meta.wikimedia.org.
User:Nick Pisarro, Jr.
On Nov 25, 2004, at 5:29 AM, Nick Pisarro wrote:
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision.
I would strongly, strongly recommend against this. The edit history is an audit trail, and should as much as possible not be allowed to be tampered with.
-- brion vibber (brion @ pobox.com)
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:
On Nov 25, 2004, at 5:29 AM, Nick Pisarro wrote:
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision.
I would strongly, strongly recommend against this. The edit history is an audit trail, and should as much as possible not be allowed to be tampered with.
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
The problem is, users sometimes include violations of policy (i.e. personal attacks) in their edit summaries. Allowing them to edit them would render this audit trail worthless.
John Lee ([[en:User:Johnleemk]])
Nick Triantos wrote:
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:
On Nov 25, 2004, at 5:29 AM, Nick Pisarro wrote:
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision.
I would strongly, strongly recommend against this. The edit history is an audit trail, and should as much as possible not be allowed to be tampered with.
-- brion vibber (brion @ pobox.com)
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:
The problem is, users sometimes include violations of policy (i.e. personal attacks) in their edit summaries. Allowing them to edit them would render this audit trail worthless.
John Lee ([[en:User:Johnleemk]])
Nick Triantos wrote:
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:
On Nov 25, 2004, at 5:29 AM, Nick Pisarro wrote:
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision.
I would strongly, strongly recommend against this. The edit history is an audit trail, and should as much as possible not be allowed to be tampered with.
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Thu, 25 Nov 2004 10:03:39 -0800, Nick Triantos nick@triantos.com 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.
That sounds like a good compromise, and remember that with the new User & Group Rights system [is that going live in 1.4?] it needn't even be "all sysops", since there can be an edit_summaries right, which could be granted only to a select few if that was felt relevant and worth-while.
However, with the feature not updating the RC log [am I right in thinking watchlists are also pulled from this, rather than the actual histories?], the value of the feature seems limited anyway. But in combination with other things like selective revision undeletion, I can conceive of uses in some of the more unusual applications of the software (they may not seem like a "true" wiki, but even the existence of a Talk: namespace was pushing that envelope once, and in the end it's up to each site-admin what they do with the software available).
Of course, the more things like this we add "in case someone wants it", the more bloated the system becomes, but without a well-developed extension mechanism [and where would the hooks that allowed this be?] the alternative seems to be someone maintaining a patch so it continues to apply cleanly...
Brion-
On Nov 25, 2004, at 10:03 AM, Nick Triantos wrote:
In any case, I'd like to see this merged back into the HEAD tree, even if Wikipedia and family don't use it.
I would not accept it in the tree.
How about if it was limited so that only the summary for the top revision could be edited?
Regards,
Erik
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of programming frenzy, I have implemented a new feature; the ability to edit the summary and Minor Edit flag of an article revision.
Brion Vibber wikitech-l@wikimedia.org writes:
I would strongly, strongly recommend against this. The edit history is an audit trail, and should as much as possible not be allowed to be tampered with.
But
Nick Triantos wikitech-l@wikimedia.org writes:
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...
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@wikimedia.org writes:
The problem is, users sometimes include violations of policy (i.e. personal attacks) in their edit summaries. Allowing them to edit them would render this audit trail worthless.
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
NickP writes:
- 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"? ... 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.
I have implemented this. If a time limit is set, once a user starts editing a comment (summary), I give them an extra 2 minutes to allow them to edit the change. After the timeout their change is rejected.
- 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.
I have implemented this. I put a message in Recent Changes of the form: "Summary of *article* changed (diff; *hist*) . . *Username* (Talk) was (*original comment*) now (*new comment*)". I made the link to the article open the article revision whose summary was revised.
It turns out that I did not have to change the schema of 'recentchanges' to implement this. I added a new type of change (define( "RC_EDIT_COMMENT", 5);) and usurped the field, 'rc_moved_to_title', to hold the original comment, since it is only used when logging moves--slightly kludgy. I modified Skin.php to properly format the new type for old and new format RC pages.
But while this all works great, I did discover a bit of a "got cha". I noticed that the number of 'recentchanges' records in my 'wikidb' is a small fraction of the number in 'cur' and 'old'. It seems that after every 1-1,000 changes the RC table is "pruned" to hold only the last week's changes. Hmmmm. I found this disturbing for several reasons: 1) The Recent Changes page lets you "see" up to 30 days of recent changes--won't work. 2) As this could be the definitive log of *all* changes on a wiki, I would think you should *never* want to prune this. 3) At the very least, the age to which it is pruned should be a variable in DefaultSetting.php so it could be adjusted on a wiki by wiki basis.
My changes are based on 1.3.7, so I have yet to merge them to the head branch.
Nick
On Dec 3, 2004, at 3:28 AM, Nick Pisarro wrote:
But while this all works great, I did discover a bit of a "got cha". I noticed that the number of 'recentchanges' records in my 'wikidb' is a small fraction of the number in 'cur' and 'old'. It seems that after every 1-1,000 changes the RC table is "pruned" to hold only the last week's changes. Hmmmm. I found this disturbing for several reasons: 1) The Recent Changes page lets you "see" up to 30 days of recent changes--won't work.
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.
- As this could be the definitive log of *all* changes on a wiki, I
would think you should *never* want to prune this.
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.
- At the very least, the age
to which it is pruned should be a variable in DefaultSetting.php so it could be adjusted on a wiki by wiki basis.
Perhaps.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org