Developer Wishlist Survey: propose your ideas
At the Wikimedia Developer Summit, we decided to organize a Developer Wishlist Survey, and here we go:
The Wikimedia technical community seeks input from developers for developers, to create a high-profile list of desired improvements. The scope of the survey includes the MediaWiki platform (core software, APIs, developer environment, enablers for extensions, gadgets, templates, bots, dumps), the Wikimedia server infrastructure, the contribution process, and documentation.
The best part: we want to have the results published by Wednesday, February 15. Yes, in a month, to have a higher chance to influence the Wikimedia Foundation annual plan FY 2017-18.
There's no time to lose. Propose your ideas before the end of January, either by pushing existing tasks in Phabricator or by creating new ones. You can find instructions on the wiki page. Questions and feedback are welcome especially on the related Talk page.The voting phase is expected to start on February 6 (tentative). Watch this space (or even better, the wiki page) - SSethi_(WMF) January 21st, 2017 3:07 AM (UTC)
Improvements coming soon to Recent Changes
Sorry to use English. Please help translate to your language! Thank you.
In short: starting on 26 September, New Filters for Edit Review (now in Beta) will become standard on Recent Changes. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.
What is this feature again?
Based on a new design, it adds new features that ease vandalism tracking and support of newcomers:
- Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
- Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
- Bookmarking to keep your favorite configurations of filters ready to be used.
- Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.
You can know more about this project by visiting the quick tour help page.
Starting on 26 September, New Filters for Edit Review will become standard on Recent Changes. We have decided to do this release because of a long and successful Beta test phase, positive feedback from various users and positive user testing.
Some features will remain as Beta features and will be added later. Learn more about those different features.
If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).
You will also be able to opt-out this change in your preferences.
Starting on September 19, the Beta feature will have a new option. Watchlists will have all filters available now on the Beta Recent Changes improvements.
If you have already activated the Beta feature "New filters for edit review", you have no action to take. If you haven't activated the Beta feature "New filters for edit review" and you want to try the filters on Watchlists, please go to your Beta preferences on September 19.
How to be ready
Please share this announcement!
Do you use Gadgets that change things on your RecentChanges or Watchlist pages, or have you customized them with scripts or CSS? You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.
Please ping me if you have questions.
Hello. While browsing the AbuseFilter configuration for this project I noticed that due to this discussion and this Task, you asked the AbuseFilter to be able to block users. However since when they added the configuration they forgot to add $wgGroupPermissions['sysop']['abusefilter-modify-restricted'] = true; the result is that no local admin can set a filter to block ('block', 'rangeblock' and 'degroup' are restricted options and only those with 'abusefilter-modify-restricted' can create/modify filters with those options enabled). If you still wish your filter to block, and the community is okay with it, I can submit a patch for review to amend the configuration. And now that we're on this AbuseFilter topic, if you wish any other amendment made to the AbuseFilter configuration I can take care of it too. Please let me know your thoughts on this. Best regards, MarcoAurelio (talk) 10:51, 16 October 2017 (UTC)