A dedicated venue for combined discussion about the future of these two review systems where a work group is also proposed has been created. See: Wikipedia:The future of NPP and AfC --~~~~
Talk:Edit Review Improvements
need to shift vandalism reversion to revscore, and pivot NPP to quality circle using teahouse methods. blow up AfC: it is worse than ACTRIAL, and is not saveable, rather train yet another quality circle to mentor new editors to use sandbox, and get sources. and templates should not be used with new editors.
Latest update does not allow manual entry of puzzles
With all due respect, how do I disable the new Recent Changes thing on my wiki? Sorry about the rushed message, but I didn't want it to put unnecessary demand on my server.
MediaWiki 1.32 PHP 7.2.13 MySQL 5.7.23
I think it's the opposite of Topic:Uloe5dgmkypfnu0h.
With all due respect, it isn't working.
Hm, yes. The config vars have been removed since. So... what about $wgDefaultUserOptions['rcenhancedfilters-disable'] = true?
I'm sorry, while $wgDefaultUserOptions['rcenhancedfilters-disable'] = true does have an effect on user settings, it still allows users to enable it. I wish for the enhancements to be disabled completely on both the Watchlist and Recent Changes.
I feel that my wiki cannot cope with the additional resource usage that doesn't justify for the fact that we are clearly not as large as Wikipedia. I feel that the implementation of the Edit Review Improvements is too soon, due to lack of documentation. The release notes for 1.32 says nothing about the Edit Review Improvements.
The feature was announced in MediaWiki 1.29's notes. It doesn't add significant extra server-side resources, except perhaps for the "live" option if abused.
I guess I fell behind again on that.
I'm sorry if I sounded harsh earlier, but the live changes thing is the thing that concerns me. We are just not big enough to have that feature enabled.
If you can find a better method than the following, please reply:
$wgDefaultUserOptions['rcenhancedfilters-disable'] = true;
$wgDefaultUserOptions['wlenhancedfilters-disable'] = true;
$wgHiddenPrefs = ['rcenhancedfilters-disable', 'wlenhancedfilters-disable'];
That should prevent your users from using it, yes. Obviously an auto-refreshed browser tab pointed at the page, which the "live" mode replaces, uses more server resources, but it sounds like that's not a concern for you.
Maybe it is just a case of me being very unfamiliar with this new feature. I am sorry about being harsh.
Issue:
It is impossible to view oldest changes if those exceed the 500 - 1000 limit.
Proposed solution
- Make rcdir=newer and rcdir=older work on recentchanges pages
- Make it work as a simpler initial implementation only available as a url parameter
- Make it work exactly the same way as the API(see API:RecentChanges or&list=recentchanges&rcdir=newer&rclimit=500)
Note:
A full interface is not part of this suggestion.
When combined with recentchanges from parameter (e.g. Special:RecentChanges&from=20181207124145) this would effectively be a poor man's version of navigation for older changes (pagination). For example, it would allow users to do something like Special:RecentChanges&from=20181207124145&dir=newer, and would work pretty much like https://www.mediawiki.org/w/api.php?action=query&format=json&list=recentchanges&rcstart=2018-12-01T12%3A46%3A39.000Z&rcdir=newer&rclimit=500.
Exposing it solely as a URL parameter is simpler, and hopefully trivial, and opens the door to a simpler implementation using userscripts or javascript. This would be much like how the search engine provides the ability to sort (Special:Search/booo?sort=last_edit_asc ) without an interface.
Which extension is needed for set up and how should I configure that?
What are you looking for precisely?
I'm looking for adopting Edit Review Improvements features (such as new toolbar on Recent changes) on my wiki.
In LocalSettings.php, you have to change the following settings:
- for RecentChanges:
$wgStructuredChangeFiltersShowPreference = true; - for Watchlist :
$wgStructuredChangeFiltersShowWatchlistPreference = true;
A future change, coming soon, will give those elements as default (they would still be disable-able in user preferences or global settings).
"the increasing use of automated and semi-automated edit-review tools has brought about an increase in rejection"
Do we know how the language used within these tools impacts the response from new editors? An automated tool written with language that is friendly and welcoming compared to something that sounds cold or (too) severe might actually impact the response from editors. One potential approach is a non-technical one. Re-write the dialog/interface/messaging of a tool and see if there is any impact to retention of editors who encountered that tool.
@CKoerner (WMF), it's a good point, and one that has been mentioned by a number of the users we've interviewed so far. What I get stuck on when I think about that issue, though, is that if I understand correctly how a lot of this works, the messages posted by programs like Twinkle or Huggle were actually written by the community. On en. wiki, they're codified on the Wiki Project User Warnings, and simply sucked in by the programs.
So if the community wrote those messages, what would the process be for re-evaluating them?
If we have data about how new users feel when they read these messages and how unclear they can be, that can convince people from wikis to rewrite these messages. On wikis where the community is active on outreaching (like Catalan, French and Polish Wikipedias), based on feedback received from IRL workshops, messages have been rewritten to be more warm and with clearer instructions.
@Trizek (WMF) beat me to it. In past lives the organization I worked for would seek out folks with skills in writing to help update the messages. We'd also do some sort of testing (A/B testing, surveys, in-person workshops) with actual people to get feedback on how they perceive the messaging.
IIRC the study, there is two things which impact new users:
- automated messages (the content of the message)
- number of messages (delivered like if whey were delivered by a machine gun)
Rewrite that kind of messages is a way we may explore, or, at least, give recommandations to people. As a volunteer, that's something I care about - a lot.
There have been several initiatives by the volunteer community in recent years to recast the template messages in order to make them less seemingly offensive. I was part of tat work group. This was the result of extensive study. I suggest that any discussion on the wording of template messages should involve the volunteer community who have the best hands-on and empirical experience.
If you have any links to share it would be greatly appreciated!
Sadly I wouldn't know where to start looking. I know that @DGG was in the same work group. Maybe he can remember. The main point of my mentioning this of course, is that the experienced members of the volunteer community know what works best. As an admin and as a patroller who patrolls the work of our patrollers I regularly see how our best templates are abused by being used on the wrong editors for the wrong reasons, it's something I care about very much. Hence the problem on en.Wiki is not the templates - it's the fact that there is currently no control over who can use them.
I have that, from the French Wikipedia Projet Aide et accueil.
@Jmorgan_(WMF) As I am working on translation at https://www.mediawiki.org/w/index.php?title=Special:Translate&showMessage=Edit_Review_Improvements%2F22&group=page-Edit+Review+Improvements&language=ja&filter=&optional=1&action=translate, I find;
- Wikimedia Research/Design Research page https://www.mediawiki.org/w/index.php?title=Wikimedia_Research/Design_Research&oldid=2547218 is outdated. Do we change the link for the working group as Wikimedia Research, instead?
- For your info, Welcoming Committee's equivalent in jawiki is inactive at: https://ja.wikipedia.org/wiki/Wikipedia:%E3%81%82%E3%81%84%E3%81%95%E3%81%A4%E5%90%8C%E5%A5%BD%E4%BC%9A. I first thought I could add a link to it, since " Welcoming Committee" did not sound familiar to me, but it doesn't look practical.
- Talking about translation, Teahouse is not put into ja either.
@Omotecho Thank you! I suggest you do this:
- leave the link to Design Research, since I was working on the design research team when I conducted that research
- if you want to, you can link to the English Wikipedia Welcoming Committee page: https://en.wikipedia.org/wiki/Wikipedia:Welcoming_committee
- if you want to, you can link to the English Wikipedia Teahouse: https://en.wikipedia.org/wiki/Wikipedia:Teahouse
Does that help?
User:Jmorgan (WMF), yes, everything is clear with me, thank you.
Having edited non-wikimedia mediawikis for years it was always clear that the special:recent changes was a nightmare. Aside from the filters that were all over the place, the biggest issue is the actual result list. Browsing the list of results is a pretty complex experience with revision data moving about randomly.
Some concrete issues with it:
- The location of the user name isn't consistent
- The extent of the changes are always unclear - bytes added or removed aren't a good enough indicator of anything. Someone can easily alter the whole article, and still only "add" 20 bytes.
- Hard to identify individual editors - one or two editors might be vandalizing and thus editing a lot, yet it is not possible to sort the list to see this easily.
- Cluttered content - everything is jumbled, and it sometimes becomes hard to see where one revision ends and another begins
Some ideas:
- Organize key elements of the revision data into a grid like layout
- Username at the end - truncated to certain characters , expand on hover or click.
- Use symbols to indicate some changes - use colors and an icon or symbol to denote extreme changes, e.g page blanking
- Tags - could also be truncated with hover, or click to show more, or use symbols for some changes, e.g. visualeditor (✎) , mobile (📱), etc
- Show a summary of visible recent changes - e.g. top editors (Joan, pierre, Yu)
- Separate content - put it in predictable areas so that users always know where to look for them.
Even the best filters can't help when the result set is a complex mix of content.
You are right, there are many aspects that can be improved from the list of results. The current efforts have been around helping reviewers to find the contributions of interest for their reviewing activities, so we mainly focused on improving the filtering system.
The list of results is a piece of information that many reviewers got their eyes trained to scan and we need to learn more about how are those used before proposing changes in this area. Your input is already useful in this regard, thanks for sharing it!
Thanks for your comments. The Collaboration Team completely agree.s I have to say, though, that the Edit Review Improvements project is not strictly about fixing Recent Changes; the goals are broader. So, as much as we'd love to dig in and make RC page results more clear and consistent and just useful, without a lot more community demand I honestly can't say this is on our roadmap at present. Maybe try suggesting a redesign of the results on the Community Wishlist next year. As I say, we share your pain!
Yes, this is something that requires a lot of thinking and research, so I don't blame you for not getting into it (if ever), as you'll likely also face resistance even if the implementation is considerably superior to the current state. Humans (and all or most animals really) are creatures of habits, and they've gotten used to the current layout.
There is also already support for improving such lists in general, assuming you mean the Community wishlist survey (https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Editing#CW2016-R071). That one focused on the the history page, which is mostly the same result layout used for most lists containing updates to pages / revisions.
The proposed mockup (https://samanthanguyen.github.io/mediawiki-demo-VisualChanges/) seems like a good starting point to (although an obvious user complaint will likely be extra unnecessary whitespace).
It is still an important part of reviewing in general, so even if extensive changes are never be made to it, some minor stylistic touch ups would certainly improve matters.
Thanks for these links. I'll check them out. And yes, the issue of user resistance on this layout is certainly one that factors into our thinking. But it is something that should be done...
Do you have some ideas about how to encourage supportive behavior? I remember someone talking about a task-management program that they liked, and one of the things that they particularly liked about it was that if you took certain actions (such as marking a task as completed), then there was a small chance that you would get a cute animated image as a reward (confetti? flying unicorn? I don't remember any of the details). It's silly, but it's friendly and human, and I suspect that it encourages many people to keep their tasks up to date.
Have you considered trying something similar to reward actions that we think are encouraging, such as Thanking editors for their first edit?
I'm glad you brought that up @Whatamidoing (WMF). Thanking is so simple yet so powerful! (So thanks!) I need to find out more about what happens currently in the area of automatic messages to new users, so we can add to it intelligently...
In addition to thanking the new users, we've also been thinking about how to keep constructive reviewers engaged. @Pginer-WMF had the idea to somehow reward reviewers by exposing the positive outcomes of people they've helped -- alerting the reviewer when one of the people she helped reaches a certain number of edits, for example. It could get a little complicated but I like the idea. We can also encourage people who get reviewed to thank the reviewer, of course.
> We can also encourage people who get reviewed to thank the reviewer, of course.
You might want to put some limits on how often you suggest that. People who edit the Main Page at enwiki get thanked many times for the same actions, and it can be disruptive. It's easy to mark a hundred pages as patrolled in a day, or to leave a hundred welcome templates, but I wouldn't want to get thanked for each one. Being thanked is more fun when it doesn't happen a dozen (or a hundred) times each day.
The volume of actions is a key point to consider related to the review activities. Thanks for pointing to that, @Whatamidoing (WMF).
My thought are along the lines of giving more visibility to encouraging factors, but not necessarily interrupting the users every time. Some possible examples:
- In your review dashboard you have a list of your recent reviews and some of them have a "1M thanks". You didn't got a notification each time but the effect of your work becomes visible to encourage you to review more.
- In your Review dashboard you can view information on the users that you reviewed last week. Next to each user there is a visual summary of their last contributions, allowing you to see that some of the users you helped are getting less reverts and more accepted and thanked edits.
- For a custom review feed on a very specific topic (e.g., "edits on Mexican rock bands by good-faith newcomers"), you decide to subscribe and receive notification about what is going on. A bulk notification of 100 new thanks being received this week may be acceptable since it is connected to the subscription you explicitly made and the frequency is controlled.
Pau
"Bulk notification" sounds like a good approach. I wonder whether it's possible to have a bulk notification that says "You were thanked 8 times [since the last time you looked] for marking 8 different pages patrolled"? "You were thanked 8 times for marking [[Example]] patrolled" seems like it would be easier to create, but most thanks for that kind of action would be one thanks per page.
'Thanking' editors is possibly one of the most abused process on Wikipedia. An excellent initiative when it was created, it's largely gone the way of barnstars and Wikilove. It's time developers understood that not all Wikpedians are children or young adults, even if many of them act as if they were.
Did you knew that on some wikis (including non-Wikipedias wikis), there is no barnstars or wikilove processes? Or on other wikis, they are not used that much? Thanks provides a way to thank people in context, quickly. When I see how many thanks are respectfully sent on wikis where I'm active on, I don't know how many people are sharing your feedback. :)
I was curious as to how well used Thanks was. On the English Wikipedia in the month of June just the top 100 "Thanker's" gave out over 10,273 Thanks.
Source (you can fork to run it for other wikis!): https://quarry.wmflabs.org/query/11641
That link may interest you, Chris: https://meta.wikimedia.org/wiki/User:Faebot/thanks
Well, there is always the trap of mistaking "my view" for "everyone's view", but I personally find Thanks very helpful. Like many users, I use it to indicate gratitude for a helpful edit and to let people know that I'm interested and supportive of their efforts.
In some contexts, I also use it to say, "I saw your reply to my comment". I don't think this is a misuse. It's not materially different from the brief "Thanks" that one says in person, when someone hands you something that you wanted while you're busy (or they are). In person it looks like this: I'm talking to someone while walking down the hallway in one direction; you're hurrying down the hallway in another direction. You have something that I need. As we approach, you hand it to me. I say "thanks" as we hand it off, and we both keep going. On wiki it looks like this: I'm doing my work, and you're doing your work. You have some piece of information that I need. You post it; I see it. I click the thanks button so that you know that I've got the information now. We both keep going. It's the same thing, just translated to my wiki life rather than my meatspace life.
I have rarely heard of uses that give me pause, e.g., someone being Thanked for posting a patently rude message or for joining an edit war, but in the few cases where I've bothered to check the log for the names of people Thanking someone, I suspect that those Thanks were truly genuine expressions of gratitude and support.
You'll forgive me for not being overly concerned about the way the other Wikimedia Wikis work. Except perhaps for the way the French Wiki does not insist on the same high standards of notability and sources that we do on en.Wiki. Et c'est pour cela que je n'y bosse pas.
(Certains francophones disent la même chose des anglophones ! ;-))
Peut-être, mais j'ai déjà traduit pas mal de vos articles pour en.Wki ;)
Based on the mailing list discussion, I would like to propose to minimize article deletions. I have a fairly new editor and I had issues because the article I created was speedy deleted because it was found that it does not convey that the topic is significant enough. Not that it is not significant, but that it only does not explain why it is significant well enough.
Deletion of the article meant that I could not improve the article further and address the issues. Nor that I had an opportunity to learn with help from others how to do better articles. Even more, to even get access to the content I created, I had to go and ask the admin to restore it. I had to learn all this, find ways to communicate with somebody, and engage in discussions. Now it seems clear what happened, but at that time was far from that. Why was an article deleted without any due process (from my perspective)? Why I cannot access anymore the content I contributed so that I could improve it and try again?
Based on this I would recommend the following approach:
- There is a global draft namespace (I heard something like this exist).
- Instead of deletion of articles, move them to this global draft namespace and provide a link to it from the original (now empty) article name, so that others interested in this article can find it among drafts and help.
- Only articles which are illegal or have some other very serious reason to be deleted should be deleted. Everything else should be kept on the basis of good faith.
- Now editors can continue to edit the article (draft) and eventually move it back to the main namespace. Not just the initial author of the article, but also others can join (and find the place to join).
- After some period (3 months? 6 months?) of draft being in the draft namespace, and it status not improved, it could be automatically deleted.
The important thing is that deletion becomes much less common. This improve experience of new good faith editors because they have a clear path forward and know what is wrong and how to improve the draft to be moved back. Bad faith editors would have their articles moved away to a draft namespace, which is not what they want anyway, so it will disrupt their agenda similarly to deletion.
Deletion is really problematic because it is so final. It cuts the whole process. To me reverts are much simpler. Your contribution is still there. You can improve on it. You can discuss it. Deletions (especially speedy ones) are experienced more forcefully.
Having been instrumental in getting the Draft namespace introduced, this all sound very similar to an initiative I begun some time ago. en.Wiki has a serious problem with its New Page Patrol system (a process that @Whatamidoing (WMF) claimed some years ago was not necessary), in spite of the excellent Page Curation suite of software tools that was also the end result of an initiative of mine and good , direct, collaboration between very senior staff who are no longer available for comment and the volunteer community.
Do feel free to find that alleged statement of mine. I, at least, will be interested in reading it in the full context.
Thanks for your feedback,@Mitar. It makes a lot of sense to reduce the negative impact of feeling that your work has been thrown to the trash. We have been exploring some ideas in this area:
- Encourage reviewers to move to some kind of working area instead of deleting it. It may be the global "draft" namespace or a sub-page on the user namespace (as many advanced users use as a kind of "draft" area).
- Anticipating the issues, and when the content is likely to be reverted, suggest to the user the possibility of publishing as a draft instead and provide the opportunity to ask for help.
- Provide some room for editors to improve the content before it is reviewed. For newcomers editing articles that are rarely visited but identified as likely to be in good-faith, we can consider deferring the review process so that they have an extra time to improve their content.
There are many aspects to consider and probably more ideas to add to the list, but I think this is a promising direction.
There are no older topics