Community Wishlist Survey 2015/Status report 1

Check out the 2016 Community Wishlist Survey results!

Community Wishlist Survey status report #1, Jan 2016

This is the first status report on the Community Tech team's progress on addressing the top 10 wishes from our 2015 Community Wishlist Survey.

In November and December, we invited active contributors to Wikimedia projects to propose, discuss and vote on the features and fixes that they most want to see. 634 people participated in the survey, voting on 107 proposals -- you can see the full list at 2015 Community Wishlist Survey/Results.

The Community Tech team has committed to investigating and responding to the top 10 wishes. In many cases, our team will be designing and building tools ourselves, or collaborating with other teams and volunteers who are working in that area. For the wishes that we can't build this year -- because it's too big for our team, or there's a problem that we can't solve -- then we can at least offer open discussion on the problem, and detailed documentation explaining what we've learned, so the information can be used by other developers in the future.

This page is our first status report, based on our preliminary assessments of the top 10 wishes. We can't actually work on ten unrelated projects at the same time, so following this assessment, we're going to narrow our focus down to a few projects. The status on most of the wishes says "needs investigation"; the picture will become clearer as we work on these.

Wikimedia Deutschland's community tech team, TCB, created this Wishlist process a couple years ago, and they're working on their own top wishes. Some of the projects on their list overlap with ours, and we'll be collaborating with them throughout the year.

We'll post another status report like this one after in late April, after the Wikimedia Hackathon and the Wikimedia Conference 2016. Meanwhile, you can participate and follow the progress on the project pages and Phabricator tickets linked below.

Overview

First, here's a quick overview of the top 10.

1. Migrate dead external links to archives: Currently in progress, working with a community developer and the Internet Archive. This is one of the two projects we're actively working on now (mid-January).

2. Improved diff compare screen: Needs investigation and community discussion to define the problems that we want to solve.

3. Central repository for templates, gadgets and Lua modules: Needs underlying technical work that's currently under discussion by another team, see below for more.

4. Cross-wiki watchlist: Needs technical investigation on the existing Crosswatch tool, and the Collaboration team's cross-wiki notifications.

5. Numerical sorting in categories: Investigation is underway. There are a couple of potential solutions that we need to figure out.

6. Allow categories in Commons in all languages: Currently talking with Wikidata about using structured metadata to solve the underlying problem.

7. Pageview Stats tool: Currently talking with the Analytics team about their new pageview API. Needs some community discussion to define the front-end spec. This is one of the two projects we're actively working on now (mid-January), because the Analytics team is eager to use the new API that they've developed.

8. Global cross-wiki talk page: Needs community discussion to define the product.

9. Improve the plagiarism detection bot: Need to work with volunteer developers to define scope on improving the existing Plagiabot.

10. Add a user watchlist: We've heard significant pushback about the vandal-fighting use case, because of the risk of enabling harassment. Currently investigating an opt-in version that would be useful for mentors, classes, editathons and WikiProjects.

How you can help

We'll need your help to make sure that we're defining and addressing these projects in a way that meets the needs of Wikimedia's active contributors. Right now (in mid-January), the two projects that we're actively working on are Migrate dead external links to archives (project page, ticket) and the Pageview Stats tool (project page, ticket).

While those projects are underway, we're encouraging people to post ideas, ask questions and talk about the projects on the project pages and Phabricator tickets listed below. Some of those pages are pretty rough right now -- we'd be happy to have your help in making them better. :)

Want to be part of development?

If you've been thinking of getting into Wikimedia development as a volunteer developer, the Community Wishlist is a great way to start, as you'll be working on things you know have been asked for. The Community Wishlist Phabricator workboard has a number of tasks. We'd encourage you to look at numbers 11–20: they, too, were very popular, but are currently off the Community Tech team's radar.

Projects

Our preliminary assessment involved looking at four dimensions -- Support, Impact, Feasibility and Risk. Here's our analysis on how these look so far.

Migrate dead external links to archives

Project page -- Phabricator ticket -- Proposal

Support: High. Dead reference links hurt our projects' reliability and verifiability, and connecting deadlinks with an archive supports the usefulness of our content. There were some dissents in the voting phase, pointing out that it's better when humans find the appropriate alternative links, rather than a bot that might not choose the right one.

Impact: High. Improving the quality of citations helps readers as well as contributors. There are some bots currently running on English, French and Spanish Wikipedias. We want to help build solutions that can be adapted to every language.

