Hello, everyone! Please let us know your thoughts related to the 2020 wishlist update. In addition, we’ll begin thinking about the guidelines for this new process, so we want your feedback (on what sorts of processes/rules we may want to consider). Thank you, and we’re very curious to see the wishes in November! --IFried (WMF) (talk) 19:16, 2 October 2019 (UTC)

I can only say I'm disappointed that this year you only take wishes from other projects than Wikipedia. Also, disappointed that from last year survey there are still many wishes not implemented. It means there should be more resources working on these wishes. Stryn (talk) 07:55, 3 October 2019 (UTC)

@Stryn: Thanks for sharing your thoughts. We're hoping that the 2020 format will grant us the time & flexibility to significantly reduce the items in our backlog, so that we can approach the 2021 Wishlist Survey with a cleaner slate. --IFried (WMF) (talk) 16:44, 11 October 2019 (UTC)

I see there is a focus this year on the non-wikipedia projects. However, there will be suggestions that basically are 'global', not specific on wikidata or wikinews. Are those going to be possible, or are those also going on the shelve for (at least) another year.

Just to note, I do strongly disagree with this format. You are here basically ignoring what the larger communities need (or even, what the global community needs). --Dirk BeetstraTC (en: U, T) 07:33, 3 October 2019 (UTC)

I gave some inputs about this question below. Pamputt (talk) 13:37, 5 October 2019 (UTC)

@Beetstra and Pamputt: Thanks for sharing your opinions and feedback. We're currently discussing the potential details of the format as a team, and we'll share what we've come up with soon. --IFried (WMF) (talk) 16:55, 11 October 2019 (UTC)

Good idea to focus on sister projects but this model maybe will be possible: add some free statings for non-Wikipedia wished and add some stansings for Wikipedia. Example: "top 10 wishes will be choosen, half of them must be smaller projects, other can als be general/larger projects". --Wargo (talk) 09:07, 3 October 2019 (UTC)

@Wargo and Beetstra: Thanks! We're excited to focus on sister projects and provide greater support to them as well. Also, we appreciate your suggestions. We're currently discussing the potential guidelines as a team, and we'll share what we've come up with soon. --IFried (WMF) (talk) 16:58, 11 October 2019 (UTC)

As a planned one-time variation from the "usual" process, I think this works. Many of the projects undertaken as part of the 2019 wishlist are quite labour-intensive, and the assurance that work will continue on them while focusing new requests on non-Wikipedia projects seems like a reasonable method of achieving success. There are some quite significant needs on the part of non-Wikipedia projects that should be addressed; the suggestion above that "global" proposals that coincidentally also impact Wikipedias may be a worthwhile inclusion into the list of proposals to be considered, provided there is a definite impact on non-Wikipedias as well.

One has to wonder, however, if some of the issues causing delay are that either the team devoted to the Community Wishlist is too small/does not have the range of knowledge needed to carry out some of the proposals, or if the commitment from other teams to provide support/education/information related to Community Wishlist proposals has wavered as these proposals have driven closer to the heart of the work of some other teams. This may be a question of internal/organizational priority-setting and hierarchy; if Community Wishlist is working on a proposal involving another specialized team, which does not support that wishlist item or believes it will interfere with their work, there is no clearcut solution here. Risker (talk) 18:02, 3 October 2019 (UTC)

@Risker: Thank you for your thoughtful and detailed message. Many of the questions that you posed share parallels with the topics that we've been discussing as a team, including: How can we continue to provide meaningful tools and improvements to the community, even as we take on larger wishes? How can we support a range of communities and needs, including smaller projects and/or projects with no dedicated teams? To that end, we're excited to see what we can learn via this new approach, and we hope to see certain processes or functions with fresh eyes. You're certainly correct that there is no clear-cut solution to these complex questions, but we're optimistic to see what can be unearthed in the year to come. Thank you! --IFried (WMF) (talk) 18:53, 11 October 2019 (UTC)

What about proposals that would affect all Wikimedia projects? Would those still be accepted? --Rschen7754 18:22, 3 October 2019 (UTC)

It is indeed THE question. If we look at the 2019 results, it appears that in the 10 selected proposals, 1 was dedicated to Wikisource and the 9 others were global proposals (not only for Wikipedia). Just to say that if proposals that would affect all Wikimedia projects are allowed, it will probably gives something similar to the past years. The same can be said for 2017, 2016 and 2015. Pamputt (talk) 06:35, 4 October 2019 (UTC)

