Wikipedia:Wikipedia Signpost/2016-11-04/Discussion report
What's on your tech wishlist for the coming year?
- Danny Horn is the Senior Product Manager, Wikimedia Foundation.
The Wikimedia Foundation established the Community Tech team in 2015 as a product team devoted to building features and making changes that active Wikimedia contributors need the most. Rather than those of us on the team coming up with our own ideas and proposing them to the community, the team decided to let the community tell us what to work on. To do this, we invited the community to participate in a cross-project survey to set our agenda for the year. This consisted of two weeks for contributors to propose ideas, followed by two weeks of support voting. On November 7, we’ll be starting the process all over again, and we want you to participate in the 2016 Community Wishlist Survey.
The 2015 Wishlist Survey engaged more than 600 Wikimedians, and produced a ranked list of 107 ideas. Community Tech committed to investigating and addressing the top 10 wishes—designing and building new tools ourselves, or collaborating with other teams and volunteers who were working in those areas. For the two wishes where we could not offer help, we investigated the issues and explained why those wishes weren’t feasible for us to tackle.
Progress on the 2015 wishlist
Our first year is coming to a close, and here’s what happened with 2015's top 10:
We've completed our work on five wishes:
- Wish #1: Migrate dead external links to archives. Volunteer Cyberpower678 created a bot that replaces dead external links on English Wikipedia articles with links to the relevant pages at the Internet Archive. At the beginning of the year, Cyberpower’s bot only fixed links that were marked with a deadlink template. Community Tech contributed code that can examine all the external links on a page, and detect dead links that haven’t been caught by contributors. The new version is currently running on English Wikipedia, and Cyberpower is working on bringing the service to Wikipedias in other languages.
- Wish #2: Improved diff comparisons. When the length of a paragraph exceeds 10,000 bytes, the diff page wouldn’t show any changes made in that paragraph. WMF developer Max Semenik worked on raising the byte limit significantly, and deployed a fix in July that’s live on all wikis.
- Wish #5: Numerical sorting in categories. This project fixes a longstanding problem on category listings – that pages which begin with numbers were sorted by initial digit. A list should be ordered like this – 7 Dwarfs, 12 Monkeys, 101 Dalmatians – but the old category collation had it the other way around. In September, Community Tech deployed a new collation system, which lists the numbers in the correct order. This fix is live on 18 Wikipedia languages now. If your home wiki doesn’t have numerical sorting yet, you can request it, after an RFC discussion on your wiki.
- Wish #7: Pageview stats tool. The new Pageviews Analysis tool is live for all wikis now; we developed the tool with volunteer MusikAnimal, who later joined the Community Tech team.
- Wish #9: Improve the plagiarism detection bot. Volunteer Eran created a bot that compared new text added to English Wikipedia with a search database, to identify potential plagiarism cases. The reporting interface that he created was difficult to use, and there was a mounting backlog of unchecked cases. Community Tech built CopyPatrol, a new tool that makes it easier for patrollers to find and fix the problems flagged by Eranbot. There’s currently a group of around six patrollers using CopyPatrol, and they’ve eliminated the backlog; suspected plagiarism cases are now being handled within a day. Community Tech is currently working on expanding the tool to work on other Wikipedia languages.
We're currently working on one wish:
- Wish #4: Cross-wiki watchlist. Community Tech has created a technical plan for a global watchlist, and we’re currently making some necessary database changes. We’ll build a proof-of-concept prototype over the next few months, and our work on the new feature will continue into 2017.
Other WMF teams are currently working on two wishes:
- Wish #3: Central repository for gadgets, templates and Lua modules. Foundational work is underway by WMF developer Legoktm.
- Wish #6: Allow categories in Commons in all languages. This wish is being addressed by the Wikidata team’s work, building a structured data system on Commons.
We declined two wishes:
- Wish #8: Global cross-wiki talk page. In order to work effectively, this would require a structured discussion system, which would probably be built on top of the existing Flow feature. However, since the Wishlist Survey, the Collaboration team has released cross-wiki notifications, and Community Tech is currently working on a cross-wiki watchlist, so the need for a single cross-wiki talk page is not as urgent as it was at the time of the survey. See the project page for a more in-depth discussion.
- Wish #10: Add a user watchlist. This request for a watchlist based on other users’ edits was flagged by WMF’s Support and Safety team as a tool that could be used to facilitate hounding and harassment. People have offered several suggestions to reduce the likelihood that the user watchlist would be used in bad faith; those are discussed in detail on the project page.
There's more information about each of these, and the full list of 107 wishes, in our latest status report.
Call for participation: Building the 2016 wishlist
The 2016 Community Wishlist Survey will start November 7, and we’re changing parts of the process to reflect what we learned in the first one. This year, the focus of the initial two-week proposal period is for the community to collaboratively craft each proposal, to present the idea in a way that's most likely to succeed in the voting phase. When a proposal is submitted, everyone is invited to comment on that proposal, and help to make it better—asking questions, and suggesting changes. Duplicate proposals can be combined; very broad proposals should be split up into more specific ideas. The goal is to create the best possible proposal for the voting phase.
In the two-week voting phase that follows, contributors vote to support the proposals that they think are worthwhile, and the ideas are ranked by the number of support votes. This process gives us a way to measure the community’s enthusiasm for each idea.
The Community Tech team will work on the top ten wishes in 2017, as we did with last year’s survey, but we also want to make sure that we can help affiliates, admins, campaign leaders, and people who work on smaller projects. To accomplish this, we’ll also pick a number of proposals to work on that didn’t make it into the top 10, but are potentially of significant impact for smaller projects or user groups.
So we’re inviting all of you smart, passionate, and opinionated Wikimedians to come and help us figure out which problems need our attention the most. Join us to submit and discuss proposals (November 7–20), and then for the voting phase (November 28–December 12). We’ll see you there!
Other discussions
Pending changes to pending changes
The English Wikipedia has used pending changes protection since 2010, deferring non-autoconfirmed users' edits to administrators and those granted the pending changes reviewers right. One feature of the pending changes extension remains unused: the feature, referred to as PC2 (pending changes level 2), defers all edits by all editors except those able to review pending changes. In 2014, consensus was formally established for the use of pending changes. The community has left the criteria for the feature's use unaddressed, until the introduction of extended confirmed protection galvanized discussion on protection levels.
A new RfC proposes the use of PC2 as an alternative to extended confirmed protection, which bars editing from users with less than 500 edits and 30 days of editing history. The RfC seems to be gaining traction, potentially putting an end to the years of discussion on PC2.
Number swap
A long discussion has recently been closed on whether the articles from "1" to "100" (specifically the natural numbers from 1 to 100, or for math geeks) should be used for the numbers themselves rather than the year in the Gregorian calendar.
![{\displaystyle [1,100]\cap \mathbb {N} }](https://wikimedia.org/api/rest_v1/media/math/render/svg/f99184901e3bd9a2ddbddc7275b9931da313074a)
Consensus has emerged that the years should find new homes as the numbers themselves move in to take the place as the primary topic (for example, the natural number 1 will be covered in 1 instead of the year 1). The debate now lies on whether to use AD or CE to describe the calendar era with increasing years, and whether to place the qualifier before or after the year.
Discuss this story
More important to make sure that the features that already exist are in working order?