Feasibility: High. Cyberbot II is currently active on English WP, and Elvisor on Spanish WP. Cyberpower678's work on Cyberbot is being supported by The Wikipedia Library and the Internet Archive. There is obviously good work being done here, and we can figure out how to best support it, and help it to scale globally.

Risk: Low. Cyberbot II is running on English Wikipedia, with no major issues encountered. It may be challenging to integrate with other wikis’ Citation templates.

Status: As of mid-January: we're working with Cyberpower678 and the Internet Archive to define end goals for the project. We're investigating a few different ways of approaching the problem, because the best solution may involve a few different tools or processes working in tandem. Right now, Cyberbot II is using the Dead link template on English WP to find dead links; we're looking into automated ways to test links. One solution may be to create a gadget that active contributors can use to test the links on a page they're editing, so that they can fix the dead links by hand. There will be ongoing discussion on the investigation ticket and the project page this month.

Improved diff compare screen

Project page -- Phabricator ticket -- Proposal

Support: Very high. There was unanimous support on the survey, although a couple of people wondered if this was too big for our team to handle. (They might be right, we'll see.) That being said -- the proposal itself was very vague, and there are a lot of different ways to define what needs to be improved.

Impact: Potentially high. This tool is commonly used by editors, and improvements could help many people’s workflows. However, the actual impact won't be clear until there's a concrete proposal.

Feasibility: TBD. We need to analyze what works in current diffs, and what the problems are that people would like us to solve. Some improvements may be easy while others would be major projects.

Risk: High. This wish is not well scoped yet, and there are no firm acceptance criteria. This will need considerable research/design research work, and the CT team does not have these capabilities. Changes to the diff page will also require significant community discussion to approve changes.

Status: We really want to work on this. It's a huge, important problem, and there's no other current WMF team that would take this on. We'll have to really dive into defining the problem, including lots of input from active contributors. Wikimedia Deutschland's TCB team also has "Show changes to the section text in a move" on their list. (link in German) We can work together. We'll focus on this in the spring.

Central global repository for templates, gadgets and Lua modules

Project page -- Phabricator ticket -- Proposal

Support: High. Strong support, but there are some important concerns expressed in the voting about the difficulty of using templates across wikis. Templates are already complicated, and this project could be offering a technical solution to a problem that needs social, consensus-based solutions.

Impact: High. Existing templates, gadgets and modules (across all wikis) will probably be affected.

Feasibility: Difficult. We're currently working (mid-January) on getting the Gadgets 2.0 Gadget Manager ready for review (see T31398). That doesn't include global gadgets, but it's a step in that direction. Creating a global repository will depend on using shadow namespaces -- there's currently an RfC about shadow namespaces on mediawiki.org. There are also notes and discussions from the Developer Summit in early January here: T115762.

Risk: High. Templates, gadgets, and modules are implemented differently and may need different solutions. Templates often transclude other templates. Adding translation support to templates will make them harder to maintain. We'll need to figure out how permissions will work, and how template and module editors can test on multiple wikis or provide a warning of changes. We need to also think about Gerrit-like code review needs for templates, gadgets and modules and possibly even a versioning system. It will be difficult to come up with a solution that will truly work across projects and will fit into the social structures of diverse communities.

Status: This work will probably depend on the shadow namespaces work, which is still being discussed, and probably won't be complete by the end of this year.

Cross-wiki watchlist

Project page -- Phabricator ticket -- Proposal

Support: Very high, with unanimous support votes.

Impact: Medium. This is very useful for contributors active on multiple projects, which is sizeable but not everybody. Crosswatch already exists as an interim solution on Tool Labs.

Feasibility: TBD, it depends on implementation. We could use Crosswatch as a guide. Crosswatch is written in Python; we could port it to PHP, but the details would be different.

Risk: Medium. The Collaboration team is currently working on cross-wiki notifications, which may or may not change the need for a watchlist, and which may have similar interface needs. It would be great if we could piggyback on their work once cross-wiki notifications are done, possibly by creating "invisible notifications" for watchlist items. This may require changes to core MediaWiki, which are always a challenge to get implemented.

Status: We'll investigate this later this year. This seems like a good project for us, but we'll need some more technical investigation to be sure. We'll want to include a filtering mechanism, so we need design work and a front-end spec. We'll talk more with the Collaboration team about notifications.

Numerical sorting in categories

Project page -- Phabricator ticket -- Proposal

Support: High. Near-unanimous support votes, with several people saying "Long overdue".

Impact: Medium. There's a clunky workaround, but it's a pain. The Wiktionary community may have an objection and opt out.

Feasibility: High. We may be able to solve this using the ICU library, which sorts numbers correctly. The current ICU conversion script is inefficient, and takes way too long on the biggest wikis. We’ll need to fix the conversion script if that's how we approach this.

Risk: Low. We need to make sure that we can efficiently regenerate all the sortkeys on large wikis like English Wikipedia. We also need to consider RTL and non-Latin numerals.

Status: We'll be looking into this soon; it seems like low-hanging fruit. We'll need to investigate the ICU library, potential drawbacks and i18n concerns. Wikimedia Deutschland's TCB team have a similar request on their wishlist: "Correct sorting of umlauts" (link in German). We'll work together with them on this.

Allow categories in Commons in all languages

Project page -- Phabricator ticket -- Proposal

Support: Very high. Unanimous support votes for the concept; comments were about different ways to implement the idea.

Impact: High with structured data, Medium to Low for a straight translation. Searching and sorting images on Commons is already difficult and confusing in English. If we really want to make Commons work well across languages, then we may need to do more than take the confusing English categories and make them confusing multi-lingual categories. Incorporating structured data would be a more scaleable long-term solution.

Feasibility: Difficult. There are hundreds of thousands of categories, maybe more than a million. Starting with A in Special:Categories, the #20,000th category on the list is Abraham. There are also a lot of overlapping categories, ex: Camels, Camelus, Camelus dromedarius, Camel anatomy, Camels eating, Drinking camels, Camel markets, Camel milk, Camels in art, etc. Is it possible for humans to realistically make a dent in translating all these categories in every language? If the solution is creating duplicate categories in each language, it's daunting to think about how to manage up to 200x the current number of categories. That being said, using structured data concepts is also difficult.

Risk: High. This needs scoping and consensus on how this could work, with the Commons community as well as Wikidata.

Status: This is an important problem, and we want to help figure out the best solution. Right now, the most promising line of thought seems to be the "concept tagging" that Wikidata could provide through a structured data platform. The idea is: tag images using concepts that exist in Wikidata, and then cross-reference concepts to find the images you're looking for. Made-up example: instead of having separate categories for Camels, Camel milk and Camel markets, you might be able to mark the images with the concepts "Camels", "Milk" and "Markets". Then you can search for images that have both Camels and Markets, and then drill down into concepts like specific locations. If the concepts are pulled from Wikidata, then they're already translated or translateable. We don't know for sure if that's going to be the ideal solution for this project, but we want to learn more when Wikidata has a working prototype. We'll have more to say as we learn more.

Pageview Stats tool

Project page -- Phabricator ticket -- Proposal

Support: Very high, unanimous support votes.

Impact: Medium. It's not something that would be used by every contributor, but there are cases where knowing the pageviews would be very helpful -- it can help programs demonstrate impact, give information to researchers, and help WikiProjects to organize efforts around high-traffic pages. There's an existing tool, Stats.grok.se -- it was broken at the time this was proposed, but it appears to be working again. Still, there are features that we can build that could offer more value.

Feasibility: High. This is well-scoped and relatively easy, compared to other projects in the top 10. WMF's Analytics team has a new pageview API that they're eager to use, and they have -- a prototype tool already set up. This needs some discussion to gather extra requirements; people may want to see filters or other features.

Risk: Low. We just need to make sure it’s reliable and scalable, so it doesn’t flood the API.

Status: This is one of the two wishlist items that we're actively working on at press time (mid-January). We're currently doing a technical review, and talking with the Analytics team. We'll be talking soon with various stakeholders -- including you, if you put the project page on your watchlist -- about what features we'd like to include in the stats tool.

Global cross-wiki user talk page

Project page -- Phabricator ticket -- Proposal

Support: Medium. This is probably the most conflicted proposal in the top 10. It got a lot of support votes, because conceptually it's a really good idea -- just one place to check for messages and hold discussions, rather than multiple talk pages on different wikis. Oppose votes brought up different concerns: Would this fundamentally change the structure of a talk page? Where does the edit history live, and how would you monitor for abuse? Would you have to add a prefix for links? Isn't this too big for the Community Tech team? And the most important question: With the Collaboration team currently working on Cross-wiki notifications, do we really need this?

Impact: Unclear. When the Collaboration team rolls out cross-wiki notifications, we'll see how well that addresses the needs expressed in this proposal.

Feasibility: Difficult. Technically, this might depend on the shadow namespaces work mentioned above in the Central global repository section. Also, this project will probably involve substantial changes to the way that wiki talk pages currently work -- for example, if we want to track where each discussion started, then each discussion will need to be its own separate object, so that the global page can piece together the most recent discussions from each wiki. Keeping each discussion as a separate object would limit the open-page freedom of current talk pages. There are a lot of different trade-offs to discuss.

Risk: High. This will need substantial work to scope, research and design the product. Also, there are already three different discussion systems on Wikimedia -- wikitext, LiquidThreads and Flow -- and we'd need a really good reason to start building system #4. See also the concerns mentioned above about the edit history, link prefixes and so on.

Status: We'll need to have some discussions about what people are looking for, and thinking through how that would work. This had a lot of support votes, and it's worth digging into what people really want from this product. This is such a complicated project that it's likely we won't complete it by the end of the year, but the discussions and documentation would be a helpful step forward.

Improve the plagiarism detection bot

Project page -- Phabricator ticket -- Proposal

Support: Very high. Lots of support on the proposal, with several people specifically calling out for a tool that can be used on multiple projects and multiple languages.

Impact: Medium to High, depending on what we're able to do. Integrating the human-checked false positive/true positive data into EranBot's existing database and improving the API could be particularly useful for research and machine learning projects, potentially improving the bot’s true positive rate and requiring less human involvement. The ability to adapt this for multiple projects and languages would be especially helpful.

Feasibility: There's an existing tool on English Wikipedia - EranBot, aka Plagiabot, based on the Turnitin database - and Community Tech has done some work to make the results more broadly useful in the last couple months, including displaying the tool's results alongside Copyvios Detector's reports. (There's more details on ticket T110144.) Turning EranBot into an extension would be considerably more difficult than making improvements to the bot.