In one of my considerations one of the points is specifically aimed at the smaller wikifamilies .. though in general the proposal is global. --Dirk BeetstraTC (en: U, T) 17:09, 11 October 2019 (UTC)

See here for current status and links to the various project pages. Risker (talk) 19:13, 3 October 2019 (UTC)

So next to nothing has been done, as usual community wishes get ignored by the ivory tower. They simply don't like to help the communities with their wishes, they only care about unwanted shiny new bling an mainly themselves. Some of the Top10-wishes were really old and well known to everybody in the Wikiverse, at least those, who care about the Wikiverse, obviously not the WMF), yet still absolutely nothing is done about them. Grüße vom Sänger ♫(Reden) 13:59, 25 October 2019 (UTC)

The page says the proposal phase ends on November 11, while Community Tech starts to organize proposals on November 5. The November 11 should have remained from the previous survey, please correct it. —Tacsipacsi (talk) 14:03, 4 October 2019 (UTC)

@Tacsipacsi: I think the CommTech review and organize phase overlaps with the proposal phase on purpose, but I could be wrong. IFried (WMF) would know for sure. Kaldari (talk) 18:27, 4 October 2019 (UTC)

@Kaldari: As far as I remember, this was not the case in previous years (they can review and organize proposals during the proposal phase, of course, but the schedule contained disjoint timeframes). What makes it even more likely to be a mistake is that the proposal phase ended exactly on November 11 last year, while all other dates are different. —Tacsipacsi (talk) 18:54, 4 October 2019 (UTC)

@Tacsipacsi and Kaldari: Hey there! We decided to allocate more time for the review process this year. So, yes, this schedule is intentional. There are two primary reasons why: First, some of the CommTech team members will be attending the Wikimedia Technical Conference (November 12-15). Second, the team wanted more time to review the proposals overall (as compared to last year’s survey). At the same time, we wanted to be conscientious of our timeline and the various priorities that we’re juggling. For this reason, we decided to begin the review stage earlier (which happens to be when the proposal stage is still occurring), and we'll continue until November 19th. Thanks! --IFried (WMF) (talk) 20:00, 4 October 2019 (UTC)

On the one hand is fine, that focus will be on the other projects. But on the other I am afraid, that majority will be for Wikidata and Commons and smaller projects (Wiktionary, Wikisource etc.) will have at the best one proposal in final.
What about to divesificate the results:

It will be top 5 only, not top 10. Another way to avoid that could be to limit to one for each project, so it couldn't be more than one for Wikidata. I am not sure we need that limit anyway. Noé (talk) 14:28, 8 October 2019 (UTC)

@JAn Dudík and Noé: Thanks for sharing your feedback. And, yes, we want to make process inclusive and encouraging for smaller projects (rather than simply creating a wishlist for whichever projects are next in line as the largest projects). Like Noé wrote, we'll be taking 5 new wishes in 2020, but we do appreciate that you shared your vision. --IFried (WMF) (talk) 17:42, 15 October 2019 (UTC)

With my proposal can one project have 0-6 tasks, and should be 5-9 projects.

There should be some minimal limit of votes too, but I believe there will be more good ideas for each project. JAn Dudík (talk) 18:40, 8 October 2019 (UTC)

I actually agree with the decision to make the survey for non-wikipedia this time around. The wikisource task on the top 10 last year was easier than most of the others, and it is reasonable to expect similarly easy tasks from the non-wikipedia wikis. Some of the wikis are different from wikipedia. Just because an task is in an anti-vandalism category does not mean that it benefits all of the projects.

Wikisource´s edit process is very different from wikipedia and the criteria of unwanted edits on wikipedia only scratces the surface on wikisource. On wikisource OCR is an big part of it, and editors fix the OCR errors and use wikicode to make it look the same as the original. For example, modern spelling corrections are welcome on wikipedia, but not wikisource (plus an modern spell checker would modernise the word, which is an no-no). Wikisource also has custom extensions and gadgets not used anywhere else.

Wikidata's and wikipedias difference should be obvious. The edit interface is not even the same and automated systems like ORES have been adjusted for wikidata.

