Community Wishlist Survey 2015

Add links
From Meta, a Wikimedia project coordination wiki
This is an archived version of this page, as edited by Ryan Kaldari (WMF) (talk | contribs) at 22:39, 9 November 2015 (→‎Improve SVG rendering: hatting examples table per Danny). It may differ significantly from the current version.
The Community Wishlist Survey 2020 is over...

Total: 72 proposals, 423 contributors, 1749 support votes

Random proposal

Welcome to the 2015 Community Wishlist Survey! We're inviting contributors from all Wikimedia projects to submit proposals for what they would like the Community Tech team to work on. After two weeks of collecting proposals, we'll ask you to vote on the proposals that you're most interested in. The proposals with the highest votes will become the team's top priority backlog to investigate and address.

See the Community Wishlist Survey description for more information about the survey process.

Note: This is the proposals phase of the survey; we're looking for proposals and endorsements. Feel free to discuss and show approval, but the actual voting phase will be Nov 30-Dec 14.

Instructions for submitting a proposal

Proposals should be discrete, well-defined features and fixes that will directly benefit the core community, in line with the scope of the Community Tech team. Proposals that are outside of that scope may be referred to other development teams or declined. Feel free to suggest big changes or small, as long as it addresses a specific need.

Participants may submit up to 3 proposals each. Proposals may be submitted in any language. Ideally your proposal should concisely address the following points:

  • What is the problem you want to solve?
  • Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
  • How is this problem being handled now?
  • What are the proposed solutions? (if there are any ideas)

Endorsements: Proposals must be endorsed by at least one other user in order to be eligible for the voting phase, using the {{endorsement}} template. Similar proposals may be combined to reduce duplication, in which case each duplicate should count as an endorsement. Multiple endorsements aren't necessary and won't affect the proposal's eligibility, but feel free to add comments on the proposals as we go along.

Participation requirements: In order to submit a proposal or endorse an existing proposal, a user must have at least 100 edits on any project or be an active Tool Labs developer. Anyone can participate in discussions, including anonymous IP users. Cross-wiki edit counts can be verified at Special:CentralAuth.

Language: We would like to include people from as many projects as we can, in many languages. This will require a lot of translation help. If you can help to translate proposals into English, we really appreciate it. Also, if we haven't posted an invitation to the survey on a village pump or wiki discussion page in your language, we'd like to! See the invitation page to help with translation. Thank you!

Submit your proposal

Submit an idea

Example proposal

Right now, there is no efficient way to find all the articles on Wikipedia that have blurry photographs, so the blurry photograph patrollers have to review every article by hand to find and replace them. It would be great if a bot could be written to analyze all the photographs on Wikipedia and create a list of articles that have blurry photographs. This would benefit the patrollers on all the Wikipedias by making their job easier and would also benefit readers who wouldn't have to see so many bad photos. --SharpPhotoEnthusiast632 (talk) 13:19, 20 November 2015 (UTC)

Endorsed Endorsed - I hate seeing blurry photographs. --AnotherGuy (talk) 15:37, 21 November 2015 (UTC)

Improve the "copy and paste detection" bot

Currently we have a bot that analysis "all" new edits to en WP for copyright concerns. The output is here. And there is the potential for it to work in a number of other languages.

Problems is that it is not up as reliably as it should be. Also presentation of the concerns could be improved. Would love to see the output turned into an extension and formatted similar to the en:wp:Special:NewPagesFeed

Currently the output is sort-able by WikiProject. It would be nice to create WikiProject specific modules to go on individual project pages.

Doc James (talk · contribs · email) 03:45, 4 November 2015 (UTC)[reply]

Endorsed Endorsed --Tobias1984 (talk) 19:12, 7 November 2015 (UTC)[reply]

Migrate dead links to Wayback Machine

See also: mw:Archived Pages.

