Talk:Community Wishlist Survey 2015

From Meta, a Wikimedia project coordination wiki

Starting date[edit]

I see people are proposing early. Will the existing proposals be treated as if they were made on November 9, and if so, why not change the start date to "now"?

I recommend either changing the start date to "now" or protecting the page (and grandfathering in the proposals that are already there). Davidwr/talk 20:10, 7 November 2015 (UTC)[reply]

The survey got a full article in the Signpost, so the cat's out of the bag. MER-C (talk) 14:14, 8 November 2015 (UTC)[reply]
Yeah, it's okay if people added a couple before the official start; it's nice to have good examples as more people find out about the survey. :) DannyH (WMF) (talk) 18:20, 9 November 2015 (UTC)[reply]

Community Tech/Project ideas[edit]

Can we just merge that page into this and add endorse/support templates as needed to aid tallying? Nemo 17:29, 8 November 2015 (UTC)[reply]

People can absolutely feel free to copy ideas from that list that they care about. I'd rather not just copy and paste the page. People haven't signed posts there, some of them are linked to Phabricator tickets -- we'd like to have this survey be its own thing. DannyH (WMF) (talk) 18:24, 9 November 2015 (UTC)[reply]
I would prefer that people copy over individual items from that page that they strongly support. Not all of the ideas on that page are feasible for our team or well-scoped. Ryan Kaldari (WMF) (talk) 19:32, 9 November 2015 (UTC)[reply]
Do you expect that people will suddenly know more about what is "feasible for our team or well-scoped"? There is no difference between the two pages. Nemo 09:15, 10 November 2015 (UTC)[reply]
My point is that some of the ideas on the Project ideas page have already been largely rejected in the discussions there, so it wouldn't be appropriate to move them here. Anyone is free, however, to move their favorite ideas over from that page. Ryan Kaldari (WMF) (talk) 18:02, 10 November 2015 (UTC)[reply]
That isn't true, we aren't free to move our favorite ideas over from that page, because of weird and arbitrary restrictions made up by someone. And I don't see why it would be inappropriate to move an idea here, even if it has already been largely rejected in the discussions over at Community Tech/Project ideas. I also don't see the problem with the fact that some of the posts there are unsigned and/or linked to Phabricator tickets. Creating this as a separate page without informing the people who posted ideas at Community Tech/Project ideas feels bad. The Quixotic Potato (talk) 02:15, 11 November 2015 (UTC)[reply]
Then, per above, please move to this page all the sections that you feel bad about. We should then redirect or otherwise blank/archive that page, which is currently a trashbin. Nemo 07:15, 11 November 2015 (UTC)[reply]
Ok, thank you. I have also removed this because it was a duplicate. The Quixotic Potato (talk) 12:25, 11 November 2015 (UTC)[reply]
I moved the imported sections to the bottom of the page. I understand why you want to keep those ideas and discussions. At the same time, we're trying to reach out to a lot of people who haven't participated in these kinds of discussions before, and I think it will be confusing for people to see a lot of ideas with May to September dates at the top of a survey that officially started in November.
I think that moving them down to the bottom of the current page is a decent compromise. It won't be the bottom of the page for long, as people add more ideas. This section will just be in the middle. Is that okay with you? DannyH (WMF) (talk) 20:31, 11 November 2015 (UTC)[reply]
No, moving them to the bottom is a terrible idea. And sticking them somewhere near the middle means that they rarely get seen. The form should add new ideas to the top. All ideas that have been endorsed should be moved to the bottom. And the form should have prefill text that makes it easier for people to endorse/support an idea. No one bothers to read the timestamp. I do not even read the names of the participants of a discussion. I am not claiming that this is fair, but the alternative is obviously less fair. Voting is always unfair. Argumentum ad populum is a fallacy. The Quixotic Potato (talk) 15:10, 12 November 2015 (UTC)[reply]
The proposals are now sorted into different categories, rather than just being listed from first to last. /Johan (WMF) (talk) 07:36, 13 November 2015 (UTC)[reply]

Out of scope[edit]

This is a bright idea to survey community wishlists. All Wikimedia engineering teams should be in contact with regular users. I understand the scope of this project is narrow. Is there any similar survey to cover broader scope (for example complete rewrite of an extension)? 4nn1l2 (talk) 11:02, 10 November 2015 (UTC)[reply]

Not at the moment, as far as I'm aware. It might be good to know there's an ongoing discussion about the WMF development process and how it should include the Wikimedia communities. This could certainly be a relevant question there. /Johan (WMF) (talk) 13:24, 10 November 2015 (UTC)[reply]
I agree with 4nn1l2 that you first need a vision on where Wikimedia is going or not going before you can decide on what functionality you are going to build. For instance: a few months ago I discovered part-up (http://www.part-up.com). This open source platform enables me to start learning projects with other people. Is this something we also want to create in the wikimedia software? Or can we copy the functionality of part-up and create something that can be used for learning projects on the Wikiversities? Timboliu (talk) 10:41, 12 November 2015 (UTC)[reply]
This is very true in the general sense, and should be part of the larger discussion of what we're doing and where we're heading. I still think the discussion about the WMF development process is the best place to talk about how the WMF is to better understand the community in that sense. This, and the general work of the Community Tech team, is in a sense more of an attempt to make the processes we already have work better, especially for core contributors. Not because it's necessarily more important, but because we need somewhere to talk about that, too. /Johan (WMF) (talk) 11:23, 12 November 2015 (UTC)[reply]

Problems with this page[edit]

General problems

Some people seem to like making up weird and arbitrary rules, and try to force others to follow those rules. Some people seem to believe that voting is fair and useful.

Problems with this page specifically

  • This will piss people off who have posted on Community Tech/Project ideas. I did, and it pissed me off.
  • Arbitrary limit on the number of ideas per person. Some people are unable to come up with one good idea. Other people have 10 good ideas. Limiting the number of ideas arbitrarily is not productive. There is literally no advantage to this. It is incredibly unlikely that this rule reduces the total amount of ideas significantly or increases the quality of the average idea.
  • The rule that others should endorse an idea in order for it to be eligible for the voting phase is not productive. What if you have a good idea that is easy to implement, but it is added to the bottom of the list 10 minutes before the voting phase starts? No one will endorse it, and no one can vote for it... A good idea is a good idea, the amount of voters/endorsers/friends of the proposer should be irrelevant.
  • Voting isn't fair, and it is rarely useful. Ideas that are added near the bottom of the list will receive almost no attention, or at least significantly less attention that the ones near the top. This doesn't mean that they are bad ideas, it just means that the list is so long that many people don't read the entire thing. Look at the Articles for Deletion discussions on the English Wikipedia. Why don't they just count votes? If voting would be a good and fair system then it would be used there.
  • The team shouldn't "get to work on top wishes", that is not necessarily the optimal strategy. Maybe the top wishes are things that are incredibly difficult to achieve and take lots of time. In that case it is better to focus on problems that can be solved quickly and easily, even though a smaller percentage of the community need them.

The Quixotic Potato (talk) 02:10, 11 November 2015 (UTC)[reply]

@The Quixotic Potato: Thanks for bringing up these points. Regarding Community Tech/Project ideas, I regret if anyone from that page feels left out of the process. I should explain that I created that page myself (with my volunteer account, not my staff account) a few months before joining the Community Tech team. Over a third of the ideas there were posted by me (all the unsigned ones). Thus merging that page into this one would have been a conflict of interests, as the survey would have immediately been dominated by my own ideas. Also, that page was never intended to be a formal survey and I never publicized it anywhere. It was just a page I created to keep track of ideas that I wanted to suggest to the Community Tech team. I didn't realize at the time that I would later be joining the team myself. I also didn't realize that so many other people would find that page and contribute to it. If you feel strongly about moving any of the ideas from that page into this one, please go ahead and do so, but please do not move them all en masse. We are not going to be rigidly enforcing the 3 proposal rule. It is mostly just to prevent people from dumping large numbers of low quality suggestions.
Regarding voting, I agree that it isn't ideal, but it is the only practical and scalable way that we could come up with to get input from hundreds of users on (potentially) hundreds of proposals. We are taking two measures to mitigate the problems you mention:
  1. We separated the voting phase from the proposal and discussion phase. Hopefully, this will allow people to consider other users' criticism and comments on proposals before voting. It also reduces the bias of the first proposals (chronologically) getting the most votes.
  2. We will be organizing the proposals into topic sections, and perhaps even subpages. This should reduce the bias caused by people having to scroll through one endless list of random proposals and losing interest halfway through the list.
If you have other ideas for how we can improve this survey or get more participation, please let us know. We will probably try to conduct a similar survey once every year or two, so any feedback is valuable, even if it isn't incorporated into this particular survey. Ryan Kaldari (WMF) (talk) 18:01, 11 November 2015 (UTC)[reply]
@The Quixotic Potato: Re Please please please try to have as few surveys as possible - wotcha got against surveys? - Thanks; LeoRomero (talk) 19:50, 12 November 2015 (UTC)[reply]
Also, regarding your final point, we will be conducting our own internal assessment of the top wishes once the voting is complete (See Community Tech/Community Wishlist Survey description#Analysis and prioritization). Tasks that are smaller and easier to complete will be assigned a higher priority than tasks that are incredibly difficult. If a task really isn't feasible for our team, we may refer it to another team or even decline it altogether. Obviously, we don't want to waste years on a single task when we could be making lots of smaller improvements instead. It's a tough balancing act between being accountable to the wishes of the community and being an effective development team. Ryan Kaldari (WMF) (talk) 18:20, 11 November 2015 (UTC)[reply]
A couple of clarifications: the plan is for the voting phase to begin one week after the proposal phase has ended, to avoid that situation.
Regarding voting, I'd like to add another point. It's a contentious matter within the Wikimedia sphere. There are good reasons for this, good arguments against voting. There are also reasons for doing it this way, not least in an international setting. This process is far more monolingual than we would have preferred it to be. I’d have loved to have a discussion open to anyone, comments being translated back and forth, something posted in English immediately available in Russian and Mandarin, something posted in Arabic soon available in Greek and English. The truth is that the invitation is translated into less than twenty languages, and it wasn't easy for us to get even to that point. There are drawbacks to this more structured approach, but one of the benefits – in addition to the ones Kaldari has mentioned above – is that it gives us a chance to at least try to make the process available to non-English speakers. It’s also more inviting if you have a passive understanding of English but can’t express yourself. You can understand a proposal, and you can vote, because that’s a process that’s easy to copy, but actively taking part in the discussion, that’s another thing entirely. /Johan (WMF) (talk) 22:25, 11 November 2015 (UTC)[reply]

┌─────────────────────────────────┘
 @Ryan Kaldari (WMF): @Johan (WMF): Ryan, you've obviously spent a lot of time thinking about this kinda stuff, and if that has resulted in more than 3 good ideas then I think we should use them all. I understand the intention was good, but good intentions can lead to terrible results (I've seen many examples). Imposing the 3=max rule on yourself would've probably been better, but I am pretty sure (I haven't checked) that the page currently contains more than three ideas that were written by you. When judging which ideas are the best we should ignore the person behind the idea. I care about conflicts of interests when and if they negatively affect the encyclopaedia.