Wikivoyage may look similar on the surface to wikipedia, but it actually uses specific extension settings and gadgets not used anywhere else. An example of this is the ability to use templates to mark hotels and restaurants onto an map.

Wiktionary uses the same titles on any language, as it shows the meaning and grammatical cases of an word in several languages, with the difference between languages being that it is explained in the right language. Wiktionary interwiki links do not, for the most part, use the same extension as the rest of the projects.

Commons has an lot more focus on files than wikipedia has. There is an difference between reviewing files and articles. Also, commons is moving closer to semantics (closer to wikidata) with the development of Structured data.--Snaevar (talk) 16:57, 9 October 2019 (UTC)

@Snaevar: Thank you so much for sharing this feedback! We're happy to hear that you support the idea, and we're also optimistic about the many ways we can support smaller projects. --IFried (WMF) (talk) 17:58, 15 October 2019 (UTC)

Somebody should read and correct general guidelines (which are same for all years), there are parts, which should be reworded according this years specific guidelines.

BTW - will be some announcement on concerned projects? If yes, there should be translations too - unfortunatelly, announcements on smaller project are mostly in english only.
JAn Dudík (talk) 06:11, 18 October 2019 (UTC)

I have changed all the "top 10" instances to to "top 5". Is there anything else we're missing?

Yes we are working on sending out localized announcements soon that will attract participation from those communities. Thanks! MusikAnimal (WMF) (talk) 05:05, 22 October 2019 (UTC)

What about merging your 3 requests into one “Please provide a quality OCR service” wish (or something like that)? A good OCR service really supported by the WMF would solve all issues. Currently OCR is only handled by user gadgets, this is, according to me, the main problem. —Pols12 (talk) 15:01, 25 October 2019 (UTC)

The first one mentioned (Improve OCR extraction from PDFs) deals with something completely different: it is a request to improve extraction of OCR text from an existing OCR layer of PDF documents (some PDF scans obtained from libraries had been equipped with an OCR layer prior to uploading them to Commons or Wikisource), while the other two deal with getting brand new OCR text from scanned documents by our tools. I was afraid that this would not be understood when I was writing the proposal and I evidently did not succeed in wording it clearly...

Oh, sorry, I had misread your proposal. The word “OCR” made me lost. Maybe only speaking about “PDF text” may suffice: this phrase would include PDF text of a LibreOffice-generated PDF document, for example. Is this kind of PDF concerned too? Or only OCRised images PDF? —Pols12 (talk) 11:19, 30 October 2019 (UTC)