Most external links have am average lifespan of about 7 years before they go dead. As Wikipedia ages, the dead external links problem grows exponentially. Internet Archive has partnered with Wikipedia to ensure all new external links have a Wayback cache. However there has been no formal process of adding the Wayback links to Wikipedia (via the cite web |archiveurl=.. feature for example). There have been attempts to automate with various bots (see en:WP:Link rot) but the coding is non-trivial and multiple volunteer efforts have stalled. Likely what will be required is a team of programmers working full-time, something that is beyond the scope of a few volunteers working spare time. It's the sort of coding work that MediaWiki could sponsor and make a big difference in the quality of content, impacting every article. -- Green Cardamom (talk) 19:27, 7 November 2015 (UTC)[reply]

Endorsed Endorsed Much needed and certainly very important for smaller Wikipedias as well. Jopparn (talk) 09:12, 8 November 2015 (UTC)[reply]
Endorsed Endorsed We have made significant progress with en:User:Cyberbot II adding links to archiveurls, but there needs to be a good technical way to store. Talked with @Jdforrester (WMF): about building it into citoid at WikiCon USA. Internet archive was there, and expressed an interest in pushing their API's to the limit, to fix the 404 and other errors on Wikipedia, Sadads (talk) 10:11, 8 November 2015 (UTC)[reply]
Endorsed Endorsed Agree that this is very much needed. ONUnicorn (talk) 13:47, 8 November 2015 (UTC)[reply]
Endorsed Endorsed Much globally needed, volunteer efforts shouldn't be the only way for an important feature like this. --AlessioMela (talk) 21:06, 8 November 2015 (UTC)[reply]

Watchlist priority options

Many veteran Wikipedians have watchlists that span thousands of articles, completely beyond the ability to effectively manage. If said Wikipedian can't edit for a certain period (say, a week), just going over the changes in the watchlist can take hours and become a chore that editors simply avoid, at the possible expense of missing vandalism and/or edits that they need to see.

There are external tools for creating and organizing watchlists in different ways, but I'd like to see many of those features built-in as part of MediaWiki. One important addition should be a tag for 'high-priority' articles, similar to how GMail has a tag for 'important' e-mail. While having multiple watchlists would support such functionality indirectly, it would be great to be able to see articles marked as 'important' inside the existing watchlist, and be able to filter them like one can now hide/show own edits, hide/show bot edits, etc.

—Ynhockey (talk) 20:49, 7 November 2015 (UTC)[reply]

  • Support Support as this is a collection of rather annoying shortcomings in core MediaWiki. All editors of all MediaWiki installations should benefit from this, so Oppose Oppose if it is implemented as an extension, gadget or any WMF specific means. MER-C (talk) 12:44, 8 November 2015 (UTC)[reply]

Improve MediaWiki's blocking tools

Our blocking tools suck. It is a trivial matter to defeat blocks, and any vandal worth his salt can do it in his sleep. (User:Philippe). Anyone who works a sockpuppet investigation page or is a victim of repeated on-wiki harassment can attest to this. Block evasion doesn't have to be deliberate -- in some parts of the world, users can be assigned a different IP address by their ISP for every edit they make. We effectively have no measures against these users.

The aim here is threefold -- to make it more difficult to evade blocks, make it easier for us to identify and deal with potential sockpuppets as soon as possible-- ideally before they start editing -- and keep collateral damage at a minimum. This proposal has multiple facets:

  • Look at other forum/blog/wiki software (e.g. Wordpress, vBulletin) and determine which blocking tools can be feasibly integrated into MediaWiki (not as an extension) subject to the constraints in our privacy policy. Implement them.
  • Implement the existing tickets:
  • Block by device ID (needs check with WMF Legal first)
  • Any other suggestions from the community that will help tackle this problem.

Improved blocking tools may be assigned to the Checkuser group initially to get a feel for how much collateral damage they cause. This will ideally reduce the burden of cleaning up after spammers, vandals and long term abusers, reduce the amount of on-wiki harassment of the type referred to in the diff above and will benefit all good faith editors of any MediaWiki installation. MER-C (talk) 12:06, 8 November 2015 (UTC)[reply]