Feature requests are like bugreports... imagine not being able to file a bugreport just because you've already reported three of them! I think we should welcome all suggestions, and ignore the ones that don't meet the quality standards. I don't think that it is likely that people will dump low quality suggestions en masse. Or, to put it differently, I think that they will do that anyway if you restrict them to 3 ideas per person. I don't think you can make a rule that significantly improves the quality of the ideas.

In my experience making rules in advance leads to many problems; it is better to grow them organically by making rules against behaviour that causes problems. This is how Wikipedia works, and how the law works IRL. For example, sending spam emails used to be perfectly legal, until it became a problem and now it is illegal (almost) everywhere. This ensures that we have as much freedom as possible.

I understand that this is the only practical and scalable way you could come up with, it is the solution most people would chose for this problem, but there is a much better way:

  • First you collect all the suggestions. Accept the fact that the quality of them will differ, this is unavoidable.
  • One or more people from the WMF have to sort them. Some should be sent to a different team. Some of them are bad ideas. Some are technically impossible/infeasible/impractical.
  • If you want people to vote, let them vote which ones of the remaining feature requests should be prioritized. You can vote in a discussion (see the last two sentences of this comment).

This way the voters don't have to waste their time voting on and responding to bad/impossible/infeasible/impractical ideas.

The people who vote are, generally, not developers. I like computers and I've installed MediaWiki on one of my webservers, but I am not a WMF developer. Ideally developers who work for the WMF should be the ones who decide when to fix which problems, because they have access to the information that is required to make a good decision.

Please please please try to have as few surveys as possible.

Johan, please change the plan so that the WMF sorts the proposals before the voting phase (see above).

To vote on proposals written in English and for participating in a discussion in English you both need good command of the English language. In order to vote you need to be able to read the proposals, most of which are in English. Luckily we have many people who are willing to help with translating. An example can be seen here: 2015_Community_Wishlist_Survey#Use_of_pictures_in_wikipedia.

I completely agree that monolingualism is a giant problem. But English is the lingua franca of the internet; we cannot change that.

Discussions are superior to voting because you get not just a sense of how many people agree with which statement, but also why, and what the arguments before and against are.

I understand your point about people with a more passive understanding of English. I would simply ask them to use the words "I agree" (e.g. "I agree with Ryan Kaldari") instead of {{Endorsement}}.

That way, people with a more passive understanding will still be able to vote. The Quixotic Potato (talk) 08:35, 12 November 2015 (UTC)[reply]

The plan is definitely to sort the proposals, and for the Community Tech team to review them in the week before the (well, official) voting phase begins. I hope one week's enough for that. We've got a fair number of proposals so far. :) /Johan (WMF) (talk) 08:54, 12 November 2015 (UTC)[reply]
@Johan (WMF):
Are you going to sort and review them all in one week? Sounds quite optimistic. :-)
The announcement on en:WP:VPT says: "For phase 1 of the survey, we're inviting all active contributors to submit brief proposals, explaining the project that you'd like us to work on, and why it's important. Phase 1 will last for 2 weeks. In phase 2, we'll ask you to vote on the proposals. Afterwards, we'll analyze the top 10 proposals and create a prioritized wishlist."
I interpret that as:
  • collect suggestions
  • vote on suggestions
  • WMF analyses the top 10
I propose a different method:
  • collect suggestions
  • WMF sorts suggestions and creates a new page with the good ones
  • voting starts on that new page
On 2015_Community_Wishlist_Survey the order is the same as I propose:
  • Phase 1: Submit proposals: Nov 9-22
  • Community Tech team reviews and organizes proposals, Nov 23-29
  • Phase 2: Vote on proposals: Nov 30-Dec 14
Is the WMF going to sort the proposals before the voting phase? And are you planning to create a new page for the voting so that voters don't have to waste their time voting on and responding to bad/impossible/infeasible/impractical ideas? And do you agree that, instead of conventional voting, it is better to have a discussion where people with a more passive understanding of English will be invited to vote by writing something like "I agree"? The Quixotic Potato (talk) 09:03, 12 November 2015 (UTC)[reply]
The plan is to review and sort the proposals in a week before the voting phase begins, yes. Whether that plan survives contact with reality remains to be seen. :) As for the exact nature of the voting process, we're getting some feedback (not least here) and we'll (as in "the Community Tech team and the community", not "the team internally", just to be clear) need to have a conversation about that before the voting phase is to begin about how to do it, but I think that conversation would benefit from us having had the chance to see a bit more of how the first phase works out. /Johan (WMF) (talk) 11:14, 12 November 2015 (UTC)[reply]
I've been bold and I have removed the 3=max restriction because that rule has been broken multiple times already and no one wants to enforce it as far as I can tell. The Quixotic Potato (talk) 09:03, 12 November 2015 (UTC)[reply]
We still very much would like to encourage users to put forward only the best ideas, and not anything they can think of. I've rephrased it slightly to reflect both this and the fact that we're not rigidly enforcing the rule. /Johan (WMF) (talk) 11:14, 12 November 2015 (UTC)[reply]
Thank you, "Participants are encouraged to limit themselves to posting up to 3 proposals each." sounds a lot better, and it is more accurate! The Quixotic Potato (talk) 11:20, 14 November 2015 (UTC)[reply]
I would like to delete the following line: Proposals must be endorsed by at least one other user in order to be eligible for the voting phase, using the Endorsed Endorsed template.. I have explained my reasoning above. Is there anyone who disagrees? If so, why? The Quixotic Potato (talk) 09:18, 12 November 2015 (UTC)[reply]
That would be a significant change to the process, and I would like to have more input from other community members before making such a change. We would also need to change the wording to say something about how the Community Tech team would be choosing which proposals to promote to the voting phase, instead of it being decided by endorsement. Perhaps we should have a small RfC here to discuss it further. Ryan Kaldari (WMF) (talk) 17:28, 12 November 2015 (UTC)[reply]
What's the benefit? There is hardly any proposal without endorsement. I'd rather increase the endorsement threshold, otherwise voting will be impossible. Nemo 18:15, 12 November 2015 (UTC)[reply]
The benefit is just to weed out proposals that are probably bad ideas (like "Flag SPA and new user accounts") or that no one understands (like "Automatic bot"). You're right that it looks like most proposals are going to be endorsed, and we may consider having a higher endorsement threshold in the future, but I wouldn't want to raise the endorsement threshold after the fact. Also, this would increase the chances that good proposals added at the last minute wouldn't make it to the voting phase. Ryan Kaldari (WMF) (talk) 20:07, 12 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Weeding out bad proposals by requiring 1 endorsement obviously didn't work. Currently there are bad ideas that have been endorsed (e.g. Thanks for anonymous editors) and good ideas that haven't been endorsed. You speak about raising the endorsement threshold which proves that you do not understand what the problem is. Asking people to endorse a proposal before the voting phase is a bad idea. It is very similar to voting, and voting itself is also bad. This endorsement stuff is basically nonsensical bureaucracy. I have explained the solution already; instead of requiring endorsements the WMF should create a new page where we can vote on (or talk about) proposals that aren't bad/impossible/infeasible/impractical. The Quixotic Potato (talk) 11:35, 14 November 2015 (UTC)[reply]
The fact that it is a significant change to the process is a good thing. Basically, the process is bad, so it requires major changes. I do not understand why you would require an RfC to change what some guy made up some day. Using an endorsement threshold was (obviously) a bad idea, and rather pointless, so removing that rule improves the process. The Quixotic Potato (talk) 11:24, 14 November 2015 (UTC)[reply]
Endorsement seems to be working fine right now. Of the 100 currently open proposals, 72 have endorsements and 28 don't. That seems like a healthy percentage to me. I see an active, productive page, with lots of people posting ideas and opinions. Whether you agree with other people's endorsements or not isn't an indictment of the process. -- DannyH (WMF) (talk) 00:47, 15 November 2015 (UTC)[reply]
@DannyH (WMF): Ehm, no, it is clear that requiring endorsements was a bad idea. The problem isn't that I disagree with other people's endorsements (but thanks for the ad hominem), the problem is that the "endorsement"-phase doesn't help in weeding out bad/technically impossible/infeasible/impractical proposals. The Quixotic Potato (talk) 02:33, 15 November 2015 (UTC)[reply]
...because that's not the goal of endorsements. Endorsements should only be used to exclude the proposals which will not interest a wide audience (i.e. get many votes) in the later phase. Filtering impossible requests and so on is another thing. Nemo 08:24, 15 November 2015 (UTC)[reply]
Then the threshold isn't high enough... But excluding proposals that will not interest a wide audience is a very bad idea. For example 2015_Community_Wishlist_Survey#Mailman_emails_passwords_in_cleartext. There aren't many people here who are interested in that kinda stuff, but it is very important. The Quixotic Potato (talk) 09:05, 15 November 2015 (UTC)[reply]
But that's an excellent example of what we – as the Community Tech team, not the entire WMF – are not trying to do with this survey, for several reasons. There's already a team (Technical Operations) that handles that. We (Community Tech) don't have their competence. As you say, security issues shouldn't be put to a popular vote to see if they're important enough to prioritize, but that doesn't necessarily mean that this process (which will guide but a small portion of the Wikimedia technical development) is pointless – it could mean it's the wrong process for this particular issue.
The plan is to address this in an upgrade to Mailman 3.1. See phab:T52864. /Johan (WMF) (talk) 11:07, 16 November 2015 (UTC)[reply]
I didn't claim that this was an example of a proposal that should be fixed by the community tech team, I used it as an example that demonstrates that excluding proposals that will not interest a wide audience is a very bad idea. And this survey isn´t exclusively for the Community Tech team, according to DannyH. Or you know, sometimes it is, and sometimes it isn´t.
there are a number of ways that we're going to use this backlog. Primarily, it's for the Community Tech team, but there will also be volunteer developers working on these, and potentially other WMF teams.
This backlog will also be public for everyone, and we've been talking to the Developer Relations team about using it as a way for volunteer developers to find high-value projects to work on. We can also use this in collaboration with other WMF product teams
Please stop trying to reopen the conversations about Flow on the 2015 Community Wishlist Survey page. Those requests are not in the scope of this survey, because the Community Tech team cannot act on them. Your concerns about Flow should be addressed to the Collaboration team
The Quixotic Potato (talk) 08:57, 4 January 2016 (UTC)[reply]