Meanwhile I editted the proposal to explain the problem better and also moved it to a more comprehensible name. As for LibreOffice: Unfortunately I cannot tell, as I have absolutely no experience with this :-( --Jan.Kamenicek (talk) 11:46, 30 October 2019 (UTC)

In my humble opinion, it is now really clear. Speaking about LibreOffice, I meant any PDF export generated by a software from a text, e.g. “Download as PDF” tool in sidebar of Wikipedia. Do these generated PDF suffer of the same issue? —Pols12 (talk) 17:31, 30 October 2019 (UTC)

To find it out, I have created a PDF from a Wikipedia article and temporarily uploaded it to Commons, see Sorga Ka Toedjoe.pdf. Then I looked at some previews what it looks like in the page namespace in Wikisource, and the results are good, comparable with the best OCR layers of PDF documents, see for example the the second page of the document. Not surpisingly, what makes problems are captions of pictures, infoboxes and the like, see for example the first page of the same document, but something similar happens with most OCR layers too. To conclude it: this kind of PDF does not suffer with the above described issue. --Jan.Kamenicek (talk) 23:10, 30 October 2019 (UTC)

As for the remaining two: I have requested to create a new tool which would not be dependent on a specific volunteer who is impossible to reach when the tool's maintenance is needed, alongside with some other improvements of the tool, while Snaevar only suggested some specific way of improving the OCR process. Unfortunately, I have almost no knowledge of the process itself, and so I am not able to say, whether the two requests are possible to be merged or not... What does @Snaevar: think about it? --Jan.Kamenicek (talk) 16:58, 25 October 2019 (UTC)

Yes, I meant: whatever the technical solution provided (new OCR software developed by WMF, fork of OCR software maintained by WMF, use of a totally external OCR software working-guaranteed, other solution), what we want is a well-working OCR tool, isn’t it? —Pols12 (talk) 11:19, 30 October 2019 (UTC)

@Jan.Kamenicek: I agree with merging the "New OCR" proposal with the "Improve OCR with wikisource text", although I would like the new tool to cover all tesseract languages, like I mentioned in my comments on the "New OCR" proposal. We would end up with an unified tool then, that would be more reliable in terms of stability and support than the others (the "New OCR" part of the proposal), and would get better and better results with time (the "Improve OCR with wikisource" part).--Snaevar (talk) 16:27, 8 November 2019 (UTC)

Granted, this merge would make you take the decision of using the Tesseract OCR engine, instead of letting the developers decide that. The thing is the WMF nearly always uses open source software. So, that excludes Abby Reader and Adobe. The problem with other free OCR engines is their lack of language support, so they are never really going to replace phetools fully.

In Indic languages specifically Tesseract was trained on an low number of pages with many repetitions. (source: [1]) So it is well trained for specific cases, but others not so much. My proposal will fix that. My proposal also tackles the "generate good quality OCR text" part.

The column issue will be fixed in Tesseract. The problem is explained in [2], and is being worked on.

Since I did make an caveat on your proposal, I am going to sweeten the deal a bit. I am willing to add all remaining non-latin languages which have an wikisource to the proposal, by adding an assistant to help users to add support for those. This assistant will also work for any latin language that may be missing. It will require puntuation, number, character information and digital text (ideally 100-200 A4 pages worth), in the language in question, from the user, and it will pull an wordlist from the text. Should you want it, the proposal of this additional feature is valid until 20:00 UTC0 today, as I need time to add it into the proposal.--Snaevar (talk) 11:43, 11 November 2019 (UTC)

@Snaevar: Thanks for agreeing with merging the proposals. May I ask what exactly you mean by the assistant to help users? I apologize, but I do not understand this very much, can you explain it to me in more detail? --Jan.Kamenicek (talk) 14:54, 11 November 2019 (UTC)

The,"Can I resubmit a proposal from previous surveys?" section says, people may submit some proposals from previous year, but didn't mention the "place". Where should they submit? Thanks in advance.--MASUM THE GREAT (talk) 16:39, 25 October 2019 (UTC)

Hello Ahm masum! You can simply create a new proposal as you would normally, and copy/paste the "Problem", "Who would benefit", etc., but do not copy the old discussion and obviously not the votes :) If you point me to your old proposal I'd be happy to copy it over for you. Best, MusikAnimal (WMF) (talk) 17:56, 25 October 2019 (UTC)

Yes, I believe there was a misunderstanding. Resubmitting old proposals is more than acceptable, but they will have to adhere to this year's format, which unfortunately does not include Commons or other global wishes like yours :( I'm sorry! Next year we'll likely open up to global wishes like this, so you can look forward to that. Apologies again for the confusion! MusikAnimal (WMF) (talk) 18:58, 27 October 2019 (UTC)

Wow! Besides Wikipedia, apparently, the other two projects, Wikisource and Wiktionary, has been receiving more proposals than any other. How would this affect the format of this year's wishlist? George Ho (talk) 05:30, 26 October 2019 (UTC)

It probably means, that the wishes of WikiSource and Wiktionary get ignored this year, like Wikipedia and all projects last year. Nearly nothing has been done to last years wishes by the WMF up to now, as usual they don't care about the communities wishes. Grüße vom Sänger ♫(Reden) 12:28, 26 October 2019 (UTC)

@Sänger Well, they've made a lot of progress on a lot of what new page patrol asked for last year, see here, and still getting lots done all the time. I can't speak much for the other tasks as I haven't been involved with them. When they say 'in progress', they actually have finished or mostly finished more than half the individual tasks. They are taking thier time to make sure that stuff is done right and isn't half-assed; I for one am satisfied with the work they've done so far. — Insertcleverphrasehere(or here) 20:30, 28 October 2019 (UTC)

I remember reading that the Wishlist team had been unable to manage the full wishlist from last year (thus warranting the smaller size for this year (notwithstanding the wishlist focus)) because the wishlist dev team size had been reduced, or that individuals had left and there hadn't been resources to replace them.

