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
That talk page is open to any questions or suggestions concerning Edit Review Improvements. Please browse topics before posting: your question may already have an ongoing discussion!
$wgDefaultUserOptions['rcenhancedfilters-disable'] = true;
$wgDefaultUserOptions['wlenhancedfilters-disable'] = true;
$wgHiddenPrefs = ['rcenhancedfilters-disable', 'wlenhancedfilters-disable'];
Although the person asking the question may have a case of "new feature shock" kind of thing.
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
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.
Issue:
It is impossible to view oldest changes if those exceed the 500 - 1000 limit.
Proposed solution
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.
To apply Edit Review Improvements on...
$wgStructuredChangeFiltersShowPreference=true;
$wgStructuredChangeFiltersOnWatchlist=true;, $wgStructuredChangeFiltersShowWatchlistPreference=true;
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:
$wgStructuredChangeFiltersShowPreference = true;
$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:
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.
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.
@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;
@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?
Related: T171757
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:
Some ideas:
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...
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 --~~~~
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.
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:
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.
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:
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:
There are many aspects to consider and probably more ideas to add to the list, but I think this is a promising direction.