So much less overwhelming[edit]

@Ryan Kaldari (WMF): @DannyH (WMF): Thanks for bringing order to the lists, that really helped! LeoRomero (talk) 21:42, 12 November 2015 (UTC)[reply]

Yeah, we were feeling a bit buried too. Thanks for alphabetizing the categories; that's really helpful. -- DannyH (WMF) (talk) 22:00, 12 November 2015 (UTC)[reply]

Suggested format[edit]

I suggest that suggesters use this form for future submissions. We can edit existing entries to fit, if you're cool with it.

Examples of LeoRomero's proposal moved to Talk:2015 Community Wishlist Survey/Proposed format

I would prefer not to make this change right now. I think sorting proposals into categories helps a lot with the readability. The table of contents is good for browsing through proposal titles. I think the experience of scrolling down through the proposals is good for helping people understand what's going on.
I'm sure that we'll need some way to condense items in the future, but I don't think we need it yet, and I definitely don't want to give new people conflicting instructions. DannyH (WMF) (talk) 19:12, 13 November 2015 (UTC)[reply]
That being said -- if some of these discussions get out of control, we could definitely condense them with an archive template. Right now, I think the only one that registers as too big is the SVG proposal in Multimedia. DannyH (WMF) (talk) 19:35, 13 November 2015 (UTC)[reply]
Understood, thanks Danny. Would such an input-format be useful for future surveys? Any downsides? LeoRomero (talk) 21:33, 13 November 2015 (UTC)[reply]
Using that format is a bad idea. Forcing people to use a format you (or anyone else) made up is a bad idea. Plain text is much more flexible, which is a huge advantage over using something like the above. But having a prefilled list of endorsements where people can simply add their signature is a good idea. Earlier I wrote: "And the form should have prefill text that makes it easier for people to endorse/support an idea.". The Quixotic Potato (talk) 11:17, 14 November 2015 (UTC)[reply]
Yeah, it's possible. I guess we'll see how the current process works out. So far, I think people have posted really good-quality proposals -- reasonable ideas, explained well. But this is only day 5; we'll see how it feels at day 10. :) -- DannyH (WMF) (talk) 21:43, 13 November 2015 (UTC)[reply]
So inspiring (but not surprising) to see such energy and intelligence among Wikimedians. Hi-10 for managing this process so well. LeoRomero (talk) 23:43, 13 November 2015 (UTC)[reply]
@LeoRomero: I am not sure why you wrote: "Hi-10 for managing this process so well". Complimenting people on stuff they did badly is not good for their learning process. Many basic mistakes were made, I listed some of them at #Problems_with_this_page. This will probably end up being a giant waste of everybody's time, they want to tackle the top 10 problems, but they have a list of 111 proposals (and people are probably gonna add more). They should've asked "What do you think the top 10 featurerequests will be?". Many good ideas aren't very popular. Many popular proposals require a lot of work and time, therefore it is better to start to work on feature requests that are quick and easy, even though they are less popular... The Quixotic Potato (talk) 11:11, 14 November 2015 (UTC)[reply]
@The Quixotic Potato: I wrote the WMF folks "Hi-10 for managing this process so well", because that's how I feel. Can't agree with you on EVERYthing, people gonna talk. I have my own concerns about the process, but at this point, this boat's in the middle of the ocean, and I'd rather plug leaks than bore holes. How can WMF do this better next time? I'm giving that some thought, and am creating a boilerplate here. Help? - Thanks; LeoRomero (talk) 17:50, 14 November 2015 (UTC)[reply]
@LeoRomero: I don't like it when people agree with me on EVERYthing. This boat's in the middle of the ocean, and heading in the wrong direction (against the currents), therefore we need to explain to the captain(s) why their original plan was bad and offer suggestions to improve it, like I am doing. Telling the captain(s) that they are doing a great job when they are obviously not is not helpful. We should point out their rookie mistakes, this is the best way to help them. Kindness = giving honest feedback that enables someone to identify and avoid mistakes he/she made. Honest people are rarely perceived as kind. I say: "this is a bad idea", but I do not say "you are a bad person". I'll use the talkpage of the boilerplate for some feedback. The Quixotic Potato (talk) 22:41, 14 November 2015 (UTC)[reply]

How will these tasks be prioritized by size?[edit]

Given the quantity of long-anticipated epic tasks being suggested in this survey, it's quite obvious that you can't address them all. Will you be sorting the proposals by the amount of work they entail, say into small (hours to a couple of days work to fix), medium (weeks) and large (at least one month), then taking the top X, Y and Z in each category? Is partial implemention of some suggestions, especially those that are a collection of semi-related tickets, an option? MER-C (talk) 22:20, 13 November 2015 (UTC)[reply]

This will give us a prioritized backlog to work from, in order of votes. The Community Tech team will take the top wishes to evaluate and report back on. We're promising the top 10 right now. It's likely that at least a couple of those top 10 wishes will be too big for us to take on, but we're going to do as much as we can.
This backlog will also be public for everyone, and we've been talking to the Developer Relations team about using it as a way for volunteer developers to find high-value projects to work on. We can also use this in collaboration with other WMF product teams -- if it turns out that the #1 wish is too big for Community Tech, then maybe that should be high on the priority list for another team. There are a lot of possibilities, we're going to see how big this gets. -- DannyH (WMF) (talk) 22:46, 13 November 2015 (UTC)[reply]
Oh, by the way, MER-C -- thank you very much for your help finding and merging duplicate proposals! :) -- DannyH (WMF) (talk) 22:48, 13 November 2015 (UTC)[reply]
@DannyH (WMF): Promising to take on the top 10 was a bad idea. Do you understand that this entire process of creating a list with 111 items is a giant waste of time if you are just gonna work on the top 10? Are you going to copy every single feature request to the phabricator? Is the WMF going to hire new coders to work on these feature requests? You should've asked "What do you think the top 10 featurerequests will be?". Many good ideas aren't very popular. Many popular proposals require a lot of work and time, therefore it is better to start to work on feature requests that are quick and easy, even though they are less popular... The Quixotic Potato (talk) 12:05, 14 November 2015 (UTC)[reply]
To elaborate, what you have is a fixed amount of... uh... story points (WTF is a story point?) to expend, and the survey is headed towards large items occupying a big chunk of the top ten. A promise of five large tasks, ten medium ones and 20 small ones would be more believable and have a lot bigger impact. Something like Improve date range searches on Special:Contributions should only take a day to fix. There are also a bunch of popular tasks that should be rejected for insufficient impact given the obvious shortcomings in MediaWiki itself -- anything that involves creating or improving gadgets until there a global gadget repository, involves Wikidata (Wikidata has its own development team) or creating extensions or bots that are (say) Wikipedia specific are prime candidates. MER-C (talk) 16:33, 14 November 2015 (UTC)[reply]
As I said, there are a number of ways that we're going to use this backlog. Primarily, it's for the Community Tech team, but there will also be volunteer developers working on these, and potentially other WMF teams. This is an opportunity for people to express what they want to see done.
If it turns out that everything in the top 10 is impossible / too big / an obviously bad idea, then we'll move on to #11. We're saying top 10 right now, because we don't want to over-promise. We may also cherry-pick some of the smaller tasks from further down the list -- but if we do, it's on us to explain to the people who voted for #11-24 why we decided to do #25.
To answer The Quixotic Potato: Yes, we may add more developers to the team. That might be new hires, or it might be somebody moving from an existing team. It's not at all up to me how, when or whether that happens, so that's not a prediction or a promise.
Will the most popular ideas be the best? Will they all be huge and impossible? I'm not sure; we haven't started voting yet. But I think there's value in having a big cross-section of active contributors express what's important to them. The good thing about this process is that it gives you the opportunity to express what you want to see. The hard thing is that it gives everybody else that opportunity too. -- DannyH (WMF) (talk) 00:32, 15 November 2015 (UTC)[reply]
@DannyH (WMF):
  • You wrote: "Will the most popular ideas be the best?"... You must be able to answer your own question, right? It is incredibly unlikely that the optimal strategy is exactly the same as the list of proposals ordered by votes.
  • You have not answered this question: "Are you going to copy every single feature request to the phabricator?". Of course some of them are already on the phabricator, I mean the rest of them. And maybe not you personally, but someone who works for the WMF.
  • You wrote: "If it turns out that everything in the top 10 is impossible / too big / an obviously bad idea, then we'll move on to #11". That implies that you are still going to follow the order of which proposal received the most votes, even though it is clear that that is a very bad idea. Please read #Problems_with_this_page. For example, small tasks that can be fixed easily and security risks (e.g. 2015_Community_Wishlist_Survey#Mailman_emails_passwords_in_cleartext) should be prioritized.
  • Who decides if the WMF hires new devs? There are more than 111 proposals here, and a shitload of open tasks in the Phabricator, so you guys desperately need new devs... The WMF has plenty of money so that shouldn't be a problem.
