Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Archive

< Community Wishlist Survey 2016

Limit Adminship In Time

edit
  • Problem: Especially in small wikis with a small community, admins may tend to rule a wiki. There may be inactive admins which support the opinions of active admins without working (gardening, helping new authors and so on) in the project itself.
  • Who would benefit: The writing and gardening part of the community.
  • Proposed solution: Lets say a period is 2 years. An elected admin loses its adminship after one period, and may gain its adminship after re-election one periods later again. So there is always one period in between, where a special person is just a normal community member without special rights.
  • More comments: This proposal is not perfect as there can be "ruling groups", "Sockpuppets" and so on.
  • Phabricator tickets:
  • Proposer: Qwertz84 (talk) 10:03, 15 November 2016 (UTC)[reply]

Community discussion

  • Hi Qwertz84, I don't really see that the technical wishlist has the authority to decide on adminship terms for the community – this is mainly a place for the communities to decide what the Community Tech team should work on (but also to highlight proposals for other developers), and the Community Tech team can't enforce admin terms. If we ever tried, we'd find our heads on spikes. (: As it works now, this is up to every single community – for example, Swedish Wikipedia has reelections every year (but without forcing admins to take a break). This is more of Requests for comment material, or if we're to be realistic, for discussions on the individual wikis.
(Being a Swedish Wikipedian myself, I'll have to privately agree that some sort of reelections is working fine for us. But this probably works better on smaller wikis than the largest ones.) /Johan (WMF) (talk) 10:17, 15 November 2016 (UTC)[reply]
  • What would be technical issue is to assgin user rights with an expiry. This would mean that in a small wiki, they would be technically able to appioint someone as an admin for 2 years, and it would automatically expire without any human intervention. עוד מישהו Od Mishehu 12:34, 15 November 2016 (UTC)[reply]
True. That would mean the technical part of this is basically the same suggestion as Stryn suggested below this one? /Johan (WMF) (talk) 14:54, 15 November 2016 (UTC)[reply]
Oh, well I'm sure I didn't read what Od Mishehu said until now. :O I've been thinking about this long time already. --Stryn (talk) 15:01, 15 November 2016 (UTC)[reply]
  • I'll repeat here the standard argument against this, which is that admins need to block and delete, and make enemies in the process. Re-RfAs are likely to be visited by such characters, and it would take extreme scrutiny from everyone else to uncover false evidence, selective quoting, etc. and allow the candidate to appear in their true light. It sounds to me like you're discussing a problem that you encountered on one specific local wiki, and rather than solving the problem locally, you're proposing to also force your unproven solution on everyone else. Samsara (talk) 18:40, 15 November 2016 (UTC)[reply]

Hi Qwertz84, your proposal is really a policy change, rather than a technical project. I've moved it to the archive. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:26, 21 November 2016 (UTC)[reply]

Meta Arbitration

edit
  • Problem: In many projects there are conflicts that are not solved.
  • Who would benefit: Small and medium-sized Wikiprojects.
  • Proposed solution: To create a Meta Arbitration.
  • Phabricator tickets:
  • Proposer: Hayordi (talk) 21:05, 20 November 2016 (UTC)[reply]

Community discussion

  • Hayordi: Is this something that needs technical development? If it's just an organizational structure, I think it's better handled by the Meta community than the Community Tech team. (: Maybe this should at Requests for Comment instead? Or did you have technical development in mind? /Johan (WMF) (talk) 11:19, 21 November 2016 (UTC)[reply]
  • Dear Johan (WMF), the stewards say they can't solve conflicts in projects. This is known in the small and medium-sized projects and, therefore, where laws don't always work. Need to find technical mechanisms to enable users to solve their problems. For example, to European States, there is the European court, and if the local courts do not work, you can go to the European court. And wiki projects, this is not possible, if the laws do not work at the local level, then what to do? Project Meta is not possible to resolve the issues, as the stewards this is not possible. Hayordi (talk) 12:30, 21 November 2016 (UTC)[reply]

Hi Hayordi, This proposal is out of scope for this survey—it's really a policy/community change, not a technical project. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:29, 21 November 2016 (UTC)[reply]

Deactivate old skins, old gadget, old tools // Integrate the most used/useful gadgets and tools

edit
  • Problem: I believe WMF and devs have difficulties to manage the high personnalize interfaces. If we want to facilitate the work of the devs. A way for this, is to archive, suppress or disactivate the old/useless skin, gadgets and tools. Another way is to integrate by default the more used gadget and tools.

There are around 70 gadgets on wp:en and on wp:fr. I don't know the most majority of the gadget of wp:fr (my main wiki). There so many gadget so many new contributors just don't want to test each gadget for see if there are one, two or three gadgets which can be useful for them... I have never checked the gadgets on wp:en or wp:de or wp:es or other wikipedia for see, if they are good idea which can be deploy on my main wiki.

The more archetypal example of gadget which should be integrated as default feature is surely the "merge" gadget on wikidata. Without this gadget no-one can't do a merge... It's like we need a gadget to rename a page on wikipedia...

It's the same problematic on Wikimedia Tool Labs. To many tools. I never checked the majority of them. But some are very useful.

  • Who would benefit: Everyones
  • Proposed solution: Like the title : "Desactivate old skins, old gadget, old tools // Integrate the most used/useful gadgets and tools"

WMF could show to the communities how many people use each gadget, like the beta features. WMF could encourage the communities to clean their gadget list.

Wikipedia should not allow contributors to use "Cologne Blue" or "Modern" skin. Useless skin. Simple solution.

And one day, the WMF should encourage veteran contributors to switch to monobook to vector. Vector is the main interface since 6 years... There are 2 possibilies : 1) A new skin will be developed (It isn't the case) => So monobook will be more and more obsolete. Or Vector will be maintain for long times the main => So monobook will be more and more obsolete.

Community discussion

I don't understand your argument against keeping alternative skins. Can you please clarify? Legoktm (talk) 04:02, 10 November 2016 (UTC)[reply]

I,personally, like the Monobook skin. What's wrong with that? עוד מישהו Od Mishehu 12:09, 10 November 2016 (UTC)[reply]
Alternatives skins need work for maintien them. Work by the WMF and work by volunteer devs for adapt and maintain gadgets and similars stuffs. Work to maintain "help pages" for the differents skins or to answer to question when the help page isn't maintain. Efforts by the entire communities to understand the differents skins. And thoses efforts are efforts which isn't to invest on new feature like Editor visual or wikidata.
When your core communities doesn't use the main skin since 6 years, how do you do to push features also disturbing like the Editor visual / Wikidata / etc ?
If you want I more specific example when I ask the french community for change the design of the french main page 1 year ago (I try to push for that change and I give up for many reason, included this one), I remember a veteran/core contributor said me very directly that the design isn't good because it was adapted for vector skin, and that he doesn't like vector and disagreed with all things which look like or be adapted to vector...
When the core community use a old skin and this core community / outdated community fight against new design and new stuff. And the wikimedian communities often fight for that reason. (A massive conflit of 1 year is (or maybe) just over on wp:fr about wikidata). And one reason to that is new stuff isn't homogeneous with skin like monobook. For you it is normal and that situation have vocation to be preserved unlimited ?
I don't understand what it's surprising to said that monobook will be one day not maintain, like the maintain of Window XP is over. --Nouill (talk) 13:16, 10 November 2016 (UTC)[reply]
Regarding "could show to the communities how many people use each gadget", Special:GadgetUsage already exists? --AKlapper (WMF) (talk) 14:25, 10 November 2016 (UTC)[reply]

This proposal seems to be based on an unproven premise: that developers somehow are overtaxed in maintaining the existing skins and gadgets. If this were actually the case, the developers would likely raise the issue themselves. Anomie (talk) 15:53, 11 November 2016 (UTC)[reply]

Proof :


I am also enthusiastically in the Monobook camp, and I'm probably also using old tools that blissfully still work. If it's not broken, don't deliberately destroy it? Samsara (talk) 20:49, 12 November 2016 (UTC)[reply]

certainly agree on that one--I cannot see how it would interfere with anyone .DGG (talk) 08:47, 20 November 2016 (UTC)[reply]
  • @Nouill: The first part of this proposal has already been done. See Special:GadgetUsage. The second part is outside the scope of this survey: "Proposals that call for removing or disabling a feature that a WMF product team has worked on are outside of Community Tech's possible scope, and won't be carried over to the voting phase."[1] As far as deprecating unused gadgets, I think that would be best to leave up to each wiki community to handle. Ryan Kaldari (WMF) (talk) 20:53, 21 November 2016 (UTC)[reply]
    • We've archived this proposal for now, but I think if you wanted to refocus it on "Integrate the most used/useful gadgets and tools into MediaWiki", that might be a workable proposal. It would also help if you specified exactly which gadgets should be integrated. Ryan Kaldari (WMF) (talk) 20:56, 21 November 2016 (UTC)[reply]

Reasons for archiving proposal

This request was archived because the Community Tech team does not feel that it contains a specific request that we could take action on if it was voted into the top 10 by the community. Reviewing and removing little used gadgets is something that is under the control of each on-wiki community. The data provided by Special:GadgetUsage on each wiki can be used to help inform those discussions. Removal of skins is also explicitly out of scope for Community Tech, but could be done on a wiki by wiki basis based on local community consensus.

The problem of discovering which gadgets and tools are useful for a particular on-wiki workflow is certainly real. Ultimately however this is a social and communications problem rather than a technical problem. The Tool Labs support project is trying to work with Tool Labs developers to help them make more stable and long term reliable tools. Towards that end there is an active RfC vote to establish clear policies for tool ownership transfer. Future projects will focus on making it easier to describe what a tool does and on making those descriptions easier to search and organize. --BDavis (WMF) (talk) 20:58, 21 November 2016 (UTC)[reply]

Free Trial of Bots

edit
  • Problem: Bots
  • Who would benefit: anybody who doesn't know how to use them
  • Proposed solution: Allow a trial period for people to have a go at using bots, say for 5 articles, before going through the whole permission thing
  • More comments: I'm an old fart, better at using pen and ink than computers. I can think about possible uses for bots, but am uncertain how to use them. The current rule, as I understand it, is you have to have permission to use a bot; but I don't know if I could use one if I had permission. It would be embarrassing to ask, before knowing if you can use it! I'd like to have a go before asking or promising.
  • Phabricator tickets:
  • Proposer: AlwynapHuw (talk) 02:29, 16 November 2016 (UTC)[reply]

Community discussion

  • @AlwynapHuw: Thanks for your proposal. Could you please edit your proposal by providing the default sections describing "Problem", "Who would benefit", and "Proposed solution" so your proposal has the same structure as others? This would allow everybody to understand better which issues you are facing, and what exactly is being proposed. When it comes to policies and permissions, I am afraid that this is up to each community to come up with social "rules" (see for example w:Wikipedia:Bot policy, Bot policy, or wikidata:Wikidata:Bots), so this proposal might be out of scope as per Community Tech#Scope. phab:T134495 and phab:T149312 might also be slightly related here. --AKlapper (WMF) (talk) 10:52, 16 November 2016 (UTC)[reply]
  • I note we have test.wikipedia.org for experimentation (and it doesn't require permissions). —TheDJ (talk • contribs) 12:26, 16 November 2016 (UTC)[reply]
  • Generally it's fine to test bots in your own user space, maybe even in Wikipedia: project space, but you need to ask for permission to run them on articles (in mainspace). I think "old farts, better at using pen and ink than computers" have a steep learning curve here. A lot of editors are curious about bots and how they work. I suggest that a "bots for beginners" demonstration of the basics, showing how a bot is set up and showing one in action (console output) would make a nice Wikimania presentation. A Community Tech member might make such a presentation. If I make it to Montreal, maybe I could show my bots in action. They run right on my Windows 7 desktop, and I recently set up my Windows 10 laptop to run them as well, if needed for backup should my desktop ever unexpectedly die. I could also demo my bot that runs AutoWikiBrowser, as that's much easier to do for a novice without programming experience. Wbm1058 (talk) 14:01, 16 November 2016 (UTC)[reply]
  • Captain Obvious here. Wouldn't it be easier to have a replica of each* wiki (aka sandbox) specifically for bot testing? I imagine it would be a slightly out-of-date version that would also re-play a dataset of new pages and edits, i.e. there would be actual simulated activity so that page patrolling etc. could be tested. And there'd be no harm done to any "real" data. *as applicable Samsara (talk) 05:00, 17 November 2016 (UTC)[reply]
  • This could be a simple change to BOTPOL on the appropriate wiki. Certainly on en:wp you could make 5 automation-assisted changes from your main account without breaking any rules. Automation assisted means that you are still approving each edit separately. Rich Farmbrough 20:38 17 November 2016 (GMT).
  • This is purely a community issue, many projects already allow for this, some specifically do not. This should be left to the communities to decide. — xaosflux Talk 12:38, 19 November 2016 (UTC)[reply]

@AlwynapHuw: As discussed above, this proposal is more of a community issue than a technical one, so it doesn't fit into this survey. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 20:46, 21 November 2016 (UTC)[reply]

Reasons for archiving proposal

There are several existing places where a new bot author can practice using their bot:

  • Beta cluster wikis are available for use by anyone. Bot edits are not blocked for normal accounts created on the beta wikis. Getting elevated rights for testing is generally as easy as making a request in the #wikimedia-relengconnect irc channel.
  • Test wiki and test2 wiki are similarly available to all Wikimedians for testing purposes. The rights approval process on these wikis is very liberal.
  • MediaWiki-Vagrant provides a fully self-contained wiki environment that can be used for local development on a laptop or desktop computer.

--BDavis (WMF) (talk) 21:09, 21 November 2016 (UTC)[reply]

Graphic Images: Allow upload of the master files used to create them

edit
  • Problem: Graphic images on Wikimedia are created with a range of software programs. Without access to the original files, no image uploaded to Wikimedia can be edited or improved by others.
  • Who would benefit: All image editors with access to the relevant software, and all image users
  • Proposed solution: Provide users of the upload wizards with an option to include the master file used to create the graphic (e.g. PowerPoint, Photoshop, CorelDraw). Other editors (assuming they have access to the relevant software program) would be able to download, edit, enhance and replace the original graphic with an improved version.
  • Phabricator tickets:
  • Proposer: Parkywiki (talk) 00:28, 11 November 2016 (UTC)[reply]

Community discussion

Convert all wikipedia's languages to use only Commons photos/videos/media

edit
  • Problem: I still think is not fair the english wikipedia (and another posible wikis) to use copy-righted material in their articles. I think that should be not permitted anymore. I'm from the Spanish wiki, and I think all wikis should have the same permissions at uploading media.
  • Who would benefit: Everyone
  • Proposed solution:
  • Phabricator tickets:
  • Proposer: VictorPines (talk) 19:44, 12 November 2016 (UTC)[reply]

Community discussion

Hi VictorPines, as discussed above, this proposal is more of a community discussion issue than a technical proposal, so it doesn't fit into this survey. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 20:47, 21 November 2016 (UTC)[reply]

edit

Community discussion

  • Havent noticed that its a big problem. But here I should point that the problem to this problem is, that Commons does not provide category names in your mother tongue, so If you dont know, how to name such category in English the only way is to set it in the mother tongue hoping someone will translate it. So it would be better to remove that deaper problem. But yes, if you feel, we should work also on this problem and this way, why not.--Juandev (talk) 17:02, 14 November 2016 (UTC)[reply]
    • There are many language versions of Wikipedia, but Wikimedia is only one. But maybe it is impossible to solve this problem. In contrast to Wikipedia, only names / titles and links to categories and images could be in more than one language, but content the same. Perhaps two languages would be sufficient - English as international language and native one. The problem is that people in given country search the internet in their own language, but readers from other countries need at least English. Darekk2 (talk) 20:40, 14 November 2016 (UTC)[reply]
  • This is, from my point of view, the same problem exposed in a section below, and an issue that was already in the top 10 wishes last year : Community Tech/Allow categories in Commons in all languages. The solution proposed was a sort of wikidata-ization of commons, allowing the translation of all categories in all languages. The last update on this was on July 28, with a demo system, but I don't see anything new since. Rhadamante (talk) 19:49, 14 November 2016 (UTC)[reply]

Clear and improved Commons rules for mass donations of media files

edit
  • Problem: Batch uploaders from GLAM institutions ignore some Commons rules. For example: There are donators (institutions) that require strict naming of the files, and force these onto Commons. Result is that there are hundreds of thousands (if not much more) of files with non-descriptive names. It makes searching for files much harder. Also many institutions ignore the practice that the author of an art-work (to be filled in at the description) is NOT the person who took a photo of the file, or scanned it for upload. Result is that many Public Domain works (by Commons rules) should now be considered CC-BY -> the photographer or person performing the image scanning. Even though Commons decided: "The official position taken by the Wikimedia Foundation is that "faithful reproductions of two-dimensional public domain works of art are public domain"". Result would often be that for example a photo of a painting by Rembrandt, even though the painting has been (licensed) as being in the Public Domain and authorship should be accredited to Rembrandt, may now be accredited to the photographer. And in stead of having a date in the seventeenth century, now dates from the 21th century. An other problem is the categorizing of the donated photo's. Often they are only categorized in a category named after the donator, plus sometimes a category named after the photographer of the Public Domain work, let's say, the aforementioned. If no action is taken, Commons will end up with millions of badly named, uncategorized and wrongly licensed files. It would be unreasonable to expect from the Commons community to solve all this mess. It could be causing, in the long run, the Commons to become a modern Babylonian confusion.
  • Who would benefit: All users of Commons
  • Proposed solution:
    (A) Clear rules for donators (the institutions), and for those persons (members of Commons) who do the actual uploading work.
    (B) A special Help page for the rules needs to be created for consultation.
    (C) Clearly defined variables for the description fields for files on Commons.
    (D) And these rules need to be presented to the donators before starting a donation process.
  • Phabricator tickets:
  • Proposer: oSeveno (talk) 14:13, 14 November 2016 (UTC)[reply]

Community discussion

Hi OSeveno, as discussed above, this proposal is more of a community discussion issue than a technical project, so it doesn't fit into this survey. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 20:48, 21 November 2016 (UTC)[reply]

Categories in mother tongue

edit
  • Problem: While MediaWiki messages are delivered in 200+ languages and there are 260+ Wikipedia language mutation, our media repository - Commons is organised in English only. That is a barrier for those, who doesnt understand English, but also for those, who speak English by spending lot of time in looking for a proper category(s).
  • Who would benefit: Wikimedia Commons photographers, Wikipedia readers (because, easier Commons will atract more non wiki contributors, who will enrich Wikipedia articles by their creation).
  • Proposed solution: Upload categories to Wikidata, create and easy way in Commons, categories can be translated or set in other languages and provide a tool which will display category names in useres prefered or IP area language.
  • Phabricator tickets:
  • Proposer: Juandev (talk) 16:49, 14 November 2016 (UTC)[reply]

Community discussion

@Juandev: Should this proposal be merged with the "The same single category with names and links in more than one language" proposal above? If there is a difference, I might not understand it. --AKlapper (WMF) (talk) 18:51, 14 November 2016 (UTC)[reply]

I think that this is the same proposal as "Allow categories in Commons in all languages", which was #6 in last year's Wishlist Survey. The way to fix this problem is to build structured data on Commons -- a large and important project that the Wikidata team is currently working on. Wikimedia Foundation is currently looking at options to increase our investment in the project. -- DannyH (WMF) (talk) 00:49, 15 November 2016 (UTC)[reply]
I'll just second that this is something important that should happen. --Piotrus (talk) 08:19, 15 November 2016 (UTC)[reply]
So, it this is already the problem you are working on, should we close this wish?--Juandev (talk) 19:52, 15 November 2016 (UTC)[reply]
Yes, we'll do that and not take this into the voting phase. But thanks for telling us that what we do is important. (:
(But be aware this might take a while – it's a big project, no quick, easy fix.) /Johan (WMF) (talk) 19:56, 15 November 2016 (UTC)[reply]
+1 to this. I have often wondered what the point of all that code allowing us to put category descriptions in other languages is if the category name always displays only in the same language it was created in (there are a few examples of this in languages other than English). Daniel Case (talk) 01:38, 16 November 2016 (UTC)[reply]
This should be solved by structured data proposal.--Jarekt (talk) 03:16, 17 November 2016 (UTC)[reply]

Allow file rotation on commons

edit

Community discussion

Hi Steinsplitter, could you add some more details here, including what the problem is that you want to solve? I haven't used Rotatebot, and I'm not sure what it does. Explaining the problem to people who aren't familiar with it will help more people understand your proposal, which will get you more support votes. -- DannyH (WMF) (talk) 23:14, 19 November 2016 (UTC)[reply]

"Medical and Chemistry Images to Links" Pixel Locating App

edit
  • Problem: The medical and chemistry articles contain images which "point" to separate areas, but do not link to Wikipedia Article Pages (as links). Determining the "Pixel Location" for those interested in repairing this issue is incredibly stressful, unless done with GIMP or other outside applications.
  • Who would benefit: Students, Professionals (brushing up), Users, Medical Researchers
  • Proposed solution: The code in GIMP is open, and a "Pixel Identifier App" within Wikipedia could encourage Template:Annotated image 4 to be used more openly. Thus, improving the images with "words" on them, to become instead, Wikipedia Article Links.
  • More comments:

Sample:

Community discussion

edit
  • Problem: Allow chronologically sorting what-links-here links.
  • Who would benefit: Editors who would like to focus effort on improving articles related to those that they are interested in.
  • Proposed solution: Don't know but evidently involves using timestamps (but it seems to be easy to use from some particular date onwards, the data used to generate notifications)
  • Phabricator tickets:
  • Proposer: Shyamal (talk) 04:59, 10 November 2016 (UTC)[reply]

Community discussion

  • Looks like a very good idea. Let's take a very simpple example: An article which, due to a slightly ambiguous title, keeps getting incorrect incoming links. It would be nice to be able to simply look at the most recently added links top be able to fix the incorrect ones, while leaving the older ones as already ahving been checked. עוד מישהו Od Mishehu 12:16, 10 November 2016 (UTC)[reply]
  • I like this idea as well, but while we're at it, it might also be useful to provide an option to sort the list of incoming links alphabetically. In both cases, there should be an option to switch between increasing and decreasing sort order as well. --Matthiaspaul (talk) 22:01, 10 November 2016 (UTC)[reply]
Simple and useful. I like it.-Nizil Shah (talk) 02:29, 11 November 2016 (UTC)[reply]
  • I note that it would not be possible to do this for links added before the implementation date of the feature, since "time of link addition" is not currently stored. All existing links would effectively show up as having been added at the same time. The date-added would also be reset by page- and section-blanking vandalism and its reversion. Anomie (talk) 16:19, 11 November 2016 (UTC)[reply]
Agreed and acceptable although in theory a background task could determine a date of last link addition by trawling through histories. Shyamal (talk) 10:36, 13 November 2016 (UTC)[reply]
Even if the older links can't be sorted by time, doing it for the newer links would still be better than nothing; and I doubt that, in many cases, vandalism and its revert would have a significant affect on the usability of this feature. עוד מישהו Od Mishehu 04:02, 16 November 2016 (UTC)[reply]

Hi Shyamal, we talked about this proposal as a team, and it's just not feasible to do this for performance reasons. Parsing each edit and creating new database tables in order to provide an option for how people view what-links-here... it wouldn't make it past the performance and operations teams. I understand the goal, and I'm sorry to decline it. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:13, 22 November 2016 (UTC)[reply]

Add ISBN support to VisualEditor

edit
  • Problem: not currently supported, making citing books much more cumbersome than it could be
    • ISBN data exists in public repositories and it would be reliatively easy to draw said data to help with automatically-filled citations
  • Who would benefit: editors that use books as sources
  • Proposed solution: VisualEditor citations support auto-fill for ISBN-10 and -13.
  • Phabricator tickets: phab:T145462
  • Proposer: LT910001 (talk) 07:10, 10 November 2016 (UTC)[reply]

Community discussion

That proposal sounds pretty much like phab:T1084 to me (functionality to be provided by Citoid) which is already being worked on? --AKlapper (WMF) (talk) 13:39, 10 November 2016 (UTC)[reply]

Be aware of mw:Requests for comment/Future of magic links. While not directly influencing this proposal, it will change the way ISBNs are handles in wikitext.--Strainu (talk) 14:06, 10 November 2016 (UTC)[reply]

would prefer OCLC number Slowking4 (talk) 16:16, 15 November 2016 (UTC)[reply]

Hi LT910001,
This has been in the works for years, and I'm happy to say that this is likely to happen soon, possibly even during the next couple of months. (Some ISBN data exists in publicly viewable repositories, but not in free repositories.) Whatamidoing (WMF) (talk) 00:10, 22 November 2016 (UTC)[reply]

Fix this CodeEditor bug

edit
Bug report (about an Upstream problem) copied to Phabricator

I know this is not the most appropriate place to write about this but, I am too lazy to find one.

  • Problem: In this screenshot you see codeeditor's mispositioned cursor. In the textbox there are three letters (Georgian ტზე) and the cursor is supposed to be between the 2st and 3nd, but as you can see it is in the middle of the second letter.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets:
  • Proposer: Dixtosa (talk) 20:14, 9 November 2016 (UTC)[reply]

Community discussion

Spelling and grammar checker in the editor

edit

Errores ortográficos y gramaticales

  • Problem:

Spelling and grammatical errors.

Errores ortográficos y gramaticales.
  • Who would benefit:

No errors, good writing

Sin errores, buen redacción
  • Proposed solution:

Implement an indicator of spelling and grammatical errors at the time of writing, using a spelling and grammar checker like LibreOffice or Microsoft Word.

Implementar un indicador de errores ortograficos y gramaticales al momento de redactar, mediante corrector ortográfico y gramatical como Libre Office o Word.
  • Phabricator tickets:

Community discussion

Hi Micnous, we talked to the Editing team about this proposal, and they said that we should decline it. You can see the Phabricator tickets linked above for more information. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:15, 22 November 2016 (UTC)[reply]

Something like a 'git blame'

edit
  • Problem: When identifying a copyright violation, administrators like me would like to identify who did the copyright violation and let them know they shouldn't do it. But currently it's impossible to know who wrote what, and when.
  • Who would benefit: Community users detecting copyright violations, or someone who would like to know who wrote some specific lines.
  • Proposed solution: Support something like a git-blame.
  • Phabricator tickets: N/A, if someone is creating one please subscribe @revi at phab.wm.o, thanks!
  • Proposer: — regards, Revi 17:21, 12 November 2016 (UTC)[reply]

Community discussion

Native stuffs are always better than 3rd party support, and I knew Xtool exists. (I didn't know WikiBlame existed, but good to know there's another alternatives.) — regards, Revi 18:56, 12 November 2016 (UTC)[reply]
Do the two linked tools work without specifying a search term? I just want an annotated view of the current revision. – Jberkel (talk) 13:00, 17 November 2016 (UTC)[reply]

Hi -revi, your proposal is essentially a duplicate of another proposal on the Editing category page: A "blame"-like feature. I'm archiving your proposal here. Thanks for participating in the survey! -- DannyH (WMF) (talk) 22:27, 21 November 2016 (UTC)[reply]

Citoid needs help

edit
  • Problem: Whoever is supposed to maintain w:Wikipedia talk:TWL/Citoid, is not bothering to reply on talk. This is a vital part of Visual editor, but it seems that it is not being properly integrated with the source-editing mode, and good ideas/bug reports from that page are ignored.
  • Who would benefit: Community.
  • Proposed solution: Can we get this tool working? Automated citation is a great boon, and it not working well is a major annoyance.
  • Phabricator tickets:
  • Proposer: Piotrus (talk) 08:35, 15 November 2016 (UTC)[reply]

Community discussion

  • The people working on Citoid actually do a great job at both responding to community enquiries and maintaining the code. I recommend joining conversations on Phabricator or posting at mw:Talk:Citoid in the future. Regards, --Elitre (WMF) (talk) 11:38, 15 November 2016 (UTC)[reply]
  • This proposal seems to be a complaint about the lack of response to this complaint. -- John Broughton (talk) 00:14, 17 November 2016 (UTC)[reply]
    • @AKlapper (WMF): Indeed, and based on that, my conclusion is that Citoid is not maintained. If it is, someone should tell the developers to monitor the page about their tool on WMF's biggest wiki. Perhaps, as Elitre (WMF) suggested, en wiki page could be simply redirected to mw:Talk:Citoid. This, in general, illustrated a bigger problem - we need to centralize such discussions. People, not only me, are wasting their time reporting bugs and suggesting features in places that the devs apparently ignore. This is a bigger problem that merits a bigger discussion. --Piotrus (talk) 13:16, 17 November 2016 (UTC)[reply]
      • I don't even think much discussing is necessary here :) All our efforts go towards centralization, lately. There has never been any indication, AFAIK, that devs would follow that page (which is linked to a community-maintained initiative, and I must say that user:czar has been awesome there); there aren't many pages on Wikipedias which are supposed to be maintained by WMF staff (let alone devs). Most devs do follow mw.org and Phab, which is expected and exactly what's already happening; for real time communications, they can sometimes be found on IRC even. Anyway, since devs' first responsibility is coding, you may want to consider pinging m:Community Liaisons in certain cases, generally speaking. Finally, you can also find a list of volunteers who may be able to help with less complex issues at mw:Help:VisualEditor/Community Taskforce#TemplateData and Citoid experts. HTH. --Elitre (WMF) (talk) 15:42, 17 November 2016 (UTC)[reply]

Hi Piotrus, I'm archiving your proposal, as per Elitre's recommendation above. Thanks. -- DannyH (WMF) (talk) 01:17, 22 November 2016 (UTC)[reply]

Copy Wiki pages

edit
  • Problem: At the moment, one can move a page, but not copy. The idea is to write an article derived from other people's articles in a legal and easy way, but without hiding the previous work.
  • Who would benefit: Authors writing an article or a book at WikiBooks.
  • Proposed solution: Having a button near "Move" named "Copy". Pressing this button askes for a target, then the page and all of the history becomes duplicated at the given location. Very similar to "Move".
  • More comments: There should be no user restriction on who is allowed to copy.
  • Phabricator tickets:
  • Proposer: Qwertz84 (talk) 09:24, 15 November 2016 (UTC)[reply]

Community discussion

This can impose new problems, such as:

  1. A user legitimately creates a page; an other user, possibly months later, duplicates it with a problematic name. A third user, who happens to be an admin. simply finds the duplicated page, and blocks the aparent creater for creating an inappropriate page name - incorrecctly.
  2. A user's contribution count would be all messed up if his/her pages will be copied.
  3. A user is banned from editing in a certain topic area. A page this user edited once the ban was in place is duplicated and changed to be in this topic area. It now looks like the user had violated the ban - which they didn't.

עוד מישהו Od Mishehu 12:41, 15 November 2016 (UTC)[reply]

  • Thank you for your thoughts. What about a message in the history log like "this page was copied from source XY". Would this help? I have no idea, how the user's contribution gets counted. Does a page copy counts every edit again? Qwertz84 (talk) 16:17, 15 November 2016 (UTC)[reply]
  • Is this a solution in search of a problem? If you want a copy of page, open the page using the wikitext editing interface, select everything on the page, copy what you've selected, start a new page, paste what was copied, and save the page. [This isn't necessarily a good idea - for example, categories should be deleted before saving, since article categories shouldn't be used in a non-article namespace, which would be the case here, but it's certainly feasible.] -- John Broughton (talk) 00:19, 17 November 2016 (UTC)[reply]
    That does often create attribution problems. For Od Mishehu's issue, adding a history entry like "X forked revision Y of page Z into this page" to the copied page may help, like page moves (which can create similar issues). Jo-Jo Eumerus (talk, contributions) 15:45, 17 November 2016 (UTC)[reply]
    Page moves are less of an issue ofr two reasons: Firstly, once the old page becomes a redirect to the new title, page-move vandalism is more likely to be fixed; page copying vandalism is less likely to be noticed. Secondly, a page move doesn't increase the reported edit count of its authors; page copying would. עוד מישהו Od Mishehu 04:39, 20 November 2016 (UTC)[reply]
  • There was extensive discussion (and opposition) last year, in Community Wishlist Survey 2015/Miscellaneous#Support for version branching for pages. @Qwertz84: This proposal will probably not be included in the voting stage this year, but I strongly encourage you to read all of the background and recent discussions, and to discuss the idea further at that phabricator task (phab:T113004), in order to have a more well-thought-out proposal for the future, or just in order to contribute detailed ideas, use-cases, and solutions there. It's an incredibly complicated idea that other people have been talking about for a long time, so requires significant research and preparation. Thanks! Quiddity (WMF) (talk) 00:14, 19 November 2016 (UTC)[reply]
  • @Qwertz84: Hi, I've archived this, per the explanation (and recommendation) above. Thanks. Quiddity (WMF) (talk) 22:46, 21 November 2016 (UTC)[reply]

Allow registered users to see the history of a deleted page

edit

Machine translation from Spanish to English, please improve! -- A las facilidades de edición le falta muy poco para ser excelente, pues hay un punto oscuro

  • Problem (problema):

The editing possibilities are enormous, and in my opinion unbeatable, because in a simple way you have access to the history of each page. But there's a difficulty, at least for those of us who are not admins. There's a process for speedy-deleting a page, or bringing it up for community consultation. Those processes should be left as they are; they're very necessary. When a page is deleted, and someone tries to create it again, it's not prevented—but there's a warning that says the page was deleted before. This is also good and convenient.

But there's no way for a contributor to see the entire history of the deleted article. Being able to see the old versions would help an editor know if it's feasible to create a new version. For example, if an article is deleted from Wikipedia because it doesn't have enough references, another editor could build on that version. The version that was deleted might have quite interesting content, and if someone is interested in creating it again, it would be helpful to have access to all previous versions.

Realmente, las posibilidades de edición son enormes, y en mi opinión inmejorables, pues en forma sencilla se pueden investigar cambios recientes de una entrada, e incluso cambios hechos muy atrás, al inicio de la creación de un determinado artículo en cierto idioma. Pero hay una dificultad, al menos para quienes no somos bibliotecarios. Observen: Se da de baja un artículo por el procedimiento rápido o por el que habilita la consulta a la comunidad. Muy bien, obviamente ambas cosas deben dejarse como están, pues son muy necesarias. Pero señalo que cuando una entrada es borrada, y alguien intenta crearla nuevamente, eso no se impide, pero se advierte que se está intentando crear un artículo que por alguna razón ya fue borrado antes, y eso también es muy conveniente que quede casi sin cambio. Entonces, qué es lo que objeto. Pues que no hay una opción para visualizar toda la historia del artículo que fue borrado así como de sus distintas versiones intermedias desde su creación, pues si ello se pudiera hacer, se podría saber más a cabalidad si a presente puede ser viable o no crear el artículo nuevamente. Recuerdo que perfectamente, un artículo puede ser borrado de Wikipedia si por ejemplo no tiene ninguna referencia, o si tiene muy pocas. Muy bien, yo he votado en algún momento por que se borre este tipo de artículos. Pero observo que esta circunstancia es válida en determinado momento y para una determinada versión propuesta (tal vez, la versión que se borró tenga un contenido bastante interesante, pero la ausencia de referencias por no existir las mismas en la web o porque nadie de tomó el trabajo de buscarlas, hace de esa entrada una buena candidata a ser borrada, y si alguien se interesa en crearla nuevamente, qué mejor que darle acceso a todas las versiones anteriores que tuvo esa entrada antes de ser borrada).
  • Who would benefit (¿a quién beneficiaría?):

All Wikipedias have quality standards, which are important, and it's not wrong to delete pages that deviate from our minimum standards. But we shouldn't lose a page that could be interesting, just because the first version was inappropriately or incompletely raised.

La Wikipedia en español o en cualquier otro idioma, debe cumplir determinados cánones de calidad, y este objetivo es irrenunciable, y no está mal que se borren entradas que se aparten demasiado de lo que señalen las normas de Wikipedia y/o lo que manifieste la opinión de la comunidad. Pero no debemos sancionar o restar posibilidades a un artículo que potencialmente puede llegar a tener mucho interés o al menos cierto interés, por el solo hecho de que en un inicio el mismo fue inadecuadamente planteado o incompletamente planteado, y ese sería precisamente el beneficio que se obtendría con la presente propuesta, poder analizar en toda su riqueza el contenido de una entrada borrada, para eventualmente volver a crearla, si es que se tienen suficientes elementos como para ello, y si es que no se volverían a reproducir las falencias que llevaron a un wikipedista o a un grupo de wikipedistas a proponer y en su momento obtener la eliminación de la entrada.
  • Proposed solution (solución propuesta):

Allow all registered Wikipedians (possibly autoconfirmed) to see the previous versions of a deleted article.

Permitir a todo wikipedista registrado con nombre y página de usuario, y que por ejemplo además al menos sea autoconfirmado, a visualizar un artículo antes borrado, para así poder evaluar mejor si con ciertos cambios que pudieran hacerse sobre ese contenido el mismo podría ser o no rehabilitado. Y si luego de esta etapa de análisis el wikipedista en cuestión quisiera rehabilitar la entrada, permitirle hacer esos cambios y plantear luego a un bibliotecario que autorice o no esa rehabilitación, según fuera lo que entendiera más conveniente.
  • More comments (más comentarios):

Note that a quick deletion can be proposed by any Wikipedian, but the same must suggest it to an admin so that the most experienced Wikipedian does it or not, according to his opinion. The idea to be studied by those who made the implementation of the present proposal, if it is considered positively, is to put similar mirror conditions. Obviously, and as long as that Wikipedian with ideas to rehabilitate the article goes ahead in the changes that he considers appropriate, he should be allowed to access that content, but of course, that facility does not have to be given in general.

Obsérvese que un borrado rápido puede sí ser propuesto por cualquier wikipedista, pero el mismo debe sugerirlo a un bibliotecario para que ese wikipedista con mayor experiencia lo efectivice o no, según sea su opinión. La idea a estudiar por quienes hicieran la implementación de la presente propuesta, si es que la misma se considera positivamente, es que se pongan similares condiciones espejo. Obviamente, y mientras ese wikipedista con ideas de rehabilitar el artículo vaya adelantando en los cambios que considera convenientes, se debe permitir al mismo que acceda a ese contenido, pero por cierto, esa facilidad no tiene porqué darse con carácter general.

Community discussion

  • This is a non-starter. We delete stuff like copyright violations and attack pages because they need to be not publicly visible. MER-C (talk) 00:29, 16 November 2016 (UTC)[reply]
  • Since registering as an editor is trivial, this proposal is essentially to allow anyone to read deleted articles. That essentially negates the whole of point of deleting them - these articles are copyright violations, attack pieces, and (mostly) just pure junk. -- John Broughton (talk) 00:23, 17 November 2016 (UTC)[reply]
  • This would be a policy change, and is thus out-of-scope for this Wishlist. As noted above, there is a process on the English Wikipedia (w:en:WP:REFUND), that lets non-admins ask an admin to give them access to the contents of a deleted page. The main point is contained in this excerpt:
    "This page is also intended to serve as a central location to request that deleted content be userfied, restored as a draft or emailed to you so the content can be improved upon prior to re-insertion into the mainspace, or used elsewhere (you may also make a request directly to one of the administrators listed here). This means that content deleted after discussion—at articles for deletion, categories for discussion, or miscellany for deletion among other deletion processes—may in some cases be provided to you, but such controversial page deletions will not be overturned through this process. Copyright violations and attack pages will not be provided at all.".
I recommend starting a process at your local project, that is similar to this English Wikipedia process. -- (Please translate this into Spanish, and ping AnselmiJuan. Thank you!) Quiddity (WMF) (talk) 00:20, 19 November 2016 (UTC)[reply]

Restrict article editing to registered users

edit
  • Problem: changes to articles by unregistered users (i.e.: ip addresses) don't allow to comunicate to the editor if necessary, as in most cases ip addresses are dynamic and not static. Contributions and comments can't be attributed; additionally the anonymity encourages vandalism. This goes against the collaborative spirit of Wikipedia.
  • Who would benefit: the whole community, by increasing collaboration and reducing vandalism, hence increasing article quality.
  • Proposed solution: restrict editing functionality to registered users, in all Wikimedia projects.
  • More comments: this may have already been raised before, couldn't locate where.
  • Phabricator tickets: not aware of any, there should be some as this problem is as old as Wikipedia.
  • Proposer: DPdH (talk) 22:26, 18 November 2016 (UTC)[reply]

Community discussion

@DPdH: Unfortunately, this idea isn't in the scope of this survey. We're looking for technical projects—new features, fixes, tech changes. What you're asking for would involve a significant policy change, so it's more appropriate for an RFC, or the Village pump. -- DannyH (WMF) (talk) 23:34, 18 November 2016 (UTC)[reply]

Good point, will do that. Thanks for the feedback, DPdH (talk) 00:33, 19 November 2016 (UTC)[reply]
And you are unlikely to succeed; changing the Founding principles, point #2, will need an extraordinary good reason. Jo-Jo Eumerus (talk, contributions) 09:41, 19 November 2016 (UTC)[reply]
Agreed with Jo-Jo that many if not most editors will treat this as a non-starter. I think there's something like an 80% rule where 80% of vandalism comes from IPs, but at the same time, 80% of contributions by IPs are considered useful. So, we will want to keep those contributions. There are ongoing efforts to better discourage vandalism, such as deferring changes, which recently passed overwhelmingly at the English Wikipedia. I am fairly confident that this is the direction the wikis will be going in, rather than outright restricting editing access. Stevie is the man! Talk • Work 13:06, 19 November 2016 (UTC)[reply]

Hi DPdH, this proposal is about a community decision, not a technical project, so it doesn't fit the purpose of this survey. I'm archiving it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:08, 21 November 2016 (UTC)[reply]

MOOCs on Wikipedia editing

edit
  • Problem: Perhaps a newer approach to guides pertaining to Wikipedia editing can be taken.
  1. Wikipedia needs to attract people involved in academia.
  2. Many users are unable to find proper guidance pertaining to Wikipedia editing even though all the relevant information are available in form of guidelines. Adherence to notability principles or manual of style can not be expected from newbies who lack guidance.
  3. An organized guide to editing Wikipedia is lacking.
  4. Apart from being self-taught about the norms of Wikipedia editing there is hardly any other way to advance the understanding of how Wikipedia works or how one can go on to the next level of Wikipedia editing.
  5. Learning material pertaining to Wikipedia editing are usually restricted to Wikipedia or its sister projects and are frequently text based in nature.
  6. Advanced understanding may be required for users who contribute to specific niches like WP:MED
  7. There can be lack of understanding about how to create and deal with templates and about how to use them optimally.
  8. There is paucity of audiovisual guides on Wikipedia editing. Even though there are a limited number of videos on such topics available on Commons, amateur users or casual users might not be well aware about them.
  9. Many users seek some sort of recognition of their skills of Wikipedia editing.
  10. Wikiversity is not as renowned as Wikipedia as a form of learning tool.
  • Who would benefit: Relatively new users who do not have guidance from mentors. For humans, the ease of learning from the use of audiovisual aids is much higher than that from merely reading text.
  • Proposed solution: Massive open online courses or MOOCs are gaining popularity and can serve as effective means for learning. They can be an effective tool in open learning and share the spirit of open knowledge that Wikipedia promotes. I propose an organized approach in designing such courses to help in spreading the message of Wikipedia, an encyclopedia that anyone can edit. Apart from benefiting regular users, such courses would also help in drawing the casual learner who is experimenting and browsing through the list of available free courses.
  • More comments: I propose for an organized approach to defining course contents and then forming simple audiovisual tools for a step by step guide to editing Wikipedia, as well as other topics pertaining to Wikipedia. There are a number of existing users have some sort of connection to various universities and affiliation and collaboration from such univeristies can be sought. The existing faculty of those universities can assist in improving the courses even further. A suitable platform for the MOOCs would need to be worked out. I propose Coursera although a more parametric approach would be needed for such a choice. After initial work from our end we can approach such platforms and try to form collaborations for such courses.

Community discussion

I am not sure if this is the right place to begin the discussion. If not, I would be happy to guided to the right place. I am proposing creation of courses related to Wikipedia editing. The contents should go from the basics to the advanced concepts. This should extend to notability guidelines and other guidelines that need to be adhered to. The courses should also touch upon advanced concepts like the use of tools and bots for semi-automated and automated edits. The primary endeavour should be volunteer driven (how to pool the volunteers - needs to be discussed) but would also need inputs from the Community Tech team. A structured and methodical approach needs to be taken to identify the stakeholders and to establish proper rapport and association between them. DiptanshuTalk 04:56, 10 November 2016 (UTC)[reply]

So it seems we agree a) this is a good idea and b) it belongs somewhere else. What do you need, User:Diptanshu.D? Simply others who spend their time? In that case, maybe move this to another page on Meta and link to it from some places where other interested editors might hang out? Are there any resources you lack? In that case maybe Grants:Project is relevant, or Rapid Grants? /Johan (WMF) (talk) 10:13, 10 November 2016 (UTC)[reply]

Hi @Diptanshu.D and Johan (WMF): sorry for my english. Contributors from fr-Wikipedia and myself, with the help of Wikimédia France, created a MOOC last year (release: february/march 2016, 6000 registrations, about 2000 attendees — see here for more information), the WikiMOOC, which was a success. And we are now creating the second edition, planned for march 2017.
The WikiMOOC is both about theory (5 pillars, guidelines, etc.) and practice (wikicode, VisualEditor, templates, etc.). We started this big project with the same diagnostic that the one you made here on the "Problem" part.
Both editions are hosted on FUN, a french MOOC host which works with Open edX. But the first WikiMOOC experience has shown us that FUN/Open edX is not suitable for our needs; we need a MOOC software adapted to MediaWiki (I give you the short version  ).
That's why we plan to create our own MOOC hosting software in the future: we want to create this platform for the entire Wikimedia movement, a) because we know that there are other chapters and Wikimedia communities who are thinking to create MOOCs about Wikipedia or about other Wikimedia projects, b) and we would also like to help other volonteers to translate and adapt our WikiMOOC in other languages, to spread "WikiMOOCs" over the world.
To create this MOOC platform, we will need:
  • time (about one year of design & development):
  • funds (for the development stage);
  • and especially contacts and help in the Wikimedia movement: we have to collect the needs of Wikimedia volunteers and chapters for MOOCs, we need to know if they plan to create MOOCs and we want to share our experience in order to generate other projects like ours.
You seem to be very interested by MOOCs, Diptanshu.D, maybe we can work together?
Best regards, Jules WMFr (talk) 15:04, 10 November 2016 (UTC)[reply]
  • MOOCs could be very useful, but their content should be at least evaluated by the online communities, who know the common topics and how to deal with them at any extent. I know this might seem unintentionally unpleasant, sorry, but just a few days ago, in a local project, we had to negotiate to build together, the online community and the national chapter, a sort of mutually agreed teaching protocol for editathon and GLAM organizers: this because of several incidents due to the insufficient indications organizers somehow gave to newcomers because organizers were not correctly trained, in turn. Mistakes in this field can cause trouble to the project, disqualify organizers and organizations, and upset those that we are calling to contribute: what an outcome to no avail... It's not about templates or other Mediawiki issues, it's about correctly teaching neutrality and copyright, wikiquette and notability, and all the other things in which you need to be specifically experienced in the specific project. So, since I would be very interested in MOOCs, I would like to see them carefully generated so that they can be the important tool we could benefit from. I am very much looking forward to seeing contents that can be translated in other languages and are open to calibration for specific projects --g (talk) 00:20, 11 November 2016 (UTC)[reply]
Pardon me for my delayed response. MER-C: Definitely it should be volunteer led. @Jules WMFr:: It is great work that you are doing. I was talking exactly about the things that you are doing. I would be happy to contribute and work alongside. Your English is great and you need not worry about it. It is only that I have no knowledge of French. After initial work we can perhaps lauch a rapid grant proposal from Wikimedia. @Léna:: Thanks for the update. I would be happy to be guided further about the chapter in South America.
@Gianfranco:: Of course it needs community validation and inputs from bureaucrats. It calls for efficient multidisciplinary team building. And that was the reason I thought that people like Johan (WMF) belonging to the liaison segment of Community Tech could help. Slowking4 seems to support such a possibility. @Johan (WMF):: Perhaps you could take a softer and more supportive approach, but anyway!
Yair rand and Stevietheman: I would be happy to invite your inputs after we go ahead a bit further.
--DiptanshuTalk 13:48, 13 November 2016 (UTC)[reply]
Diptanshu.D – sorry if I came across as harsh, my point was not to brush this aside, but merely to try to find the best ways to support you and where to best continue the discussion to move this forward. /Johan (WMF) (talk) 14:39, 13 November 2016 (UTC)[reply]
Dear @Diptanshu.D:, I think your proposal is timely and relevant. I second @Jules WMFr: on his presentation of the WikiMOOC : The WikiMOOC is already here to stay. It has enjoyed a first successful session a few months ago and a second session is underway. I, for one, have only recently joined the team, but I can testify that this is clearly a volunteer driven project, and one that is actually working with only minimal funding from the French chapter. You can check the "learning pattern" that has been written about this project.
In the short term, no grant or technical support is needed, but in the long term, our experience leads us to envision the development of a MOOC platform of its own, based on MediaWiki, and this is where we will need the technical (and financial) support of the foundation, @Johan (WMF):.
On the topic of MOOC platforms, I would recommend not to use Coursera or Canvas or any of those because their licensing (software and pedagogical material) policies are totally incompatible with a creative commons policy. Plus, their business model is based on reselling of personal data. The first two WikiMOOC sessions are based on the open source EdX platform, but it is our experience that the very structure of EdX material (especially regarding discussion forums) is not adapted at all with a MediaWiki way of dealing with archiving, transparency, and simply discussion structure.
Furthermore, our aim is to develop a structure that would be reusable and adjustable to different pedagogical needs : a WikiMOOC in a certain language, or about a certain Wikimedia project or about an academic course regarding Wikipedia.
On this latter topic, and regarding your point number 1, I am actually an academic, a Historian of science by trade, I investigate Wikipedia as a research subject, and I do teach Wikipedia (If you read French, you can check my "plea to teach Wikipedia" in The Conversation). This WikiMOOC is for me an opportunity to imagine reusable pedagogical material that would benefit a lot of academic pedagogical projects around this topic. As a matter of fact, I am in the process of mounting a tentative partnership between my University and the Wikimedia French chapter.
To conclude, I do believe that the WikiMOOC initiative could be the starting point of a great pedagogical platform. Alexandre Hocquet (talk) 02:07, 14 November 2016 (UTC)[reply]
@Alexandre Hocquet:: Wow! I went through the translated version of your article on The Conversation (courtesy: Google translate). You have rightly summed up the facts including the licensing issues. The problem with EdX is that there is no financial aid available (not that I know of) and the charges are higher if one opts for a certificate. On the other hand, the justification of going for conventional platforms like Coursera and EdX is that they have already built a pool of users (possibly non-Wikipedian), whom we could reach out to.
I wish to contribute to the project. We perhaps need a separate place/platform for the discussion, as well as to pool the prospective contributors. Detailed and parametric discussions need to ensue. Perhaps it would be justified to create a project page in English Meta. Or is English Wikiversity a better platform? I say this because I am unable to speak French and hence my proposal would be to replicate (and improve upon) the existing effort in French to English language. I hope that Jules WMFr would be able to guide me about how to take it forward and how I could help. DiptanshuTalk 06:16, 14 November 2016 (UTC)[reply]
Hi @Diptanshu.D:. Open EdX (the software, used in a lot of websites, FUN included) and EdX (the website, whith higher charges for certificate) are two different things; Alexandre was talking about Open EdX, the software.
Yes, I think it's time to create a meta page, in english, for the "international" WikiMOOC project: I will take care of that as soon as possible. In the meantime, can you send me an email at jules.xenard wikimedia.fr? [Ok, you just did it a few hours ago!] Kind regards, Jules WMFr (talk) 10:02, 14 November 2016 (UTC)[reply]
Thanks Jules WMFr for your response. I think that perhaps Wikiversity would be a better place to start (as compared to Meta). What do you think? Thanks for clarifying the difference between EdX and Open EdX. --DiptanshuTalk 10:13, 14 November 2016 (UTC)[reply]
@Diptanshu.D:: I think meta is a better place to create a page about this project in english: we can easily create translations if needed, Meta hosts every language in the same website and is the right place for international coordination, for projects which concern every other Wikimedia project (which is the case for the MOOC platform project). While a page on Wikiversity will only be in english.
I'm writting you an answer by email. Jules WMFr (talk) 10:17, 14 November 2016 (UTC)[reply]
Awesome. I love how this conversation is helping people find each other. (: Regarding Meta and several languages, just me if you have a page and want it marked for translation, if you can't do it yourselves.
Going back to the specific technical part of this: Jules WMFr, Alexandre Hocquet and Diptanshu.D, could you try to specify what it is you'd need from the Community Tech team before November 28, so that people know what they're voting for? The reason I'm asking this is because the more specific the wish is, the better chance you have of the team doing what you need, and the easier it is for the community to make decisions on what they'd like to prioritize. It's not like everything needs to be decided here and now, but can you give us an idea of how you'd like this to work? /Johan (WMF) (talk) 12:27, 14 November 2016 (UTC)[reply]
Yes, it's very useful to meet other people interested by this subject. @Johan (WMF): I think it's a bit early (for me, at least) to have a clear view of how the Community Tech team can help us. Basically, for the tech part, to create a platform, we need developper(s), and not only volunteer developper(s): developping this platform will take a couple of months, we need someone who can focus on it. So we need a paid developper. I'm not sure WMF can provide that, and I don't think WMFr has now enough budget hire someone, so a grant may be needed to hire a developper for a couple of months. Then, the developper (who must already know mediawiki) will probably need some technical support from the WMF, but it depends on how much the platform will be based on MediaWiki and how much it will be connected to Wikimedia projects (we need the platform to be connected to Wikimedia projects, in order to facilitate the round trips between the courses on the platform and the practice on Wikipedia). CC 0x010C, who currently works a lot on the technical side of the WikiMOOC, and cc Jitrixis, who may also be interested by this discussion. Jules WMFr (talk) 13:04, 14 November 2016 (UTC)[reply]

This seems like something out of scope, but interesting. Maybe it should be posed as a grant request for a project? I'll also point out to w:Wikipedia:School of Open course, and I'll point out my own w:User:Piotrus/Wiki course, which AFAIK is the only course about Wikipedia being thought for several years. I'd be happy to chat about it more, but if you reply here, do ping/echo me because I will never check for replies otherwise. --Piotrus (talk) 08:09, 15 November 2016 (UTC)[reply]

@Piotrus:: It is great to know about what you are doing. Great stuff. We have created the page WikiMOOC and plan to take it ahead as an international collaboration. Please feel free to contribute. DiptanshuTalk 15:49, 16 November 2016 (UTC)[reply]

Hi Diptanshu.D, Piotrus and Jules WMFr, it looks like this discussion has evolved beyond the Wishlist Survey :) -- I've archived the proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:20, 22 November 2016 (UTC)[reply]

DannyH (WMF): Thanks for the initiative. I could not however find the archival link. Could you please help? --DiptanshuTalk 02:38, 24 November 2016 (UTC) Got it. Sorry! Just to mention, a project page has already been opened at WikiMOOC and is being gradually worked upon. --DiptanshuTalk 02:41, 24 November 2016 (UTC)[reply]

Watching contributions of selected users

edit
  • Problem: There is a number of sparingly editing problematic users. Someone warned or blocked may start to edit again after a long time. It would be advantageous to be notified of such a come-back. Currently, the only possibility to follow someone's contributions is to check them manually (unrealistic) or add a user discussion page to watched pages and wait for comments (not efficient, often too late, easy to miss).
  • Who would benefit: Community
  • Proposed solution: Add a new notification icon that would indicate an activity of a selected user. The selection could be available on 'User contribution' and 'Block user' pages, e.g. as a [Contribution notifications/No contribution notifications] switch. The tool should be available for sysops only.
  • Phabricator tickets:

Community discussion

This is essentially a copy of last year's proposal. I don't think that this proposal is viable in a general case due to stalking concerns, while its application for mentorship only is too niche. Max Semenik (talk) 21:30, 9 November 2016 (UTC)[reply]

Last year's request was flagged by WMF’s Support and Safety team as a tool that could be used to facilitate hounding and harassment. People have offered suggestions to reduce the likelihood that it would be used in bad faith; those are discussed in detail on the project page. It's possible that we could implement some of those suggestions and take the idea back to Support and Safety, but it's likely to be controversial either way. Kaldari (talk) 23:06, 9 November 2016 (UTC)[reply]

Good idea, I'd like to use such a feature on Commons. --Achim (talk) 20:48, 11 November 2016 (UTC) Can't support this idea, for all the exact reasons that WMF Support and Safety team pointed out. I know you created this proposal with the right intention, but I believe the feature could be abused very easily. :/ SamanthaNguyen (talk) 23:48, 11 November 2016 (UTC)[reply]

  • An exceptionally useful feature for admins and users needing to follow up on blocks, bans, SPI. etc. Something I have always missed. Conversly could also help to track users who need help with their editing. Fears that it would be used in bad faith are minimal compared to the advantages. The opt-in / opt-out seems to be a reasonable solution.Kudpung (talk) 11:02, 13 November 2016 (UTC)[reply]
  • I don't think that limiting this to SysOps resolves the concern about misuse. Consider a privileged user tracking someone who has called them out for abuse of position or sexual harassment. Consider an Islamophobic SysOp tracking Muslim activity. Bcharles (talk) 00:41, 16 November 2016 (UTC)[reply]

Hi Michał Sobkowski, as stated above, this proposal is the same as last year's Community Tech/Add a user watchlist. You can see more info on that project page. I've archived this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:22, 22 November 2016 (UTC)[reply]

Users who don't speak English might be hesitant to code

edit
  • Problem: Users who don't speak English might be hesitant to code.
  • Who would benefit: Any contributor desiring to code in a non-English project.
  • Proposed solution: While a way to share common libraries of templates and Scribunto modules, users should also be allowed to code in their own language. Enabling user to localize keywords of templates and modules (if, else, while…). Possibly this may go through translatewiki, and surely it may benefit the idea of a glossary to facilitate documentation translation.
  • More comments: The few (reserved) keywords that compose a programming language isn't a big deal, but because they are (usually) in English, their is a huge tendency to name variables (including functions) and add comment in English too. The consistency of this "all in English" code tacit guideline will depends on English level of contributors. More importantly, that may rising up the difficulty for beginning to contribute on local templates and modules. As our community is trying to widespread it's technical contributors, this may lower the barrier for first contributions. Note that this is not incompatible or against having a common repository for Scribunto modules and templates, just like having Wikidata or Commons doesn't prevent locale policies and specific ways to handle things.

Community discussion

"Users should also be allowed to code in their own language" does not really sound like a description of a problem but instead a proposed solution. Maybe you meant that "users who don't speak English might be hesitant to code" instead? I'm also wondering if this proposal refers to reserved keywords in programming languages only, as you're basically free to choose function names in whatever human language? If this was somehow implemented and I looked at code using a human language I do not understand, would this proposal also include a way to automatically display the code "translated" to a human language that I prefer? --AKlapper (WMF) (talk) 13:01, 10 November 2016 (UTC)[reply]

Ok, I switched the title to your proposal. The scope of the proposal can be discussed. The proposal is more focused on the reserved keywords, and possibly built in functions when this can be aliased from the feature that language provide already. Templates and modules can be named at user discretion, as well as lua functions, but user can't alias keywords like if. --Psychoslave (talk) 21:52, 11 November 2016 (UTC)[reply]
  • I can imagine this being somewhat helpful, especially outside the context of Wikimedia projects (in teaching and such; modules aren't that common), but once you venture off from Latin script languages, everything starts stacking up against you. There's scarcely any infrastructure for basic things. As a native speaker of a w:Right-to-Left language I can tell you the complications'll be much more interesting than most European language speakers would think, and it's exactly the non-Latin script language speakers this would be most useful for, I mean It'd save you needing to learn a new script. Here's a clip of a guy who made an Arabic programming language and you can see that even without nice features this not simple. Enosh (talk) 09:29, 11 November 2016 (UTC)[reply]
    There is also chinese python in the family on non-latin script programming language. --Psychoslave (talk) 21:51, 11 November 2016 (UTC)[reply]
  • I'd basically say, show me when Amazon and Facebook are doing it, and then we can consider. This problem is so complex, it's not a feasible wikimedia project. —TheDJ (talk • contribs) 11:14, 11 November 2016 (UTC)[reply]
    You can play with lupa right now which is a modified Lua 5.3 interpreter which allow coding with Esperanto keywords (a more modular approach to allow easy translation to other languages is planned). I don't say it's ready for production and that the road between this project and what it would take for a smoothly integrated solution of this proposal in the WM environment would be easy. As far as I know, no single big corporation as achieved projects like Wikipedia, but our community did it. If you have more specific feedback on difficulties to implement such a proposal, please share it. --Psychoslave (talk) 21:51, 11 November 2016 (UTC)[reply]
    GCC hasn't done it either, and they've been around for a lot longer than us. MER-C (talk) 08:28, 14 November 2016 (UTC)[reply]
    First, what's the point of listing all projects that didn't make what's proposed here? If they never felt this need, then surely they never implemented it. Now if they explicetely rejected the idea with some rational arguments, that may worth having a look at it and you are welcome in providing a link to such a document. Moreover, GCC is mainly used directly by end users: unlike Scribunto modules in the WM, end users have necessary latitude to modify the environement to fit their wish. In C-family programming language, one might use a set of #define as a quick solution to translate keywords. Also note that GCC doesn't even support unicode string for identifiers despite it's already included in 1999 C standard, the code can only include the akward \u notation. On the other hand, Clang supports extended identifiers since version 3.3. So it looks like GCC is not really the paragon of internationalisation support that one might take as an example. --Psychoslave (talk) 08:31, 15 November 2016 (UTC)[reply]
  • I hope this is a joke. Programmers speak their own internationl language. --Dixtosa (talk) 10:25, 12 November 2016 (UTC)[reply]
    Hi. Please don't waste both our time with comments which bring no constructive information, with unnecessary haughty tone. --Psychoslave (talk) 12:34, 12 November 2016 (UTC)[reply]
  • Several points:
    • I don't think this would really be that difficult. Ideally, we'd have a button above the editing area that allows switching languages on the spot, allowing code to be moved across wikis, and allowing modules to be edited even if they were originally written in languages foreign to the editor. (Regarding technical implementation, it might make sense to store the modules in "English" (standard Lua) even if the "English" is not ordinarily visible to editors.)
    • I'd like to remind everyone that contributor-built Lua modules are not the same thing as WMF internal software development in PHP/JS/etc. The entire thing is built around random volunteers being able to safely and easily code simple things. If this is blocked off by language to most contributors, that severely limits potential use.
    • It's important to remember that Lua's predecessor, which was a giant pile of parser functions, already had this option. #if, #ifeq, #switch, etc were all localized. Further, this was done even when it meant that templates couldn't be easily moved across wikis. For Lua this wouldn't be the case, so all the more so other languages should be supported.
  • Allowing people to contribute regardless of language is an extremely important principle throughout Wikimedia. We should uphold that principle if at all possible. --Yair rand (talk) 18:01, 13 November 2016 (UTC)[reply]
  • Agree with TheDJ—this is simply not feasible. MER-C (talk) 08:28, 14 November 2016 (UTC)[reply]
This proposal could be implemented to degrees on a scale, from just adding Spanish coding, to any western alphabet language, to any alphabet or abjad. So it seems that saying it is not feasible indicates too ambitious of an implementation. Perhaps start with Spanish, then Portuguese, German, and French, before taking on Arabic, Hindi, Bengali, and Russian. Finally Chinese and Japanese could be developed. Bcharles (talk) 02:07, 16 November 2016 (UTC)[reply]
  • Coding doesn't happen in primarily in English but in programming languages. Companies that operate in non-Western countries still use the same programming languages. Despite being a German native speaker, translating "if" or "while" into German would make it harder for me to read code. ChristianKl (talk) 10:56, 16 November 2016 (UTC)[reply]
    • I'm affraid I don't clearly understand you first sentence. For the second point, well, of course when you don't have much localized programming language out there, there's not many company which use localized programming languages. Actually, there are some localized programming language, such as WinDev, which are used by some companies in the wild. Now, I wouldn't recommend WinDev to anobody out there, but it does exist. Note that here the main purpose for such a project is not to fit the custom of already super skilled developers. The goal is to lower the barrier for non-programmers. Those who may have a computable need and a desire to build a little script to solve it, but which might be discouraged by the barrier of language. --Psychoslave (talk) 14:28, 21 November 2016 (UTC)[reply]
  • This would not be practical for the Community Tech team to implement unless Lua were internationalized via some 3rd party library, such as your Lupa interpreter (but for multiple languages). No one at the WMF is in the business of writing interpreters, and it doesn't seem within our scope to do so. Ryan Kaldari (WMF) (talk) 01:23, 22 November 2016 (UTC)[reply]

Complete translation for Wikipedia app

edit

Machine translated, please help to improve! -- Aplikacja Wikipedia

  • Problem:

I greet you warmly. One small problem is bothering me. Sometimes I use the Wikipedia App on Android and I do not like that some things are in English, such as continue reading, randomizer, trending, because you read and probably others. I hope that the problem will soon be resolved.

Moi drodszy,
Na początku mojej wiadomości serdecznie was pozdrawiam. U mnie wszystko w porządku czego i wam życzę z całego serca. Nurtuje mnie jednak jeden mały problem. Czasami korzystam z aplikacji Wikipediia na Androidzia i bardzo nie podoba mi się, że niektóre rzeczy są po angolsku: continue reading, randomizer, trending, because you read i zapewne inne. Mam nadzieję, że problem zostanie szybko zażegnany.

Community discussion

I guess this is a complain about Wikipedia App for Android not being fully translated into Polish. This can be done quickly on translatewiki.net. Matěj Suchánek (talk) 21:47, 10 November 2016 (UTC)[reply]

Many of these have very recently been translated (e.g.) and will be visible in the next app update (first the beta app, then the main app). However, I've filed a bug (phab:T150549) for the one that I think should already be working. I'll collapse this proposal in a few days, hopefully someone can translate this into Polish, please? Thanks. Quiddity (WMF) (talk) 20:24, 11 November 2016 (UTC)[reply]
Need app wikipedia can translate page to other language, with Special:Translate. Murbaut (talk) 14:25, 15 November 2016 (UTC)[reply]

Hi Zwiadowca21—as stated above, the translations can be done on translatewiki.net. This isn't a technical project, so it doesn't fit into this survey. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 00:04, 22 November 2016 (UTC)[reply]

Send OpenStreetMap Foundation money

edit
  • Problem: While separately-organized entities, the WMF's projects like Wikipedia, Wikivoyage and Wikidata are closely intertwined with OpenStreetMap (and the former two rely heavily on its data to show geographical information). Currently, they're apparently struggling to reach €70,000 in funding, which seems minuscule relative to WMF standards. (Although I have edited OpenStreetMap, I am not affiliated with the OSM Foundation and no one asked me to post this. I just thought it might be a good idea.)
  • Who would benefit: The OSM community and everyone else who uses their data, including Wikipedia, Facebook, and occasionally Apple.
  • Proposed solution: Send them a small loan of a million dollars medium-sized donations (periodically or one-time) so they can sustain their project and improve their servers/website/infrastructure/community organization/documentation.
  • More comments: This is totally unnecessary, but I thought it would be a rather nice thing to do given that (a) we depend almost entirely on their data for interactive maps and map images and (b) the WMF has a rather large cash pile compared to OpenStreetMap. (I originally posted this in Chapters and Affiliates but that seems to be incorrect, since there are no OSM-linked affiliates.)
  • Phabricator tickets: None yet.

Community discussion

Hi Jc86035—as noted above, this proposal is more like a grant request than a tech project for Community Tech, so it doesn't fit into this survey. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:24, 22 November 2016 (UTC)[reply]

Record the country location for each edit

edit
  • Problem: Chapters (but also affiliates) have problems to identify from which country there is an edit. We know that the IP is a private data but the country where the edit is done can be identified in several cases and it is not a private data. Chapters in general support the local community and sometimes are contacted by wikipedians but it's difficult to identify from the user page if the user lives in the country of the chapter. At the same time in any on line contest it would be helpful to know from which country people participated.
  • Who would benefit: Chapters, administrators, users and in general everyone who needs to georeference an edit.
  • Proposed solution: Where it's possible, the IP can be georeferenced per country, the IP information will be kept hidden while the country will be part of the page history. This information can be integrated in the chronological information.
  • Phabricator tickets: There is no Phabricator ticket, it is interesting to know the opinion of the community.

Community discussion

  • I like this idea. However, if the geographical data can be really twisted if the general public is banned for using Wikipedia and people who wants to read or edit Wikipedia can only use VPN, such as the case in China, then won'these kind of contribution disturb the tool? --Liang(WMTW) (talk) 00:27, 13 November 2016 (UTC)[reply]
  • We already record geoip information for all requests, however even something as inaccurate as country from where a particular edit was made is absolutely private and we are unable to make it public. For example, would you really like everybody to see where are you travelling? And even if you don't mind, how many people disagree with you on that? Max Semenik (talk) 02:03, 13 November 2016 (UTC)[reply]
  • I support the attempt to understand the community position in a public discussion, instead of not discussing it. Right now, as internet users, we already "provide metadata" to many third party. More in general, as I discussed with other wikimedians, we are very slow to absorb the zeitgeist of the internet (as in the case of this aspect) and that's not bad, but we should be able to actively take the right direction soon or later, whatever that is. The delay we often experience is not an issue per se (even if our "architecture" sometimes looks "old"), as long as it allows to make a much more informed choice in agreement with our principles and our users. That being said, as Ilario knows, there are much more efficient target possibilites with registered users. A progressive strategy to do would be to act at that level, see the potential, than improve it. BTW, the algorithms to analyze user pattern I've drafted could be applied to IP pattern. It should be possible once recent data are stored, to extract given a specific area, a group of IPs active there. They might be linked to just few users, but they are there. In any case politically, I would try to test some voluntary metadata submission. Everytime an IP saves, a small box appears to allow this type of reuse in a much free way, something like that. Some people use IP because they don't think their network is secure, because they believe in this type of contribution as a symbol of the variety of the wiki environment, because they don't want to log in as it takes time. But maybe they have nothing against their metadata being used. IMHO, what WMF should do is to put a warning, a release form or something similar when an edit is saved. At least in ns0, or content-related namespace. And maybe after a while this perspective could be reversed, namely it is free to opt out but the default scenario is to provide such information (but this is much more stonger, it will require more results and discussions, I also doubtful about that at the moment). Of course, it should be up to every platform to allow this or not, we can start with just some of them and see how it works. As I've been learning over the years, often a simple 5-10% sampling of a group can be enough to target effective policies. Again if a minority is happy to share those information "freely", I don't see why a majority should oppose for an ideological reason.--Alexmar983 (talk) 05:03, 14 November 2016 (UTC)[reply]
  • Note for Ilario: I moved your proposal to this category, because "Chapters and affiliates" isn't a popular enough category. Just FYI. -- DannyH (WMF) (talk) 18:19, 14 November 2016 (UTC)[reply]
  • I strongly disagree with the statement that "the country where the edit is done can be identified in several cases and it is not a private data". Why it is not private? This information could be shared only for those who explicitly agree to share it. Bot anyone who wants to state their country can do so on the user page. Alexei Kopylov (talk) 20:10, 14 November 2016 (UTC)[reply]
It can be guessed, in some cases... as far as I know. Here is an example: if a user that knows Vietnamese and writes also on enwiki since many years, you can guess it is probably living in Veitnam or US or Australia or UK etc but you don't know where of course.. but if its recent images of Vietnam on commons are all taken on holiday season or specific weeks, and the rest are instead all scattered over the year around a certain area... and he's discussing on a talk page of an article about a local topic (metro system of a town, election of mayor...) and he uses a certain spelling, well you kinda know where he's living and that he's not in Vietnam. Again it's not precise in many cases, but I can tell you it's not so wrong either. Maybe he also moved to Germany in the last months and you don't know, but you can grasp some truth. Edits sometimes are like crumbs, you can follow them as in the fairytale. With some users you can guess a precise area, with other ones you can only be generic, but it is feasible. Of course does the user "explicitly agree to share it" or not? Problem is, what is "explicitly"? For a good or expert observer, many details are explicit, in the end. Are you, the observed, aware of this?--Alexmar983 (talk) 13:49, 15 November 2016 (UTC)[reply]
  • Personal example: I'm very much not anonymous when I edit, but if I were, country data for each edit would not only be private information – it would make it easy to identify who I am. For example, I occasionally do ambitious edit articles related to science fiction literature on Swedish Wikipedia. The Swedish science fiction scene is not big, so there is a limited number of persons with an encyclopedic interest in the literature, but many enough that you can't just guess who could have written something if we're all pseudonymous. You can't assume it's someone you know. However, I recently moved to Berlin for a while, and will be moving back to Sweden towards the end of the year. If the edit pattern on a specific subject shows that this user spent a couple of months in a country and it correlates with me moving there, it would be easy for a lot of people with interest in the same subject to figure out who's behind the edits. Even more so since you could track me whenever I'm travelling. Also, when editing very specific subject, the location of someone can be a very big step towards identifying that person even if they don't move around, e.g. someone editing Bokmål (Norwegian) Wikipedia from Estonia. /Julle (talk) 07:00, 15 November 2016 (UTC)[reply]
  • Any data which would allow you to guess who I am is private data; knowing when I travel internationally is such data, and could be determined by watching the country I edit from. And there are some rare country/language combonations, which may be useful in determning who some editor is - for example, a Hebrew editor in Lebanon. עוד מישהו Od Mishehu 07:24, 15 November 2016 (UTC)[reply]
  • Lack of geoip is hampering researches trying to understand Wikipedia community. But while people are giving away their private information left and right, and Facebook and such know a ton about an average person or Wikipedia editor, we don't even know basic demographic info so that we could understand ourselves better. Shrug. I doubt this will ever change. People like privacy, and Wikipedia is the only place on the net where it is respected. --Piotrus (talk) 07:59, 15 November 2016 (UTC)[reply]
  • Privacy means you decide what to say about you, it does not strictly mean you decide what people should say about themselves, unless they are minors. If some users are willing to share this information and they say they're above 18, it should be possible to allow that. I mean people are giving metadata everywhere because they don't know or don't care, I am sure some of them could be ok with that here. Making this public, explaining it, will make us more ethical than everyone else. Just to be clear: I would never tick the box in the case, unless I am using such data (and I don't need them) and in that case I would consider hypocrite not to do so. But that's more of a personal choice. That being said, if I want to know where an active user is from, is not really that complicated even now. What about your pictures on commons? What about a spike in minor contribution on a different wiki (for example you're more active with minor edit on dewiki, suddenly... maybe you have a new German-speaking partner or maybe you move to one of those three countries...it's subtle but it's there)... you forgot to log in and you edit with your IP, than correct an edit that is clearly done with your pattern immediately later with your username. I could check on line, and see more or less the area of that IP with some simple website. Nothing is 100% sure but even if you write about a non localized topic such as chemistry or science fiction, with sufficient attention people can get more or less an idea about where you are in the majority of cases. it's a generic information but still from that, combined with additional details you leave here and there, pinpointing is not difficult, if someone has the will to do it (basically a stalker). Also people talk A LOT. Wikimedians say a lot of things about other people, the more they want to be anonymous, the more you know. I guess we could make a seminar about that, I'm surprised these concepts are not discussed as they should, and I keep saying that a lot lately. I'm also surprised how people are often confused and they worry too much about things that are quite feasible where the focus should be not to be sure that someone can't do but to realize that skilled people can do it in any case already and you can't control it... also I think that we forget to target areas where maybe we can actually improve something about our privacy. For example I would expect more people to ask WMF to put some limit to the power of check users, so it can be even more balanced and controlled than it is now... and it can be much improved, as I realized discussing with other people offwiki. Good to know because I was thinking about that. --Alexmar983 (talk) 13:17, 15 November 2016 (UTC)[reply]