Risk: Medium, higher for more involved work. We'll need considerable discussion on the scope and definition.

Status: We're confident that we can do some helpful work on this wish this year. We need more investigation and discussion to figure out a clear scope of work. We'll be able to focus on it more in a few months.

Add a user watchlist

Project page -- Phabricator ticket -- Proposal

Support: Medium. This proposal got a lot of support votes, but also some passionate dissents from people concerned about this tool being used for harassment or bullying. We've also heard this concern from other sources since the survey ended, including volunteer developers at the recent Wikimedia Developer Summit. The proposal suggested several different use cases, and it's useful to break those down. For the sake of discussion, we can call them the Vandal-tracking use case and the Mentorship use case. The Vandal-tracking watchlist would help people to keep an eye on potentially problematic editors. This could be used to track potential vandals, people with a history of breaking important rules, and other dubious types. The Mentorship watchlist would help mentors, trainers, editathons and WikiProjects, where a group of people agree to keep an eye on each other's work -- either at a single event, or over a longer period of time.

Impact: Vandal-tracking: Low-ish. You could bookmark Contributions pages of contributors that you're concerned about; this watchlist would just make it more convenient. It's the same whether you're using this tool for good (tracking potential vandals) or evil (harassing contributors that you don't like). Mentorship: This would be very helpful for large group classes, editathons and programs that support groups of contributors. Those situations are relatively rare compared to the entire user base, but for those people, it would be great.

Feasibility: High. This is straightforward, compared to other wishes in the top 10. For the Mentorship use case, the difficult thing is figuring out how people opt-in to join or leave the group.

Risk: For Vandal-tracking: High. This could turn into a tool that encourages harassment on wiki. It would be nearly impossible to track abuse of this tool. The proposal suggested limiting the tool to admins, but many people have pointed out that admins are not necessarily perfect actors. For Mentorship: Low risk.

Status: As you can tell from the analysis above, the team is feeling positive about the Mentorship use case and concerned about the Vandal-tracking. Our current plan is to think about an opt-in system, where contributors would agree to join the group of people being followed on the watchlist. There are some user interface design questions that we need to explore -- how people would be invited to join, how they'd leave, whether they're joining one collective watchlist or they're each agreeing to be followed by a single mentor. We'll need to talk with people who would use this feature, to learn more about what they'd want. For the Vandal-tracking use case: we agree that this would be helpful for good-faith tracking, but we can't ignore the risk of facilitating bad-faith harassment. That being said -- if people have ideas for how the Vandal-fighting could be addressed without increasing the risk of stalkers, we're very interested in hearing about it. We'll be talking more about this later this year.