I agree that "there's value in having a big cross-section of active contributors express what's important to them" but unfortunately this process has been handled very badly. The Quixotic Potato (talk) 02:21, 15 November 2015 (UTC)[reply]
The problem is that it isn't clear to everyone that working on proposals on popular demand is an inherently bad idea. Nor have we met a unison resistance to the idea that prioritizing issues – as one small team withing the WMF – according to popular demand is in itself a problem, though several different objections have been raised. I've actually had complaints that we're going to prioritize among the top alternatives depending on size, difficulty etc, instead of simply following the will of the community and start working on #1 and finishing that before moving on to #2. Argumentum ad populum is a fallacy when you're investigating the truth of a specific thing – but we're not, we're trying to figure out what Wikimeida contributors want because we think not enough attention has been paid to that historically. I've – as an editor, not in a WMF role, which I haven't had for very long – been wanting the Wikimedia movement to use more surveys for years, not as a replacement for having discussions but as a complement.
I don't want to get stuck defending an admittedly far from perfect process instead of working together to make it better, but at some point, somewhere, I think the WMF needs to listen to what is popularly requested from the community. /Johan (WMF) (talk) 11:07, 16 November 2015 (UTC)[reply]
@The Quixotic Potato: I'm not sure I really understand your suggestion. What kind of answers would you expect from the question "What do you think the top 10 featurerequests will be?" I imagine most people would have no idea, and a few people would create lists like:
  • Cross project notifications
  • Wikitext syntax highlighting
  • Section watchlists
I'm not sure how that would be useful. We could just create that list ourselves. I much prefer to allow people to present and argue for their favorite ideas. Even if a proposal doesn't become one of the top 10, it's not a waste of time. People get to discuss it, brainstorm possible solutions, and we (the WMF) become aware of the issue. Several of these proposals have already spurred hallway conversations at the WMF or reinvigorated long-dormant Phabricator discussions. Everyone at the Foundation is interested to see what people are posting here.
As far as all the ideas being too big, we'll have to wait and see what people vote for. Even large ideas often have small pieces that can be tackled incrementally. Maybe you're right that we won't be able to tackle most of the top proposals, and maybe we will need to change how the process works next time with input from you and others. So far though, I'm pretty satisfied with how the survey is going. Your suggestion to divide proposals into small, medium, and large is an interesting idea which we may want to try next time. I worry though that people would get bogged down debating which proposals are big and which are small, but maybe that's an unfounded concern. I understand your desire to focus our team's efforts on the "best" ideas rather than the most popular, but you should be aware that there is a long history of the WMF focusing on the "best" ideas, which the community has then hated with a passion. Perhaps we are erring too much on the side of trusting the community's judgement in this case, but a very similar process has worked well for Wikimedia Deutchland's TCB team. Anyway, thanks for continuing to share your thoughts, even the critical and/or pessimistic ones. We are learning a lot during this process and I'm still hopeful that it will have some positive outcomes. Ryan Kaldari (WMF) (talk) 03:39, 17 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Speaking of small things, if you (or someone else) could spare an hour or so to review log-action-filter (part 2), patrolling of uploads, per-category editnotices and bulk revision deletion from Special:Contributions that would be great. MER-C (talk) 12:07, 17 November 2015 (UTC)[reply]

Develop tools to convert Flow and LQT pages to normal talkpages[edit]

Moved comment to talk, where it belongs. The Quixotic Potato (talk) 10:47, 15 November 2015 (UTC)[reply]

If that hypothetical scenario ever did become true, the proposed tool would be fully-developed. The WMF has a duty and intends to maintain or improve the extension, and that extends through all the standard software life-cycle phases. Quiddity (WMF) (talk) 00:38, 14 November 2015 (UTC)[reply]

We need these tools now, because there are already pages that use Flow but we do not yet have a tool to convert them back to talk pages. Same thing for LQT. The Quixotic Potato (talk) 10:46, 15 November 2015 (UTC)[reply]
See also: Talk:Community_Tech/Project_ideas#Opinions The Quixotic Potato (talk) 10:49, 15 November 2015 (UTC)[reply]

Ping The Quixotic Potato. This is tracked in Phabricator task T96301 and task T90075, because task T122961 is a Community Consensus request to convert EN:WT:WikiProject_Breakfast back to a Talk page. Alsee (talk) 01:08, 14 January 2016 (UTC)[reply]

Announce[edit]

Hello. I announced the opening of this survey on my blog, in Portuguese: https://andersbateva.wordpress.com/2015/11/16/wikimedia-foundation-aberta-a-pesquisa-de-desejos-da-comunidade/ .--MisterSanderson (talk) 04:59, 18 November 2015 (UTC)[reply]

Thank you. /Johan (WMF) (talk) 07:57, 18 November 2015 (UTC)[reply]
And I've added the blog to Planet Wikimedia: https://pt.planet.wikimedia.org/ Nemo 08:00, 24 November 2015 (UTC)[reply]

Voting phase[edit]

Which voting system are you going to use for the voting phase? I suggest approval voting. No opposes, just supports. No other limitations. 4nn1l2 (talk) 11:09, 21 November 2015 (UTC)[reply]

We haven't really decided, since we wanted everyone to have a chance to take part in the discussion about how to do it, but we pretty much agree with your suggestion and will probably go with it unless good arguments to do otherwise turns up during the next week. Please note that the current endorsements are not votes, by the way. /Johan (WMF) (talk) 18:20, 23 November 2015 (UTC)[reply]
If approval voting is used, will controversial items be removed before the voting phase? Nemo 07:59, 24 November 2015 (UTC)[reply]
And by controversial you mean not only endorsed but also (heavily) opposed? Or something else? /Johan (WMF) (talk) 08:13, 24 November 2015 (UTC)[reply]
Nemo, any proposal that got at least one endorsement will go into the voting phase. The discussion from the proposal phase will be on the page (collapsed under a template), and there will be more free discussion during the voting. I think the role of the comments (support or oppose) is to help other people to make a decision; if you think a specific proposal really is a terrible idea, then you can feel free to say it, and discourage people from voting support.
Also - the top voted items are going to be evaluated by the Community Tech team, and we're responsible for publishing our evaluations and our plans. The discussions during both phases will be a valuable part of our evaluations. In the case of a good, feasible idea that would be controversial for a project, we may recommend that people start an RfC in their community, to make sure that there's widespread consensus before we start building anything. And if a really actually terrible idea ends up in the top 10, then the team will explain why it can't (or shouldn't) be done. DannyH (WMF) (talk) 17:34, 24 November 2015 (UTC)[reply]
If you are going to allow free discussion even in the voting period, please at least don't use the rubbish formula of to make a ranked list of priorities -- just subtract opposes from the supports. 4nn1l2 (talk) 19:20, 24 November 2015 (UTC)[reply]
We're just going to use a straight count of Support votes. People can post Oppose comments as part of the discussion, but Oppose votes will not be counted.
If we counted Oppose votes, then it would be easy for me to support the proposal that I like by casting Oppose votes on all of the other proposals. That would be a harsh and unpleasant way to show support, but if a couple people do it, then everyone would have to follow.
Oppose and neutral comments will "count" in the sense that a compelling negative comment could discourage other people from casting Support votes. But only the Support votes will actually be tallied. -- DannyH (WMF) (talk) 20:22, 24 November 2015 (UTC)[reply]
Very sensible :-) ‍‍‍4nn1l2 (talk) 20:42, 24 November 2015 (UTC)[reply]
Suggest that you offer five options, next time: Strong Support ('counts' the same as support but is more indicative of intent), Support, Comment, Tactical Oppose (aka not-in-my-top-ten), Strong Oppose (aka absolutely against this on the merits). In that way, you could calculate "for informative purposes" the (support+strongSupport)/(support+strongSupport+tacticalOppose+strongOppose) value, as well as "for decision-guidance purposes" count support+strongSupport. It might give you a better idea, though, of which people were *really* opposed to something. I'd also suggest Support If Time Permits, as a sixth option, so that proposals could be marked as "nice to have" but not top-ten. 75.108.94.227 11:22, 5 December 2015 (UTC)[reply]
Please count the oppose votes, there are several proposals that have opponents as well as supporters, if you go ahead with schemes that have more opponents than supporters then it makes a nonsense of the idea of this being a community consultation. Remember even the AFT had some community support. WereSpielChequers (talk) 16:01, 26 November 2015 (UTC)[reply]
Our current reasoning goes something like this: we don't want to encourage oppose votes in order to get one's own pet suggestion ahead, as Danny described above.
However, we'll do some sort of screening and assessment after the voting – making sure no one else is already working on it, that it's something we can do, that it's something that wouldn't take all our time for the next year while we could do fifteen other almost equally popular suggested improvements in the same time et cetera. If something has more opposing than supporting votes (or equal number, or ...), it's not like we're going to ignore that fact and consider it something the communities want us to do.
You feel this wouldn't be a working process? /Johan (WMF) (talk) 12:22, 27 November 2015 (UTC)[reply]

Holidays[edit]