Hi Ilario, as stated above, this proposal isn't allowed under the Wikimedia Foundation's Privacy policy. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:27, 22 November 2016 (UTC)[reply]

Increase access to Wikipedia

edit
  • Problem: Censorship of Wikipedia. There are over a billion people who do not have access to Wikipedia, or only have partial access to Wikipedia due to censorship. This causes individuals to not be fully informed of a wide array of subjects.
  • Who would benefit: Over a billion people, who presently aren't able to access w:Wikipedia.
  • Proposed solution: Have the Wikimedia Foundation, assist on solutions, either through financial support or providing volunteer and/or paid opportunities, on creating a way of providing access to those who are presently blocked from reading Wikipedia in its various forms to bypass those blocks to freely access Wikipedia and the other projects of the Wikimedia foundation.
  • Phabricator tickets:

Community discussion

Unfortunately, some nations since they cannot see what is being viewed on Wikipedia, has blocked all of Wikipedia, cause they are unsure that people within their nation are viewing information which they choose to censor. This is explained in the Wikipedia article which I linked in my proposal. I honestly do not know what exactly Wikimedia foundation can do, but IMHO if they can do something to increase access to Wikipedia in nations where it is blocked, it will only help the people who do not have access to the knowledge which is on Wikipedia.--RightCowLeftCoast (talk) 12:25, 15 November 2016 (UTC)[reply]
Anyway, you definitely need to clarify this proposal. It's too broad. I doubt Wikimedia would want to help people get around blocks country-wide blocks on Wikipedia, as that would have major legal implications. — Gestrid (talk) 19:45, 14 November 2016 (UTC)[reply]
Thanks for the info about Phabricator. That's unfortunate, guess the ability to read about the W:Tienanmen Square Massacre, or any number of other censored items to billion plus people isn't needed then.--RightCowLeftCoast (talk) 12:25, 15 November 2016 (UTC)[reply]
It would be good if everybody could access Wikipedia but that doesn't mean that any action to circumvent blocks doesn't come with costs. It's not Wikipedia's role to develop Tor or proxy networks. ChristianKl (talk) 15:04, 15 November 2016 (UTC)[reply]
Making sure people can access Wikipedia is on of the most important things, or the most important thing, the Wikimedia Foundation does. The problem is that there's a limit to what you can do when a nation state with control of the networks within their borders decides to shut off access. As noted above, we introduced forced HTTPS last year, which makes it more difficult to shut off access to individual articles – anyone watching the traffic can see it's going to Wikipedia, but this is to make it far more difficult for them to tell which article someone is reading. We could mirror the content, but countless others are already doing that, and the general public would never find us before the censors did and shut off access to the new site. In some countries, Tor or a general VPN service are ways to get around this, but these solutions exist and are developed by experts on the technology. We couldn't do it better than they already are. And we can't overthrow governments.
It's not that we don't consider this of uttermost importance, it's just not much the Community Tech team can do here. Unfortunately. /Johan (WMF) (talk) 11:47, 16 November 2016 (UTC)[reply]

