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.
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:
We're currently working on one wish:
Other WMF teams are currently working on two wishes:
We declined two wishes:
There's more information about each of these, and the full list of 107 wishes, in our latest status report.
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!
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.
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.
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 CE or AD 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?