Hi everyone, this week the US – where most of the team is located – celebrates Thanksgiving. Some of us are still working, but I'd just like to point out that it could take us some extra time to respond for a few days. :) /Johan (WMF) (talk) 12:24, 25 November 2015 (UTC)[reply]

Problem with location of a proposal[edit]

2015 Community Wishlist Survey/Categories#Tools for dealing with citations of withdrawn academic journal articles is located on the "Categories" page. However, there is nothing in the proposal, at all, that relates to categories. I think it belongs on the "Miscellaneous" page. John Broughton (talk) 00:52, 30 November 2015 (UTC)[reply]

The proposal has been moved. /Johan (WMF) (talk) 11:42, 30 November 2015 (UTC)[reply]

Village pump message: Voting is now open![edit]

I think you'd better send a message to village pumps of all WMF projects and let them know that the voting phase has already begun, otherwise you will probably end up with a low voter turnout. 4nn1l2 (talk) 03:45, 30 November 2015 (UTC)[reply]

AFAICS the voting pages are not ready: there is no translation system set up yet. Translation was one of three reasons to conduct the survey on wiki, so I'm sure the team by now has a plan to implement it (before the bulk of the votes happen). Nemo 09:37, 30 November 2015 (UTC)[reply]
The US, where most of the team is located, hasn't woken up yet. We'll notify the communities soon. There's a prepared invitation for that purpose, so we're definitely planning on it. /Johan (WMF) (talk) 11:47, 30 November 2015 (UTC)[reply]
Johan, I just translated the message into Persian. But I neglected the 1st message and only translated the 2nd message. Can you handle that or I need to translate the 1st message as well? I also counted 111 proposals. Since Persian uses Arabic numbers, I thought you may have difficulty updating XXX on the original message. If there was any modification, feel free to drop me a line and I will update the numbers. 4nn1l2 (talk) 13:28, 30 November 2015 (UTC)[reply]
Translating the second message only makes a world of sense. That's all we need by now. Thank you! :) I'll get back to you if we need an update. /Johan (WMF) (talk) 13:39, 30 November 2015 (UTC)[reply]
@4nn1l2 and Nemo bis: We're working on making all the proposal subpages translatable right now. As soon as that is done, we will send out an announcement about the voting phase to all the projects. Ryan Kaldari (WMF) (talk) 18:21, 30 November 2015 (UTC)[reply]
Not that people can't vote now if they want to, but we won't go out to other wikis, most of them non-English, with the announcement until the pages are at least translatable. It's possible that won't happen until tomorrow, UTC. /Johan (WMF) (talk) 19:05, 30 November 2015 (UTC)[reply]
Sorry I've just informed the German tchnical bar. it is not the main bar BTW.--Alexmar983 (talk) 22:57, 30 November 2015 (UTC)[reply]
Me too, I already advertised it with watchlist notice in FAWP similar to ENWP. 4nn1l2 (talk) 23:15, 30 November 2015 (UTC)[reply]
That's fine. All the pages are translatable now. Ryan Kaldari (WMF) (talk) 06:40, 1 December 2015 (UTC)[reply]
It's not like it's a secret. You can tell your communities whatever you want to tell them, of course. :) /Johan (WMF) (talk) 11:25, 1 December 2015 (UTC)[reply]
The communities have now been notified. :) /Johan (WMF) (talk) 14:44, 1 December 2015 (UTC)[reply]

Artificial Intelligence[edit]

It may be more prudent to separate tools asking for AI support. Implementation of these will be similar and seemingly unrelated tasks would benefit from similar AI algorithms. This would keep discussion in one place. -- とある白い猫 chi? 19:56, 30 November 2015 (UTC)[reply]

That's an interesting idea. Can you give some examples of the proposals that you mean? -- DannyH (WMF) (talk) 20:04, 30 November 2015 (UTC)[reply]
Anything that says "en:machine learning" would be in this hypothetical group, which includes these:
  • Machine-learning tool to reduce toxic talk page interactions
  • Machine learning to identify sockpuppets
  • Suggesting AbuseFilter by machine learning
The various toolkits and algorithms which support generic machine learning infrastructure, would be more or less applicable to all three ideas. Also, several of the "image recognition" projects could be AI projects -- the one called "Image searches based on image recognition" is definitely in this area -- and would form a superset of the projects which are specifically about machine-learning (image-recognition often needs machine-learning *and* en:machine vision AI techniques). Other image-projects are not specifically AI-centric, such as "Suggested multimedia for article" which is mostly about non-AI programmatic-reading of licensing metadata.
  One proposal that *could* be an AI project (en:natural language processing), but is not phrased as such currently, is the proposal to Improve the copy-and-paste-detection bot. Most of the suggested changes are visual and workflow-related improvements, whereas, if the proposal was to "make the copy-n-paste-bot able to detect close paraphrasing" or something, *that* would be an AI project. Similarly, there is a proposal for a "Tool to use Google OCRs in Indic language Wikisource" which is legally tricksy but programmatically simple -- whereas writing FLOSS code to *perform* the OCR, rather than relying upon Google's proprietary AI codebase, would definitely be an AI project, were that the proposal being made. In other words, almost every proposal could be AI-related, but several proposals are AI-specific and even AI-niche-specific (machine learning and machine vision). Best, 75.108.94.227 11:59, 5 December 2015 (UTC)[reply]

Unable to vote?[edit]

I've tried a few times to add a "support" vote (with or without comment) to some of these proposals, and my edits are rejected with this note:

"This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Antispam"

2macia22 (talk) 11:08, 1 December 2015 (UTC)[reply]

@2macia22: We'll look into it (Kaldari has now been informed, as an administrator on Meta). Worst case, if the filter keeps identifying your votes as spam, write on my talk page, indicating which proposals you want to support in which categories, and if you have any specific comments, and I'll post them for you with your signature, explaining why in the edit comment. But that ought not to be necessary. :) /Johan (WMF) (talk) 12:08, 1 December 2015 (UTC)[reply]
Should be better now. Nemo 13:26, 1 December 2015 (UTC)[reply]
Thanks, Nemo. /Johan (WMF) (talk) 13:45, 1 December 2015 (UTC)[reply]

alleged herding[edit]

I changed this list:

To look instead like this:

  • ...with 8, 49, 4, and 88 support votes (respectively as of Dec 5th)
  • ...with 7, 12, 0(!), 18, 0(!), 69, and 3 support votes (respectively as of Dec 5th)
  • ...with 45, 52, 4, 32, 48, 21, and 8 support votes (respectively as of Dec 5th)
  • ...with 32, 5, 14, 15, 34.5, 87, 30.5, 4, 7, 10, 29, 6, 7, 21, and 4 support votes (respectively as of Dec 5th)
  • ...with 1, 4, 5, 9, 2, 0(!), 17, 9, 0(!), 9, 59, 2, 13, 1, 33, 7, and 2 support votes (respectively as of Dec 5th)
  • ...with 8.5, 41, 42, 33, 6, 4, 7, 11, 0(!), 5, 17, 0(!), and 3 support votes (respectively as of Dec 5th)
  • ...with 9, 1, 30, 0(!), and 6 support votes (respectively as of Dec 5th)
  • ...with 13, 32, 4, and 25 support votes (respectively as of Dec 5th)
  • ...with 8, 4, 21, and 6 support votes (respectively as of Dec 5th)
  • ...with 7, 16, 7, 35, and 23 support votes (respectively as of Dec 5th)
  • ...with 21, and 15 support votes (respectively as of Dec 5th)
  • ...with 3, 23, 3, and 59 support votes (respectively as of Dec 5th)
  • ...with 77, 21, and 6 support votes (respectively as of Dec 5th)
  • ...with 56, 75, 5, 37, 4, 23, and 41 support votes (respectively as of Dec 5th)
  • ...with 6, 11, 42, 12, 3, 15, and 13 support votes (respectively as of Dec 5th)
  • ...with 6, 23, 15, 0(!), 32, and 35 support votes (respectively as of Dec 5th)
  • ...with 5 support votes (respectively as of Dec 5th)

But that was reverted, by 4nn1l2 on the sole basis that it would encourage herding.[1]

I find that specific revert-rationale to be pointless, albeit "correct" in some narrow sense... pointless because any person can see, under each and every proposal, how many people voted for said proposal. All I'm doing here, is listing, on the top-level-page, what is clearly visible to anybody visiting any of the actual proposal-subpages. It is literally impossible to add one's bangvote, without seeing how many other people have bangvoted before you. Is there consensus to keep these counts out of the top-level page, and if so, what is the rationale? If not, can I please put the figures back in? People that are in a hurry will want to see which proposal-subcategories are more active, since there is a limit to which proposals actually have a chance to be worked on. Thanks, 75.108.94.227 18:48, 2 December 2015 (UTC) (Updated: IJBall (talk) 18:15, 5 December 2015 (UTC))[reply]

In your version, people in hurry may don't bother to open, say, the Wikiversity subpage and take a glance even at the title of the proposal. A proposal which has already received 71 votes in favor, obviously does not need some additional votes (surplus votes) to be placed on 10 top priorities. Let other proposal have a chance of being seen! 4nn1l2 (talk) 19:09, 2 December 2015 (UTC)[reply]
I understand the thing that you're trying to do. Highlighting the proposals with the highest votes would help people see where the "hot" issues are, and could encourage them to chime in, either in support or opposition. I can also see 4nn112's argument that we don't just want to drive people towards the already well-received options.
But either way, I don't think this system works. For one thing, it would be impossible to keep that list updated by hand. After just a couple of days, we've already had more than 300 people vote, and there are new votes every couple of minutes. It's also very difficult to read that chart and make sense of it. I think it's just visual noise.
So I think the list is doing a decent job as it is; people seem to be able to find proposals to support so far. But I'd be open to other ideas that might help to improve this system. -- DannyH (WMF) (talk) 19:38, 2 December 2015 (UTC)[reply]
A nice graphical table-chart thing, which automagically syncs to the various subpages, and shows visually clean horizontal-bar-chart indicators?  :-)     That would be ideal, of course. But beyond my skill to implement using only wiki-markup and templates. Maybe I should propose development, of such a thing, for the ... wait. Nevermind. p.s. The point of listing all the counts, rather than just the 'hot' issues, was specifically so that busy folks could ignore the proposals with too few counts to succeed, and also ignore the proposals with too *many* votes to fail (opposes are being ignored after all), and concentrate specifically on that narrow range of proposals which have sufficient interest to possibly succeed, but are not presently in the top ten. Best, 75.108.94.227 11:14, 5 December 2015 (UTC)[reply]