Add a user watchlist

Tracked in Phabricator:
Task T2470

Allow editors to "watch this user" by adding a tab or link on user (talk) pages, contributions, history, Special:Block and other appropriate places, and a separate user-watchlist special page which lists the latest contributions from users on the list.

  • As an admin, I want to be able to check on potentially problematic editors at some time in the future.
  • As an experienced user, I want to follow each step of a newbie I'm coaching, to fix their edits, assist in their discussions, provide guidance in general, without having to watchlist all the pages they may edit, so that all my time is spent helping them
  • As a wiki trainer with dozens people to follow, I want to have a page where to have an overview of their complete activity, controlled by a "central" list of usernames which I can just edit/past in a single place. I can then act on specific edits/pages/users or just know what's going on overall.

Limit to admins only if necessary to mitigate stalking concerns. I currently use something I hacked up myself, but this really needs to be in core MediaWiki. MER-C (talk) 12:51, 8 November 2015 (UTC)[reply]

For simple wiki training groups, there is toollabs:magnustools/herding_sheep.php. Nemo 15:00, 8 November 2015 (UTC)[reply]

Add a Category watchlist

Tracked in Phabricator:
Task T9148

Add a category watchlist feature, that lists all changes, additions to, and removals from a category. En-Wiki has HUGE maintenance backlogs dating back to 2006 or earlier in categories like Articles lacking sources. I don't think those backlogs would be as bad if we could watchlist categories and know when an article was added to them. Likewise, some articles have a significant overlap, and if interested editors could watchlist categories and see when new articles were added to categories it would help avoid unnecessary duplication of content. ONUnicorn (talk) 14:11, 8 November 2015 (UTC)[reply]

  • This is currently being worked on right now by the German TCB Team and will be made available in the coming months. See the linked ticket for details. I Support Support this, by the way, if Community Tech can help get this out the door faster. MER-C (talk) 14:19, 8 November 2015 (UTC)[reply]

Create a bot to show changes in articles for each WikiProject.

  • Problem: I'm working on articles about gastropods (= snails), We already have more than 30,000 articles in the Wikipedia:WikiProject Gastropods. There is already a bot for new articles (en:User:AlexNewArtBot/GastropodsSearchResult), but not for changes made in existing articles. This makes it quasi impossible to track those changes and remove any possible vandalism. And this goes for all other WikiProjects.
  • This would benefit all users.
  • Proposed solution: creation of a bot for each WikiProject, tracking changes in each WikiProject. Articles in each WikiProject are easy to identify since they have a dedicated template on their talk page. JoJan (talk) 14:54, 8 November 2015 (UTC)[reply]

Watchlist timed expiry

Tracked in Phabricator:
Task T100508

I would like to be able to set an expiry time for watchlist items, of say one week or one month. There are many pages that I do maintenance on or repair vandalism that I would like to watch for a brief period of time, but have no long term interest in. The UI I envisage would just have additional tick boxes: watch this page indefinitely, watch for one week; watch for one month. Derek Andrews (talk) 23:49, 8 November 2015 (UTC)[reply]

Flag SPA and new user accounts

I think it would be useful if Single Purpose Accounts and new user edits were flagged somehow in page histories and reports such as Recent Changes. These are often sources of problematic edits, so it would help in identifying such edits. Additionally this information is useful in deciding how to respond to problems and it would thus save having to check user contributions. Would have to decide how to define such accounts. Maybe a SPA is one with more than 80% or mainspace edits on one page, and new users are those with less than 20 mainspace edits, but maybe there are stats available that might give a better understanding of how to set this criteria. Derek Andrews (talk) 00:08, 9 November 2015 (UTC)[reply]

As regards new users, I believe this can be done by setting edit filters to tag edits by users with few edits. No comment with regard to SPAs. BethNaught (talk) 18:21, 9 November 2015 (UTC)[reply]

