Community Wishlist Survey 2017/Status report 1

This is an end of year report published by Community Tech team on the work we accomplished over 2018. We had an exciting year with lots of interesting projects that made it to the top in the 2017 Wishlist Survey. This year has given us an opprtunity to learn a good deal about templates, maps, edit summaries, editing experiences and so much more. We got a chance to talk with a lot of small user groups, from maps devotees, to grantees, to people with black belt in SVG editing. It has been a wonderful experience and we want to echo our heartfelt thanks to everyone who has spent time helping along our projects.
We are still working on some of these projects and you will continue to hear about them from us.


Community Wishlist 2017 projects edit

Kartographer improvements edit

 
This image file shows an embedded (mapframe) map of the 2018 Wikimania location (mapframe maps are not implemented on Metawiki). Link to actual map.

Kartographer improvements was the #1 wish in the 2017 Survey, indicating a big need for better wiki maps. The project was too big for Community Tech to handle alongside its other work, so Collaboration Team was dedicated for six months to the job. The project, dubbed Map Improvements 2018, had two goals: 1) to ensure that Kartographer and the associated maps technology stack were stable and could be easily maintained as maps gained a wider audience; and 2) to accomplish the two “main wishes” named in the Community Wishlist proposal, along with as many of the other wishes as were possible in the time provided. (Of the two main wishes, by far the most significant and challenging was T112948, “All map location names should be shown in the user's language.”) In June of 2018 Collaboration Team succeeded in meeting those goals. In addition, the team took on the extra challenge of bringing embedded (mapframe) maps to 277 Wikipedias that previously lacked the feature (including English Wikipedia). Between that feature  launch and the writing of this report, at the start of 2019, users have illustrated wiki articles with over a half-million new embedded maps. (Read more about map internationalization here: "Interactive maps, now in your language.")

Ping users from the edit summary edit

 

This was one of the more straightforward wishes from the wishlist with the project requirements being very clear. The request was to let users ping other users from edit summaries, using the regular user mention syntax - [[User:XYZ]]. This feature was implemented early on in the year. Since it was a part of the Echo extension, it was made available on all wikis as it rolled out. Based on feedback, we had to make a way to ignore pings from bots in edit summaries and to also ignore pings from automatic summary mentions when edits are reverted.

Event Metrics edit

 

The third most popular wish of the 2017 Survey asked for a “next generation tool” to quickly and easily provide the metrics that event organizers need to help measure their projects and demonstrate the impact of their work. Despite the title of this wsh, it was clarified prior to voting that the WMF would not be supporting the Dashboard any longer and would instead work on a different tool. That tool, an evolution of the Grant Metrics tool, has been dubbed Event Metrics. As of January, 2019, we are in the midst of developing Grant Metrics, which is designed to provide a wide range of new statistics to event organizers, in addition to new filters that will enable them to more flexibly and narrowly define events in the system.

"Who wrote that?" tool edit

Blame Tool is one of the hardest projects that came out of the 2017 wishlist. There are a couple of existing solutions but there is no good way to integrate the required functionality in MediaWiki. Searching thousands upon thousands of revisions to find out who wrote which part of an article requires extremely fast searching of revision history, which is not possible with the storage system we use for the wikis. To implement such a storage system that would work for all projects is out of the scope of this team and would require a lot more server space, time and effort than we had on our hands. But lucky for us, the WikiWho service already maintains such a service (although it does not work for all projects yet). Our plan is to utilise this service to make a proof-of-concept browser extension and eventually a gadget to provide blame tool functionality.

Template wizard edit

 

TemplateWizard was a surprising project to see in the top 10 list. The feature is an easy to use wizard that helps users fill in templates and provides helpful information pulled from TemplateData. It is a feature that already exists in VisualEditor and the request was to add it to WikiEditor too.
We talked with the Editing team about the possibility of porting the existing tool to work with WikiEditor to keep the interface and user experience consistent but it was quickly ruled out as a possibility owing to complexities in extracting out the code from VE. So we built TemplateWizard from scratch. We designed a proof of concept user script initially to gather early stage feedback and then expanded on it to build a full-fledged MediaWiki extension. This was one of the first projects we had a designer for, who helped us come up with a product that looks and feels modern and has come to be liked a lot by users.