Hi RightCowLeftCoast, as stated above, this proposal is a larger sociopolitical issue, and not something that the Community Tech team could act upon. I've archived your proposal here; thanks for participating in the survey. -- DannyH (WMF) (talk) 01:29, 22 November 2016 (UTC)[reply]

Let's fix our relation with maps / Nearby gadget

edit

WikiVoyage has a tool called Dynamic Maps: [2], which may be relevant for this discussion, it also has numerous problems with bad code, but it shows promise (when it works it allows for pretty boundaries - not some deep red shade, but instead light inside, dark outside - and for POI markers). Compare https://en.wikipedia.org/wiki/Wonju and https://en.wikivoyage.org/wiki/Wonju for example, WV wins hands dawn.

There may be other tools I am not familiar with, all disorganized, not connected, with no uniting strategy. It's a mess that needs to be fixed!

  • Who would benefit: All WMF projects using maps. All end-users.
  • Proposed solution: Let's organize all the mapping WMF projects together. Why is WikiVoyage mapping separate from Wikipedia? Who maintains WikiMiniAtlas? Is it another imitative dependended on one user who will one day leave and the entire plug in will collapse?

Also, why are our WikiMiniAtals maps hidden as small globe? They should be proudly displayed as a proper image, expanded, not hidden waiting for 1 user in a 100 to find that feature.