┌─────────────────────────────────┘
I originally made the hotspot chart on the 2nd; the numbers above have been modified by other folks to keep them somewhat updated, thanks. Here are the original hotspots from the 2nd, compared to the current hotspots as of early on the 13th, which is the day before the voting-phase ends.

  • ...with 7 13, 39 60, 11 18, and 70 111 votes (respectively as of Dec 2nd 12th)
  • ...with 8 13, 10 19, 2 3, 8 20, 7 10, 57 82, and 2 8 votes (respectively as of Dec 2nd 12th)
  • ...with 37 53, 41 77, 7 11, 26 37, 47 62, 17 26, and 7 nix votes (respectively as of Dec 2nd 12th)
  • ...with 22 44, 5 10, 8 17, 9 20, 28 41, 71 101, 22 41, 2 7, 6 11, 3 18, 21 34, 7 9, 5 nix, 18 25, and 4 nix votes (respectively as of Dec 2nd 12th)
  • ...with 0 2, 3 7, 3 5, 11 14, 5 9, 2 2, 10 22, 7 11, 1 1, 10 13, 41 68, 2 3, 11 16, 7 10, 27 48, 5 10, and 4 7 votes (respectively as of Dec 2nd 12th)
  • ...with 4 11, 35 54, 30 47, 26 38, 3 11, 4 10, 5 10, 7 15, 1 1, 5 6, 10 20, 1 2, and 3 5 votes (respectively as of Dec 2nd 12th)
  • ...with 7 12, 2 3, 21 39, 1 1, and 1 8 votes (respectively as of Dec 2nd 12th)
  • ...with 7 15, 19 42, 5 12, and 19 31 votes (respectively as of Dec 2nd 12th)
  • ...with 4 11, 4 8, 18 28, and 8 11 votes (respectively as of Dec 2nd 12th)
  • ...with 5 9, 12 17, 6 10, 27 37, and 15 28 votes (respectively as of Dec 2nd 12th)
  • ...with 17 22, and 12 15 votes (respectively as of Dec 2nd 12th)
  • ...with 3 8, 18 31, 3 4, and 52 77 votes (respectively as of Dec 2nd 12th)
  • ...with 60 83, 15 23, 6 8, and 1 nix votes (respectively as of Dec 2nd 12th)
  • ...with 36 62, 57 82, 3 7, 27 47, 4 7, 13 30, and 30 55 votes (respectively as of Dec 2nd 12th)
  • ...with 2 7, 6 12, 30 48, 8 12, 2 3, 11 18, and 12 18 votes (respectively as of Dec 2nd 12th)
  • ...with 5 9, 20 24, 10 18, 4 4, 28 45, and 29 38 votes (respectively as of Dec 2nd 12th)
  • ...with 5 6 votes (respectively as of Dec 2nd 12th)

