Community Wishlist Survey 2016/Process notes

This page is for the Community Tech team to keep notes on process ideas for the 2016 Community Wishlist Survey. Everything on this page should be considered an early draft. There are lots of discussions ahead with lots of stakeholders, including any active contributors who feel like talking about the survey. If you have questions or suggestions, please post them on the talk page.

July 21, 2016

At several Wikimedia events this year, community members have asked how Community Tech could help smaller groups of users. There are groups and projects that could get a huge benefit from a relatively small amount of technical assistance, but they don't have enough members to compete for raw support votes with the big Wikipedias, or Commons. Examples: Program leaders, GLAM, Wikisource, admins and stewards, volunteer developers.

The core of Community Tech's work is and will be the top 10 wishes in the international Community Wishlist Survey, but with additional resources, we can broaden the team's scope to include helping smaller projects and user groups. For the new fiscal year starting in July, the Reading team is making additional investments in Community Tech -- adding Bryan to the team to work on Tool Labs support, and another developer for off-Wishlist projects. For the rest of the calendar year 2016, that investment will allow us to work on the Programs & Events Dashboard, and the #25 wish on the 2015 survey, Google OCR for Indic language Wikisources.

The next wishlist survey: Track 1 & 2

Starting with the next survey, we need to get community input on both sides of this broader focus -- the core top 10 wishlist for the international community, and the additional projects that support smaller groups.

For next year, we'll allot 75% of our work to the top 10 wishlist (Track 1) and 25% to the smaller groups (Track 2).

We'll do another Community Wishlist Survey in November/December 2016, run more or less the same way.

Proposal period: We invite people to submit proposals for wishes. We split up the proposals into categories as we go along. There's discussion during the proposal period, and we ask people to endorse proposals in order to move them to the voting stage.

Voting period: Two weeks for votes and comments. We only count support votes in the final tally, but opposes and neutrals are welcome, in order to spark discussion on the merits and drawbacks of the proposal.

From the point of view of the people proposing, endorsing, discussing and voting, there's no real difference between Track 1 and Track 2. In last year's survey, we had some categories that could have been Track 2 -- Moderation and admin tools, Wikisource, Wikidata, Wikiversity. For this year's survey, we can do it the same way -- split off categories for GLAM, Volunteer developers, etc. Anybody will be able to propose, discuss and vote for any category.

Two lists of projects

The only difference is the way that we construct the backlog. The Community Wishlist top 10 is based on the Track 1 categories -- Bots and gadgets, Editing, Categories, Watchlists, etc. 75% of our work will be based on that list.

Then there's a separate Track 2 wishlist, based on the Track 2 categories -- Program leaders, GLAM, Wikisource, Admins and stewards, Volunteer developers. This is basically the "middleweight" championship. Those categories are still competing with each other for support votes, and the people who want those proposals to score high on the Track 2 wishlist will have to encourage people from their projects/areas to come support their proposals. 25% of our work will be based on the Track 2 wishlist.

Even if a group doesn't get enough votes to boost their proposals to the top of the list, the proposals and discussions are still valuable. This year, wishes below the top 10 were picked up by a lot of different people -- WMDE's Technical Wishes team, volunteer developers at hackathons, and developers from other WMF teams. Proposals that are well-argued and clearly defined will still get attention, even if they don't have enough votes to reach the top.

August 9

Important to remember: We need to avoid big catch-all "improve this" tickets. See 2015's #2 (improved diff compare screen), #17 (improve SVG rendering), #29 (improve MediaWiki's blocking tools) and #41 (improve Special:Log). The word "improve" is not necessarily forbidden -- "improve the plagiarism detection bot" turned out fine. But that should be a red flag which indicates that the proposal may be too broad.

The problem is that it's hard to know when an "improve this" wish is done. Is fixing one thing enough? What if you do four out of five? And, worse -- what if the fifth one was the most important, but you didn't do it because you spent too much time on the other four?

Examples:

Improve SVG rendering says "Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia." It should list the eight to ten bugs. An upgrade to the library fixed a few, but then people didn't know what else to fix.
Improve MediaWiki's blocking tools lists ten different ideas. They could easily be split into three smaller groups. This is a "know it when you see it" thing -- a general "only put three tickets per proposal" guideline might help, but that guideline should be used when splitting them up actually makes the proposal easier to understand and act on. Remember that volunteers and GSoC students use these. Splitting things up helps volunteer developers to take on a task they can handle.

We should include a couple sentences about this in the instructions. After the proposal stage, we should look for things like this and split them up before voting starts.

Aug 18

For promotion: Signpost

Aug 26

Talked to Juliet and Ed in Comms. We'll start doing blog posts about wishes to build up the story of the team. These should include screenshots, and quotes from people who asked for it / use it.

Ways to reach people:

Do a blog post for the first day of proposals.
They've got a Communication Committee of people doing communications for affiliates.
Wikimedia Foundation Social media hub on Facebook

Sept 26

Leon's suggestion: Use WatchlistNotice. (He knows how for English WP, see if we can use a global translated version?)

Oct 28

Original set of categories (these may change over the first few days of the survey as we see interest):

2015 survey:

Bots and gadgets (4 proposals)
Categories (7 proposals)
Commons (6 proposals)
Editing (15 proposals)
Miscellaneous (17 proposals)
Moderation and admin tools (13 proposals)
Multimedia (5 proposals)
Notifications (4 proposals)
Reading (4 proposals)
Search (5 proposals)
Special pages (2 proposals)
Talk pages (3 proposals)
Templates (3 proposals)
Watchlists (7 proposals)
Wikidata (7 proposals)
Wikisource (6 proposals)
Wikiversity (1 proposal)

2016:

Admins and stewards
Bots and gadgets (or Bots and tools?)
Chapters and affiliates
Commons
Editing
Miscellaneous
Moderation tools
Multimedia
Programs and events
Reading
Search
Watchlists
Wikidata
WikiProjects
Wikisource

Oct 31

Working on a CentralNotice request...

Text: 2016 Community Wishlist Survey: Submit your ideas for new and improved wiki tools!