@IFried (WMF): - how has the team's size (or number of work days) been changed in the last 18 months?

This isn't a complaint laid at your door - in fact, given the issues about outstanding projects, I think this setup is quite a good way of mitigating issues and extracting some positives, but it is a concern. Nosebagbear (talk) 17:30, 27 October 2019 (UTC)

Hi, @Nosebagbear:, I'm the Engineering Manager for the Community Tech team. I can comment on the resourcing of the team. The Community Tech team is at its largest size of team members (including engineers) since the team's inception. I'm confident that should we have someone leave the team, we would be able to replace them. I don't think we've ever said, at least since I joined, that any sort of status change was due to team resourcing.

That said, in the last couple of wishlists we've taken on larger and larger wishes which necessarily take more time and effort. So, while we've increased the team size, we've also taken on more and more complex work. In some ways, this is good because the wishes we do can be more impactful or simply larger. However, it can mean that we get to fewer wishes in the same time as we might have before. AEzell (WMF) (talk) 21:23, 28 October 2019 (UTC)

In the non-English versions of this page (example: Community_Wishlist_Survey_2020/de), there is a text field and next to it is a blue button with the text "Create a non-Engish wish". The text field is meant for the title of the proposal, but it's empty so it's not clear what it's for or what happens when you click the blue button. In the English version the text field has a grey text "Title of proposal". Could that be added to the non-English version too, or the text above the text field amended to mention that you start the proposal by typing the title into the text field? -kyykaarme (talk) 08:58, 30 October 2019 (UTC)

Done You can now translate the placeholder. —Pols12 (talk) 12:20, 30 October 2019 (UTC)

#1: Indeed somewhere along the way I got rid of the need for the year parameter. I don't think we need to bother writing a script to remove it from all the transclusions, though. It's not hurting anything.

I see, Special:Diff/19501650 is because the translation for "Edit proposal/discussion" is set by Special:Diff/19501662. This will not work because the category pages are not translated, so whatever is passed to the Proposal header template will get shown the same to everyone. Our system of templates, subpages, etc. unfortunately doesn't play nicely with the Translate extension. MusikAnimal (WMF) (talk) 21:23, 3 November 2019 (UTC)

I wish there was a image (.iso or docker or something) which people can download to get the latest copy of any wiki and its currently installed extensions and scripts on their pc. With the difference being that they're a full admin and crat and everything else they can possibly fancy there. Then they can use it to develop extensions and scripts and whatnot. I believe this may increase engagement of more people in development work. But I don't know (a) whether it's better to have QEMU or DOCKER or what else (b) who is the best expert in this to guide me with creating a vanilla debian image and setting a wiki on it which is developer friendly.

Also if I would like to submit this proposal to this survey, then do I add it in each sister project (meaning I add about a dozen of identical proposals) or where do I put it? I can also submit one to Wikispecies and then in the other ones submit a dummy proposal to each of the remaining wikis, then the dummy one would ask to refer to the first one for discussion. --Gryllida 23:15, 4 November 2019 (UTC)

@Gryllida: Unfortunately I don’t think this proposal fits this year’s scope—§ Guidelines, second bullet point disqualifies global wishes, and this one seems to be such. You can create a task for it on Phabricator and wait for someone to do it (or ask at Tech first), or hope that next year’s survey will allow global wishes. (By the way, I’m not sure if it’s feasible at all, even if we mask out sensitive personal data such as email addresses, password hashes or checkuser logs. But please don’t continue discussion about this topic here, go to Phabricator or Tech instead.) —Tacsipacsi (talk) 19:36, 5 November 2019 (UTC)

Thank you for the tip, Tacsipacsi. Gryllida 22:50, 6 November 2019 (UTC)

The page says "Why no global wishes: We spent a lot of time discussing whether we should include global wishes. On the one hand, we genuinely understood the desire for global wishes. On the other hand, we didn't want global wishes to dominate the wishlist, thereby defeating the purpose of supporting smaller projects. We also discussed the possibility of permitting some global wishes. Overall, we decided that, because we're only accepting 5 new wishes this year, we didn't want to limit the already reduced resources available to smaller projects. With that being said, we still plan to address global wishes from last year’s wishlist (e.g., Watchlist Expiry, Section Name in Diff)." However I believe that there are some global wishes which help smaller wikis develop the tools which they need, which are specific to that project. In my view having a framework that makes development easier to get started with has a greater potential than funding of 5 most popular wishes for each year. I raised this topic at "that page", where it is available for discussion. --Gryllida 22:55, 6 November 2019 (UTC)