As you can see, there was relatively little change in the top-eleven-spots, between my sampling on December 2nd and my sampling just after December 12th. To make it more plain, here are the hotspots, ordered by number of comments (enumerated ones only... which is obviously not equivalent to number of supports to which the devs will be paying attention

Obviously, hotspots measured by *total* numbered-comments don't directly equate to winning proposals: partly that is determined by number of support-comments, and partly by dev discretion. But early hotspots tend to keep trending upwards, with the current approach to wishlist-voting, where everybody can see the commentary made by other people. I think that is probably a good thing, because interest in the proposal is a good measure of interest in seeing a solution to the problem the proposal addresses. However, next year it would probably improve the process, if the vote-counts were tallied automatically, and displayed on the overview-page.

  Rationale: an insightful comment on a proposal with five votes is helpful, because that proposal might be improved, and then might be adopted next year, or the year after that. An insightful comment on a proposal with 500 votes is also helpful, because that proposal will almost certainly be implemented, and it is better to catch problems and prioritize mandatory requirements early on. But, because resources *are* limited, the most important proposals are the ones on the bubble: in a top-ten-contest, that means proposals #9 and #10, plus proposals #11 and #12. Some of those will be worked on this year, unless insightful opposes are written. Some of them will be deferred until next year, unless insightful supports are added. To maximize the value of time spent writing insightful comments, for wikipedians with limited time (not including myself obviously ;-)   it may help to point people at those on-the-bubble proposals. Thanks, 75.108.94.227 15:52, 13 December 2015 (UTC)[reply]

Archive request[edit]

Why don't you archive the last proposal in the editing subpage? 4nn1l2 (talk) 11:41, 3 December 2015 (UTC)[reply]

Oh, good point. Okay, I archived it. Thanks! -- DannyH (WMF) (talk) 17:49, 3 December 2015 (UTC)[reply]

Read text aloud[edit]

I was not aware of this until today, voting has already started, may be next time. A functionality that could read aloud the text for the differently able persons would be nice. There's a channel on youtube that does a similar thing for enwiki but without proper attribution. -- Fauzan✆ talk ✉ email 17:00, 4 December 2015 (UTC)[reply]

Hi Fauzan, thanks for the link! Do you know how many videos have been uploaded total by Audiopedia@youtube? (They registered 2013-11-28) I couldn't find out...
There is a similar service by http://en.wiki-videos.com/ and http://de.wiki-videos.com/ wich produced 120,000 clips with shortened WP information in 45 seconds. Both are automatic text-to-speech software i guess. What do you think, would you really use these videos? I think the blind have specialised software for internet browsing, they are not the target audience for this. --Atlasowa (talk) 18:17, 4 December 2015 (UTC)[reply]
Atlasowa, Audiopedia have 49,646 as of now. Some platforms have built in ability to convert text to speech. I am not sure about the target audience, it depends on whether the general Wikipedia reader would want to have such a facility in built, or use add ons. Thanks! -- Fauzan✆ talk ✉ email 08:05, 5 December 2015 (UTC)[reply]

Scope[edit]

I came to this page from SEW and actually thought it was about proposals specific there-to. Maybe it should be made clear that this applies to ?all Wikipedias?Kdammers (talk) 02:52, 5 December 2015 (UTC)[reply]

The description at the top of the page says "all Wikimedia projects", but I can see how people might miss it. I could bold it, if you think that would help. -- DannyH (WMF) (talk) 18:50, 6 December 2015 (UTC)[reply]

Top 15[edit]

I know the WMF has promised to look at the Top 10 proposals, but I hope they look seriously at the Top 15. After having just updated the vote totals, I think anything with over 40 support votes (as of Dec. 5) should be seriously looked at (roughly >45 support votes represents the current Top 10) – but some of proposals that are currently in the "low 40s" in terms of support votes look to me to be just as important as the some of the "Top 10" stuff. Just my $0.02... IJBall (talk) 18:20, 5 December 2015 (UTC)[reply]

Yeah, we're planning on addressing as many as we can. There are a lot of really good proposals, and I'm excited about getting into them, once the voting is over. We promised top 10 because we're a small team and we don't want to promise too much, but the whole list will be a prioritized backlog for Community Tech, volunteer developers and possibly a relevant product team. I don't want this to be "top 10, forget the rest". -- DannyH (WMF) (talk) 19:00, 6 December 2015 (UTC)[reply]
  • My concern about restriction to the "Top 10" is that there are several proposals that relate primarily to projects that have dramatically fewer participants than the Wikipedias and Wikidata and Commons. This places them at a continuing disadvantage to having their needs met. It becomes circular: fewer technological innovations to address identified issues means attracting fewer participants, which in turn means fewer people demanding the technological innovations. I'd like to encourage Community Tech to reserve a few slots on their activity list for smaller projects such as Wikisource or Wiktionary. Giving these projects better tools (especially tools that are familiar to Wikipedians) will be much more likely to result in community growth and activity than many of the tools designed for bigger projects, and I would encourage Community Tech to include this factor in its final decisions. The "trickle down" theory of tool development (i.e., make it for a big project and someone will eventually modify it enough for the smaller projects) has proven to be almost entirely unsuccessful. I've tried to do my bit by supporting proposals targeted at non-Wikipedia/Wikidata/Commons projects if they are supported by users who participate on those projects, but it is pretty obvious already that even the most desirable ones may not make the top 10. Risker (talk) 19:05, 6 December 2015 (UTC)[reply]
Yeah, it's a good question. Figuring out these priorities is tough -- when you have limited resources to spend, it's hard to figure out where the investment will have the greatest return. What we're doing here is one way of approaching it. I'm interested to see where all of those projects end up on the list -- if they don't get addressed right now, then there's a show of support that everybody can talk about. Sorry for the vague philosophical answer to your specific question. This process is new for us (both our team and WMF), and it's hard to say exactly how things are going to play out. -- DannyH (WMF) (talk) 17:27, 7 December 2015 (UTC)[reply]
The middle ground would be to prioritize proposals that affect all Wikimedia projects. Anything that affects one project only should be deprioritized or, if I was running things, declined for resubmission in a later round. MER-C (talk) 18:38, 7 December 2015 (UTC)[reply]
Sensible reasoning behind that, of course, but I can't help wondering: if Community Tech isn't going to address small project-specific requests that might be very relevant indeed to the projects in question, who is? /Johan (WMF) (talk) 09:01, 8 December 2015 (UTC)[reply]
Of course I expect you are going to consider both things. Some wiki-specific issues are extremely cheap to solve for a big return (like fixing broken gadget definitions), but some "small" wiki-specific projects have high costs (e.g. the proposed WikiProject wizard). Nemo 09:37, 8 December 2015 (UTC)[reply]

Canvassing?[edit]

Is this message appropriate? 4nn1l2 (talk) 22:21, 10 December 2015 (UTC)[reply]

Yes, it's fine. I'm surprised more people aren't doing it. It spreads the word about the survey, and people who come to vote on one proposal will also find other proposals they support. Feel free to tell people about the proposals you want to support. -- DannyH (WMF) (talk) 17:38, 11 December 2015 (UTC)[reply]

634 Teilnehmer[edit]

Gibt Euch die Zahl von gerade einmal 634 Teilnehmern zu denken? Das ist m.E. lächerlich wenig. Allein die deutsche WP hat ca. 1.000 "sehr" aktive Mitarbeiter. K.A. wieviele es global sind, aber Sicherlich weit oberhalb dieser Zahl. Wenn nun also nur eine so kleine Zahl teilnimmt kann das IMO verschiedene Gründe haben:

  1. die Technik ist kaum noch zu verbessern (muhaha :D )
  2. die technischen Möglichkeiten eigene Ideen anzubringen waren zu umständlich und Leute sind schlicht daran gescheitert
  3. man versteht Euch nicht weil ihr bspw. bei den Aufrufen nicht in der Lage seid die Sprache der Wikipedianer zu sprechen
  4. nur wenige glauben, dass ihre Meinung für die WMF irgendwas wert ist

...Sicherlich Post 09:15, 22 December 2015 (UTC)[reply]

I think 634 people is a good response for something like this; it's not easy to get people to leave their home wiki and contribute to Meta. We tried to promote this as widely as we could, without spamming people about it.
I agree that there are a lot of contributors who don't feel like the WMF is listening to them. I hope that this survey, and the work that our team does over the next year, can be a step forward. It's our team's job to show that we can deliver on requested features, and we're going to work hard to make that happen. I hope that you'll participate next year. -- DannyH (WMF) (talk) 19:19, 22 December 2015 (UTC)[reply]
@DannyH (WMF): Indeed, there are many contributors who are aware of the fact that the WMF isn't listening to them. Both the WMF and the group of contributors who are aware of the fact that the WMF isn't listening to them are large groups, which makes it difficult to talk about them without using generalizations. Let's keep it simple, and talk about us. We disagree about a couple of things. I wrote you a message. You ignored it for almost two months. I am aware of the fact that you aren't listening to me. Are you going to "work hard" to change that? The Quixotic Potato (talk) 08:09, 4 January 2016 (UTC)[reply]
As far as I'm aware, we've never had a movement-wide process in which more than a small fraction of the active editors have participated, at least not since the very beginning when it was feasible due to the very small number of Wikimedians (or Wikipedians, as they all were, back then). Your #2 will always be relevant as soon as people have to leave their home wiki (which isn't saying that other reasons don't come into play as well). /Johan (WMF) (talk) 11:15, 12 January 2016 (UTC)[reply]

2016[edit]

I object to this and this reversion on the grounds that the Foundation should not preempt community suggestions by removing community work because of arbitrary scheduling.

@DannyH (WMF):

  1. Are there any reasons that removing the suggestions could improve the survey?
  2. Are there any reasons that leaving the 2016 Community Wishlist Survey open for suggestions now instead of waiting until November would not encourage more and a wider diversity of suggestions?
  3. If the community is forbidden from cooperating with the Foundation in conducting the survey, then should it be renamed the Foundation Wishlist Survey? EllenCT (talk) 00:08, 15 July 2016 (UTC)[reply]
i just wish the WMF was as aggressive reverting the "sea-lioning" of the inspire campaign, as shutting down pre-mature dreaming. i guess we can dream on the WMF time frame. this is a common form of collaboration as dictation. should not be surprised that more people will disengage. Slowking4 (talk) 03:09, 15 July 2016 (UTC)[reply]
Hi EllenCT: The Community Wishlist Survey is a very important process for the Community Tech team; it forms the core of our work for the year. We're responsible for running the process in a way that's as effective as we can make it, and people correctly hold us accountable to that. We're going to make some changes in the process for the next survey based on feedback from various groups, but we want to know more before we start that conversation. It depends on how some of our projects go this year, and we're only six months in.
You posted a link at the top of several of our team's pages announcing a new 2016 survey, in a way that clearly implies that it's our team making the announcement. You used the same font and placement for your announcement as we used to post our status report link, on the same page. Also, on the survey page that you created, you didn't make it clear that this was a process that you invented. You didn't put your name on it, or explain that it was your idea, and you linked to our results page. Again, anyone who looked at that page would obviously assume that the Community Tech team was starting the new survey. We would be held accountable for making that decision, without talking to any of the other stakeholders in the process.
If you'd like to start your own brainstorming list of proposals for the next survey, then you should do that; it's a good idea. But I don't want Community Tech to specifically encourage people to post a list right now, because we may change the format of the proposals in the next survey. Some of the proposals in last year's survey were vague, and it proved difficult in a few cases for volunteer developers to know exactly what people were voting for. If we decide to make the proposal format more detailed, then it's not helpful for us to have a list of links to talk page diffs, which we'd be responsible for adapting into the new format.
As Nemo points out below, I think it would have been better to talk to us, before you decided to change the way that we run the survey process. If you want to start a brainstorming list, or even create your own volunteer-run wishlist survey, then you can do that. My request is that you don't give the impression that the Community Tech team is responsible for the new process that you've created. -- DannyH (WMF) (talk) 18:36, 15 July 2016 (UTC)[reply]

IMHO the reversion makes sense: "Community Wishlist Survey" as a name means the thing that WMF does (yes, there is an implicit "WMF" somewhere in the name). If the WMF plans to start the survey in November, right now they probably have no idea what the exact format will be (if it's not the same format, any suggestion added now may be trashed; better add them to the issue tracker then). I think you rather wanted to open a discussion like the following. Nemo 06:14, 15 July 2016 (UTC)[reply]

yeah, or they could have slapped a big under construction - see you in september, and conducted this on the talk page. by putting it here, it makes a threaded conversation hard to follow; it's a thousand arguments in a thousand places. just cause they are well within their rights, doesn't mean it is a good idea. if you cannot model how to deal with difficult people, then you should not be surprised, by the cultural buzzsaw. everybody wants to be betacommand. Slowking4 (talk) 18:40, 19 July 2016 (UTC)[reply]

Schedule and objectives for a reiteration[edit]

Topic: When should a new survey happen? What will be its goals? Should it be like the 2015 one?

My opinion: I must say I was surprised by [2], because it seems to me that there is no shortage of work to do with the existing wishlist. I don't see what benefit there could be by reiterating the survey in few months from now; it would be enough to make a new wishlist in 2018. A survey could be useful if it provided either of the following:

  1. significantly higher participation (one order of magnitude more, or at least 10 languages instead of 1), giving more legitimacy to the wishlist even if it ends up being the same;
  2. assessment of the work done so far and suggestions to change the way the wishlist is worked on.

Nemo 06:14, 15 July 2016 (UTC)[reply]

We're planning to run another Wishlist Survey annually, running in November/December to give Community Tech and volunteer developers a fresh set of projects to work on.
Community Tech is responsible for addressing the top 10 wishes this year. By the end of the year, some of the top 10 wishes will be complete, and released. But there are some that we won't be able to complete, for a few possible reasons -- because there's a technical blocker that makes the proposal impractical, because another team is currently working on that project, or because the community couldn't come to consensus about how it should be addressed. One way or another, the top 10 proposals will either be done, declined or reassigned by the end of 2016.
Meanwhile, we're working with the Technical Collaboration team and the WMDE Technical Wishes team to address the wishes below the top 10. Some of those wishes have been worked on by volunteers at the Wikimedia hackathons this year, and we've been collaborating with WMDE on some of the wishes from the German survey and ours. By the end of the year, many of the wishes below the top 10 will either be done, or declined because of technical blockers. You can see the progress that everybody's making on the 2015 Community Wishlist Survey/Results page, and on the pages and Phabricator tickets linked there. We posted our second status report in May, and we'll post a third report sometime later this year.
That doesn't mean that all 107 wishes will be addressed this year, but we're going to need a fresh list for 2017. I expect to see a lot of new participants in the next survey, because more people have heard about our work now. We also want to change the format in some way, to give user groups a better chance of getting technical assistance. We're still figuring out exactly what that will mean, but we've got a few months to think and talk and work on it. So yes, I expect that there will be higher participation, and changes to the format, plus a new set of volunteer-sized projects that people can work on at the hackathons. -- DannyH (WMF) (talk) 19:04, 15 July 2016 (UTC)[reply]
Would you please answer my questions? Would you expect to see more or fewer if you stopped deleting them until you run the survey to sort them? EllenCT (talk) 20:03, 15 July 2016 (UTC)[reply]
I would expect to see the same amount. -- DannyH (WMF) (talk) 21:07, 15 July 2016 (UTC)[reply]
What are the reasons that you might have for such an expectation? What if someone thinks of an idea in October but forgets it in September? I've tried to be as civil and Socratic about this as possible. Would you please answer my three numbered questions above? EllenCT (talk) 21:26, 15 July 2016 (UTC)[reply]
"1. Are there any reasons that removing the suggestions could improve the survey?" Single-handedly changing the process of the survey without speaking to the people who are responsible for it is disruptive. When you posted your links and created the 2016 Community Wishlist page, you created the strong possibility that people would be confused about how the next survey is supposed to work. When it came time for our team to actually begin the new survey, people who were confused by your actions would think that our team is being irresponsible. This would complicate the smooth running of the new survey for everyone. Replacing your suggestions with an accurate explanation of the process makes it more likely that the next survey will run smoothly.
"2. Are there any reasons that leaving the 2016 Community Wishlist Survey open for suggestions now instead of waiting until November would not encourage more and a wider diversity of suggestions?" I think I answered this in some detail above. We're probably going to modify the format of the next survey. But even if we didn't, links to talk page diffs would not be acceptable proposals. Encouraging people to add to a brainstorming page would create confusion when we open the survey process for real in November. That confusion could easily result in less participation overall.
"3. If the community is forbidden from cooperating with the Foundation in conducting the survey, then should it be renamed the Foundation Wishlist Survey?" That isn't the case. I would be very happy if you wanted to cooperate with our team in conducting the survey.
"4. What if someone thinks of an idea in October but forgets it in September?" The two links that you posted aren't gone; they're clearly accessible in the diff that you posted above. If you want to keep a personal list of ideas that you'd like to propose in the next wishlist survey, then I'd suggest putting it on your user page. That would help you keep track of your ideas, without confusing other people about the survey process. -- DannyH (WMF) (talk) 21:56, 15 July 2016 (UTC)[reply]
Thank you, Danny. It is refreshing to have my questions taken seriously in form, but I am disappointed that you say providing actual suggestions for improvement is disruptive. Your argument supporting the accusation is that, "If we decide to make the proposal format more detailed, then it's not helpful for us to have a list of links to talk page diffs, which we'd be responsible for adapting into the new format." But that argument is completely unsupported because you can ask those who have submitted suggestions to provide them in a different form at any time, if you do not wish to put them in your preferred form. To whom may I appeal your accusation that I have been disruptive?
Furthermore, your assertion that, "Encouraging people to add to a brainstorming page would create confusion when we open the survey process for real in November. That confusion could easily result in less participation overall," is also not only unsupported, but it stands in stark and direct opposition to the philosophy of open editing, and so I also wish to appeal that determination.
What makes you think I don't want to cooperate with your team in conducting the survey? Is there literally any way I could have signaled my willingness to cooperate more fully and completely than by providing suggestions for improvement?
I find it almost impossible to believe that you seriously think keeping the survey closed until November will not influence the number of suggestions you will obtain, or will disrupt any of the methods or processes you use to rank and sort proposals. If you are unwilling to explain my appeals to your management then please let me know who to contact to do so myself. EllenCT (talk) 22:11, 15 July 2016 (UTC)[reply]
Hi, I think the wiki way would be for the Community to have some kind of space to prepare itself for the survey and be creative beforehand+. I bet WMF staff is already preparing on their end in some Google Doc, so it's only fair for the Community to do the same. :-) This space could be a subpage, a talk page, anything. Remember this is pretty much the only way the Community can interact. Just my thoughts. --Gnom (talk) 06:20, 21 July 2016 (UTC)[reply]
I absolutely see your point. Unfortunately, we got burned last year on exactly this. See the above conversation on #Community Tech/Project ideas. We had a page where people added project ideas, and then we asked folks to transfer over the proposals that they were interested in, putting it into the new format. We were still trying to figure out how the process was going to work, and the discussion about that page turned into an unpleasant stumbling block, right out of the gate.
So if somebody wants to create a brainstorming page that we're not involved with, they can. I would just ask them to make it clear that it's a community page, not created by the Community Tech team. The page that EllenCT created on the 2016 Community Wishlist Survey was clearly meant to suggest that her brainstorming page was the first stage of the new survey process.
I'm sure we'll make a lot of mistakes with the next survey, in keeping with the natural cussedness of things in general. I just don't want to make the same mistakes that we made last time. :) -- DannyH (WMF) (talk) 17:29, 21 July 2016 (UTC)[reply]
I have restored my requests to 2016 Community Wishlist with the disclaimers as requested. If it is deficient please improve it or let me know or both. I appreciate the effort to compromise, and I repeat my request to reconsider your determination that the suggestions or format were disruptive in any substantial way. EllenCT (talk) 05:41, 6 August 2016 (UTC)[reply]
Ellen: please do not post your messages on Community Tech team pages. I am asking you to do this as a kindness to me. -- DannyH (WMF) (talk) 05:44, 6 August 2016 (UTC)[reply]
Why? I think this revert shows no respect for cooperating with the community. The Community Tech team didn't create that page, and it had the specific disclaimers you requested above prior to your reverting them. I repeat my request to appeal your decisions, on the same grounds: you will not get as many suggestions if you censor them until November. To whom may I do so? EllenCT (talk) 05:47, 6 August 2016 (UTC)[reply]
I can see both side's concerns. I have an idea that might accommodate everyone. How about adding a second line resembling this:
Please use the talk page to discuss the 2016 Wishlist process, or as a scratchpad for ideas that might be submitted.
Another idea is to have a dedicated scratchpad page link, if you don't want to clutter the two onto same page. Alsee (talk) 23:45, 9 August 2016 (UTC)[reply]
  • I am pleased with the WMF response to the past wishlist. Right now I am helping to organize WikiConference North America and I came to this page to see if there was a place to post comments for the next wishlist. This conference is in the first week of October, and I wish that somehow the wishlist concept could be advertised at the conference. I understand that pages might not be set up for this in time, but I wish that there could be. DannyH (WMF) - if you can think of a clever way to receive comments by then, or if someone on the organizing team could be present in San Diego to present on last year and advertise this year, then I think the wishlist concept is something that would be well received in person because it was such an accessible way for so many people to participate in discussions last time. Thanks. Blue Rasberry (talk) 14:11, 10 August 2016 (UTC)[reply]
Oh, that's great! Quiddity is going to be at the conference, and he'll be able to talk about the current wishlist work, and what we're planning for the next survey.
I'm going to put together a more informative and better-looking "coming soon" page on 2016 Community Wishlist Survey, so people can watch that page, and get updates as we get closer to the survey.
About the pre-survey scratchpad idea that several people have asked about: For the 2016 survey, we want people to be engaged more actively during the survey period. We don't want people to just leave a sentence on a page and drift away for three months. We want people with proposals to participate in the discussions during the survey period -- answering questions, clarifying ideas, possibly splitting up big proposals into smaller pieces.
It's been tricky this year on some of the top wishes to figure out exactly what everybody thought they were voting for -- for example, the #17 wish, "Improve SVG rendering", says "Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia." Volunteer developers have tried picking this up at hackathons, but they don't know what the eight to ten bugs are. We want to make sure that doesn't happen with the next survey, and that means we need people to stick around and respond to questions.
To some extent, you're selling your idea to the community, over a period of about six weeks. That's a long time to ask people to pay attention, so we really want to focus that energy during the survey period. Having a four-month "soft opening" from August to November would make it harder for us to get people excited once the survey officially starts.
So -- people should come to the survey in November ready to pitch ideas that they feel really strongly about. If you forget about an idea between now and then, then it's probably not important enough to be in the survey. We want the proposals that are impossible to forget. :) -- DannyH (WMF) (talk) 21:04, 10 August 2016 (UTC)[reply]
Quiddity, may I invite you to submit a presentation proposal at the conference through the online form? Please ping me when you do, and I will support it. I would be grateful if you could incorporate some kind of scheme to solicit ideas and discussion at the conference, particularly if you could find ways to include newcomers to Wikimedia events. To make this conference work, we really would like more people at the conference engaging contributors who are newer. Additionally, if it is not inconvenient, the conference organizers would appreciate any comment you can share after the fact about your experience of using the conference to solicit feedback for your project. Thanks for whatever you can do. This is a great project and I appreciate your bringing it to this event. Blue Rasberry (talk) 15:05, 11 August 2016 (UTC)[reply]
@Bluerasberry: Hi, I'm attending the conference as a volunteer (taking 3 vacation days and everything!), partially because I'm looking forward to an event where I can mostly relax, and meet new people and old friends, and even get some random editing done. (I hadn't explained this to Danny; sorry for the confusion!). I'm also very uncomfortable with speaking before large groups. However, I'll happily talk to anyone informally about the wishlist (and any of my work) in the hallways and during meals, and I'll consider doing a lightning talk.
Sidenote, re: "engaging contributors who are newer" - The Community Tech team is focused on "the needs of active Wikimedia contributors for improved, expert-focused curation and moderation tools". Whereas I think requests/suggestions from newcomers are often essentially "+1s" to an existing feature-request, or are requests for something [a tool/feature/template] that already exists but the newcomer hadn't stumbled upon yet. Any experienced editor can help the newcomer with those kinds of things! I deeply grok the impetus, but the Community Wishlist probably isn't the best venue to direct their feedback to; generally locations like the w:en:WP:Teahouse or Helpdesk are more ideal. HTH, Quiddity (talk) 21:36, 11 August 2016 (UTC)[reply]

2016 proposal phase now open[edit]

Hi,

A reminder to folks watching this page: The 2016 Community Wishlist Survey has now started with the proposal phase. /Johan (WMF) (talk) 00:26, 9 November 2016 (UTC)[reply]

2016 voting now open[edit]

The 2016 Community Wishlist Survey is now open for voting. (: /Johan (WMF) (talk) 18:25, 28 November 2016 (UTC)[reply]

2016 results now in[edit]

You can see the results from the 2016 wishlist survey on 2016 Community Wishlist Survey/Results. /Johan (WMF) (talk) 12:54, 16 December 2016 (UTC)[reply]

2017 Wishlist Survey![edit]

Hey everyone – the 2017 survey is going on right now, and this weekend is the last chance to post a proposal. If you had missed it so far this year, head over to 2017 Community Wishlist Survey to post something. /Johan (WMF) (talk) 01:18, 18 November 2017 (UTC)[reply]

Vote in the 2017 Wishlist[edit]

You can now vote for proposals over at the 2017 Community Wishlist Survey! /Johan (WMF) (talk) 06:23, 28 November 2017 (UTC)[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Community_Wishlist_Survey_2015&oldid=18494585"