Last modified: 2011-03-13 18:06:47 UTC
a request from shay yakir: hello, i am a syscop at the hebrew wikipedia and all the rest of the syscop asked me to report a problem that we have. when we make a revert there is no edit summery. this opption is very important to us because it's make transparency for the reason to the revert. here a link to the list of all the sysop in the he wiki that asking for this opption to be available. http://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%92%D7%99%D7%9C%D7%92%D7%9E%D7%A9/%D7%90%D7%99%D7%A1%D7%95%D7%A3_%D7%97%D7%AA%D7%99%D7%9E%D7%95%D7%AA thank you, shay yakir
Depending upon the method used to revert, you may or may not receive the option to provide an edit summary. If one views the older incarnation of a page via that pages' history, then edits and saves that version, one is presented with the option to provide an edit summary; this could be something like, "Revert - vandalism". However, when using the rollback tool, an edit summary is automatically reverted, something like "X reverted to previous version by Y on Z". Generally speaking, the rollback tool should only be used to correct simple vandalism, and all other reverts should go through the former process.
It would though be nice to give the admin the possibility to add an notive for the reason of rollback. For example: An IP-user makes some edit and adds some copyrighted content in an article. The admin reverts the article. And it would be nice if he can add a reason like: "reverted because copyvio: http://...". Mostly the ip-user don't want do any harm. He just don't know our copyright issue. If there's no reasoning or comment, he don't understand why his content is reverted. So he does it again, or he gives up. A short reason would help a lot in such situations. I would like to work on this problem because the example above is quite often on the Chinese Wikipedia. Probably because the copyright issue is not quite perceived in China. And such a field would make a lot of work easier for the admins there. I have got the source from cvs, but would like to get some hint where to start.
I don't see that inserting such a field would actually be any less work than using the conventional method available to normal users. To be frank, I think that if a special reason for the revert is needed, then selecting the old version in the history and saving with an edit summary such as "Removed copyright violation - please see [[Wikipedia:Copyright]]" is just as good. Rollback is for fast reverting of a version; reverting from copyright violations isn't such a case.
Well, the experience is, people use this function to reverse copyright violations. And you cannot tell every admin, don't use that. Compare: If the admin use the conventional way, he must go to history page, select the earlier edition, make edit, type in reverse reason, and then save. Sometimes the net is simply slow, or the software doesn't work properly, and the user had done many edits, which should be reversed. (This happens quite often, please believe me.) Or he just click the reverse button. At the moment he have no choice to put a reason. Otherwise he can put a reason as a hint for the newbie, why his edits vanished. Many admins would choose the second way.
My opinion on the subject is that forcing a reason for rollback upon the sysop slows down the rollback process. What if several rollbacks are needed? Rollback is used for simple cases where not a lot of explanation is needed, i.e. vandalism, etc. If you have to provide a reason, it seems more courteous to me to take the trouble to use the alternative route. My second thought would be that this is effectively asking for a duplicate method to the same means; with a rollback function that has a reason field, then there is no difference from choosing an older version and reverting to it, whilst providing an edit summary.
Why can we don't make the reason field optional?
I'm not objecting specifically to the field itself so much as the slowing down of the rollback process by having to click a second button; whether or not you enter a reason would still be optional regardless, as is an edit summary. One compromise MIGHT be if we had two rollback modes; rollback as it is now, and revert; the latter actually just loads the previous version of the page in edit mode and plonks the cursor in the edit summary field.
Ok, agree. I would like to work on this subject. I think it is also related to #3546. Can you tell me where to start on. I am an experienced programmer on java and c++ and have installed mediawiki on my development workstation. I just need some hint to start on.
The rollback link is specifically designed as a quick way to revert large amounts of vandalism from one user by running down their contribs list and clicking the button. Adding any intermediate form destroys its usefulness. If you are doing reverts THAT ARE NOT FOR MASS VANDALISM, then you SHOULD NOT USE THE ROLLBACK LINK FOR THAT. If you are doing anything that requires leaving a specific comment, then click the history, edit, leave comment, save. Resolving WONTFIX.
Hello Brion, I see the idea. But as I said before, people just use it because it is an easy using tool. And I known quite a lot sysops using rollback just the way you don't want them to use it. And they wouldn't follow the way you tell them to do it. So from the point of view of the user, and I personally believe that the purpose of a software is to be used be the user, a developer should respect that. And I think the proposal of Rob is the way to tell the user don't use the rollback, but give him a quick way to do what he want to do.
You could set up a shortcut or bookmark of some description that would do what you want, or perhaps something in JavaScript. Don't ask me where to start though, I despite client-side scripting like that. Brion worded what I wanted to say better.
hi all. please see the [http://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7% A9:%D7%92%D7%99%D7%9C%D7%92%D7%9E%D7%A9/%D7%90%D7%99%D7%A1%D7%95%D7%A3_%D7%97%D7% AA%D7%99%D7%9E%D7%95%D7%AA support] i got in Hebrew Wiki for this idea. The Hebrew Wiki is a small community - only 65 users with more then 100 edits a month [http://en.wikipedia.org/wikistats/EN/ChartsWikipediaHE.htm]. only 10 admins are dealing with vandalism and the revert options used very often. It would be very nice to have such an option and as you can clearly see, this preposition has the support of almost all admins in Hebrew Wiki. Maybe it's not suitable for larger communities, but a small community like our can gain a lot if this option will be aviable for the admins
As has been said above; if it's simple vandalism, then using the rollback tool is fine. Sysops currently have two options for reverting changes, as described above.
well, it would be very nice if i as an admin could use this options. If I could give a short summery like "another edit of a known troll", "vandalism", "copy rights violation" or just "reverting please see the talk page for details" it will help me and other admins to serve the community
The point I shall continue to make is that you already have that functionality. Implement as follows: 1. Go to the article 2. Open it's history 3. Click on the version you want 4. Click edit 5. Enter a reason in the edit summary field 6. Save it This is sped up if using the link to the diff from Special:Recentchanges (which skips straight to step 3).
Well, it's not as simple as you think. When i am checking the recent changes, i am going to "difference" and then i revert. You suggest i will skip the revert option and open the file history. It is very uncomfortable. Of corse, if it a major change I am following this instuctions, but when it's just a simple vandalism or some minor error of a newcomer i don't have any option to give my reason for reverting. Of corse, I can be nice and i can go to the history and revert from it, but i don't do it becouse i am checking hundreds of articles every day. This feature doesn't suppose to replace the option you have mentioned. It just suppose to add more options to the admin. As a matter of fact, if you consider the current situation, admin can revert the article, even if it is a major change without giving any reason by using the revert tool. Of corse, this action is a violation of the admin rights and obligation, but lets not be naive - no one will cancel the sysop power from the administrator if his only failt is a couple of inexplained reverts. It means - by adding this feature you don't increase the power of admin over a simple user, but only give him a simple tool to explain himself to the community. I really don't see any reason to object this proposal.
You already can do this. Every user on the wiki can already do this. There is nothing that needs to be added, and it has nothing to do with admin powers because every visitor to the wiki can already do this.
You didn't understand. Of corse any user can revert the article from it's history. I am talking about adding a summary section when admin reverts the article from "difference between two versions". Since only the admins have the automatic revert option it is directly connected to admin powers. In simple words: instead of the automatic summary "reverted to the last version by user x" I suggest to give the admin the option to write the reason by himself.
Well of course, if we're talking about newbies, then one ought to consider that they won't necessarily check the page history for a reason. In these cases, a note on the talk page is more effective, and more personal.
I am not sayind a note on the talk page is not effective, but why should we limit the possibilities? If admin wants to make some personal note, its ok, but if he doesn't want? This is a very small feature which doesn't increase the admin powers but adds a new tool. I don't see any reason to limit the optitions admin has if it has nothing to do with his special rights over the regular users
This is becoming an argument of wiki principles, not a technical issue. I'll briefly answer your question by saying that any admin worth his salt knows to contact his users. Regardless, the functionality is present in two methods; adding a third introduces further complexities.
*** Bug 4367 has been marked as a duplicate of this bug. ***
*** Bug 5048 has been marked as a duplicate of this bug. ***