And WMF should develop a proper map strategy. They are very important for mobile devices and computers alike. Making Wikipedia more map friendly would be a major milestone in making it more useful. Wikipedia is over 15 years old, it is time we got some good maps!

  • Phabricator tickets:

Community discussion

  • Ehm, this is mostly all done and dusted. What you see in Wikivoyage IS the maps work that the WMF has done over the last year and each wiki community that wants to use it can use it too (don't expect the WMF to start editing content). Now surely, we can do a LOT more with maps integrations, but this survey is about the community making specific software requests and "make a strategy" doesn't really seem to fit that I think. I suggest coming up with more concrete proposals on how and where to use maps and filing those individually. —TheDJ (talk • contribs) 00:00, 16 November 2016 (UTC)[reply]

Hi Piotrus - as noted above, there's a WMF Maps team which is working on the issues you've brought up. I've archived this proposal, thanks for participating in the survey. -- DannyH (WMF) (talk) 01:31, 22 November 2016 (UTC)[reply]

Make it possible to merge user accounts and contributions

edit
  • Problem: Users who contributed with multiple user accounts or with a registered user account + as anonymous contributor can't keep all their contributions together
  • Who would benefit: see above
  • Proposed solution: To make it possible to merge user accounts, and anonymous contributions with registered user accounts
  • Phabricator tickets:

Community discussion

The problem with anonymous users is that there is no way to know that the author of the edit is the one requesting the merge. עוד מישהו Od Mishehu 12:43, 15 November 2016 (UTC)[reply]
  Oppose Part of this is already possible via Steward requests/Username changes. The other part is impossible, as anonymous contributors are...well, anonymous, so noone can prove or be sure that these contributions were performed by a specific person who claims so. So I am afraid that this proposal is invalid. --AKlapper (WMF) (talk) 12:45, 15 November 2016 (UTC)[reply]
@Od Mishehu & AKlapper: in the request for merging some IP address contributions to an user account, the request should be signed both with the registered user account and with the IP address, in a short time. --92.115.106.250 14:39, 15 November 2016 (UTC)[reply]
@AKlapper ("Part of this is already possible via Steward requests/Username changes") - that page says "We are sorry to announce that Global User Account Merges are not possible, and will not be in a near or mid-term future. As such, we will not accept any request to merge user accounts as it is technically impossible at this moment to do so." --92.115.106.250 14:39, 15 November 2016 (UTC)[reply]
The phab task for merging registered+anonymous, is phab:T31188, but as above, it's difficult to determine who originally saved a change from an IP address. I.e. The person using the IP might have changed within the last few seconds (e.g. the next person to use the IP address 92.115.106.250 might be someone different from the original editor here). If I understand correctly, you are additionally proposing that specific edits (not the entire contribution-history of an IP address) might be merged to a registered user, which would probably be a subtask of T31188, but even more difficult code-wise. I don't think the benefits would warrant the quantity of work required, but you could propose it there.
I believe the phab task for global user merge is on indefinite hold, because of the massive complexity of our user database tables, per phab:T49918#1985840.
Hope that helps. Quiddity (WMF) (talk) 20:04, 15 November 2016 (UTC)[reply]
No hope even with accounts with very few edits? I mean are some accounts much worse for example?--Alexmar983 (talk) 16:49, 16 November 2016 (UTC)[reply]

Can't we have at least something like an adoption mechanism? Like the registered user can (maybe within 24 h, 7 days or similar) mark an IP edit as "his/her edit". Something that is marked as an additional summary, or similar. Sometimes people write this in the next summary of a following minor edit, but a box to select would be nice. At least we know who's who, and also nasty accusation of improper IP use can be debunked (if I mark the IP as mine, it's clear it was a mistake).--Alexmar983 (talk) 08:24, 16 November 2016 (UTC)[reply]

I'm (cluelessly) wondering about the implications of wmf:Privacy policy. --AKlapper (WMF) (talk) 13:13, 16 November 2016 (UTC)[reply]
You're right... but can't we put a warning that you're linking yourself to an IP and you should be aware of this and that? Although sometimes you do that also because the IP is not your usual connection that's why you're not logged in, and it's also actually quite easy from a pattern to understand when an IP is from an unlogged user based on topic and style. I don't know... I don't say this is superimportant, but it is strange that we don't have a standard way to say that, if we want to say it. For example, last summer someone from my house did a edit I knew nothing about initially but I tried to fix it and I said in the talk page that it was "my IP". I mean it is not the same example but if I could have put a virtual post-it, under codified rule, saying "this was my relative, (s)he did a copyviol and I'm fixing it" I would have preferred. I mean what could have happened? That someone knew the area where I live, which is known? The provider of that house, which is a very common one? That my relative protected by my IP cares about his/her mistery and protests? I don't know really. If the community thinks that the common good is to protect everyone from the slight possibility of a misuse, fine with me in any case.--Alexmar983 (talk) 14:58, 16 November 2016 (UTC)[reply]
I think that the proposal is unbalanced. Merging accounts and account and IP edits are two different problems as level of complexity, IMHO. The first should have been possible by now in our dreams, and in any case it's much less controversial from the point of view of privacy. I would say that of course we should start with the first aspect, than move to the second one, probably. In an ideal world. Too bad it is on hold.--Alexmar983 (talk) 16:46, 16 November 2016 (UTC)[reply]

The most realistic method for allowing users to "reclaim" anonymous edits for a while would be to generate throwaway accounts for anonymous edits (T133452). Which is a change with far-reaching implications. --Tgr (WMF) (talk) 03:17, 18 November 2016 (UTC)[reply]

Proposal #Linking of accounts controlled by one user seems more realistic than this. --𝔊 (Gradzeichen Diſk✉Talk) 09:38, 18 November 2016 (UTC)[reply]

Certification program

edit
  • Problem:

There are many wikimedians who are very active online but they never take a step forward to help others and train them either through workshops or even persons around them. The second category is editors who are active offline, but they don't have an official recognition to train others. The audience will implicitly say, who are you to teach us how to edit on Wikipedia ? Saying that you are an active member or an editor is not very credible or convincing to many.

  • Who would benefit:
  1. The wikimedians who are interested to train new editors in workshops;
  2. The teachers involved in the education program;
  3. Anyone who is interested to have a certificate from a famous organisation like WMF.
  • Proposed solution:

WMF create a certification program that contains one or many levels and series of questions for each level (the same concept as LPI for Linux). Who succeed the test will receive an electronic (or paper) certificate from WMF.

  • More comments:

This solution will encourage a lot of people to participate and contribute more. People love certificates and work a lot for them ! Once they will have them, they will show up and train others to approve that they deserve it.

  • Phabricator tickets:

Community discussion

I like this Murbaut (talk) 00:46, 16 November 2016 (UTC)[reply]
  • This work is already ongoing in Community Engagement/Leadership Development Dialogue which says, "We need your help in refining not only what the Wikimedia Foundation provides in terms of direct training activities for community leaders, but also to refine how we describe those leaders." Note there are 4 collapsed-sections on that page with further details, or a blog post if you prefer that more narrative-style of description. There is a lot of interesting discussion on the talkpage. Please do join in on that work and the existing discussions! -- As such, and also because this is not a primarily-software-related issue, it is outside the scope of this wishlist. Hope that helps. Quiddity (WMF) (talk) 19:30, 16 November 2016 (UTC)[reply]

Hi Vivaystn - as noted above, this proposal isn't a tech project that the Community Tech team can work on, so it falls outside the scope of this survey. I've archived your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:34, 22 November 2016 (UTC)[reply]

The navigation of the special:prefixindex

edit
Bug filed as phab:T150918.
  • Problem: The navigation looks like a Mess. like this, If we click 'Next Page' one time, it will find that there is no 'last page' to go back. It seems that we lose some subquery because of the query by the key 'from'. It's a bad implement.
  • Who would benefit:
  • Proposed solution:
    • Without the saving status: We can get a whole query record with the condition, and then just use the limit function of MySQL (or the other operation as same as the limit function on the other datebase implement.) to get subquery to show. We need the mark of 'limit','offset' to control the location of the query list.
    • With the saving status: Get a whole query record and saved a new records list with a new query token by a new query with click the 'show' button. then the subquery get in the records list with 'query token','limit' and 'offset'. The records list will be cleaned up automatically after a moment to release the space.

Community discussion

@Cwek: Thanks! Could you clarify in the proposal summary what is the actual problem to solve here? Are you "only" requesting that the navigation of Special:prefixindex misses a 'Previous page' link? Or something else? Is this phab:T32965 (which is resolved)? What is "the saving station" (sorry but I don't understand what is meant by that)? --AKlapper (WMF) (talk) 13:18, 16 November 2016 (UTC)[reply]
For example, if I understand correctly, you want these 2 pages to have identical navigation links (Previous & Next), after you click "Next page" once:
Is that correct, or do you want something more complicated? Quiddity (WMF) (talk) 19:49, 16 November 2016 (UTC)[reply]
@Quiddity (WMF):，Are you sure that the Special:PrefixIndex is right? Yes, I mean that it seems like there's no 'Previous page' function on the Special:PrefixIndex.
Sorry, 'saving station' is a mistake, it's 'saving status'. --Cwek (talk) 00:50, 17 November 2016 (UTC)[reply]
@Cwek: What do you mean by "is right"? (I'd guess you might be thinking of the URL: I changed the URL by hand, so that the 2 links were easier to compare. The default URL that it gave me was: https://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=foo&namespace=0 but both links work the same. I think there is/was a plan to fix all those /w/index.php links eventually, but that's a completely different problem!)
I've filed a bug at phab:T150918 which I believe covers this proposal. Please add any additional problems that the bug causes for you, in that task.
For this Wishlist, the bug is small enough that we should probably exclude it from the list of items that everyone gets to vote on in 12 days. There are already 230+ proposals, and we have to try to keep the list limited to high-importance problems, so that people can read and understand them all, and thus use their time wisely. I hope that seems reasonable to you. Thanks for the bugreport! Quiddity (WMF) (talk) 01:20, 17 November 2016 (UTC)[reply]
I think the description on phab:T150918 is clarity for the problem. Thanks.--Cwek (talk) 01:42, 17 November 2016 (UTC)[reply]

Edit the summary after saving

edit
  • Problem: It can happen that because of a distraction, your summary is not as complete or correct as you were expecting. Sometimes it's a slip of the mouse. But on a text I can reedit the mistake it later, I can't for a summary. Why so? Would it be possible in a certain time range to reedit that text? It's not so important, but it happened to me a dozen times during the last five years that I really would have like to do something about that. Last time a strange collapse of my web browser windows made me for example save an incomplete edit summary right when I was supposed to give there a copyright information. What are the odds? I put it also in the talk page, as I was also planning to do but still it would have been useful to fix that. And I couldn't.
  • Who would benefit: Everyone.
  • Proposed solution: This information has to be saved somewhere, so I guess it should be possible to change it. Or at least, as I suggested with the proposal of merge of IP contribution, to add a second summary after a while with additional information. Maybe just for more advanced or registered users, something like the autoconfirmed users. And maybe only for ns0 or content-related namespaces.
  • Phabricator tickets:

Community discussion

@Alexmar983: Is this the same as phab:T71393 when it comes to VisualEditor? --AKlapper (WMF) (talk) 13:19, 16 November 2016 (UTC)[reply]
Thank you AKlapper (WMF). Is this a way to recycle a previous summary? Or just an way to keep an edit in a limbo on the VE before actually saving it, sort of a more sophisticated preview that also affects the edit summary? I really don't use VE but does it have something like a separated summary window that appears only after the edit (upper right of the screen, right?), which of course increase the focus on this aspect and therefore reduces the frequency of mistakes? I remember I did suggest more than two years ago, in order to help newbie and users with very repetitive tasks, that at least in VE some sort of automated summary could be introduced. Like if insert a template X, VE summary automatically insert the text "template X added" in my edit summary preview. Not that this solve my problem per se, but of course the higher the reduction of human editing, the lower the possibility of a loss in some information. But the main questions remains: why is the edit summary so "rigid" in our architecture?--Alexmar983 (talk) 14:17, 16 November 2016 (UTC)[reply]

A difficulty with edits to summaries is that you then need a history for the summaries and an ability to watch those types of edits (e.g. more entries in RecentChanges). And then possibly the ability to edit the summaries in that history, which needs a history for those edits, etc. Anomie (talk) 18:18, 16 November 2016 (UTC)[reply]

Yup, and this is part of why it was declined in phab:T15937#2606108, with more details there. Quiddity (WMF) (talk) 19:55, 16 November 2016 (UTC)[reply]

I believe this was in last year's survey, and as such, I think this is a good idea. I think that if the editor changes it within a quick window, there would be no need to keep a history—just allow an overwrite. I make mistakes in my summaries, and if I could fix it within 5 minutes, most of those wouldn't exist, and I wouldn't have to consider doing the occasional "null edit" to "correct" the previous summary. Stevie is the man! Talk • Work 19:13, 16 November 2016 (UTC)[reply]

I can think someone of abusing edit summaries if this is possible. --Stryn (talk) 20:45, 17 November 2016 (UTC)[reply]
There is a very simple answer to this issue, you do the same thing you did with all features that you consider critical, you restrict their use to specific classes of users. Probably autoconfirmed or autopatrolled/autoreviewer. And you test for some months if even under this assumption the abuse is a likely scenario (I bet it is not). Usually the summary is used mainly by expert users, newbie mainly forget it, I don't expect them to know this feature exists. In their case the goal is to understand the summary exists. As a very specific option restricted to large yet selected group, I guess its use will not be critical. That would be disappointing for expert IP, but again half is better than nothing.--Alexmar983 (talk) 04:08, 18 November 2016 (UTC)[reply]
If "summary overwrite by users with a specific right" isn't palatable to enough people, perhaps we could have an official "summary correction edit" instead, whereby the editor is simply doing an edit to correct or rephrase an earlier summary, and that gets tacked on in the page history, but without the usual link to a diff and such. I don't know of the technical feasibility of doing it this way, though. Stevie is the man! Talk • Work 13:44, 19 November 2016 (UTC)[reply]

@Anomie: Maybe after Multi-Content_Revisions this could be done with a non-ridiculous amount of work? --Tgr (WMF) (talk) 03:12, 18 November 2016 (UTC)[reply]

That looks like a possible pathway, never heard of that. I gotta read it carefully now. I mean, I guess we are open to every pathway here.--Alexmar983 (talk) 04:08, 18 November 2016 (UTC)[reply]
"This requires a substantial refactoring in the storage layer of MediaWiki"... so you are targeting one of the core issue, am I getting it right? This would requires, I suspect, also some calibration with the revision flag system and the to-be-confirmed preview mechanism existing on some platforms, maybe? I see that the problem is complex, but solving it would really open some intriguing possibility.--Alexmar983 (talk) 04:12, 18 November 2016 (UTC)[reply]
@Tgr (WMF): Edit summaries wouldn't be a "stream" or "slot" in MCR, they'd still be a property of the revision itself. So MCR changes nothing here. If you try to shove the edit summary into a slot somehow, you'd end up with this request being roughly "I want to be able to change the content of an old revision instead of creating a new revision with my new content." Anomie (talk) 15:04, 18 November 2016 (UTC)[reply]
ok but can we have, don't know, a revision that changes the summary and not the content? So: my content is fine, but I made a mistake in the summary, can I make a specific dummy edit that add my summary after the original one?--Alexmar983 (talk) 05:00, 19 November 2016 (UTC)[reply]
@Alexmar983: As above, that "edit to the summary" would need to be logged and viewable. It would complicate both the UI of all the various pages where edit summaries are displayed, and also complicate the databases. Per above and phab:T15937#2606108, this has been archived. Quiddity (WMF) (talk) 01:32, 22 November 2016 (UTC)[reply]

List of 1000 most visited articles a day

edit
  • Problem:

We do not always know what our readers need. Special difficult on smaller Wiki's.

  • Who would benefit:

The editors may add more quality to the most read articles, to the benefit of the readers. Could also be used for corporation with organisation related to frequently visited articles.

  • Proposed solution:

A list of the 1000 most visited articles on every wiki project. Like this. This would also be relevant for projects within a wiki.

  • Phabricator tickets:

12:52, 16 November 2016 (UTC) (with credit to User:Stigmj )

Community discussion

In my proposal I also described the possiblity to for projects within a wiki; The total views and top list of articles in a category hierarchy, and within a portal. F.ex. The total views of articles in the category hierarchy in the Medicine Portal, and the 500 most visited articles in this hierarchy each day. Maybe this also exists already? Hogne (talk) 10:33, 18 November 2016 (UTC)[reply]
@Hogne: To some extent, yes. There is also the Massviews tool which lets you get pageviews for pages from several sources such as a Category. See the FAQ and Pageviews Analysis#Massviews for some documentation. I will give you some examples (the sources are which option to pick on toollabs:massviews):
Etc. If this doesn't fulfill your wish, feel free to request any new features at Talk:Pageviews Analysis. This is an ongoing project and we're always looking for ways to improve the tools. Best, MusikAnimal (WMF) (talk) 19:46, 18 November 2016 (UTC)[reply]

Hi Hogne - as MusikAnimal says above, we'd be happy to talk to you about new features at Talk:Pageviews Analysis. I've archived your proposal here, thanks for participating in the survey. -- DannyH (WMF) (talk) 01:35, 22 November 2016 (UTC)[reply]

Improve the AbuseFilter extension

edit
Stopping this taking up space.
The following discussion has been closed. Please do not modify it.
  • Problem: The AbuseFilter Extension - which is enabled on all Wikimedia projects - is an extremely powerful tool, but one that would really benefit from some attention, development, and improvements. A large number of requests have built up on Phabricator over the years, with edit filter managers held back from the extension's full potential by a number of restrictions and bugs.
  • Who would benefit: Many of the improvements proposed here would primarily improve the ability of admins and edit filter managers to effectively manage and deploy edit filters to fight vandalism and spam, among the other ways in which filters are used, ultimately benefiting all users.
  • Proposed solution: These are some of the major improvements and fixes that have been requested, based on discussions at the English Wikipedia and on Phabricator:
  • A return of per-filter resource tracking and improvements to global resource tracking - The extension has limited computational resources available to it, and edit filter managers must be careful to ensure that no filter uses more than necessary or certain filters will fail to run. There was previously per-filter usage information, which was since removed for technical reasons. Returning this feature, along with improved ways of tracking usage across all filters, would be a huge benefit; edit filter managers currently work largely blind of the limits imposed on them.
  • Edit filter changes on Special:Watchlist - It would be incredibly useful to be able to track changes to filters through the Watchlist. Certain workarounds are in place on the English Wikipedia, but a proper solution, integrated into the Watchlist, would be a great improvement to the oversight of these powerful filters.
  • Ability to check if edit tripped another filter - This would allow a filter to include a condition that states "if filter X was tripped". The feature could be used to save resources; putting groups of non-trivial conditions that are done across many filters to be a single condition in another filter, like a subroutine, ultimately allowing for more filters.
  • Some other important and outstanding issues from Phab:
  • Blocked users can still edit filters. (T142389)
  • AbuseFilter cannot see global edit count (so filters which target very new editors may falsely flag editors who primarily edit other language wikis) (T130439)
  • The testing interface does not work for Flow edits (T115128)
  • AbuseFilter isn't working properly with Wikidata item creations (T106136)
  • There should be a way to manually bypass edit filters (T69936)
  • Non-admins can view the contents of deleted pages through the abuse filter (T44734)
  • Filters should be able to have per-filter block lengths (T32024)
  • There are a number of strange issues regarding variable types (T140829)

Community discussion

  Proposal needs improvement @Samwalton9: Currently this proposal does not meet the requirements outlined in Community Wishlist Survey 2016#What happens during the proposal phase?: The problem description is not specific enough and several different requests are squashed into a single proposal. Could you please split your top three requests into three separate proposals? Thanks in advance! --AKlapper (WMF) (talk) 18:52, 7 November 2016 (UTC)[reply]

@AKlapper (WMF): I worried about that when writing it. The problem is that the extension really needs a large number of small improvements rather than few large ones. I've made a new proposal for what is probably the most important aspect below, and may split one or two more soon. Samwalton9 (talk) 19:45, 7 November 2016 (UTC)[reply]

Stopping frequent vandalisers who changes ip constantly

edit
  • Problem: In many small wikipedias certain "professional" vandalisers come and vandalise pages by frequently changing his ip and admins just barely fix/ revert and that is it. This causes a lot of un caught vandalisms. This problem can be observed daily in Mongolia's wikipedia and I am sure that many other small wikipedias have this disease.
  • Who would benefit: Smaller wikipedias with fewer guards/ admins will benefit and this makes general wikipedia more clean and readable!
  • Proposed solution: It is time for coders to develop maybe AI like bot or something that stop this problem.
  • Phabricator tickets:

Community discussion

  • There are three possible solutions:
    • Port w:User:ClueBot NG to some other language Wikipedia—not likely, you will need to assemble a large training set
    • m:ORES—maybe, but you still need the training data
    • phab:T5233 may help a little in the meantime. We should get this by the end of the year.
I'm not sure what Community Tech can do here. This proposal seems too vague, open-ended and complex. MER-C (talk) 01:45, 14 November 2016 (UTC)[reply]
It is not vague or open ended because there are even whole big team of moderators who help fighting against vandalisms in small wikipedias but unfortunately their smaller wikipedia language knowledge is mostly at 0 level so they mostly revert large scale vandalism text edits. But if vandaliser destroys small text then those foreign moderators are no help no mater how many of them oversee a small wikipedia. I quite sure that this problem is solvable by more of AI equipped bots or something. Orgio89 (talk) 02:05, 14 November 2016 (UTC)[reply]
I understand the problem you're trying to solve -- after all, I am an admin on en.wp who deals with hardcore abuse regularly. The solution you propose is vague, open-ended and difficult -- obvious vandalism is easiest to detect and revert automatically. You are overestimating the ability of current AI to solve this problem -- our experience is that AI is not a magic bullet (see w:Wikipedia:Wikipedia Signpost/2013-02-04/Special report#For anti-vandalism/damage and w:Wikipedia:Deferred changes). MER-C (talk) 04:02, 14 November 2016 (UTC)[reply]
@MER-C: I fixed the wikilink to Phabricator. You forgot the "T". — Gestrid (talk) 07:51, 14 November 2016 (UTC)[reply]
For most kind of AIs this is doable because it is the same person many different IPs vandalising wikipedia articles in same pattern so many algorythms likely quickly going to catch the pattern and reverting pattern so next time from different IP similar vandalism is quickly recognized. So why not the WMF coders team to develop own database protecting AI tool to stop the vandalism and ban those polluted IPs on Wikipedia. And if that IP is some one innocent consumers random ip that temporarily used by a vandaliser possibly there are other solutions to overcome that since most users have random ips. Orgio89 (talk) 01:32, 15 November 2016 (UTC)[reply]
@Orgio89: Per above, I'm afraid we'll have to archive this proposal as there's not much we can do. Vandalism is a natural consequence of the wiki that we all have to deal with. I am looking into it, but unfortunately I believe your wiki (and similar sized ones) may be too small to build the necessary datasets for machine learning. In the meantime, there are numerous tools available to all wikis to assist in fighting vandalism. The AbuseFilter can prevent common vandalism words or phrases from being added, among other heuristics. There is also Huggle, a real-time counter-vandalism tool that might assist your patrollers. I will keep you informed about ORES solutions for smaller wikis, should that team be able to help you. Sorry my reply could not be more favourable! Regards, MusikAnimal (WMF) (talk) 20:34, 22 November 2016 (UTC)[reply]
There's a possibility ORES could be helpful here, if they could get ~500 observations or so. Won't be perfect, but could cut away a sizable part of the workload. /Johan (WMF) (talk) 03:28, 23 November 2016 (UTC)[reply]

Wikipedia's "Right to be Forgotten"

edit
  • Problem:

There are dated arguments between others, which are deleted, yet, are retained by the other users who continue to horde the argument, which are usually ended, but still exist. Why can't forgiveness or forgotten-ness reign, nobody wants arguments to be retained.

  • Who would benefit:

Everyone.

  • Proposed solution:

A user should be able to identify an argument for an admin to scrap, perhaps an archive of arguments could exist for a user to decide? It should be easier to identify and remove.

  • Phabricator tickets:

Community discussion

Hi Twillisjr, This proposal doesn't really fit with the purpose of the wishlist survey. We're asking for technical projects—new tools, fixes, tech changes. Your suggestion is really a matter for policy discussion, which is better suited for a Village Pump conversation, or an RFC. -- DannyH (WMF) (talk) 19:46, 18 November 2016 (UTC)[reply]

Thanks for the input, feel free to place it in the proper place with my name. I was thinking of a tool to locate talk page edits faster, and have a tool to send and accept requests. Twillisjr (talk) 23:25, 18 November 2016 (UTC)[reply]

Twillisjr, in this case, we wouldn't be able to build a tool like this, because your premise -- "nobody wants arguments to be retained" -- isn't necessarily shared by a majority of other people on the site. You'll have to take up the discussion in another place. I'm archiving your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 02:09, 23 November 2016 (UTC)[reply]

Increased political diversity of editing community

edit
  • Problem: The community is well aware of the gap, and lack of participation, of women throughout the various projects of the Wikimedia foundation. To reduce this gap, the foundation, and the various projects and individuals within those projects have made a concerted effort to welcome, mentor, and grow the participation of women through the different Wikimedia projects. Unfortunately, it has been my experience, and perhaps the experience of others, that dependent on a potential editors political affiliations, policy opinions, or ideology that they are not welcomed into the community of project participants. This has caused some potential editors to avoid contributing to Wikipedia, to choose not to utilize the Wikipedia, and sometimes criticize Wikipedia. This may create a gap of editors, as those who do not fall within the political affiliations or ideologies that the majority of editors self-identify with, may be singled out and their editing efforts to not be given good faith and interaction made hostile to dissuade continued editing, and thus decreasing the political diversity of the editing community.
  • Who would benefit: Wikipedia, by creating a balanced and diverse editing community which will help overall neutrality.
  • Proposed solution: Perhaps, like the efforts to increase and support LGBT & Women editors, there should also be efforts to increase and support a politically diverse editing community.
  • More comments: I shared my experience on the subject during an unconference session of WikiConference North America.
  • Phabricator tickets: What is a Phabricator ticket?

Community discussion

  Oppose @RightCowLeftCoast: As per rules, this proposal seems to be outside of Community Tech's scope, as it does not seem to not involve or require any software development but instead setting up potential programs (which are not run or managed by Community Tech). If I misunderstood your proposal, please elaborate. Thank you! --AKlapper (WMF) (talk) 19:20, 14 November 2016 (UTC)[reply]

Proposals that call for removing or disabling a feature

This proposal does not call for removing or disabling a feature, therefore has nothing to do with Community Tech, and thus the rules do not bar such a proposal, as I understand the rules for proposals.

This proposal is for programs and events. There are programs to increase Women editing, and to support LGBT editors, within Wikimedia. Therefore, there is precedence for Wikimedia to provide support, or attempt to increase editing by an underrepresented group of potential editors.--RightCowLeftCoast (talk) 12:31, 15 November 2016 (UTC)[reply]
RightCowLeftCoast: Do you have a specific technical need in mind? What is it more exactly you'd want the Community Tech team to develop? /Johan (WMF) (talk) 18:54, 15 November 2016 (UTC)[reply]
Nothing. However, I believe like how there are events (and associated groups) which look to support and increase editing by the women and LGBT communities, there should be similar events (and associated groups (and WMF associated programs/initiatives)) which seek to reach out to those potential editors of political alignments that are under-represented within the Wikimedia editing community, and support them as growth to learn the pillars of editing, and become productive positive editors.--RightCowLeftCoast (talk) 00:58, 16 November 2016 (UTC)[reply]
OK. I'm not trying to brush this aside, but this Community Wishlist process is to decide what the Community Tech is to work on (and create a list other developers can look at), so if there's nothing technical you want us to develop, maybe this isn't the right place for this and the discussion belongs somewhere else where the right people will see it, and not in a technical wishlist where it drowns in twohundred other wishes. (: This is not my area at all, but maybe this would work best as a community initiative, that the WMF could support through a grant (note: I have no say in who gets grants) if resources are necessary? /Johan (WMF) (talk) 11:53, 16 November 2016 (UTC)[reply]

I have some sympathy for what RCLC is asking, but how to turn it into a technical proposal? This may not be what RCLC has in mind and might face other problems, but let me try:

Project-related draft spaces could be set up (maybe a special type of page) where only members a a specific subproject could edit, getting help from others of similar interests so that articles could be refined before putting them up for the full encyclopedia. Possible example: make a project WP:Draft articles on Women. Within this project members could propose articles, make drafts, correct other's drafts, and then say "this article is now ready to go into the encyclopedia." I'd think the technical set-up would be fairly simple, but limiting input from non-members might be quite controversial. Smallbones (talk) 17:39, 16 November 2016 (UTC)[reply]
A bit more. I see this as setting up "safe space editing" within Wikipedia. While everybody could view the draft articles, a list of self-included members would have to be set up, probably a very easy sign-up procedure. But then there would have to be enforcement of the sub-community rules to exclude folks who "just don't get it." So a sub-community process/rules/admins would also have to be set up, which is where I think the main difficulties would be. Smallbones (talk) 18:21, 16 November 2016 (UTC)[reply]
yes, and more tools to enable editathons as a safe space. to the extent that talk does not work and event pages do not work, then organization is off-wiki. more tools to migrate drafts to sandbox to article space. more dashboards to organize red link lists as a to do list with tracking of results. it is currently ad-hoc, need easy to use tool set to organize events. Slowking4 (talk) 13:13, 17 November 2016 (UTC)[reply]

Image descriptions for the blind or visually impaired

edit

Machine translated from German to English, please help improve! -- Bildbeschreibungen für Blinde oder schwer Sehbehinderte

  • Problem:

Image descriptions are less detailed because most editors think that the image can be seen. But for users that are blind or have problems with sight, that's not the case.

Bildbeschreibungen sind wenig ausführlich, da man davon ausgeht, dass man das Bild sehen kann. Bei Blinden oder Sehbehinderten ist dies jedoch nicht der Fall.
  • Who would benefit:

Blind and visually impaired Wikipedia users

Blinde und sehbehinderte Wikipedia-Benutzer
  • Proposed solution:

Insert a detailed picture description, possibly as an alternative description, which blind or visually impaired people can turn on in their settings. (opt-in)

Einfügen einer ausführlicheren Bildbeschreibung, möglicherweise als Alternativbeschreibung, die Blinde oder Sehbehinderte in ihren Einstellungen aktivieren können (opt-in)
  • More comments:

This request was submitted by a member of the German Wikimedia association via OTRS, the applicant is in contact with him.

Dieser Wunsch wurde von einem WMDE-Mitglied über den OTRS gestellt, der Antragsteller steht mit ihm in Kontakt
  • Phabricator tickets:

Community discussion

edit

On EN Wikipedia we have "alt text" for that purpose. Wikipedians just need to fill in the details. Alt text is typically a requirement for articles that are FA or GA. How does this proposal differ from that? Doc James (talk · contribs · email) 19:25, 18 November 2016 (UTC)[reply]

Sure, it is not about FA or GA only. I think a parameter should be added to the image link, to state an alternative text especially for visually impaired readers. The standard alternative text shows the text only if the picture is not available. In my opinion is a technical change necessary to get this task done. Thank you Doc Taxon (talk) 20:43, 18 November 2016 (UTC)`[reply]
@Doc Taxon: Hi Doc. This feature already exists. Any time a file is included on a page, you can give it an "alt" parameter, which is used as alternative text especially for visually impaired readers. For example [[File:Horse.jpg|200px|alt=Photo of a horse in a field|A horse]]. Ryan Kaldari (WMF) (talk) 21:18, 22 November 2016 (UTC)[reply]

Wikipedia Redesign for better readability

edit
  • Problem: Wikipedia's design is not conform to new standards.
    • full width text is difficult to read on a large screen
    • the left column include many useless links. In ten years as a regular contributor, I've never use many of them like "create a book", "download as pdf", etc

It would be nice to have a modern interface which would make reading WP's article easier. There are many inspirations, such as the great WikipediaRedefined projet, Gitbook design or Tufte's design principle

  • Who would benefit: everyone
  • Proposed solution: the possibility to choose new skins such as gitbook style, tufte style, etc
  • Phabricator tickets:

Community discussion

Hi PAC2, your proposal is too broad to fit into this survey; it's not a tech project that Community Tech could work on. I'm archiving your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 02:06, 23 November 2016 (UTC)[reply]

Fix insource regular expression searching sometimes returning different results for the same query

edit
  • Problem: insource searches are a potentially powerful tool for finding syntax errors and patterns of wikitext that need to be fixed or replaced. Unfortunately, doing searches with multiple wild cards can result in searches that return different results every time, partial results (with no indication that the search was aborted before finding all results), or even zero results (again with no error message).
  • Who would benefit: Gnome editors, and of course the readers of articles with these errors in them.
  • Proposed solution: Improve insource regex searching so that it returns full search results, or at least so that it returns better error messages when it returns partial search results. Definitely fix it so that a more expansive version of a working search returns the same number of pages as, or more pages than, a more restrictive search. Possibly allow human searchers with certain privileges to lengthen timeouts or create a background process that writes search results to a page in the user's space when time and available processing power allows.

Community discussion

Hi Jonesey95, as Dan says, the Discovery team is working in this area. I'm archiving your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 02:05, 23 November 2016 (UTC)[reply]

edit

I wish case sensitive search. --Hedwig Storch (talk) 16:36, 17 November 2016 (UTC)[reply]

  • Problem:

Search is not case sensitive.

  • Who would benefit:

People who use case-sensitive search to find what they want and want less irrelevant results.

  • Proposed solution:

Make search case sensitive.

  • Phabricator tickets:

Community discussion

Keyword: Infobox _____

edit
  • Problem:

The term "infobox" is very important to certain editors, but the keyword must be entered into a search engine instead. If a fairly new user types "infobox company" into the search box, it simply does not work. However, typing "infobox company" into a major search engine will grant them direct access to the infobox.

  • Who would benefit:

New users, slightly interested contributors (to increase their work for the masses).

  • Proposed solution:

Raise the importance of the keyword "infobox" and allow "infobox _____" to become the first article page in results.

  • Phabricator tickets:

Community discussion

  • @Twillisjr: Thanks for the proposal. Generally, solutions that involve boosting one specific thing (such as the word "infoboxes") are problematic for a number of reasons. Firstly, they involve hard coding, which causes problems down the line with maintainability as the number of special cases increases; this is already a significant problem with our search systems which the Search Team is slowly fixing. Secondly, it would reduce the discoverability of other articles, such as Infobox, by hiding them behind templates that are not useful for most readers. Thirdly, there would be localisation issues here; this would be a very wiki-specific solution. In summary, this proposal is not something that should be done. --Dan Garry, Wikimedia Foundation (talk) 19:08, 21 November 2016 (UTC)[reply]
  • @Twillisjr: I'm archiving per above. However, I strongly recommend you go to https://en.wikipedia.org/w/index.php?title=Special:Search&search=&fulltext=Search&profile=advanced and select Template namespace (and any others you regularly want) and then click "Remember selection for future searches". That has been invaluable to me as an editor (especially as someone who frequently wants to find old discussions and proposals, and obscure helppages, hence I also check the "Wikipedia" and "Help" and "Mediawiki" namespaces and talknamespaces.) HTH. Quiddity (WMF) (talk) 21:56, 22 November 2016 (UTC)[reply]

Intangible source

edit
  • Problem: currently we are missing a large section of traditional knowledge with our inability to verify/authenticate intangible sources of knowledge. We also miss out on the firsthand or eyewitness accounts of major events that add life to the sum knowledge for an event.
  • Who would benefit: all projects
  • Proposed solution: create a project that is capable of collating, identifying and authenticating oral traditional stories as well as establish a protocol for eyewitness accounts put this in searchable text format that links to an audio file along with a trusted users statement of authentication.
  • More comments: These wouldnt be a replacement of reliable traditional sources but rather quotes that can enhance an article and provide the user with an opportunity to explore the event.
  • Phabricator tickets:

Community discussion

  • FYI, I've been brainstorming a new tool / software / possible sister site lately, where this might fit into as well. mw:Wikimedia User Interface/Concepts/Story builder and phab:T150461. No plans for development yet, but I think there might be some potential in it. —TheDJ (talk • contribs) 21:10, 14 November 2016 (UTC)[reply]
  • I think this could be useful for most - if not all - projects. But I'd like to see more details. Not entirely sure why audio is required, e.g. a text written by a named individual, supported by a trusted editor, might also work. This Wishlist AFAIK is for technical solutions, so the software should be developed, but the implementation (putting the results on-wiki) is up to the individual projects. Smallbones (talk) 17:23, 16 November 2016 (UTC)[reply]
    • the importance of audio is that it would be dealing with oral sourcing as this is about recording knowledge thats traditionally passed along within cultures that dont have fixed written(tangible) formats. it Would need tooling to enable linking of text to within specific points in time of those recordings Gnangarra (talk) 23:12, 18 November 2016 (UTC)[reply]
  • More details needed! I think the projects already exist, see our projects. Gnangarra, what topics are these stories about? What Wikimedia project best accomodates them? What do you propose to change to make it easier to write such stories? --Gryllida 23:08, 22 November 2016 (UTC)[reply]
    • This concept has been thrown around for a while and the commons response other projects can accommodate them but every project requires a policy change that would negatively impact its current purpose.. This is a two part project about capturing traditional knowledge of oral cultures that is passed from generation to generation the authority of the knowledge is based on the status of the person speaking, in Australia we have over 300 such Indigenous cultures, languages and knowledge systems. The second part is about capturing the eyewitness accounts of events where the authentication of the person telling their perspective is the key to the authentication of the knowledge, these first hand accounts would enhance the encyclopaedic articles. The commonalities are in the oral sharing of knowledge/experience and in the need to have an authentication process we can trust Gnangarra (talk) 23:49, 22 November 2016 (UTC)[reply]

@Gnangarra:, I'm archiving this proposal because it falls outside of the scope of this survey - it's not a technical proposal. Thanks for participating in this survey! Max Semenik (talk) 23:29, 22 November 2016 (UTC) @MaxSem: improving audio tools, placeholders to specific points in time, along with transcribing tools and creating an authentication tool to identify which copy was authenticated and user level of authenticator would be needed first Gnangarra (talk) 23:49, 22 November 2016 (UTC)[reply]

Wikipedia pro

edit

Machine translation from Spanish, please help to improve!

  • Problem:

Wikipedia is an encyclopedia that basically presents informational content, in a simple language, and without contrasting all the information it provides. This makes it unattractive to professionals of higher cultural level.

Wikipedia es una enciclopedia que básicamente presenta contenidos de tipo divulgativo, en un lenguaje sencillo, y sin contrastar toda la información que aporta. Esto hace que sea poco atractiva a profesionales de mayor nivel cultural.
  • Who would benefit:

Bring together Wikipedia and professional groups, where they can find quality and updated information, which will serve their work.

Acercar a Wikipedia a colectivos profesionales, donde puedan encontrar información de calidad y actualizada, que les sirva para su trabajo.
  • Proposed solution:

Create "professional Wikipedias" that are complementary to "classic Wikipedia", written using professional jargon, developing all topics scientifically, but not original articles, but revision texts with up-to-date content and the highest quality. All this following the rules and guidelines of Wikipedia, and its style of presentation of articles. The only thing is that publishers should not be anonymous, and should register as a professional with a particular qualification.

Crear "Wikipedias profesionales" que sean complementarias a "Wikipedia clásica", redactadas usando jerga profesional, desarrollando todos los temas a nivel científico, pero sin ser artículos originales, sino textos de revisión con contenidos puestos al día y de la máxima calidad. Todo ello siguiendo las reglas de juego de Wikipedia y su estilo de presentación de artículos. Lo único es que los editores no deberían ser anónimos, y deberían registrarse como un profesional con una determinada cualificación.
  • More comments:

We could create:

  • "Wikipedia Medicine" (which includes knowledge of medicine and its specialties, pharmacy, psychology, dentistry, podiatry, nursing, physiotherapy, etc.)
  • "Physical Wikipedia" (includes physics, chemistry, astronomy, mathematics, geology, etc.)
  • "Wikipedia Economy" (includes economic, business, tourism, management, accounting, etc.)
  • "Wikipedia Legal" (includes law, politics, diplomacy, etc.)
  • "Wikipedia Engineering" (includes all types of engineering and architecture)
  • "Wikipedia Biology" (includes biology, veterinary, genetics, environment, etc.)
  • "Wikipedia Philology" (includes all types of philology, language, literature, documentation, etc.)
  • "Wikipedia History" (includes history in all its variants)
Podrían crearse:
    • "Wikipedia Medicina" (que incluye los conocimientos de la medicina y sus especialidades, farmacia, psicología, odontología, podología, enfermería, fisioterapia, etc)
    • "Wikipedia Física" (incluye física, química, astronomía, matemáticas, geología, etc)
    • "Wikipedia Economía" (incluye económicas, empresariales, turismo, gestión, contabilidad,etc)
    • "Wikipedia Legal" (incluye derecho, políticas, diplomacia, etc)
    • "Wikipedia Ingeniería" (incluye todo tipo de ingenierías y arquitectura)
    • "Wikipedia Biología" (incluye biología, veterinaria, genética, medio-ambiente, etc)
    • "Wikipedia Filología" (incluye todos los tipos de filología, lengua, literatura, documentación, etc)
    • "Wikipedia Historia" (incluye historia en todas sus variantes)
  • Phabricator tickets:

Community discussion

@Raimundo Pastor: Ahora parece que hay muchos artículos en las Wikipedias existantes que ofrecen más información que requiere alguien (por ejemplo, sobre las matemáticas o temas biológicos), y añadir a ellos necesita que ayudamos los esfuerzos que trabajan a promover editar Wikipedia el día de hoy, en vez de partir la enciclopedia. Quizás quiere proponer ediciónes de Wikipedia sencillas en otros idiomas como se puede encontrar en inglés? Mahir256 (talk) 01:36, 15 November 2016 (UTC)[reply]

@Raimundo Pastor: This proposal might be out of scope for the Community Tech team as the team "will mainly work on development tasks" and does not work on "large, long-term development projects" according to Community Tech#Scope. --AKlapper (WMF) (talk) 15:30, 15 November 2016 (UTC)[reply]

No, la idea no es crear una "Wikipedia sencilla en otros idiomas", sino varias Wikipedias profesionales para diferentes grupos que les sirva de herramienta de trabajo. Evidentemente es una tarea a largo plazo, pero creo que es positivo que se exponga en público, como estrategia de desarrollo de Wikipedia. Un cordial saludo:--Raimundo Pastor (talk) 17:40, 15 November 2016 (UTC)[reply]

  • I propose these Wikipedias are not separate, but are inside of Wikipedia.
Raimundo Pastor, would adding a 'author qualification' field to WikiProject assessment templates be sufficient? --Gryllida 23:02, 22 November 2016 (UTC)[reply]

@Raimundo Pastor:, I'm archiving this proposal because it falls outside of the scope of this survey - it's not a technical proposal. Thanks for participating in this survey! Max Semenik (talk) 23:31, 22 November 2016 (UTC)[reply]

Prioritize the existing WikiCite project

edit
  • Problem: there is no central repository for citations in Wikipedia, rather citation templates litter the article space in a disjoint and erratic fashion
  • Who would benefit:
    • all editors – adding citations should become more streamlined
    • all readers – through more complete and more current citation information
    • external researchers undertaking citation analysis on Wikipedia
  • Proposed solution: prioritize the existing WikiCite project
  • Phabricator tickets: not applicable

Community discussion

As the original poster, I am not sure if this is the correct place to highlight this project, but it certainly needs to be advanced. Notwithstanding, this proposal may need to be withdrawn and I am happy for that to happen. RobbieIanMorrison (talk) 15:44, 10 November 2016 (UTC)[reply]

As somebody who's been very involved with WikiCite, I feel the same. However, I am not sure if the Community Wishlist is the right venue for this ask. We need to define technical needs and their respective priority and costs, and formulate a clear ask. I am hopeful we can do this as part of the next annual plan cycle, I'd love to have your input.--DarTar (talk) 16:00, 10 November 2016 (UTC)[reply]
Currently this proposal seems to not meet the requirements outlined in Community Wishlist Survey 2016#What happens during the proposal phase?, as the request is not specific enough. The problem might be that there are too many citation templates around (and the outcome of that) and a proposed solution might instead be "Create a central repository for citations"? Identifying the (maximum three) top problems that you are currently facing would help everybody to understand what exactly is requested when discussing, voting, or working on fixing issues. Thanks in advance! --AKlapper (WMF) (talk) 16:58, 10 November 2016 (UTC)[reply]
  • I agree with above—except for the part that there are too many citation templates! :-) Embrace these, they are great! I think the lack of a central repository for citations is an acknowledged issue, a HUGE issue that should be fully funded and should involve stakeholders from all sides of the issue, as well as industry experts in the data and library & info fields. But I'm not sure if this is the place for this. WikiCite is doing great work and should be fully supported, as should Wikidata. But in a comprehensive, fully-funded, formal way. Not as an ad hoc project. -- Erika aka BrillLyle (talk) 19:22, 10 November 2016 (UTC)[reply]

Pictures under category

edit
  • Problem: Picture data is shown under category
  • Who would benefit:
  • Proposed solution: picture description should be shown instead of data
  • Phabricator tickets:
  • Proposer: Haubi (talk) 20:15, 20 November 2016 (UTC)[reply]

Community discussion

Hi Haubi, your proposal doesn't have enough information for us to use. I've archived your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 02:03, 23 November 2016 (UTC)[reply]

Improve Wikisource integration in Wikibase

edit
  • Problem: Wikisource items currently seem only marginally useful. A large part of them remains without statements.
  • Who would benefit: Wikisource users, users encountering empty Wikisource items.
  • Proposed solution: Build some improved GUI or separate instance.
  • Phabricator tickets:

Community discussion

Hi Jura1, this proposal is too vague to be voted on in the survey—people wouldn't really know what they were voting for, and we wouldn't know what to build. I've archived your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 02:02, 23 November 2016 (UTC)[reply]

If it's reformulated to "move Wikisource items to a separate instance" would that be easier: DannyH (WMF)? --Jura1 (talk) 07:01, 23 November 2016 (UTC)[reply]
Jura1, we'll need you to add a lot more detail to the problem statement and proposed solution. Why are Wikisource items not useful? What improvement would you want to make in a GUI? How would a separate instance help? If you can rewrite, that would be great. -- DannyH (WMF) (talk) 17:59, 23 November 2016 (UTC)[reply]

Cross-wiki repository for Lua & other modules

edit
  • Problem:

Module use is limited to one language Wikipedia or one Wikimedia project at a time.

  • Who would benefit:

Users who would not have to reinvent the wheel recode each module for their own language Wikipedia or Wikimedia project.

  • Proposed solution:

Like Commons is a cross-project repository for media, & Wikidata is a cross-project repository for data, Wikimodule would be a cross-project repository for modules written in Lua & potentially other languages (Python, CSS, Wikimarkup template code, etc.) as well.

Community discussion

Probably close related with Global gadgets wish. JAn Dudík (talk) 07:00, 8 November 2016 (UTC)[reply]

  • should not be limited to modules written in the development language called Lua, but to those written in Python as well. Even CSS, regular Wikicode like templates etc.  Klaas `Z4␟` V:  15:42, 13 November 2016 (UTC)[reply]

Hi Peaceray - as discussed above, this wish is dependent on the Shadow namespaces project. This was #3 on the Wishlist Survey last year, so we know that a lot of people really want it. :) I've archived your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:44, 23 November 2016 (UTC)[reply]

WikiFastFacts

edit
  • Problem:

Even in Simple English and Concise Wikipedia the verbiage is long and complex. Approximately half of the adult world reads at a level 2 or below on the PIAAC. This indicates low levels of literacy are common even in adults. For students literacy levels are lower due to the developmental nature of their skills

  • Who would benefit:

Everyone

  • Proposed solution:

Create a WikiFastFacts. WikiFastFacts will be a bullet point version of Wikipedia. It will contain concise facts about a topic without the added verbiage often seen in Wikipedia and even Simple English Wikipedia. Most people remember basic facts about a topic. WikiFastFacts will become the repository for that kind of information. It will be useful to all readers but particularly the less literate. A sample page can be seen here

  • Phabricator tickets:

Community discussion

@Hhamilton: Hmm, perhaps something like Reasonator or like SQID, but aimed more at Simple Wikipedia target-demographics, is what you have in mind? I.e. A limited subset of the contents from Wikidata, rather than the deluge that is currently given. (We usually try to avoid manual duplication of content, otherwise the various versions can get forgotten/ignored, plus there's more to maintain (content-wise and wiki-wise and headspace-wise). Reduce/reuse/recycle! Quiddity (talk) 01:08, 10 November 2016 (UTC)[reply]

@Hhamilton: So the proposal summary is basically "Create a bullet point version of Wikipedia with concise facts"? Asking as I saw the "WikiFastFacts" section heading and had no immediate idea what that proposal might include so you might want to edit and rename your proposal for the voting period so people can understand faster what the proposal is about. :) --AKlapper (WMF) (talk) 13:09, 10 November 2016 (UTC)[reply]

To all- Yes the proposal is to make a bullet point type Wikipedia. I looked at Reasonator and SQID and if something could be made or modified to show only select items that may be a good solution. So I understand those better... Are they using an api or javascript and css to assemble pages by pulling from Wikidata?.

I think Wikidata, a reskinning of Wikidata or the infoboxes on Wikipedia serves this purposes. --Spshu (talk) 19:17, 12 November 2016 (UTC)[reply]
 Klaas `Z4␟` V:  agrees with Spshu 100% 15:36, 13 November 2016 (UTC)[reply]
@Hhamilton: It looks like both those tools are using JavaScript, per Reasonator and https://tools.wmflabs.org/sqid/#/about - HTH. Quiddity (WMF) (talk) 22:25, 17 November 2016 (UTC)[reply]
@Spshu::@Klaas: For literate adults Wikidata is fine. For kids and the less able reader Wikidata formatted into simple clear bullets would serve them much better. More readers are less literate than fully able readers. For example in the state of Georgia 21% of students read on grade level. Reading ability should not block a person from knowledge. A reformatted version of Reasonator would do the job nicely. Or a reskinning of Wikidata would also be good. —The preceding unsigned comment was added by Hhamilton (talk) 00:12, 18 November 2016

Hi Hhamilton, this proposal is an idea for a new community project, rather than a technical project that the Community Tech team could work on. There's not much we can do for this, sorry. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:30, 23 November 2016 (UTC)[reply]

Display subpage name in category

edit
  • Problem: The Wikisources have utilised subpages to build works, yet the display of the categorisation of subpages is problematic due to the long titles and when the pertinent part of the title could be the last segment of the title. For example the page The Dictionary of Australasian Biography/Krichauff, Hon. Friedrich Edouard Heinrich Wulf could be best displayed as Krichauff, Hon. Friedrich Edouard Heinrich Wulf
  • Who would benefit: all Wikisources
  • Proposed solution: build a means to tag a category to display the works based on {{SUBPAGENAME}} or the last segment of a name
  • More comments: Many Wikisource compilation works that have subpages that are significant, be they biographical dictionaries, poetry, or series of lectures.

Community discussion

Proposal has been archived

@Billinghurst: I'm afraid this has too narrow a use case, when there are so many other proposals vying for voters' attention. Sorry! (By the way, the example page you give above isn't categorised at all.) —SWilson (WMF) (talk) 05:45, 23 November 2016 (UTC)[reply]

Fix the indentation display bug on top of pages with headline

edit
  • Problem: when a page has a header, the top paragraph, which is the continuation of the previous page, is displayed with an indentation in the page mode. This has no effect on transclusion, but causes many contributors to try and fix this by adding code at the beginning of each page. example.
this appeared long ago when the interface was changed to manage headers.
  • who would benefit : every wikisource contributors, and the whole community by avoiding inept recurring code.
  • Proposed solution : fix the screen display when the headline is filled. Thanks.

Community discussion

Implement visual editor on Wikisource

edit

Machine translation from Spanish, please help to improve!

  • Problem:

Lack of formatting in documents

Falta de formato en los documentos
  • Who would benefit:

Format, aesthetics

Formato, estética
  • Proposed solution:

Visual editor, like a word processor.

Editor visual, como un procesador de textos.
  • Phabricator tickets:

Community discussion

This work is ongoing, in phab:T138966, with 4 very complicated subtasks to complete before it is ready. No need to re-vote for this. Quiddity (WMF) (talk) 21:02, 11 November 2016 (UTC)[reply]

Create Wikisource App

edit
  • Problem: Wikisource has very less visitors as compared to Wikipedia. For example, during October 2016, a total of 15,619M total visitors (mobile+non-mobile) viewed Wikipedia, whereas only a total of 22.0M visitors visited all language editions of Wikisource.[1] The most-enriched English and French Wikisources had mere 2.7 M and 2.1 M visitors respectively during this October,[2] which is very low compared to their Wikipedia counterpart.[3] One of the reason for this is lack of Wikisource specific app for book readers, which keeps mobile users away from this project.
  1. ↑ https://stats.wikimedia.org/EN/TablesPageViewsMonthlyAllProjects.htm
  2. ↑ https://stats.wikimedia.org/wikisource/EN/TablesPageViewsMonthly.htm
  3. ↑ https://stats.wikimedia.org/EN/TablesPageViewsMonthlyCombined.htm
  • Who would benefit: Both old and new Wikisource readers
  • Proposed solution: Creation of Wikisource App for all language edition

Community discussion

This proposal has been archived

@Bodhisattwa: Certainly it is a terrific idea to get more people reading Wikisource on mobile, but a Wikisource-specific app is too big a project for Community Tech and as @Jberkel says above, there are already many ways of reading epubs on mobile and that perhaps we can instead target making our content more accessible to these people. Sorry to have to archive this proposal. —SWilson (WMF) (talk) 04:00, 23 November 2016 (UTC)[reply]

Cross-wiki search suggestions

edit
  • Problem: It is possible to navigate, for example, from English wikipedia to the article about Argentina in Spanish wikipedia by entering "es:Argentina" in the search box, or to the English wiktionary entry about whatever by entering "wikt:whatever". You won't, however, be given search suggestions like when you are about to navigate to another page in the same wiki.
  • Who would benefit: Users who are interested in several wikis.
  • Proposed solution: Our search engine should learn that, if the text entered into the search box begins with interwiki prefixes as described here, search suggestions should be made from that very wiki associated with the given interwiki prefix.
  • Phabricator tickets:

Community discussion

Sorting categories for Wikisource

edit

Machine translation from Polish, please help to improve!

  • Problem:

When viewing the contents of this category division, titles having a sub and having no subcategories is misleading. The reader is looking for a title in the alphabetical list - and quite confusing is that you must look twice: in sub - and the sides.

For example, s:pl:Category:Maria Konopnicka is a bibliography of the author's works. When the reader is looking for one song, he does not know whether to look at the texts with subcategories, whether in the texts do not have subcategories.

Przy wyświetlaniu zawartości danej kategorii podział na tytuły mające podkategorie i nie mające podkategorii jest mylący. Czytelnik szuka danego tytułu w spisie alfabetycznym -- i dość mylące jest to, że musi szukać podwójnie: w podkategoriach -- i w stronach.
Dla przykładu s:pl:Kategoria:Maria Konopnicka to spis bibliograficzny utworów autorki. Gdy czytelnik szuka jednego utworu, nie wie, czy ma szukać w tekstach mających podkategorie, czy w tekstach nie mających podkategorii.
  • Who would benefit: Wikisources
  • Proposed solution:

Remove pagination, and subcategories should be one index.

Usunąć podział na strony i podkategorie, powinien być jeden spis alfabetyczny
  • Phabricator tickets:

Community discussion

Hello @Wieralee:. 3 questions:

  • Does this idea apply to any other (or all) wikis, or only to Wikisource? (If just Wikisource, we can move this to Community Wishlist Survey 2016/Categories/Wikisource)
  • If pagination is removed, how do we limit the number of links, if there are many thousands of pages within the category? (Because we want to avoid giving anyone a many-megabyte page)
  • What do you mean by "subcategories should be one index"? Perhaps, you mean that we should remove the limit of "200 subcategories per page" as seen at w:en:Category:Populated places by country? Or, you mean that subcategories should be displayed in a different layout on the page?

Thanks. (Sorry for writing in English). Quiddity (WMF) (talk) 00:24, 10 November 2016 (UTC)[reply]

Hi Wieralee, I moved this proposal into the Wikisource category. I think it'll get more attention here. -- DannyH (WMF) (talk) 00:26, 16 November 2016 (UTC)[reply]

This proposal has been archived

@Wieralee: As some categories can contain many thousands of entries, it's not possible to include all pages (from all subcategories) in one big listing. Sorry! Let me know if you want to discuss. And thanks for participating in the survey! SWilson (WMF) (talk) 03:55, 23 November 2016 (UTC)[reply]

Add support for linking to redirects

edit
  • Problem:
At present, the Wikidata frontend "Set a sitelink" does not allow links to redirect pages, although there are technically no reasons not to allow this. However, since different Wikipedias are organized differently, the target of a redirect may not be the proper equivalent term for a given term in the English WP, whereas the redirect page may be. This causes editors to create Wikidata links to pages which are not the exact equivalent of a local page (which creates a lot of manual work later on), or to not create links to foreign Wikipedia articles at all (which is losing an opportunity to build the web and is rendering the whole idea of maintaining iwls through Wikidata ad absurdum).
Therefore, in these cases, it should be possible to create links to redirects rather than their targets.
Actually, it is possible to work around this restriction by temporarily invalidating the redirect to be linked to (simply by removing the leading # in front of the REDIRECT token), then add the disabled redirect to Wikidata (now without causing an error message, as the page is no longer seen as a redirect), and reenable the redirect afterwards (as an example, the redirect Prism dioptre was added to Wikidata this way). However, this is cumbersome, requires multiple edits, and if done by users with few edits in foreign Wikipedias, they may be reverted even before they could add the link to Wikidata. (Also, it requires that the editor is able to carry out the necessary temporary edits in the foreign Wikipedia at all - which might be next to impossible for some in a foreign language and with this brain-damaged "VisualEditor" popping up by default for new editors in most foreign Wikipedias.)
  • Who would benefit:
Editors, who work in multiple Wikipedias and create connections between related topics. Indirectly all users would benefit from more (and more correct) iwls.
  • Proposed solution:
Add a checkbox to the Wikidata "Set a sitelink" dialog under "Badges", which would disable the current behaviour to follow redirects to the target page. F.e. "[x] Target is redirect". (This should be trivially easy to implement.)
This does not need to be a permanent flag, it is enough to temporarily disable the code which detects redirect pages / attempts to follow the redirect to the target page. Once the Wikidata link to the redirect has been established everything can continue to work as before - these links don't create any problems for Wikidata. (In fact the effect isn't different from someone changing an already Wikidata'ed article into a redirect.)
  • More comments:
The iwls are shown on the redirect page, not on the redirect's target page, so someone reading the target page may not see them unless s/he checks the incoming redirects. This may be seen as a shortcoming, but technically, it is correct and does not create any problems and does not get in the way of any possible solution with a larger scope somewhen in the future, and it is already much better than not allowing links to redirects at all.
  • Phabricator tickets:

Community discussion

Note this is also needed as part of the solution for the "Bonnie and Clyde" problem - see this discussion in Wikidata. ArthurPSmith (talk) 14:32, 14 November 2016 (UTC)[reply]
The "Bonnie and Clyde" problem is phabricator task T54564 - task T54564 Jane023 (talk) 15:46, 14 November 2016 (UTC)[reply]
An alternate solution could be to open a dialog box when a sitelink is checked and recognized to be a redirect. That dialog box would leave the user the choice to use the target or the redirect link. --Melderick (talk) 21:04, 20 November 2016 (UTC)[reply]

Hi Matthiaspaul—I've archived this proposal as per the response from Lydia Pintscher (WMDE). Thanks for participating in the survey. -- DannyH (WMF) (talk) 17:56, 23 November 2016 (UTC)[reply]

Return/reinstate HTML data dumps for offline

edit
  • Problem:

Wikipedia's current XML dumps are great for rebuilding mirrors; but anyone who wishes to access a searchable web dump, or a compiled MHTML dump, is left jumping through thousands of individual hoops. No smooth transaction exists from XML to clean, usable, individual HTML pages.

  • Who would benefit:

Anyone who wants a ready to use offline version of Wikipedia (and wikimedia projects in general, eg Wikisource).

  • Proposed solution:

Restore the crawling routines, and reinstate HTML data dumps.

  • More comments:

Though the initial dump will probably be a tedious and exhaustive process, sequential updates after that point should be rather easy (and considerably smaller). Equally, HTML, much like XML, is text based, making compression with current software ideal for a considerably smaller single package file to download.

  • Phabricator tickets:

Community discussion

  • That site link and the T17017 information only reiterates the fact that when it comes to quick easy backups for offline reading static HTML dumps remain the most ideal method. Something that remains ignored because the current effort is on building portable mirrors rather than accommodating the world of mega storage ereaders. Yes zim is useful in it's limited recreation sense but when it comes to booking out wikipeida, or any wiki, a static dump in html is by far the best method to transfer a wiki project to a zhtml database for conversion or serving as a searchable indexed epub. et al. Especially index serving such as using Calibre and a networked drive to serve individual pages via library link to an epub or K8 reader.Lostinlodos (talk) 06:02, 20 November 2016 (UTC)[reply]
  • @Lostinlodos: Hi, I've talked to a developer who summarized the situation. Briefly: The static HTML dumps are't scalable, so reviving the dumps for large wikis is not feasible. However, the replacement is HTML dumps from RESTBase, which is currently being worked on in phab:T133547 (with more updates coming soon). This ongoing work doesn't need to be voted on to indicate community desire, hence I'm archiving this proposal, but the interest in the work is appreciated! Hope that helps. Quiddity (WMF) (talk) 19:01, 23 November 2016 (UTC)[reply]

Option for "Place the category box above all other content" in German/all wikis

edit
  • Problem:

Extensive articles are hard to overview

  • Who would benefit:

Categorization-interested-users

  • Proposed solution:

see: en.WP

  • Phabricator tickets:

Community discussion

  1. Open w:de:Benutzer:Wheeke/common.js
    Or (to have this feature everywhere): m:Special:MyPage/global.js --𝔊 (Gradzeichen Diſk✉Talk) 09:24, 18 November 2016 (UTC)[reply]
  2. Paste in these 2 lines at the bottom:
// Import "categories above all" gadget from Commons
mw.loader.load("//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-CategoryAboveAll.js&action=raw&ctype=text/javascript");
3. Save page. Done!
Or, if you want everyone else in the Dewiki community to have access to the feature, as a site-wide gadget, then start a discussion at w:de:Wikipedia Diskussion:Technik/Skin/Gadgets to propose it. :-) Quiddity (WMF) (talk) 19:03, 16 November 2016 (UTC)[reply]
@Quiddity (WMF): it worx! many thx!!--Wheeke (talk) 07:26, 17 November 2016 (UTC)[reply]
@Quiddity (WMF): Looks like this proposal is solved; I've moved it to the archive. -- DannyH (WMF) (talk) 20:35, 23 November 2016 (UTC)[reply]

Improve CommonsHelper (Move-to-commons assistant)

edit
  • Problem: CommonsHelper tool by User:Magnus Manske for transferring files from Wikipedias to Commons is not working well. The file descriptions generated even for the easy cases are horrible, see here or here and often can not be even parsed correctly. There are tools specifically designed to clean up the mess generated by the tool, like c:User:Magog the Ogre/cleanup.js but it would be easier to get it right in the first place. As a result file transfer from en-wikipedia to commons is very slow because it is so time consuming to fix the uploads. In the worst case scenario, transferred file descriptions are so bad they are tagged for deletion for lack of license or proper source. The user notified about pending deletion is the person or bot that transferred the file not the uploader and the file is deleted. Even if someone wants to fix the image, at that point image on Wikipedia might be already deleted so it is impossible to correct the issue without getting admins involved.
  • Who would benefit: Wikipedia and Commons users
  • Proposed solution: Start from scratch and design tools which only deal with one wiki at a time. For example for English Wikipedia, query for most commonly used templates in file namespace and come up with mappings to commons templates. Ask Commons community for help with designing the optimal description. Recognize cases that will not be handled by the tool and do not do them. In the end redirect transferring user to newly created page and ask for verification that the description looks good. Also ideally files would be imported with complete file edit history so all the contributions can be correctly attributed (copyright issue) and so we do not loose anything in the transfer.

Community discussion

Jarekt, can you put a sentence or two at the top of this proposal, to explain what CommonsHelper does? It could make this proposal more compelling for people during the voting. -- DannyH (WMF) (talk) 18:35, 18 November 2016 (UTC)[reply]

  Done Thanks for suggestion. --Jarekt (talk) 18:44, 18 November 2016 (UTC)[reply]

Would it be within the scope of this new tool to help organise all files on a wiki, in a drive to move everything to Commons that can be moved? I know this is being done already on many wikis, but some dedicated maintenance function might help. Even some easily accessible statistics (# files can be moved, # files can't, # we don't know about). --Magnus Manske (talk) 14:26, 19 November 2016 (UTC) to[reply]

I was thinking more along the line that once there is a tool that works than the rate of transfer would increase. Organizing a drive to transfer files should be the responsibility of the community of users on a given wikipedia. Per meta:Non-free content page, it seems like there are a lot of wikipedias that allow local uploads, however it is not clear how many of them also hold free uploads. Some Wikipedias like Polish one no longer have any local file storage as they moved everything to Commons. I do a lot of cleaning of Commons maintenance categories and large fraction of files there are transferred from other wikis, mostly EN-WIKI. I find it annoying that the uploaders would leave those files for others to correct, but than when I do my own uploads I see how much work it is to correctly move even one. I think the idea of triage into: files that can be moved, files that can't, and we don't know about is a key. EN-Wiki already identified many images ready for transfer, see en:Category:Copy to Wikimedia Commons reviewed by Sfan00 IMG for example. One challenge I see is a large number of templates used on EN-Wiki and need to map them to templates on Commons. Sometimes it is a simple matching when there is identical template on Commons, sometimes it is more complicated when different fields have to be matched one by one. Wikidata might be able to help with some pairing. --Jarekt (talk) 04:06, 22 November 2016 (UTC)[reply]
I've written and released an Cross-platform tool, MTC!, which makes it easy to correctly transfer files to Commons from en.wikipedia. This already solves most, if not all of the inadequacies with the current CommonsHelper. -FASTILY 23:05, 20 November 2016 (UTC)[reply]
That sounds great. I will give it a try. --Jarekt (talk) 04:06, 22 November 2016 (UTC)[reply]
User:Fastily I just tried your tool with mixed results. Many files I managed to transfer were transferred with great descriptions and there was no need to fix anything on Commons other than categorize the files. Other files needed some manual help to create valid page. The tool sometimes works and sometimes transfers "0 files", restarting it seems to make a difference. Also some files seem invisible to the tool, like w:File:Sj6board.jpg ("No Maching files found :(" message). Finally since I used the tool I can not edit on EN-WIKI and always get "Sorry! We could not process your edit due to a loss of session data." error when making manual edits. I think it is a great step forward, but it still needs improvements. --Jarekt (talk) 19:05, 22 November 2016 (UTC)[reply]
@Jarekt: thanks for your feedback! I've updated the user manual at w:Wikipedia:MTC! based on your comments :) Could you list a a few instances where you had to make many manual edits to create a valid file description page? MTC! won't transfer w:File:Sj6board.jpg unless you check the box for Disable the smart filter, because PD-author is on the blacklist (many files transcluding this tag are copyvios/missing evidence of permission). The "Sorry! We could not process your edit due to a loss of session data." error sounds like a MediaWiki bug, and is definitely unrelated to MTC! Regards, FASTILY 08:32, 23 November 2016 (UTC)[reply]
Due to development of w:Wikipedia:MTC! which overlaps greatly with goals of this proposal, I would like to withdraw it. --Jarekt (talk) 20
49, 23 November 2016 (UTC)
Hi Jarekt, I archived your proposal. Thanks! -- DannyH (WMF) (talk) 22:41, 23 November 2016 (UTC)[reply]

Keywords to images and categories

edit
  • Problem: This is not important, but maybe would facilitate searching
  • Who would benefit: Everybody
  • Proposed solution: Possibility to add keywords to an image or category in addition to file name, description, category etc.

Community discussion

Hi Darekk2: The proposal phase ended on Monday; you posted this proposal too late. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:09, 24 November 2016 (UTC)[reply]

Collect and organise my knowledge

edit
  • Problem: I have learnt great information on Wikipedia. However, it is not easy to keep track of it in order to go to it later. For example, it is hard to find again that interesting fact you learnt about a specific type of shark you no longer recall the name of. There is little support to collect, organise and share what you learnt on Wikipedia. Saving pages in my watchlist, reading lists on mobile, or creating manually lists under my user namespace is not enough. Current solutions in this area are disconnected from the rest of the system, are not easily searchable, make it easy to share your knowledge with others or in some cases discover updates.
  • Who would benefit: Readers that do research in an organise way, or want to learn more on specific topics. Readers interested in creating cross-article content based on reliable information.
  • Proposed solution: Provide ways to collect and organise knowledge of interest for a user (pages, images, but also facts or quotes from our content). Provide ways to combine the collected knowledge into stories for users to create new Wikipedia-based content and share it. Allow people to indicate when they "learnt something new" to surface the most relevant stories/collections.
  • Phabricator tickets:

Community discussion

"Download/Retention of Offline Wikipedia" Instructions

edit
  • Problem:

The instructions for obtaining a copy of Wikipedia as an Archive from a repository is incredibly complicated. In several years, I have yet to obtain it, and this is a symptom that others are not doing so, while they should. Rather, *Absolutely Should*

  • Who would benefit:

Those who share large files with those who need it, computer hard drives to retain something much needed, those with power outages on a regular basis (disturbances to internet uptime), etc.

  • Proposed solution:

Improved access, FTP? Perhaps an agreement for pre-installs upon new purchases from device vendors? Everyone can play a role at every level. Improved instructions, however, are at the core of this issue. I'd like to see a world with an encyclopedia on every computer and the educated sharing it on a drive with another individual. Updates would be an excellent addition.

  • More comments:

Open

  • Phabricator tickets:

Community discussion

Twillisjr, I moved your proposal here, from the Miscellaneous page. There are a couple other proposals about offline Wikipedia above, please take a look and see if you think they should be merged. -- DannyH (WMF) (talk) 19:41, 18 November 2016 (UTC)[reply]

Twillisjr I think this shares a lot of details with what I have proposed above. We do have offline avaliable through en:Kiwix as an app for multiple different system. Greater awareness is needed and maybe better branding. Doc James (talk · contribs · email) 21:03, 18 November 2016 (UTC)[reply]

Thank you for pointing this out, I will include a comment into two which seem similar, although not all details meet the specifics of my request. Hopefully, as I respond, we will be able to isolate the small margins of different ideas. Thanks for responding! Twillisjr (talk) 02:45, 19 November 2016 (UTC)[reply]

Hi Twillisjr -- as you said, the offline proposals are very similar. I'm moving your version to the archive. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:22, 24 November 2016 (UTC)[reply]

More usable and accessible offline Wikipedia

edit
  • Problem: The offline Wikipedia is too dull, less accessible, and too generalised for worldwide active usage. Since worldwide now over 3 billion smartphones are in use. But because of too dullness of offline Wikipedia those 3 billion potential users are cut-off of cruciual or even life saving articles of Wikipedia. (well maybe 0.5 billion are always in 3G or 4G coverage area and within their data usable limits at given times) Because of healthcare related articles are in real emergent demand hence the Kiwix team observed it and made medical part of Wikipedia more accessible to the world through smartphones. So all the other parts of Wikipedia such as science, culture, history and even sub categories really needed to be selectable for offline downloads and possibly used by any age or social groups. Well since English version is the largest and most knowledge accumulated one maybe better start from English wikipedia.

Despite regularly updated one gigantic dump file why not to release 50-100 different categorized small dumps that covering biology, physics, mathematics, history, architecture, music etc's that maybe updated once or twice per year. Which these dumps will be far more useful for users of most kinds. For example an engineer would likely install mathematics, physics, technology, science categories on his or her cellphone in most cases so the Wikipedia is really having a chance to precisely and deeply fulfilling well categorized encyclopediac purpose for a user. Which in 95% of cases people will only realistically use 2-8GB of Wikipedia in data numbers.

  • Who would benefit: Everyone who carries smartphones or at least 3 billion people really begin to carry real own selected knowledge reference in their pockets, and desktop pc or laptop are kind of dying culture nowadays. This will make Wikipedia highly usefull for hundreds of millions of active professionals and students thus possibly real knowledge penetration phenomenon likely occur.
  • Proposed solution: The WMF really need to consider this idea and get into work with their coders team since the hardware/consumers are already in 3 billion units ready.
    • Cut the current over 70GB (archived version of 13.3GB) of offline english wikipedia dump file into key user friendly categories starting from the all scientific and technological categories like: in science: mathematics, physics, biology, chemistry ... ; in technology: mechanics, electronics, nano technology, computer hardware, computer software, AI etc...
    • Maybe then other useful categories like: music, architecture, culture, history, medicine, gardening...
    • And the other software team members might likely figure out better solutions of these categorizing and making it user friendly for efficient smartphone friendly usage.
    • The key principle of the solution is this wikipedia database need to be well categorized and user selectable according to above mentioned categories examples, whether it is Wikitaxi or Kiwix anyone could choose his or her best 5-20 categories and install those in their smartphones which in most cases would take just 2-10GB of space which most of users and even less active users begin to use their pocketed Wikipedia knowledge in quite handy way.
  • Phabricator tickets:

Community discussion

  • @Orgio89: Thanks for your proposal. So if I understand correctly, you propose to create Wikipedia data dumps for specific topics and areas? I'm asking as the current proposal title "More usable and accessible offline Wikipedia" is a bit vague. :) Currently the "Problem" section seems to also cover some parts of the solution that you propose, could you split this please? Thanks in advance! --AKlapper (WMF) (talk) 12:29, 15 November 2016 (UTC)[reply]
Thanks for your comment I've expanded the solution part as your suggestion. Orgio89 (talk) 13:04, 15 November 2016 (UTC)[reply]
But this solution makes the Wikipedia encyclopedia more close and precise for users. For example for 5 million musicians out there for them carrying physics, mathematics included offline Wikipedia does not make sense instead of carrying whole musics category Wikipedia articles database likewise for 8 million physicists and mathmeticians out there carrying detailed musics articles does not make sense instead of just carrying and using math and physics category Wikipedia database. Orgio89 (talk) 23:37, 18 November 2016 (UTC)[reply]
Perhaps if the current 13.3GB of offline dump file would have categorized through different subjects into 100-150 categories then the Wikipedia knowledge providing service will be far more flexible and accessible for 99% of users which means 1.5 billion english speaker and smartphone carrying users are ready to use this way. Orgio89 (talk) 03:16, 19 November 2016 (UTC)[reply]
For certain devices, plugging into a direct land line and loading data as if the device is a removable drive is difficult, and now, the Wikipedia app itself cannot be downloaded to iphone 4's because they do not have ios8. Suddenly, the devices storage of obtained offline wiki pages is useless. That sort of future is important to prevent. Twillisjr (talk) 03:28, 19 November 2016 (UTC)[reply]

Hi Orgio89: There were several proposals about offline Wikipedia, so I've taken your proposed solution, and added it in the discussion section under Expand offline capability within the Wikipedia / Kiwix app. I'm archiving your proposal here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:30, 24 November 2016 (UTC)[reply]

Generic page lists

edit
  • Problem: MediaWiki offers several page list types: keyword search, global recent changes, user contributions, categories, changes related to a page, pages that link to a page, pages with prefix.

However, each page list type has a specific view: keyword search lists are ordered by relevance, user contributions are ordered by edit date, pages that link to a page are ordered by page creation date, pages with prefix are ordered alphabetically, categories are ordered by tag. You cannot order the category pages by file size or last edit date, neither you can see that information. So I propose a generic page list system, where people can choose the view.

  • Who would benefit: People who want to explore the millions of pages.
  • Proposed solution: Each page list type should have the option to change the view. So, given a certain list of pages, users should be allowed to see the following information and sort the pages by the following information: article name, file size, last edit, first edit, number of editions, summary, other metadata. The views should allow to show or hide the respective information. There should be a separate view to see the last changes of the pages in the list, a view to sort the category pages by tag, and a view to sort the pages by keyword relevancy.
  • Phabricator tickets:

Community discussion

This could be difficult to scale due to database query efficiency issues. Anomie (talk) 20:24, 11 November 2016 (UTC)[reply]

Hi 167.58.54.10, This proposal is too broad for the survey. The list pages that you're talking about are very different—a category listing and user contributions aren't the same kind of thing, even if they're both in list form. I would ask you to narrow this down—but you didn't log in, so you won't get this ping, and you probably won't read this message. So I archived your proposal. -- DannyH (WMF) (talk) 01:46, 24 November 2016 (UTC)[reply]

edit
  • Problem:

User can have more accounts: bots, sockpuppets or alternate accounts. When somebody pinged his another account, user is not notified unless he visit his alternate account.

  • Who would benefit:

Bot-owners, editors with multiple accounts

  • Proposed solution:

User should fill in options his main account. In main account he should see all notification for all subaccounts

  • More comments:
  • User:FooBarBot should have filled Main account: FooBar
  • User:FooBar have in his notifications tab Messages for anoher accounts (like now Messages from other wiki) for FooBarBot

Community discussion

Very useful for bot operators. There are many cases when someone notifies bot account but the bot operator is unaware of that. --Wesalius (talk) 07:19, 8 November 2016 (UTC)[reply]

Is this proposal basically phab:T50892? If so, this comment might be worth to discuss. :) --AKlapper (WMF) (talk) 10:36, 8 November 2016 (UTC)[reply]
Users who edit Wikipedia with their main account more often than they check their Wikipedia email (which may be different fromt their real-life email) would certainly gain from this proposal. עוד מישהו Od Mishehu 12:29, 10 November 2016 (UTC)[reply]
Email notification is one possibility, but for editors/bots working on multiple projects usable only with global preferences. JAn Dudík (talk) 20:40, 10 November 2016 (UTC)[reply]
Having not seen this proposal, I made a similar but broader one here. Samwalton9 (talk) 14:00, 18 November 2016 (UTC)[reply]

This is related to the management of multiple account (see a "similar" proposal in the miscellaneus section). As usual I support any form of integration. If bot account could be created as spin-off of user account with some sort of a clear relationship stored in a cross-wiki management interface, including notification, that would be more efficient. But it is the same problem with honest sockpuppet and WIR account.--Alexmar983 (talk) 14:02, 18 November 2016 (UTC)[reply]

Hi JAn Dudík: This proposal is very similar to Community Wishlist Survey 2016/Categories/Miscellaneous#Linking of accounts controlled by one user, so I'm archiving your proposal here. I'll add a link under that proposal so that people will be able to see yours as well. -- DannyH (WMF) (talk) 01:50, 24 November 2016 (UTC)[reply]

Scripts and Tools to support Metrics for large scale meetups

edit

Proposal edited, new version: Tool to post barnstars after large scale meetups

  • Problem:

It is hard to collect the usernames from large scale multi-location meetups like en:Art+Feminism. Specifically:

  1. A way to automatically collect all usernames. This becomes quite difficult with hundreds of events, in multiple sign in formats, with inevitable user input errors, on dozens of wikipedias.
  2. A way to list all users created by event organizers with account creator permissions; these users are often the ones that slip through the cracks and don't sign in to the event page.
  3. A way to post barnstars on each user's talk page afterwards. This research paper: https://www.springer.com/cda/content/document/cda_downloaddocument/9783319478791-c2.pdf indicates that interaction on user pages is a key indicator of user retention, so we hope to be able to start with barnstars, and then later check in. en:User:MediaWiki message delivery doesn't look like an actual message, nor is it from a recognizable user that they can write back to. Doing this manually is not an option for an event with thousands of participants.
  • Who would benefit:

Anyone who is organizing large scale meetups, and needs to prepare metrics reports.

  • Proposed solution:

User:Dispenser has a tool: http://dispenser.homenet.org/~dispenser/cgi-bin/useractivity.py?page=Wikipedia:Meetup/NYC/ArtAndFeminism_2016&days=90&view= that does a lot of the work for #1. It would need some revision to allow for the specific use cases (and output formats) that we are working with.

  • More comments:

There is a chance that there are other extant solutions to these problems. We have consulted with many other Wikipedians associated with WMNYC and A+F, and this is what we have been able to figure out.

There is a possibility that some of #1 will be ameliorated by the use of the Event Dashboard, which we hope to use this coming year.

  • Phabricator tickets:

Watchlist folders

edit
  • Problem: Watchlists are somewhat hard to navigate, and currently only organized by namespace.
  • Who would benefit: Wikimedian editors and readers.
  • Proposed solution: Watchlists should have a function for "folders" via the mobile iOS Wikipedia App and Android Wikipedia App, to act more naturally as bookmarks (like using bookmarks in a web browser). This would have multiple uses for many people, such as creating a collection of educational resources. Other functions it can work as:
    • For marking what articles to edit, such as a folder named "United States 50,000 Challenge" which would contain articles to edit.
    • For creating a collection of templates that an editor uses a lot
    • Folders for articles to read later (similar to how YouTube has a "Watch Later function")

I imagine this would help greatly with editing, especially WikiProjects, along with readers alike. This would help me personally :)

Some other things that would also assist with more natural bookmark management would be the ability to customize folder colors, and move folders around.

It would also be nice if this could be a feature for the web special page, Special:Watchlist :)

Community discussion


Separate long-term-watched pages on the "View and Edit Watchlist" screen

edit
  • Problem: When the "Add pages and files I edit to my watchlist" box is checked in Preferences, Watchlists can get very long, and when using the "View and Edit Watchlist" function a user must check through the whole list each time to find items that he or she no longer wants to watch. However, some of the time is wasted because pages of particular interest to the user are checked over and over again.
  • Who would benefit: Editors who edit large numbers of pages and want to separate short term and long term watching
  • Proposed solution: Add a function in the "View and Edit Watchlist" which would allow a user to select certain items and then click "Add to long term watchlist" (or similar wording). These would then be sorted separately so that the editor could go through the others without having to constantly skip over these ones each time.
  • Phabricator tickets:

Community discussion

No, AKlapper (WMF). That looks useful, but this is a different and simpler proposal. At times I have had thousands of pages on my watchlist; setting an individual expiry time for each would take up hours and hours of time. I edit a lot of drafts and AfC pages, moving them into the encyclopedia. How long I watch these depends on what other editors do next, so I couldn't specify a specific time in advance. All I want is to be able to mark my favourite pages, ones in which I have a continuing interest, and have them sorted into a separate section, instead of being mixed in randomly with the others when I am editing my watchlist.Anne Delong (talk) 14:24, 15 November 2016 (UTC)[reply]

Watchlist separation

edit
  • Problem: A huge watchlist in personal preferences - in it more than 42,000 articles. When trying to edit watchlist, then it freeze-up.

The current solution for many people to create separate small lists to use "Related changes" (RecentChangesLinked tool), but it's not possible to watch talk pages that way.

  • Who would benefit: Everyone.
  • Proposed solution:
  1. Allow multiple watchlists for a user.
  2. or edit watchlist in parts, like it when viewing category - "next 500 pages"
  3. or Make RecentChangesLinked tool also include talk pages.
  • Phabricator tickets:

Community discussion

Could someone translate that to English please? The other two proposals below are not in English either. --mfb (talk) 12:10, 14 November 2016 (UTC)[reply]

Thanks. Quiddity (WMF) (talk) 23:04, 24 November 2016 (UTC)[reply]

Make Special:IndexPage transcludeable

edit
  • Problem: At this time Special:IndexPage can only be viewed as a clickable link. Where it is of value is where search filters can be applied, especially for wikiprojects. However it would be of more value if a search link could be transcluded and displayed on project page, eg. display the progress of 69 volumes (63 + 3 + 3) of the Dictionary of National Biography; alternatively all the works of an author
  • Who would benefit: all WSes
  • Proposed solution: make special page transcludeable, either whole page or the body

Community discussion

Archived

@Billinghurst, Yann, and VIGNERON: Archiving this, as the feature's been implemented and is just waiting for deployment. Sam Wilson 01:04, 25 November 2016 (UTC)[reply]

Make search possible in Flow subjects

edit
  • Problem:

Flow doesn't index topics content

  • Who would benefit:

Anyone who want to find something usefull, a question who was already solved for example.

  • Proposed solution:

Index flow topics content

  • Phabricator tickets:

Community discussion

Hi Speculos: The proposal phase ended on Monday; you posted this proposal too late. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 22:37, 25 November 2016 (UTC)[reply]

Improve SVG rendering

edit

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 a 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 fixing an issue often takes only few days (see task T7792).

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

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 as it does its job for their purposes. The Maintainer of libRSVG is Federico Mena Quintero. He maintains libRSVG in his spare time.

Community discussion

Hi Menner, the proposal phase ended last Monday; you posted this proposal too late. I've archived it here. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:55, 27 November 2016 (UTC)[reply]

Greatly overhaul media viewer

edit
  • Problem: It's slow to load and offers no real benefit.
  • Who would benefit: Everyone.
  • Proposed solution:
  1. Rebuild MediaViewer using frameworks with a smaller footprint, both in terms of payload and execution time
  2. Focus only on essential features, in particular consider dropping:
    1. Progress bar - does it cause an unacceptable cost in terms of download size, stability, execution time?
    2. Fullscreen mode - is this a much-used feature? Again, does it cause costs in download size, stability, execution? I think this may be a superfluous feature in the real world as browser windows are often at almost full screen size anyway.
  3. Use CSS rather than JavaScript for modal elements, for performance reasons as stated above
  4. Display useful info, one item per line
    1. File description
    2. Capture date
    3. Artist/creator/uploader and license
    4. Location of work displayed (e.g. museum)
    5. Anything I may have forgotten
  5. Optionally use as development basis https://github.com/Samsara-on-English-Wikipedia/MediaViewerNG (implemented: opening and closing image in MV, keeping scale to window, executing barely more than the minimum JS needed; not implemented: support for old IE versions, scaling to multiple images, pulling description from Commons, other GUI interfaces)

Community discussion

Hi Samsara, this proposal is out of scope for this survey—it's asking for the removal of an existing feature, as I said above. I've archived your proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:33, 21 November 2016 (UTC)[reply]

@DannyH (WMF): I find it deeply disappointing that no dev was able to say in realistic detail how the well-noted shortcomings of the tool would be fixed, and that you're now using the original wording of the proposal as an excuse to avoid any commitment on this issue. You know it's still broken. Samsara (talk) 19:49, 21 November 2016 (UTC)[reply]
Samsara, if you want to revise the proposal, it could go back in the survey. The way that it's written right now, it can't. You have several days to revise, if you want. Let me know what you'd like to do. -- DannyH (WMF) (talk) 20:44, 21 November 2016 (UTC)[reply]
Samsara, I'm bringing this back to the archive. You said "(putting this back here since I've had no response to ping)" -- where was the ping? I didn't get one, so I'm not sure who you pinged, or where.
I can see that you revised it, but this proposal is still essentially "undo major features of media viewer, and/or redesign it from the ground up". I'd suggested above (on Nov 14th): "If the main problem being discussed here is that MediaViewer takes too long to load, then we could turn this into a proposal to improve the loading time." The revised proposal is not specifically targeted to that problem. Points #1 and 3 are load time-related; that could have worked. #2 and #4 are not load time-related; they're about features that you'd like to remove or add.
If the proposal was specifically about the load time, and if that was done before voting had started, then we could have put this into the survey. I'd responded to your ping a week ago, inviting you to revise. Unfortunately, it's too late to revise it again and put it back into the survey.
I'm happy to talk more about this, if you want. -- DannyH (WMF) (talk) 15:53, 28 November 2016 (UTC)[reply]
@DannyH:
  1. Please give me a concrete proposal how the current MediaViewer can be improved in speed and the magnitude of improvement to be expected. You've asked to make this proposal quite specific, so please contribute to this effort. Let's have specific goals. I've shown with a code example and some development hints that it can be done.
  2. I asked about the design goals of MV and got no reply. Samsara (talk) 21:28, 28 November 2016 (UTC)[reply]

@Samwilson: @MusikAnimal (WMF): What discussions did I miss earlier? I saw this being added back and forth. Samsara (talk) 21:28, 28 November 2016 (UTC)[reply]

@Tgr (WMF): I submitted the speed report as requested. Can you make a specific suggestion for how the speed of MV could be improved? Samsara (talk) 21:28, 28 November 2016 (UTC)[reply]

@Samsara: It's too late to revise this proposal and put it back into the survey. Revisions needed to be complete before voting started. I told you on Nov 21st that you had several days to revise. You waited until Nov 28th, the last night before voting started, and revised the proposal in a way that still violates the guideline that I told you about. I know that's frustrating and disappointing for you. I tried to give you as much information and as much notice as I could. -- DannyH (WMF) (talk) 21:34, 28 November 2016 (UTC)[reply]
@DannyH (WMF): You waited until Nov 28th? Seriously? What is your day job, and what is mine? Am I obligated to work to your schedule, and is it reasonable to expect some respect from you in our interaction? Samsara (talk) 21:39, 28 November 2016 (UTC)[reply]
@Samsara: I'm sorry, I didn't mean to imply that I knew how much time you had in your schedule. I'm just saying that I told you on Nov 14th that this wasn't appropriate for the survey, and on Nov 21st that you had several days to revise it. Nov 28th is the day that voting starts, which means it's too late to add a revised proposal; that's the schedule that we're working from. -- DannyH (WMF) (talk) 21:46, 28 November 2016 (UTC)[reply]
@DannyH (WMF): Apart from that, you're factually wrong - there was a viable revised proposal on the 27th. Samsara (talk) 21:51, 28 November 2016 (UTC)[reply]
@Samsara: Unfortunately, as I said above, this revised proposal still violates that guideline. The proposal is recommending scrapping features of MediaViewer that (as far as I know) don't contribute to the load-time problem. I wish we'd had this conversation a few days ago, I would have helped you revise the proposal. I was checking Meta through the weekend to help people with proposals. Your proposal was revised on what was, for me, Sunday night, and you didn't ping me to look at it and see if it was okay. I'm not trying to tell you what you should do or shouldn't do; I'm just explaining why this situation makes it too late to fix now. -- DannyH (WMF) (talk) 22:00, 28 November 2016 (UTC)[reply]
Oh, PS, just so it's clear: This was not the only proposal to be archived because of the schedule. There were several posted after the proposal phase deadline (Nov 21st); you can see them on this page, directly above yours. -- DannyH (WMF) (talk) 22:03, 28 November 2016 (UTC)[reply]
@DannyH (WMF): Which feature have I proposed dropping, independent of its effects on load time? Samsara (talk) 22:13, 28 November 2016 (UTC)[reply]
@Samsara: As I said above, earlier today:
"I can see that you revised it, but this proposal is still essentially "undo major features of media viewer, and/or redesign it from the ground up". I'd suggested above (on Nov 14th): "If the main problem being discussed here is that MediaViewer takes too long to load, then we could turn this into a proposal to improve the loading time." The revised proposal is not specifically targeted to that problem. Points #1 and 3 are load time-related; that could have worked. #2 and #4 are not load time-related; they're about features that you'd like to remove or add. If the proposal was specifically about the load time, and if that was done before voting had started, then we could have put this into the survey." -- DannyH (WMF) (talk) 22:19, 28 November 2016 (UTC)[reply]
@DannyH (WMF): So are you willing then to retract your previous assertion that The proposal is recommending scrapping features of MediaViewer that (as far as I know) don't contribute to the load-time problem. as that upon your closer examination, is not the case? Samsara (talk) 22:26, 28 November 2016 (UTC)[reply]
@Samsara: No, that's why I posted the quote. Item #2 in the new proposal is recommending specific features to remove, because you don't find them essential. Item #4 in the new proposal is recommending a change to the information presented on the page, including a specific design requirement (one item per line) that has nothing to do with load time. Again, as I said above: "If the main problem being discussed here is that MediaViewer takes too long to load, then we could turn this into a proposal to improve the loading time." The revised proposal is not tailored to that goal. -- DannyH (WMF) (talk) 22:34, 28 November 2016 (UTC)[reply]

Samsara, I fear this proposal overgeneralizes from very limited anecdata. It takes around 700-800 ms from the initial click to MediaViewer displaying the final image for the median user. That's not great (a change typically feels instantaneous if it happens in less than 200 ms) but that's an average from all over the world, many users are on slow bandwidth, and the WMF does not have expensive caching centers all over the world so transferring a large image will never be lightning fast. The file page takes more time to load - it's hard to accurately measure how much since browsers don't report when have they finished downloading an image, but they do report the first time they start displaying anything at all, and even that takes slightly more time (despite MediaViewer loading a significantly larger image). This is not particularly suprising - the code for MediaViewer is around 150K when compressed, and an average file page is around 500K with all the assets (excluding the image itself). The difference only grows after the first time, as MediaViewer gets cached by the browser and never needs to be downloaded again, while a file page is around 300-400K even after all the cacheable assets have been cached.

Loading speed varies greatly (it's 10 second at the 99th percentile, ie. it takes longer than that for the one percent of the users with the slowest loading speed) and it's conceivable that MediaViewer does not work well with specific browsers or browser extensions or connection types (although I'm pretty sure if such a thing exists it only affects a small fraction of the userbase, otherwise it would show up in the stats). If that's the case though, the main blocker to fixing it is the lack of information about the edge cases in which performs badly, so the most effective way to help is to contribute speed reports, as I mentioned. (Thanks for doing that!) Once there is enough information to figure out exactly what causes the slowness (as I said, it's almost certainly not the JS download size - the file page is significantly larger than that), it might make sense to lobby for the Community Tech team (or someone else) to work on it, but in the two years so far there have been many complaints but almost no useful data, so report collection is definitely the bottleneck.

As for the other issues:

  • the image viewer on mobile is a different software that's unrelated to MediaViewer.
  • you can scroll down to show more information (including the description and the date). Unfortunately some information (such as retouching) is not available in structured form so it's not possible to display in a sane format. That's only relevant for a tiny fraction of the images though. Eventually having structured data on Commons will solve that.
  • in general, trying to show all the available information often just results in users ignoring it all and thus gives worse results than only showing the most important bits. MediaViewer has went through extensive usability testing and that informed the current design. I wasn't involved in that and don't have much opinion either way but if you are interested I would encourage you to reach out to the design team (by filing a task for proposed changes in Phabricator, for example) instead of just jumping to conclusions about what would work.
  • you can find the design goals of MediaViewer on its project page. Basically, better image viewing and browsing experience, quick access to the most important information, help with reuse and attribution.

Hope this helps. --Tgr (WMF) (talk) 03:10, 30 November 2016 (UTC)[reply]
(Disclaimer: I am one of the people who worked on creating MediaViewer, but I am not its official maintainer at this time (although I might help out in my free time). All of the above is my personal opinion and not the position of the WMF, the current maintainers or any other group.)

@Samsara: Pinging you so that you see Tgr's reply above. ^^^^ -- DannyH (WMF) (talk) 04:00, 30 November 2016 (UTC)[reply]

Find and Replace across wiki pages/projects

edit
  • Problem: In our Tamil Wiki Projects, we have lot of red links since references are copied from English / Other language wiki to our wiki. It creates red links and it looks very bad in our article. We have policy that all our articles will be in local language. No redirects for other languages. Similarly people often misspell some of the words. There should be find and replace across our wiki pages. The same tool can be helpful in all other wiki's for fixing typo issues or some repeated misspelled words :-)
  • Who would benefit: Most of the person who does clean up.
  • Proposed solution: I have created a tool to find and replace with list of items. However I need to copy and paste the articles and needs to analyze and replace it. I need a tool which can do for all the wiki articles. It can have the feature to show me the page and context for confirmation before replacing it. Looking forward for something like Find in Files and Replace feature available with Notepad++. There might be other tools available, which am not aware of.
  • Phabricator tickets:

Community discussion

@Dineshkumar Ponnusamy: There is a simple "find and replace" built in to both the wikitext toolbar (see screenshot from Tawiki), and in the visual editor options menu (see screenshot from Tawiki).

For a more powerful set of features, the w:en:Wikipedia:AutoWikiBrowser software (Tamil page that I cannot read, and might not be uptodate w:ta:விக்கிப்பீடியா:விக்கிதானுலவி) might be what you're looking for. (note: it requires a Windows OS, and I'm not familiar with its usage). There are some alternatives listed in the "See also" section there, which might also fill your needs.

Does that solve your proposal? If not, please could you update it, based on this new information? Otherwise it is probably not clear enough to enter the voting stage. Thanks! Quiddity (WMF) (talk) 02:00, 19 November 2016 (UTC)[reply]

@Quiddity (WMF), thanks for looking at my proposal. Am not looking for normal find and replace inside a page. I am looking for Multiple Find and Replace in Multiple pages at a single click. Look at this change! I want this to be done with the help of a tool which has little Artificial Intelligence. I have created a windows based tool with Artificial Intelligence, but it process one article at a time, similar to AWB. Am not sure whether the latest version of AWB supports this feature! Thanks Again. --Dineshkumar Ponnusamy (talk) 04:25, 19 November 2016 (UTC)[reply]
@Dineshkumar Ponnusamy: It is possible with AWB, per the line at the top of the documentation page, "Although AWB does have an automatic mode enabled for some bot accounts, it normally just assists a human.". However, it is strongly recommend to use the manual mode (which allows rapid editing through a list of articles) to enable error-checking, and to catch any edge-cases which don't fit expected results. Hope that helps. Quiddity (WMF) (talk) 17:41, 21 November 2016 (UTC)[reply]
@Dineshkumar Ponnusamy: See also, the Community Wishlist Survey 2016/Categories/Bots and gadgets#Web-based AutoWikiBrowser alternative proposal. I will archive this proposal, in a day. Thanks. Quiddity (WMF) (talk) 18:57, 21 November 2016 (UTC)[reply]
@Quiddity: Is this proposal still subject to archiving? Stevie is the man! Talk • Work 22:47, 28 November 2016 (UTC)[reply]
@Stevietheman: Thanks for the reminder! (And your comments throughout). Now done. Ping @Dineshkumar Ponnusamy: for visibility. Quiddity (WMF) (talk) 23:37, 28 November 2016 (UTC)[reply]

Primary Sources tool for Africa

edit
  • Problem: African editors have trouble locating suitable primary sources to provide reference bases for their articles
  • Who would benefit : This would benefit editors in Africa by enabling them to better/ more easily leverage suitable sources
  • Proposed solution : A variety of academic sources JSTOR/Haithi trust etc are licensed for free access to those in Africa (sometimes only African universities). What I would want to do is develop a version of the Primary Sources Gadget that could mine the data that is available for those in the continent, and make references to it available to African wikimedians to help their editing work. This would probably need negotiating new access frameworks but I think this achievable.
  • Phabricator tickets:

Community discussion

I agree on the problem but do not really understand the solution. Adding content from Africans with local knowledge can often run into erase-debates, which adds to the imbalance in North-South content. Kipala (talk) 16:56, 18 November 2016 (UTC)[reply]

Bot that will help in analysing Biography on Wikipedia

edit
  • Problem: We noticed that there are no tool that can be used for analysing or sorting biography on wikipedia,. There are instance, we need biography in term of gender,dead,Living, countries etc
  • Who would benefit: Anyone interested in research on biography in the movement
  • Proposed solution:
  • Phabricator tickets:

Community discussion

Voting – Analysing Biographies on Wikipedia

edit
  1.   Oppose Vague and malformed proposal. This should probably be archived. -FASTILY 06:58, 2 December 2016 (UTC)[reply]
  2.   Oppose Developing specific tools for research purposes that will help solve the described problem seems reasonable but nothing can be done without having precise request on what is needed.--Kiril Simeonovski (talk) 12:45, 2 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Archive&oldid=24950194"