Deploy Article Alerts to other languages edit

The Community Tech team has reassessed the technical complexity of the remaining wishes from the 2017 Community Wishlist Survey and after doing that, the team has come to the conclusion that working on this wish is not feasible in combination with the other projects we have. In light of that, we will not be working on this project. There are a few reasons behind this decision. This project is very technically complex due to the differences in how different wikis run their workflows. We completed an investigation (task T184304) to evaluate the technical work that would be involved and we could not come up with a project direction that satisfied all the requirements. As workflows differ on every wiki, it is impossible to build something that will work seamlessly for all wikis and provide as much value to all projects as Article Alerts currently does to English Wikipedia. Thus, to build a tool that is useful to all wikis requires us to analyze every wiki’s workflows and make the tool work for all of them. This work is beyond our team’s current capacities, especially because we have multiple other projects to complete before we begin to work on the new wishlist wishes. Our workload this past year was more than we'd expected and it has forced us to re-evaluate whether doing ten projects every year from the wishlist is a reasonable idea.

Auto-save feature in Visual Editor and WikiText Editor edit

This wish was to prevent loss of edit data in case the tab/window crashes before the user is able to save their edit. This wish was completed by the Editing team. The feature is implemented for VE and 2017 Wikitext Editor. The edit data is stored in the user's browser so in case of a crash, if the same tab is opened back in the same browser, the edit data will be restored in the editor. If the user has multiple open edit tabs which crash, each of them can be restored by reopening the editor windows.

Allow 'thanks' notification for a log entry edit

This wish was to allow users to be able to thank other users for log actions. The feature was implemented as part of the Thanks extension. Users can now thank other users for several log types on Special:Log and subpages.

SVG Translate edit

 

This wish is to create a tool to allow users to add translations for SVG image labels. There was an existing tool to do this but it became non-functional a little while ago.
As we gathered user feedback on the project, we realized one of the important pieces was MediaWiki rendering of SVGs which was in English by default on all projects. We made that a priority and worked on fixing that behavior. SVGs now render in wiki language by default and if the translation does not exist, it falls back to English.
This project is in progress and we have a prototype ready for users to play with. The tool is being worked on and will potentially be available for use by February. The prototype links are available from the project page.

Commons deletion notification bot edit

 

Commons Deletion notification bot is a bot that posts a warning on talk pages of articles using images that have been nominated for deletion on Commons. The bot works under the Community Tech bot user account along side other bots run by the team. The bot is currently enabled on five wikis. Users may request to enable the bot on a new wiki by posting on the project talk page and seeking consensus on their wiki for the same.

Other projects edit

AfC Process Improvements 2018 edit

After the conclusion of ACTRIAL on English Wikipedia, Community Tech team helped implement its permanence. This was followed by a project to improve the Articles for Creation process on the wiki by building a set of enhanced prioritization tools to help with the increase of incoming drafts. These improvements were also made available to New Pages Feed patrollers. Community Tech team worked on this project for almost two months during its initial stages and worked on incorporating drafts in the New Pages Feed and adding sorting by state and date filtering.

Deprecation of RelatedSites extension edit

This project was assigned to the Community Tech team via the Code Stewardship Review process. The RelatedSites extension had been deployed for many years on the Wikivoyage wikis but it served a limited purpose of creating interwiki links which has been superseded by Wikidata. We worked on sunsetting the extension and removing its usages from all projects.

Global Preferences edit

Global Preferences was a lingering project from the 2016 Wishlist survey that was finally completed in July 2018. The project was a big one for this team and took many months longer than initially projected because of unforeseen issues in various phases of the project, most importantly deployment. It was finally succesfully deployed on all projects in 2018, with follow-up bugs filed and fixed.