Well it metters just for voting. We have one proposal in Wikiversity group which can positivelly affect all Wikimedia projects. Juandev (talk) 23:13, 10 November 2019 (UTC)

It's been a long-standing issue throughout the past few surveys. I believe (at least post-proposal phase) that multi-category proposals aren't really a problem. Community Tech has no reservations against the concept, but the bot does :( Allow me to investigate, and if I can get it working I will transclude your proposal under Wikisource on your behalf. Kind regards, MusikAnimal (WMF) (talk) 04:55, 12 November 2019 (UTC)

Why the proposals change weirdly its order on the page. Its hard to track the newones if sometimes the newones are on the bottom, sometimes in the middle. Juandev (talk) 21:41, 10 November 2019 (UTC)

Sorry about that! The automated rotation is there to ensure fair visibility during the voting phase. Obviously this wouldn't apply during the proposal phase, so I will adjust the bot so that this same problem doesn't happen next year. Thanks for raising this issue, MusikAnimal (WMF) (talk) 04:48, 12 November 2019 (UTC)

In the lead of the Wishlist there is written: " we've invited people to write proposals for any features or fixes that they'd like to see..." While I consider it an excellent idea to vote which new features the contributors would welcome and which not, I raise my eyebrow when reading proposals for fixes. An uninformed person could think that if something gets broken, it is always repaired and it is done quickly (within hours or exceptionally days), so that contributors can feel comfortable and nothing slows their contributions down. However, Wikimedia reality is different, people wait for years until some bugs are fixed, and I understand similar proposals in the annual Wishlists as the last desperate attempts to draw attention to problems which have not been solved and are not being solved. The fact that community votes which of the bugs will be solved and which will have to wait for a couple more years shows the seriousness of the situation in all its nudity. Of course, almost all of these attempts are doomed to be fruitless given the small number of the chosen ones, but what else can one do? Is not the ineffectual Phabricator the biggest problem that needs to be solved? --Jan.Kamenicek (talk) 15:42, 11 November 2019 (UTC)

Hello. Is it possible to activate the Translation Module on the proposals ? In fr.wikisource community, we are asked to translate the Wikisource proposals, in order to make them more understandable. Thank you ! --Consulnico (talk) 10:14, 15 November 2019 (UTC)

You can copy text to below or above and replace with translation, so they will be in two languages on one proposal page. --Wargo (talk) 20:47, 16 November 2019 (UTC)

Yes I can, but it is not efficient. The Translation Module would be far more efficient for this purpose. --Consulnico (talk) 09:26, 18 November 2019 (UTC)

Some time I wonder about my capacity to make lot of not very necessary thinks forgetting the most important ones... I've completely forgotten this task on phabricator. That's already pending for a while and nothing seems moving in the area... However, a text-to-speach engine could be a real plus for the wikimedia user experience. That's could for instance transform a wikiversity course close to the Mooc format, or make possible for the traveler to hear information about his next destination with his eyes closed in a night-time public transport, or even transform wikinew in radio diary or wikisource and wikibook in audio book. Damn it, I feel bad. Why did I forget that wish!? Is it too late, I guess? Lionel Scheepmans✉ ContactFrench native speaker, sorry for my dysorthography 01:37, 25 November 2019 (UTC)

It seems global wish but this year only one wish-for-one-project. --Wargo (talk) 19:23, 25 November 2019 (UTC)

Hi guys! I have been editing for the past ten years on the Afrikaans Community. HMTL and softeware is not one of my strengths. I have however attended two Wikimania's and a chapter meeting in Berlin. All of these have a similar pattern: there are a lot of high level, very technical discussions and presentations with a lot of stuff being demonstrated. Yet, not once did I feel that I, as a simple end user right down of the at the bottom of the Wikipedia ladder got anything that make creating and maintaining articles easier. In fact, it becomes more and more difficult to teach new users to get going with articles. Do you really know what our requirements are? Food for thought... Regards. Oesjaar (talk) 15:59, 25 November 2019 (UTC)