Text-to-speech for phonetically spelled words

I realize this may be a bit out of scope but I wanted to throw it out there...

It would be very useful to have some mechanism that would generate a sound file from phonetically spelled words, at least in English. Right now if one clicks on a phonetically spelled word (e.g. one tagged as a IPAc-en inline template), one is directed to a pronunciation key. It would be nice if wikimedia created some sort of function that would also sound out the word say in an .ogg file. Wikiliki (talk) 17:30, 9 November 2015 (UTC)[reply]

Improve SVG rendering

What is the problem it would solve?
de:Kraft: Third pic has bug described by task T7792

SVG is an important file format for graphics on Wikipedia and is used in thousands of science articles. And this also the underlying software libRSVG has many problems with rendering SVG even the article about force in german (de:Kraft) is affected.

The issue arises since libRSVG was programmed by the Gnome Project to render scalabe icons for their desktop environment. Graphics that contain text was not goal and activities around libRSVG are limited to maintenance today. Because of that important features required for usage inside Wikipedia are buggy or missing. Some bug reports and feature requests by our community are undone since nearly ten years. A test of my own showed that required work often takes only few days (see task T7792).

SVG is important to Wikipedia but without our intervention the underlying software stays error prone.

Another big example...
File:GTAW broken.svg: Buggy since ten years!!!

The file on the right is used by en:Gas tungsten arc welding and in many more languages and even translated. It provoked bug described by task T97758. Due to its long endurance on Wikipidia it has been shown to our readers many million times. (A workaround has been applied to render it correctly recently.)

Further...

To get an overview about the importance of a file format some statistic is useful. Based on database dump dewiki-20150302-pages-articles.xml.bz2 of german language Wikipedia the following estimation can be done. (Only short evaluation about systematic errors has been done.)

  • SVG: 56k
  • PNG: 92k (similar scope as SVG)
  • JPG: 1104k (mostly pictures)
  • GIF: 10k (similar scope as SVG)

Results have been gained with Linux tool en:grep. To change to another file format adapt the following command line call.

date && grep -o -E "(gif|GIF)\|(thumb|mini)" ./dewiki-latest-pages-articles.xml | wc -w && date

(Only counts images that are embedded as thumb preview and not e. g. all the small flags in sport statistics.)

Which users would benefit?

Everybody who is researching scientific or technical information on Wikipedia of any language will benefit. SVG is the preferred file format for high quality science graphics.

It will increase participation because less errors in SVG rendering removes pitfalls for authors without experience in the limitations of libRSVG. As consequence less distraction is created and new authors keep contributing.

This also increases quality because less errors in SVG renderer switches focus from workarounds to content. SVG simplifies re-usage and translation of content and high quality graphics can be share across languages. Thus improving and promoting SVG pushes quality.

How is this problem being handled now?

The SVG renderer libRSVG is part of the Gnome Project. Although it is not in the focus of the Gnome community. The Maintainer of libRSVG is Federico Mena Quintero, employed by Red Hat as programmer for the Gnome Project. But he maintains libRSVG in his spare time.

And some examples...
The following discussion has been closed. Please do not modify it.
Bug task T65703

patch needs update

task T7792

patch needs update

task T65236

Patch needs review

task T55899

Patch needs review

task T43426
Bad
File:Fluoxetine 2.svg
 TODO Empty sheet
Good
File:Fluoxetine 2.png
 TODO
What are the proposed solutions? (if there are any ideas)

Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia. Fixing only a few simple bugs would reduce the pain greatly. I expect this to require four weeks of work for fixing bugs, test them and manage software release.
-Menner (talk) 20:04, 9 November 2015 (UTC) I'll also support selecting bugs, mastering libRSVG code and software release.[reply]

Discussion

@MER-C:I haven't completed with my wishlist yet. Here is a list of bugs. Half of them is not a libRSVG problem some are corner cases. Most of the bug reports contain a link to a Gnome Bugs.
Yes it shouldn't take long to update patches. Creating patches also doesn't take long. I've made five easy patches in five days but thoroughly releasing also takes time... and on the long term it is WMFs responsability to maintain libRSVG.
In task T112421 it says libRSVG 2.40.2 is in use. libRSVG 2.40.11 is released currently but I don't know if its still compatibly with Ubuntu 12.10 LTE used by WMF.
--Menner (talk) 21:03, 9 November 2015 (UTC)[reply]
Here's a bunch of tickets that will be closed when updating to the latest version. Community Tech can't help with system operations, unfortunately, and I don't think the WMF should be the maintainers of this software. See if you can ask for commit access -- I fear patches submitted by Community Tech will be swallowed by Bugzilla. MER-C (talk) 21:31, 9 November 2015 (UTC)[reply]
Federico is quite open to our interests although he's short on time. I haven't talked to him recently and he is difficult to grasp. He accepted two of my patches but then omitted the next three without comment. I don't have enough time to push them currently and I see WMF in the responsebility to go on. -- Menner (talk) 22:00, 9 November 2015 (UTC)[reply]
The table with examples is going off the side of the page (at least on my screen). This makes scrolling up and down the page awkward. Is it possible to move that to another page, and link to it? DannyH (WMF) (talk) 22:31, 9 November 2015 (UTC)[reply]
@Menner: These are probably not bugs that the Community Tech team could address directly. However, if it is identified as a high priority by the community, we could help investigate the problems and flag them to other teams (or outside developers). As MER-C mentioned, the Ops team is responsible for our SVG rendering on the production wikis, but maybe there are some solutions that haven't been considered yet. For example, perhaps the WMF could hire a contractor from the GNOME community to work on librsvg for Ops. (Also, I'm afraid you can't endorse your own proposal. Sorry if that's confusing.) Ryan Kaldari (WMF) (talk) 22:36, 9 November 2015 (UTC)[reply]

Automatic search for similar items in Wikidata

In small Wikipedias, where our task force is reduced, we have lots of pages (mainly subtemplates and categories) that are not linked to items in Wikidata. Some of this items (for example, automatic taxonomy subtemplates) can be found in different languages but it's a very hard work to link by hand all of them. As most of them follow the same structure, and many of them have even the same name, maybe a bot could suggest links. -Theklan (talk) 22:16, 9 November 2015 (UTC)[reply]

Inserting templates in PDF and Books

Since... well, don't know since when, books and PDFs are not rendering information inside templates. As lots of information is inside templates (also happens with tables) all of this is not rendered when you download the file in PDF. -Theklan (talk) 22:18, 9 November 2015 (UTC)[reply]

Make it easy to build infoboxes that display information from wikidata

Currently, there is no well-established system across different wikipedias that would help editors to build infoboxes (there is no established Template:Infobox across different wikipedias).

Building an infobox that displays information from wikidata is even more difficult: Building a nice infobox that displays information from wikidata requires modules written in Lua (without that, it is impossible to make wikilinks work properly). It would be nice to have one standard Lua module for this purpose, maintained and stored in one central place (e. g. on meta), without the need for each and every wikipedia to copy this module over and continue to maintain the copy.

Both editors and readers would benefit from a solution. Furthermore, a solution would promote Wikidata, because it would be much easier to use information present on Wikidata on all wikipedias.

Proposed solution: Implement both A and B:

A. Devise a Template:Infobox that is easy to use and that is maintained in a central place.

B. (Perhaps a bit easier than A.) Write a Lua module that formats content from Wikidata properly (e. g. in a Wikipedia article about a city, create a formatted list of the sister cities (cf. d:Property:P190), where each list element is a link to the article about the sister city or, if this wikipedia does not yet have an article about a particular sister city, a link to the Wikidata item about this sister city). Provide this Lua module in a central place where every wikipedia can directly use it.

--UV (talk) 22:36, 9 November 2015 (UTC)[reply]

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