Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Archive

< Community Wishlist Survey 2017

This page is an archive for 2017 Community Wishlist Survey proposals that won't go on to the voting phase. Proposals may be archived for various reasons, including: the proposal is too vague, the idea is technically unfeasible, the problem has already been solved, an existing product team is already working on it, the proposal is a social/community change rather than a technical one, or the proposal is asking to remove features that WMF product teams have built.

Only members of the Community Tech or Technical Collaboration teams should move proposals into or out of the Archive. If your proposal has been archived and there's still time before the voting phase starts, please continue the discussion on your proposal! You may be able to fix a problem with the proposal, and get it back in the survey. Once the voting phase starts on November 27, 2017, we can't move any proposals out of the Archive.

make more detail in information，To protect all reader profit

  Idea is not well explained

  • Problem:
  • Who would benefit: reader
  • Proposed solution: create more protection
  • More comments: create more information
  • Phabricator tickets:

Community discussion

edit

This proposal is currently too vague and unclear. Please follow https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey#What_happens_during_the_proposal_phase.3F and provide way more information, by editing your proposal. --AKlapper (WMF) (talk) 12:38, 7 November 2017 (UTC)[reply]

  • Sorry, but I've archived this proposal because nobody can understand what you mean. You may want to find someone to translate your proposal from your native language. Feel free to revise and unarchive. Thanks! Max Semenik (talk) 18:35, 8 November 2017 (UTC)[reply]

Provide a search facility for office documents (like .doc)

  Unrelated to Wikimedia projects

  • Problem:

By now searches in e.g. .doc files is not possible.

  • Who would benefit:

Anyone up to the wikia software base, where it would be of additional benefit due to enhanced possiblities to use wikia for business applications.

  • Proposed solution:

An internal tools is needed to decipher (proprietary) data formats. There is an abandoned project/version somewhere (saw it some years ago).

  • More comments:
  • Phabricator tickets:

--Mideal (talk) 10:57, 7 November 2017 (UTC)[reply]

Community discussion

edit

Hmm, how is this related to bots and gadgets? Sounds more like https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Search to me? --AKlapper (WMF) (talk) 12:32, 7 November 2017 (UTC)[reply]

Archived

edit

Per my comment above, I've archived this proposal as it's clearly not related to Wikimedia projects. We're not enterprise users and you can't even upload files in proprietary office formats here. Please feel free to reformulate and unarchive. Thanks for participating! Max Semenik (talk) 19:52, 8 November 2017 (UTC) [reply]

Rules for internal Wikimedia projects

 N Proposes social/community change rather than a technical feature

  • Problem: Harrasment, defamation and lies of users in internal or non offical Wikimedia projects/groups (e.g. Phabricator, Meta) make contributing impossible to some users. The problem is, these groups does not have conflict solving processes, like Wikipedia and attackers, may freely live, within these communities.
  • Who would benefit: Wikimedia Projects, inidividual contributors
  • Proposed solution: Establish transparent decission making process and adopt Wikipedia like proceduress like Arbitration Comittees, within the groups, which doesnt have them yet.
  • More comments:
  • Phabricator tickets:

Community discussion

edit

I'm afraid this is out of scope for this survey as the survey is about community's technical needs while your proposal is about policies. Do you have any technical asks? Max Semenik (talk) 21:07, 8 November 2017 (UTC)[reply]

@Juandev: Just this year, Wikimedia's Code of Conduct for technical spaces went into effect. It is a new policy and committee designed to resolve exactly the problems you are mentioning on Meta, Phabricator, IRC, and other technical spaces. Are there any tools or features that need to be built for this to work? I'm going to archive your proposal, but please open a new one if you have ideas for tools or features for us to build. — Trevor Bolliger, WMF Product Manager 🗨 21:24, 8 November 2017 (UTC)

Викимарафоны и конкурсы с ценными призами

 N Proposes social/community change rather than a technical feature

  • Problem: Викимарафоны и конкурсы по написанию статей в настоящее время привлекают недостаточное количество участников. Работа над статьями ведётся весьма медленно. В то же время конкурсы "Ящик конфет/компьютер/автомобиль/ за репост" в соцсетях набирают сотни тысяч и миллионы репостов. Почему же мы не можем организовывать нечто подобное? К тому же многие редакторы были бы рады получить вознаграждение за активную работу.
  • Who would benefit: википроект, в котором будет проведён такой спецзабег.
  • Proposed solution: необходимо регулярно организовывать статейные конкурсы с ценными призами. Призы может обеспечивать спонсор, при этом каждый приз должен быть брендирован Википедией. Статьи заливаются в Фонтан и оцениваются жюри, причём базовые критерии качества (размер от 5 КБ, хоть одна ссылка а источник, хоть одна категория, антиплагиат) проверяются автоматически. Возможные форматы конкурса:
  1. Обычный забег по написанию статей, универсальный или тематический. Статьи оцениваются жюри балльно, в конце концов все участники ранжируются по количеству баллов и соответственно получают награды.
  2. Забег с вероятностью. Призы разыгрываются рандомно, как в конкурсе репостов, но количество баллов влияет на вероятность (пример: в марафоне 2 участника, первый получил 10 баллов, второй - 40. С вероятностью 80% приз получит второй участник).
  3. Призы с объявленной ценностью. Заранее объявляется ценность каждого приза (например, значок - 10 баллов, смартфон - 1000 баллов и т.д.), а по итогам забега каждый участник может потратить полученные баллы на любые призы по своему усмотрению, как в ru:Поле чудес.
  4. Гарантированные призы. Ставится несколько планок, и в зависимости от того, какая достигнута, участник получает приз. Например, если по итогам марафона более 300 баллов - получает набор сувениров, более 2000 - смартфон, более 5000 - ноутбук.

Разумеется, призы могут быть тематическими, если таков марафон. Например, на марафоне искусств можно разыгрывать репродукции картин и книги, на географическом марафоне - атласы, глобусы и навигаторы, на музыкальном - сборники нот, наушники и музыкальные инструменты. Главный приз должен быть наиболее ценным, а поощрительными призами для большого количества участников могут быть блокноты, значки, магнитики и даже коллекционное издание Википедии на CD-диске. Под Новый год можно проводить большой марафон с исключительно ценными призами, например, главным призом может быть автомобиль (а поощрительные призы - ёлочные игрушки в виде логотипа Вики). Для повышения интереса новичков марафоны должны быть широко анонсированы в социальных медиа.

  • More comments: работа над статьями в настоящее время выглядит так: "Служи, дурачок, получишь значок!".
  • Phabricator tickets:

Community discussion

edit

Archived

edit

I've archived this proposal because it's about running an event while our survey is about technical problems only. Thanks for participation though! / Я перевёл это предложение в архив потому что оно касается проведения мероприятий, тогда как наш опрос только для технических вопросов. В любом случае, спасибо за участие! Max Semenik (talk) 23:06, 8 November 2017 (UTC) [reply]

Establish fund for those, who work with community

 N Proposes financial/cultural change rather than a technical feature

  • Problem: Price of transporation or of some tools, bocks some people to work with community.
  • Who would benefit: Activy community, Wikipedia and Wiki projects
  • Proposed solution: We have funds, which supports development, we have fund which support people on travel on non Wikimedia events, but we dont have fund/programme to support people on travel for people, who need to meet physically community and work with them. So, I would set some roles and establish it.
  • More comments: Even we had reasearch on community, which revealed us much. We still take care of newbies and of looking for new editors. Old editors, kind of stay behind an are left. To work with these editors, may help with their survival, but also with how, they will care of new editors and adopt changes. If you want to travale and animate people to work on the crosslanguage project, you must be from a country, where is a strong Chapter, which will support you - otherwise your activity is lost.
  • Phabricator tickets:

Community discussion

edit

Hi Juandev, this proposal doesn't fit the purpose of this Wishlist Survey. We're looking for ideas for features or fixes that our development team can build. Our team doesn't financially support community projects; I think what you're looking for is the Grants process. I'm going to move your proposal into the Archive. Thanks for participating in the survey. -- DannyH (WMF) (talk) 23:37, 8 November 2017 (UTC) [reply]

Blockbox (information on relevant policies to blocked users)

 N Proposes social/community change rather than a technical feature

  • Problem: Well, coming from a currently (as of writing this on August 19th, 2017) blocked user I can tell you one thing, the blocking experience is very user unfriendly, if you are not familiar with WikiJargon or have sufficient knowledge of all the rules and guidelines (which I have familiarised myself with now) this can be a troubling ordeal, especially since you might not know your options. One of such options (on English Wikipedia at least) would be the UTRS, if your talk page access has been revoked and you have no idea what to do.

Maybe you think that what you did was appropriate, well the list on the “Blockbox” could precisely show what options you have as well.

  • Who would benefit: Well, most importantly the readers, and of course blocked users. This would also largely save the time of administrators for (1) not having to explain the reasons for their blocks after it has been applied as the policies are directly linked, (2) have an informative guide to all the necessary information, and (3) make it more likely that the appealing people are more informed on WikiPolicies, how to appeal blocks and how to avoid any re-blocking.
  • Proposed solution: Well, Wikimedia projects are all educational, so why not educate those who have been blocked on why they have been blocked? In those United States of America many police 👮🏻 officers read people their rights upon arrest, this could also familiarise those who genuinely have a wish to be helpful to educate the readers and utilisers of Wikimedia projects to return and learn what they did wrong.

Remember, trolls and vandals probably won’t file an unblock request, in most cases they will evade and troll some more, but those who are genuinely interested in learning from their mistakes and willing to contribute positively should be given a chance, even if they’ve been unfriendly I would say “be friendly to unfriendly people and they might return the favour”, in fact I would probably advocate a model of “talk first, block later” but to apply that community wide would be unrealistic, allowing blocked people to be properly educated on their disruptions and their options might even work to prevent a repetition of the behaviours that lead to their blocks in the first place.

I thought of an idea that could basically serve as “the Miranda rights of Wikipedia” (or “the Blockbox”) where after a user or IP gets blocked by an admin (so not rangeblocks or autoblocks but direct blocks) a bot will automatically leave this message on their talk page (even if the talk page was previously deleted). This could start off on English wikipedia and then if it turns out to be successful could be “exported” to other wikis.

It appears that you have been blocked.

Please read the guide to appealing blocks.

* If you are currently unable to access your talk page you may request an unblock via the Unblock Ticket Request System or the #wikipedia-en-unblockconnect chat channel.
* Checkuser and Oversight blocks may be appealed to the Arbitration Committee.
* If you were blocked by Jimbo Wales then you may appeal directly to him and/or the Arbitration Committee.
* If this is a Sockpuppet then you should confess your main account (or IP) now so you may receive a reduced penalty.
* If you have been blocked for a username violation then you can simply create or request a new account or request to be renamed here or at #wikimedia-renameconnect, if however the username was made in bad faith then first request a rename and then you may appeal the block; further reading Wikipedia:Changing username.
* If you have been blocked for adding promotional material or spam then please read about our policy on this and our external links policy before requesting an unblock.
** If you continue to violate this policy then the next time the duration of your block will increase. If you believe the link(s) you added aren't spam then you may request for it to be removed from the blacklist.
* If your options are currently still unclear then please read the more technical how to appeal a block.

Notes: As of currently the standard offer is 6 months but maybe if a user confesses this could be reduced to 3 months or something in that direction, this would give sockpuppeteers more of an incentive to co-operate.

The above are all the blocking criteria I am currently aware of, this is just a suggestion and open to improvement.

Personally I envision this box/template to be red or orange or a combination thereof but I am not familiar enough with the parameters to adjust this.

Maybe a sad Wikitan in prison clothes could be used as the image. 🤔

Note that all links 🔗 function as if they are in the English Wikipedia and may not function here on Meta.

For this task a new bot called the “Mirandabot” will be programmed, on a more humourous note it could tag every edit with “You have the right to remain silent, anything you say can and will be used against you in an appeal of WikiOrder”, this bot solely exists to deliver the above template and may not perform any other tasks.

IMPORTANT NEED FEEDBACK: Maybe a note for living people who were trying to remove unsourced slanderous material from pages about themselves to be directed to the right outlets, this will almost certainly prevent many WMF office actions. But then again I’m not a barrister, works?

Also note that this is to prevent further disruptions and to familiarise blocked persons with the guidelines and policies that apply to Wikipedia, as of now those willing to come back to contribute positively are faced with a wall of silence and not all rules and guidelines are properly linked to each other, I believe that creating such a system can be instrumental in preventing many disruptions, sure trolls will troll not every blocked person is a vandal and we should not assume as such.

Honestly I thought that this idea could also “grandfather in” users blocked prior to its launch, however that might require a “MirandaBotOld” or might it simply delay the newly blocked members of the community, however I think that time should be no issue and that all standing blocks should also be grandfathered in.

The goal of this project is to ultimately reduce the number of disruptions and increase the numbers of willing good faith contributors, if we would approach everyone with a friendly message showing them their available options and inform them to properly read the guidelines they did wrong I strongly believe that the amount of continued disruptions to the project shall decrease, even if there are current flaws and yes the system is open to abuse (angry trolls might vandalise the IRC channels) I think that it will do more good than harm.

  • More comments: Additionally there should be a newly established “Sockfession booth” where Sockpuppeteers (such as myself) may have the option to confess and receive less penalties, however the system may only be used once and repeated violators of WP:SOCK will then be “punished” the same way as those who didn't confess (your “once sock shot” if you will).

Other names for the Sockfession booth could be “Wikipedia costums” (as in border costums), “Multiple Account Disorder Therapy Group” (for those who share my sense of humour, to those that don't get it it’s named after the multiple personality disorder), or “Drawer checkings” (get it…. Because they’re socks… I’ll let myself out).

  • Phabricator tickets:

Community discussion

edit
Hi Donald Trung: The Wishlist Survey is looking for proposals that the Community Tech product team could work on. What you're proposing here is a social/community change, rather than a technical feature. I'm archiving this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:14, 9 November 2017 (UTC)[reply]

User watchlist

 N Declined in a previous survey

  • Problem: в настоящее время невозможно удобно следить за вкладом выбранного участника, сделанным в любые страницы. Это может быть полезно для контроля за потенциально недобросовестными или неопытными участниками либо за участниками, чей вклад представляет интерес для наблюдающего
  • Who would benefit: зарегистрированные участники
  • Proposed solution: предлагается включить функцию "Следить за вкладом участника". В этом случае в списке наблюдения будут отображаться все его правки, сделанные в любые страницы. Аналогичное наблюдение можно сделать для IP-адресов.
  • More comments:
  • Phabricator tickets:

Community discussion

edit

Translated to English...

  • Problem: It is currently not possible to conveniently monitor the contribution of the selected participant made to any page. This can be useful for monitoring potentially unscrupulous or inexperienced participants or for participants whose contributions are of interest to the observer.
  • Who would benefit: Registered participants.
  • Proposed solution: it is suggested to include the function "Follow the participant's contribution". In this case, all the edits made to any pages will be displayed in the watchlist. A similar observation can be made for IP addresses.

(Translated to make discussion more accessible to others. Tortillovsky (talk) 00:15, 9 November 2017 (UTC))[reply]

Yes -- unfortunately, this isn't a feature that we can build. There are good reasons why people want a feature like this, but it makes things too easy for a user who wants to harass others. As Semmendinger said above, you can read more about this on the Community_Tech/Add_a_user_watchlist page. I'm going to move this proposal to the archive. Thanks for participating in the survey! -- DannyH (WMF) (talk) 21:48, 9 November 2017 (UTC)[reply]

Take the subject of licenses seriously

 N Primarily a policy/licensing change rather than a technical feature

  • Problem: Wikidata withdraw licenses while performing massive imports from miscellaneous sources, including Wikipedia. This put the project itself, and every project using it at large scale, at a heavy legal risk.
  • Who would benefit: Anyone using wikidata at some expand.
  • Proposed solution:
    • Integrate a field "licenses", enabling to document this at the same extent as references
      • Update this field for every Wikidata entry which obviously came from a massive import (be it through bots or crowd sourcing)
      • If any, remove data which came from such a massive import backed on sources without at least one explicit free license
      • Allow every user to select a set of free licenses under which they agree to publish their own original contributions, so that the "licenses" field is set automatically for this user contributions. As on Commons, user should select at least one free license, but neither CC0 nor any other license should be an mandatory choice.
        • Of course if the data is already licensed under a license not compatible with some of the user set of license, any attempt to contribute should lead to a warning and, after user approval, a publication only under the modified data license set and its intersection of compatible licenses within the user license set.
      • For the sake of equity that our movement is highlighting as one of its core value, the default license set should only include copyleft licenses.
        • For the sake of compatibility with other Wikimidia projects that Wikidata is suppose to back, this default set of licenses should include CC-BY-SA-3.0-unported and possibly GFDL 1.3.
      • Whatever the default set of licenses will be selected, the existing data should move to it, so it will cover further updates of this entries. But CC0 might stay relevant for data imported so far when they didn't came from sources with incompatible licenses – like Wikipedia. Note that this move is completely allowed by CC0 and was even advanced as part of the plan beyond the test phase[1].
    • Conduct an open legal inquiry with experts of the field to create a clear up-to-date report of what is – under current laws – definitely legal, definitely illegal, and what is in the realm of legal blur.
      • Following this report, adopt clear policies for Wikidata to only accept contribution that stands in the field of definitely legal practices
        • If any, clean Wikidata entries which are already recorded and don't conform to this policy
        • Possibly, develop some tools which help making this policy respected
  • More comments:
    • This solution does not prevent any reuse at all. It only makes more clear what are the real potential legal issues, were the current practise is to pretend there is no issue without presenting any serious report on the subject. Giving a fine grained license information allow reusers to remix accordingly with full background knowledge. Querying features make it easy to filter data which are covered under compatible licenses.
    • On a side note, a policy regarding import of Wikipedia content should be created in order to avoid circular references which make a large portion of Wikidata references useless for Wikipedia and sister projects, all the more when the reference doesn't provide a precise passage of an article in a given version.
    • Enlarged community consultation on some or all of this point would be appreciable.
    • Most points are independents, or the list depth reflect this dependencies, so it's not a take or leave it all proposal.
  • ↑ So do I understand it correctly that during development and testing, we can can go with CC-0, and later relicense to whatever seems suitable, which is possible with CC-0 [Wikidata-l] Is CC the right license for data? Denny Vrandečić Tue Apr 3 09:42:57 UTC 2012
    • Phabricator tickets:

    Community discussion

    edit
    IANAL but it seems like a good idea to have Wikidata content doubly-licensed under CC-BY-SA and ODbL, to ensure that no compatibility issues arise from importing stuff into Wikidata. It's a win-win: if you take the stance we should ignore the fact that certain jurisdictions uphold database rights, no ill will come from using our data. If you accept the (regrettable) existence of database rights, this will have the added benefit of multiplying free cultural goods. NMaia (talk) 00:42, 9 November 2017 (UTC)[reply]
    IANAL but it seems like a good idea to have Wikidata content doubly-licensed under CC-BY-SA and ODbL
    You can not legally relicense CC-BY-SA under ODBL without explicit agreement of each author. To be clear, I'm not hostile to ODBL nor any free license, although I would recommand non-copyleft licenses only in very specific cases, in which I would not include Wikidata as a whole. But I would argue that you just can't take a whole data set such as Wikipedia, parse it into every predicates that automation state of the art enable you to extract, and put the result under whichever license fit your own personal preferences. All the more when after that you propose to generate stubs for smallest Wikipedia, stubs which could be then be licensed under CC0 as they come from synthesis of CC0 data, isn't it? And in the same time, you can't directly translate an Wikipedia article, even a stub, and say the translation is CC0. But I'm also not a lawyer, hence the need of creating a report by experts of the field as a prior requirement for some points of the proposal.
    Also note that with this proposal, users which would like to do so, might indeed add ODBL as one of the license set under which they agree to release their works, and that massive import from ODBL sources could lie within Wikidata, but they would be flagged as such (as well as under other licenses if it does apply). Responsibility for mixing in synthetic ways a large set of data which are coming from misc. sources would be buried by the mixer.
    It's a win-win
    if you take the stance we should ignore the fact that certain jurisdictions uphold database rights, no ill will come from using our data.
    No it's not a win-win. It's a "I withdraw your license clauses which doesn't accommodate me by withdrawing the whole license" case. Those who licensed their work under CC-BY-SA virtually lose all their rights in the process. I said virtually, because until they are serious investigation done which prove it otherwise, this is just a plain illegal practice, and everybody who use this data are just building their works on highly doubtful legal ground.
    Please stop propagating the obviously fallacious "certain/some jurisdictions" offer monopoly on database. So far, the most official peace of claims made by the foundation regarding database rights states that their are indeed monopoly accorded on databases, based on misc. legal grounds, both in USA and Europe. Ok, that's not the whole world, but it's not just a few marginal cases. All the more the previous link doesn't say there is no monopoly on data in other countries, so until someone come a complete report on the state of the law on this topic, please assume that it is not legally safe to make as if there was issue. Plus the motto for our movement is "a world where every human have access to the sum of all knowledge, not those who have the luck to live in a favourable jurisdiction.
    This seems more a policy issue, which probably doesn't really match the goals of community tech tasks.
    This is a policy issue, which do lead to technical needs to help its tracking and compliance. Of course the root requirement is not technical, I would not expect a single requirement to start from purely technical needs. Technical solutions are there to solve problems of our community, aren't they?
    The proposal make it clear that there are points which do have extra-technical requirements, but the dependency tree always finish with a leaf that is technical or have at least one technical dependency. Plus, once more, this is not a take or leave it all proposal.
    Shouldn't this be discussed within the Wikidata community first ?
    Wikidata doesn't impact only Wikidata, but all Wikimedia projects and even beyond as the Wikidata team is actively pushing exo-wikimedian reuse. So, of course Wikidata community is warmly welcome to discuss the topic, just as the rest of our community. Sure the discussion might have been conducted completely out of this technical wishlist, but since some possible technical requirements have already been identified, this just make plain sense to report it there, doesn't it?

    --Psychoslave (talk) 09:11, 9 November 2017 (UTC)[reply]

    Having the discussion at this place is a good way to have a discussion that won't affect policy as the technical wishlist as it's not within the powers of the Community Tech to affect policy.
    This is essentially about removing the feature that all of Wikidata is CC0 and the wishlist documentation says "One more note: 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. They won't be in the voting phase."
    Saving that it's a win-win also ignores the fact that not having data in CC0 creates problems for Wikidata. To take one example, Quora couldn't easily exchange data with us if we would have a copyleft license. The same goes for other projects. ChristianKl (talk) 10:43, 9 November 2017 (UTC)[reply]
    the technical wishlist as it's not within the powers of the Community Tech to affect policy
    I agree, the technical community don't needs to establish policies (beyond its own right to discuss it as part of the community), if that is what you mean. Nevertheless it can provide tools which help to track respect of policy, whatever it happens to be.
    This is essentially about removing the feature that all of Wikidata is CC0 and the wishlist documentation says "One more note: 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. They won't be in the voting phase."
    That's not a bug, it's a feature. Well, no, this is a serious issue that have to be resolved yet with serious investigations on the one hand, and it happens that on the other hand a technical feature might lower the heavily doubtful legal state of Wikidata items. All the more the feature requested might also serve to explicitly state that an item is under CC0, if that is not legally doubtful in view of the data source and the amount of data extracted from it that was imported within Wikidata. I'm not aware of any feature on this topic for which the WMF product team that would be removed by such an addition of feature. At worst it might require deletion of items whom provenance raises licensing doubts, but no such thing can be added in the database by the WMF product team as they surely respect that the foundation terms of use that they merely host the content, and that editorial control is in the hands of [contributors] who create and manage the content.
    Saving that it's a win-win also ignores the fact that not having data in CC0 creates problems for Wikidata. To take one example, Quora couldn't easily exchange data with us if we would have a copyleft license.
    You are making a wrong assumption if you take this proposal if you take for hypothesis that it tries to prevent any use of CC0 within Wikidata. If Quora did obtained from their users to publish all their works under a CC0, then we don't need any further permission to import that in Wikidata, and specifying a source with timestamps and specify it was published under CC0, then its fine. Or if they have or their user granted them a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to do whatever they want with their works, surely there is no problem with Quora including data under CC0 within Wikidata. But if the problem you mention is that with copyleft license Quora can't do whatever they want with the work of the Wikimedia community, then yeah, that's the intended goal of the copyleft license. Just like people are not legally allowed to upload random files from Commons on Facebook. What you are talking about is all but win-win. So far, it looks more like Wikidata was transformed into a license laundering machine, gathering tremendous amount of data which is pretended usable under CC0 without providing any serious clue to ground that claim. The fact that Google founded half the sum of the initial project and that Denny Vrandečić which have been leader of the project and a fervent CC0 promoter now works on the Google Knowledge Graph which – with other sources – relies on Wikidata, is worrisome. Not because they use Wikidata community works, which is fine, and copyleft license allow that too. But because tomorrow they might just improve their own internal database, curated with custom non-free curation interface or simply through their sprawling worldwide tracking system of users who contribute in an unaware passive manner. And as they will have extracted all the value of Wikimedian CC-BY-SA projects through the Wikidata license laundering machine, our projects will be left as a hopeless hijacked victim, and our then invisible community will be dispelled as slaves in the realm of the all mighty for-profit tech giants. Well, sure, that's a grandiloquent way to paint a really dark dystopia picture. But, sadly, it's not a unrealistic scenario.
    So, really we shouldn't care much if Quora or anyone else out there might have difficulty to use Wikimedia works as a result of our movement knowledge equity commitments. If the price asked for some agreements is to approve inequity, then our movement must reject it.
    But for now, the main technical point of this proposal is not asking anything but to provide better license curation tools to our community. --Psychoslave (talk) 13:28, 9 November 2017 (UTC)[reply]
    Serving data under CC0 is allowing data users a maximum of freedom. This license choice allows Quora to participate by adding free data to our project. The statement says "We will break down the social, political, and technical barriers preventing people from accessing and contributing to free knowledge". Having Wikidata under a more restrictive license would be a barrier for some stakeholders to participate.
    Disagreeing with policy decisions is your right, but this isn't the forum where policy is supposed to be decided and pretending that this doesn't go against the decisions for the Wikidata project is ignoring the realities. ChristianKl (talk) 13:53, 9 November 2017 (UTC)[reply]
    Serving data under CC0 is allowing data users a maximum of freedom.
    But that's not the goal of Wikimedia movement. The goal is knowledge equity. We can promote freedom wherever it begins to confirm freedom of everybody, but beside this threshold freedom, that knowledge ought to canalise, is blind pulse with no safeguard against the worst behaviours that humans are apt to.
    This license choice allows Quora to participate by adding free data to our project.
    That wouldn't change with this proposal. If Quora do have the right and the will to add data under CC0 to Wikidata, this proposal will let this possibility intact.
    Having Wikidata under a more restrictive license would be a barrier for some stakeholders to participate.
    The proposal wouldn't prevent what you described. Plus the converse of your statement is also true: having a less restrictive license can also be a repulsive barrier for those willing to contribute, but only within a fair mutual equal right beside works that will be derivative from their contributions.
    Admittedly, I fail to read "We will break down the social, political, and technical barriers preventing people from accessing and contributing to free knowledge" as "we will encourage individual to withdraw all rights that civil societies ever granted them so that for-profit corporation can exploit freely their works, being assure that they would have no legal duty if they ever arrived at a winner-take-it-all economical monopoly position". If you want to insist more on the case of Quora, I would ask you to provide more information about what do they give, what do they take, who created what they give (benevolent or paid editors?), under which condition (license, EULA) this work have been created, and how Wikidata is used by Quora if it is in any way (do they credit their sources?).
    All the more, if they can release under CC0, then they can release it under a copyleft license, so there is no legal mandatory reasons to refuse to do so if where interested in an equitable cooperation, istn't it? --Psychoslave (talk) 14:37, 9 November 2017 (UTC)[reply]
    Example needed
      Oppose adding a license field. Wikidata is CC-0 licensed and it should remain that way. Anybody addding data should be aware of that. If there has been a copyright violation, the copyright owner can request the associated data to be removed; of course we can also be proactive in such cases if we become aware of them. Have we had any example of such a request? Can you envision a specific case where it would happen? Why wouldn't it be handled the same way copy vio's are handled in wikipedia and Commons? I don't see any need to change the licensing in wikidata itself. ArthurPSmith (talk) 13:26, 9 November 2017 (UTC)[reply]
    Wikidata is CC-0 licensed and it should remain that way.
    Wikidata pretends it can re-license anything under CC0 regardless of the legal status of the source and the amount of extracted data from it. That's really different. It's more like if I pretended that since I only send you a sequence of bytes which, taken alone, represent a at best some random integer, that the fact that the whole file you built with this signal happen to be a perfect copy of the last Hollywood blockbuster blue ray makes you legally free to do whatever you want with this file, like dealing with partners. However database comes with additional special legal information monopoly which vary between countries, that's basically a good analogy for the approach that so far Wikidata took regarding licensing issues.
    If there has been a copyright violation, the copyright owner can request the associated data to be removed; of course we can also be proactive in such cases if we become aware of them.
    Or we can be proactive in just respecting licenses traceability and let end user take the responsibility to mix them in synthesis works, or to filter data by compatible licenses.
    Can you envision a specific case where it would happen?
    Well, just as many cases as there was performance of massive data import which didn't compelled with the source term of use. So far, as far as I know, misc. Wikipedia versions are among the main source provider, so it makes a lot of contributor potentially able to sue for license violation. That doesn't mean this would necessarily lead to a condemnation. I just don't know, really. That's why I said it's a doubtful legal status, and not a clearly illegal practise.
    Why wouldn't it be handled the same way copy vio's are handled in wikipedia and Commons?
    Because Wikidata is designed for scalability through automation, not only legal issues are also scaled, but without a proper tracking system, it will be difficult to analyse what data are impacted by a given legal issue.
    I don't see any need to change the licensing in wikidata itself.
    I hope my answers might enlighten somewhat. --Psychoslave (talk) 13:56, 9 November 2017 (UTC)[reply]
    if the issue is copyright on large-scale collections of data and not individual facts, then adding a license field on individual statements cannot help. Perhaps this issue needs to feed into bot approvals and could be associated with some sort of tagging of large-scale collections of bot edits. Putting a license field on statements is definitely the wrong approach here. ArthurPSmith (talk) 15:29, 9 November 2017 (UTC)[reply]
    How this would not help when this would result in copyleft license compliance? This is indeed a tagging of large-scale collection import, whether through bots or crowdsourcing, with each item keeping a tags for licenses (and matching references), if you want to name it this way. The result is that one might select items which are available under a given license. --Psychoslave (talk) 21:37, 9 November 2017 (UTC)[reply]
    It's not true that Wikidata says that any data can be imported. On the other hand, facts aren't copyrighted. When the American Chemical Association told Wikipedia a decade ago that they aren't happy with Wikipedia to store their CAS numbers, Wikipedia position was that CAS numbers are facts and can be freely shared even if the ACA didn't like it. WikiCommons made decisions like hosting the monkey-selfie to assert a permissive interpretation of copyright. Wikimedia's position was never to stay aware from the grey-zone of copyright as that removes the abilities of us to do what we do but it's rather to fight the lawsuit for the monkey-selfie.
    Having the view that facts are copyrighted wouldn't only make it more complex to import from Wikipedia but also to import from elsewhere. ChristianKl (talk) 15:52, 9 November 2017 (UTC)[reply]
    Recently, a person on our project chat asked whether he can contribute data about when software was released. He used our data on software release data as input for a machine learning product. Given that our data about software release dates isn't complete, he pays people to complete the data and is willing to give that data back. This is the kind of commercial project that benefits from Wikidata. If we had a license that would force him to relicense everything his machine learning algorithm produces as CC-BY-SA, he probably wouldn't build on our dataset.
    Just like corporations rather use Apache licensed libraries and contribute back to them then doing the same thing with GPL, it's easier to work with more freely licensed data. ChristianKl (talk) 15:53, 9 November 2017 (UTC)[reply]
    Given the rules of share-alike combining multiple share-alike licenses that aren't compatible in one project of linked data as you propose might also create it's own legal risks. ChristianKl (talk) 16:06, 9 November 2017 (UTC)[reply]
    It's not true that Wikidata says that any data can be imported.
    I don't think I said otherwise, and of course I hope you can't import the indefinite stream of bytes that generate your local /dev/urandom stating that your personal computer generated this peace of bytes at some timestamp, which would be factual but completely useless as far as I can imagine.
    On the other hand, facts aren't copyrighted.
    This is just a too fuzzy statement to have any relevancy. At large, this is just plain false, as to retake the Harry Potter example, you can't enumerate the complete list of words and their ordinal occurrence positions that appear in the saga. Yes, this would be a lot of factual data, and as they provide enough data to rebuild to whole work, this would be just plain hold copyright violation. The same is true with Wikipedia articles. Imagine you can automatically generate a whole article on a linguistic Wikipedia which doesn't cover the subject yet thanks to data stored in Wikidata which were extracted from an other Wikipedia. We are not yet there, but there are already stubs which are created that way, according to what I red somewhere. Now, imagine that enough information was extracted from the article and that the generator is so efficient that the result is equivalent with a direct translation. If you believe Wikidata claim about its license laundering ability "because it's only facts", then you could publish this synthetic article under CC0. But a direct translation would require CC-BY-SA. Even better, imagine your generator actually generate the article within the same language as the single original article from which all related data were extracted from, with a 100% match between the original and the synthetic. Ta ta, this generated article is now CC0, so is the original one, according to Wikidata claim that factual data can't have copyright issue at any scale. Clearly there is a problem. Sure with predicates stored in Wikidata, such a 100% matching will be more difficult to obtain than with an enumeration of factual statement about ordinals where a word appears in a text, but conceptually the problem is exactly the same.
    Wikimedia's position was never to stay aware from the grey-zone of copyright as that removes the abilities of us to do what we do but it's rather to fight the lawsuit for the monkey-selfie.
    Well, I like this attitude. But right now, we are in the purest grey grey-zone. I would be fine with a Wikipedia vs Wikidata case with WMF as both complainant and defendant (if such a thing is possible). That would minimize the risk and make it clear whether license laundering through the factual data argument is legally receivable and at which scale. Until we do have such certainty, then we should just respect the licenses of source works.
    Having the view that facts are copyrighted wouldn't only make it more complex to import from Wikipedia but also to import from elsewhere.
    Sure, law is always cumbersome when it stands in our way. But making as it doesn't exist where it annoy us don't make it vanish. Also you seems to continuously confuse facts, data carrying statements about facts and large aggregation of that kind of data. That might be OK in casual conversation, but for such a topic, please avoid to mix everything up.
    Recently, a person on our project chat asked whether he can contribute data about when software was released. He used our data on software release data as input for a machine learning product. Given that our data about software release dates isn't complete, he pays people to complete the data and is willing to give that data back. This is the kind of commercial project that benefits from Wikidata. If we had a license that would force him to relicense everything his machine learning algorithm produces as CC-BY-SA, he probably wouldn't build on our dataset.
    Well, first I don't plaid for forbidding CC0 in Wikidata, although I do plaid for a default set of license which only include copyleft licenses. If there are users who do want to withdraw every single right they have on their work when they have other options, that's fine. But forcing people to contribute under such a license when all other Wikimedia project where Wikimedians have grown their communities use copyleft license or at least let the user choice.
    Now, back to your example, I just don't care to release my work under licenses that are not practical for people who are not willing to play equitably and publish back under the same conditions. Either they would have comply with CC-BY-SA, or they would have search an other solution, both being far better than to see them using a free work to create derivatives and publish the result as a non-free work. Actually to me your example means that we missed a possible occasion to foster free works, so it's an example against non-copyleft license.
    But once more, it's OK to let people publish under CC0 if they really want to do so. But making it mandatory to contribute to Wikidata is not OK, as it would be unacceptable to have a mandatory CC0 on Commons or all Wikimedia projects. All the more, mass import of non-CC0 material while nothing proved it's legal is clearly an issue which should be solved.

    --Psychoslave (talk) 22:54, 9 November 2017 (UTC)[reply]

    • CC-0 is fine for Wikidata. Facts can't have a copyright, and I am against a copyright for a collection of facts. --Yann (talk) 15:23, 9 November 2017 (UTC)[reply]
      • Maybe you mean that you feel fine with CC0 for Wikidata. It doesn't mean it is legally fine to make massive import of non-CC0 sources within a CC0 database. The same apply regarding copyright and factual data collection, a personal mood is not a law. Here are some facts: The first word of the w:Wikimedia article is The, the second is Wikimedia, the third is movement, and I could factually enumerate each word within this article. Enumerating a few words and their respective positions in the text doesn't raise any legal problem. Enumerating a large part of them, or all them, does raise legal concerns. Actually it's plain old copyright violation. Otherwise circumventing any information monopoly would be trivial, and related laws would be pointless. While I do personally think that no monopoly should ever be granted on any kind of information, this is my personal opinion which unfortunately doesn't match legal reality. I don't publish Harry Potter saga in Wikisource, nor a factual position of each word occurrence used in Harry Potter within Wikidata because I think it would be illegal, not because I think that law is fine or that this works and fact are culturally worthless. Therefore, as long as they are law which grant monopoly on information and that it's unclear to which degree they impact a database who aims at gathering facts, it would be more careful to track finely sources of statements and their licenses. Wikimedia is not sci-hub, we follow the path of legality, whatever our personal feelings are about this laws. --Psychoslave (talk) 20:31, 9 November 2017 (UTC)[reply]
    • This is not a community issue. It is up to the WMF legal team to decide if they are happy with the possible liability of licensing bulk copyrighted data under CC-0. The variation by jurisdiction is immense, and I am taking the view that although in some instances we are probably causing a copyright violation, this is not a major issue, and the WMF and partners are perfectly able to deal with any possible lawsuits that result from it. I assume it will be reasonably possible to remove any datasets that are litigated if and when, given that this is structured data, and the database owner could simply run a search query to ascertain the affected items in any given dispute. In short, if it ain't broke, don't fix it. A Den Jentyl Ettien Avel Dysklyver (talk) 16:13, 9 November 2017 (UTC)[reply]
    This is not a community issue.
    Please provide a method to decide what is a community issue according to you. Here is my own proposal: 1. a person have concerns that according to this same person have an impact on the community. 2. this person report the said concerns 3. the community decide whether a. it doesn't care, b. share this concerns or c. explain why this concerns are mere delusions supported with a large rejection consensus indicating that the community find the problem is irrelevant. I don't feel like we are nowhere near 3.c so far, so I will take you claim that this is not an issue as an indicator for such a decision process, but not a conclusive fact, even in bold character.
    It is up to the WMF legal team to decide if they are happy with the possible liability of licensing bulk copyrighted data under CC-0.
    My opinion is that the Foundation is is accountable to the community. So they are not free to experiment whatever might be the fancy of the day at the expanse of putting the community sustainability at risk and certainly not without a clear transparent report which evaluate this risks. Assume good faith is fine, and trust balanced with known past behaviour is OK. But blind trust is misguided, don't blind trust the foundation, me or even yourself: keep your mind open to critiques from and toward everybody. But avoid paranoia (even if we indeed have a worldwide secret evil plan against you, mouhahaha).


    I assume it will be reasonably possible to remove any datasets that are litigated if and when, given that this is structured data, and the database owner could simply run a search query to ascertain the affected items in any given dispute.
    A goal of this is proposal is to ease that kind of solving and even prevent this kind of litigation. However it doesn't go as far as systematic deletion of all problematic material under the current lack of license tracking system.
    In short, if it ain't broke, don't fix it.
    Yeah, so, my opinion is that the current state of Wikidata is broken. The license problem apart, it didn't hold its promise of avoiding circular dependencies with Wikipedia references. This is an other related problem of source tracking laxity. Denying the broken state won't change the fact that it's here.

    --Psychoslave (talk) 21:26, 9 November 2017 (UTC)[reply]

    Archived

    edit

    This proposal is primarily about changing the licensing policy and while it includes some development work, we can't start this work before there is agreement that licensing should change. This is a technical survey and thus it's not suitable for policy discussions. I suggest you to start a discussion on Wikidata because until the community is on board , this is not happening. Considering all of the above, I've archived this proposal. Thanks for participating in our survey! Max Semenik (talk) 23:56, 9 November 2017 (UTC)[reply]

    Well @MaxSem:, I'm a bit disappointed of course, but I prefer to concentrate on constructive actions rather than complaining. So your suggestion to put the community as a whole on board, not on Wikidata alone because this is a problem which impact the whole Wikimedia ecosystem. What are the proper processes to engage the whole community about a topic with such a large impact on its future for a mere contributor like me? --Psychoslave (talk) 09:05, 10 November 2017 (UTC)[reply]
    Wikimedia has decentralized decision making. Apart from the movement strategy discussion, there's no venue for whole community discussions. ChristianKl (talk) 21:05, 10 November 2017 (UTC)[reply]

    Better readership statistics

     N Outside the scope of Community Tech. The good news is per below, the Analytics team has some plans to implement similar statistics in the future.

    • Problem: There's only one pageview statistics tool (that I know of) which only tells the number of pageviews per day for a given article; it is a simple tool that does not differentiate readers from viewers. I think there is a need for more and better data, such as (1) whether an article is simply clicked on but not scrolled (ie not read much) or read with scrolling (2) how many minutes on average an article is read (3) which subsections get read (4) where the eyeball traffic comes from (for example, whether from other Wikipedia articles, or from the web) (5) whether the pageviews were unique readers or the same readers reading multiple times.
    • Who would benefit: The community will benefit if we can learn more about how we're serving readers. Better data will help us focus on specific articles, knowing which to improve and so forth. If there was an indicator of how many unique readers that a specific contributor has -- over time -- then it could encourage contributors to earn more readers by quantifying their contributions.
    • Proposed solution: I am not technical enough to offer specific solutions but there are talented programmers here who can.
    • More comments: Note: if there is such data already available but I just don't know about it, I apologize in advance, but to my knowledge, it doesn't yet exist.
    • Phabricator tickets:

    Community discussion

    edit
    • I don't think wikipedia uses Google analytics :) good idea, but we could end up revealing more than we want people to see abut our actual readership. A Den Jentyl Ettien Avel Dysklyver (talk) 16:34, 9 November 2017 (UTC)[reply]
    • I helped author Pageviews Analysis, which I think is what you're talking about. I will try to answer your concerns but note that I am not on the Analytics team, nor can I give any official word regarding privacy policy.
      With pageviews, referral information (where traffic comes from) is being stored, along with some other data, but this is all intentionally considered private and is not exposed to the public. I agree more detailed statistics could offer some great benefits, but the general notion is that privacy will be compromised, and that is given priority. I can think of some examples, but I will leave that to the privacy experts. Similarly, data on unique devices are not publicly available, except on a per-project basis. For that, check out Siteviews.
      At any rate, changing the availability of these statistics is not a job for Community Tech. If you would like to learn more, you could try reaching out to the Analytics team directly. They will be able to give you better answers than me, but again I am doubtful such private information will become publicly available, and it should be noted special requests for the data are rarely granted.
      Given this is not in our purview or within our control, I'm going to have to archive this proposal. We very much appreciate your participation in the survey, and I am sorry we cannot help any further! MusikAnimal (WMF) (talk) 01:36, 10 November 2017 (UTC)[reply]
      • Well I suppose thank you is in order for at least responding to my request. I have been a significant contributor to Wikipedia, since 2009, writing and revamping hundreds of articles, and with my contributions of images (over 1000), a metric of how well I am doing here, the only metric that I have, is pageviews, and my guess is that they add, over time, to over 200 million pageviews. That is, the idea that people are reading my contributions motivates me and I bet it motivates other contributors too. I continue to think that my request for improved readership statistics is valid, that they would indeed help the encyclopedia by motivating contributors, as well as providing clues about where best to focus our energies (eg substandard wiki-articles with significant readership). My sense is that it is surely possible to provide better readership statistics while preserving privacy, such as by revealing only aggregate numbers or averages, and not reporting numbers if they fall below a certain threshold, say 30 views. So I believe that tabling my proposal is premature and I suggest that you reinstall it.--Tomwsulcer (talk) 10:28, 10 November 2017 (UTC)--Tomwsulcer.--Tomwsulcer (talk) 10:36, 10 November 2017 (UTC)[reply]
        • I agree! I just don't think Community Tech can do anything about it. It might be nice to still leave this proposal up during the voting phase, just to see how many people are on board with the idea. I will discuss this with my team. We have a lot of time (until November 27) so do not worry, your proposal is not losing momentum here in the archives :) I'll get back to you soon! MusikAnimal (WMF) (talk) 20:26, 10 November 2017 (UTC)[reply]
          • Ok, thanks again for responding, and if it is or becomes feasible to somehow get better readership statistics, while protecting privacy using aggregate numbers, I think we'd all be better off.--Tomwsulcer (talk) 14:26, 13 November 2017 (UTC)[reply]
            • Hi Tomwsulcer, I'm Dan Andreescu and I work for the Wikimedia Analytics team. We do have plans to work on some of the statistics you request here, and the results of that work will come out over the next year and beyond. We can get around some of the privacy problems by tricks that include the ones you mentioned (discard buckets that are too small, separate out statistics so they can't be used together to de-anonymize private information, etc.). We have some bigger commitments that we have to finish up through the spring, but after that I personally intend to focus on projects like WikiCredit. This begins to try and deliver to each user statistics that are relevant and rewarding, hopefully. I would suggest you send your request to our mailing list so everyone can see that community members value this kind of work. Milimetric (WMF) (talk) 18:14, 13 November 2017 (UTC)[reply]

    Add an undo/revert button to diff view

    • Problem: The mobile web diff view features an enormous 'thank' button at the bottom of the screen. Sadly, I find myself reverting people far more often than I thank them. Quickly reverting a dodgy edit is the sort of quick editing that should work well on mobile. Unfortunately, the mobile interface makes this all but impossible without manually rewriting the text.
    • Who would benefit: Editors checking their watchlist on their phones.
    • Proposed solution: Provide an undo button adjacent to the thank button. Undoing an edit would work the same way as on the desktop site - open the editing interface with the offending text removed from the source.
    • More comments:

    Discussion

    edit

    Endorse --BugWarp (talk) 13:16, 10 November 2017 (UTC)[reply]

    Voting

    edit

    → link to page section is hard to click

      Withdrawn by proposer [1] (too many proposals)

    • Problem:

    "→" link to page section on History page, Watchlist page or RC page is too small and it can be really hard to click.

    • Who would benefit:

    Every user who wants to go to a specific section from History page, Watchlist page or RC page

    • Proposed solution:

    Make the link bigger, apply the link to the whole section title there, whatever...

    • More comments:
    • Phabricator tickets:

    T165189

    Community discussion

    edit

    Allow Gender magic word in other namespaces

      Withdrawn by proposer [2] (too many proposals)

    • Problem:

    In some languages (e.g. Czech, Slovak, Polish) there is a different grammar for male and female (for example in case of "You could"/"You should"). In Help namespace there is a tendence to be user-friendly and this magic word would help there.

    • Who would benefit:

    Novice users on Czech, Slovak, Polish, ... projects

    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    T137717

    Discussion

    edit

    A vertical reading-mode for Classical Chinese.

      Duplicate proposal 

    of 2017 Community Wishlist Survey/Miscellaneous/Vertical writing support
    • Problem: Classical Chinese 🏛 Wikipedia is currently written horizontally reading from left-to-right, and then up-to-down, this isn't how any actual Classical Chinese text is written, and there certainly is the technical capability to make this script written in “the correct order”.
    • Who would benefit: People who get irritated by the fact that Classical Chinese Wikipedia 🏛 isn't written like actual Classical Chinese texts. 🧐
    • Proposed solution: Create an optional mode for the Classical Chinese Wikipedia 🏛 to be read in the traditional-style of vertical writing with characters going from up-to-down, and then from right-to-left. I think 🤔 that this should also be applied to mentions of Latin script, Cyrillic script, Greek script, Devanagari script, Etc. included within the Classical Chinese Wikipedia 🏛.
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Section edit for VisualEditor

      Request withdrawn

    • Problem: VisualEditor currently requires an entire page to be parsed in editing mode. This makes editing long pages difficult.
    • Who would benefit: Everybody.
    • Proposed solution: Allow section edits on VisualEditor. Only the chosen section is loaded, on a separate screen (just like the Wikitext "edit section" behaviour).
    • More comments: It doesn't matter that the page isn't parsed exactly, because editors are generally aware that clicking "edit section" means that the preview is limited to the section that they're editing anyway and some changes will affect the rest of the page in ways that only become obvious after saving. This hasn't deterred people from using "edit section" on Wikitext mode and shouldn't deter people from using "edit section" on VisualEditor mode. But the additional performance requirements on loading an entire page onto VisualEditor is making the editing of long pages very difficult.

    Discussion

    edit

    Make all forms of Unicode available on all Wikimedia projects.

      Withdrawn by proposer (too many proposals)

    • Problem: Currently I am drafting an article that deals with the Qing Dynasty (the Manchu Empire) which uses a great deal of Manchu script, if I were editing on a wiki where I could use the template {{ManchuSibeUnicode|ᠠᠪᡴᠠᡳ<br>ᡶᡠᠯᡳᠩᡤᠠ<br>ᡥᠠᠨ<br>ᠵᡳᡴᠠ}} however there is no local {{MantsjoeXibeUnicode|}} template on Dutch Wikipedia, for articles relating to the Qing Dynasty, being able to use the vertically written Manchu script is paramount. This problem also extends to other wiki's as not all of them have volunteers willing to invest their times in writing these templates.
    • Who would benefit: Everyone. 🤳🏻
    • Proposed solution: Make Unicode templates universal among all Wikimedia projects, and allow all forms of Unicode input 🔢 to work. 🐱‍💻
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    All forms of Unicode do work, assuming the browser has appropriate fonts to render them. These templates override the default font stack with alternatives that may exist on Windows and Macs, and sometimes provide additional CSS. Anomie (talk) 15:09, 9 November 2017 (UTC)[reply]

    The functional part of templates like this can be copied verbatim, the time-consuming part is translating the documentation. Having "universal" templates would make some aspects a little easier. --bdijkstra (talk) 21:21, 9 November 2017 (UTC)[reply]

    @Donald Trung: Please note that you are only allowed three proposals maximum. This was mentioned in the survey rules. You need to withdraw your rest. -- NKohli (WMF) (talk) 19:39, 10 November 2017 (UTC) [reply]

    Allow IP editors to see talk pages in the mobile browser.

      Withdrawn by proposer (too many proposals)

    • Problem: Currently if you edit as an IP-user on a mobile device using the mobile browser you don’t see the button 🔘 “Talk” (or “Overleg”, Etc.) anywhere, if you wish 🌠 to access the talk page you have to manually switch to “desktop” mode, then click on “discussion” and then switch back to mobile 📱. But even then you can’t edit the whole page in “Mobile” mode, only individual sections.
    • Who would benefit: Mobile-users 👥.
    • Proposed solution: Allow mobile IP-users to see the talk page button, there’s literally no need to only restricting this to named accounts.
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    • I support this. More broadly, access to the talk page should be far more prominent, it's a central vital aspect of our projects. I stopped to use the native app on my mobile because I never found an obvious way to do that. Access talk page should be everywhere (contextual menu, at top and bottom of article, at the beginning of each section and engraved in bold character within the telephone case) rather than nowhere. --Psychoslave (talk) 11:39, 9 November 2017 (UTC)[reply]

    Allow mobile editors to edit entire pages (optional)

      Withdrawn by proposer (too many proposals)

    • Problem: Currently if you edit in the mobile browser (like myself) you will run into numerous restrictions on editing that make it a more tedious task, one of these editing restrictions is the inability to edit full articles, imagine if you need to move one paragraph from one part of the article to another, the scenario goes like this: A mobile user wants to move something into a more relevant section of the article, but because of technical restrictions they have to blank one part first or move it in an impractical manner before being able to add it properly, they explain that they only need 6 (six) minutes to finish “the next” edit or maybe one (1), they then try to “finish” the second edit and click on “save 💾” but find an error message, a rollbacker has already reverted claiming it as vandalism and left a pesky template accusing the mobile 📱 editor of vandalising a page they’re a major contributor to. This should be preventable.
    • Who would benefit: Mobile-users 👥.
    • Proposed solution: Allow an option when one clicks on “the top pencil ✏” that says “edit section or edit whole article”, this way (mobile-)users can choose between either simply editing the intro exclusively or editing the entire page without having to go to “desktop” mode.
    • More comments: Otherwise allow for “intermediate edits”, seriously when you’re on mobile “assume bad faith” (see w:en:WP:BADFAITH) is the only way rollbackers can communicate with you, I wouldn't be surprised if almost every user that hated editing did so because they’re on a mobile device, and their intermediate edits were seen as “vandalism”.
    • Phabricator tickets:

    Discussion

    edit
    • Strongly endorse. Main reason I don't edit on mobile. I often myself in the same position as the proposer, with the added commentary that "ref names" are unhelpful in the mobile view, as it's not possible to see where else the reference is used in the article without having access to the full page. LocalNet (talk) 22:58, 10 November 2017 (UTC)[reply]

    A mobile UploadWizard for Wikimedia Commons.

      Withdrawn by proposer (too many proposals)

    • Problem: The current Wikimedia Commons UploadWizard is very Mobile 📱 unfriendly, and it always directs people to the desktop version to upload their files, if like me you’re (currently) unable to use an application 🈸 for Wikimedia Commons then you have to resort to use the Wikimedia Commons UploadWizard which can be a real pain in the neck if you use a small screen.
    • Who would benefit: Mobile-users 👥. And of course everyone else as their would be more educational photographs to use. 😉
    • Proposed solution: Create a mobile-version of the Wikimedia Commons UploadWizard. It would basically look and act identical to the current Wikimedia Commons UploadWizard but then adapted for smaller screens.
    • More comments: I don’t really think 🤔 that there's much to say here, just make an optional mobile UploadWizard, if someone doubts that this is a problem then I would advise them to take a wireless telephone 📞, and attempt to use the Wikimedia Commons UploadWizard for 10 (ten) photographs, share your results. 🤭
    • Phabricator tickets:

    Discussion

    edit

    Endorse. The app should be more user friendly, allow external sources uploads and allow more licenses than it currently does.--BugWarp (talk) 13:16, 10 November 2017 (UTC) [reply]

    VisualEditor summary autocomplete

      Withdrawn by proposer [3] (too many proposals)

    • Problem:

    In Wikitext editor there is a summary filed there automatically drops down/up an autocomplete/suggestion field with some possibilities. But in VE there is no such autocomplete option.

    • Who would benefit:

    All VE users

    • Proposed solution:

    Add some dropdown under or over VE summary field with some suggestions and autocompleted values

    • More comments:
    • Phabricator tickets:

    T50274

    Discussion

    edit

    Improve FastCCI capabilities and performance

      Withdrawn by proposer (too many proposals)

    • Who would benefit: Users who would otherwise create a combinatorical explosion of intersection categories.
    • Proposed solution: Enable FastCCI to perform that kind of intersection quickly and reliably. (It currently times out on sufficiently large categories.) Enable permalinks to the results, and possibly cache them on the server side. Enable the ability to do 'shallow' unions and intersections, i.e., ones that don't include files in descendant categories.
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    • I would also very much like to see significantly better search capabilities on commons - fuzzy search, boolean operators, order by filesize, megapixels and other metrics - say, popularity - would all be extremely helpful. Instead of adding this to fastCCI, is this stuff not a question of Commons' "search" capabilities? Might be better to propose it there -- Thennicke (talk) 10:29, 10 November 2017 (UTC)[reply]
      • @Thennicke: I jumped the gun here--I'd like there to be better category intersection/exploration options, but they don't have to go through FastCCI specifically. I figured 'Multimedia and Commons' is a good place for it, but I can kinda-duplicate the request under 'Search', if you think that's a good idea. Grendelkhan (talk) 23:05, 10 November 2017 (UTC)[reply]
        • Up to you; it was only a suggestion. I suppose it doesn't really matter which section it's in because it's mainly commons related, but the heading suggests that this is only about FastCCI, which I would suggest changing to say "search" in general. Thanks :) -- Thennicke (talk) 02:28, 11 November 2017 (UTC)[reply]

    New tag for notes

      Withdrawn by proposer (too many proposals)

    • Problem:

    Cannot edit notes in VE.

    • Who would benefit:

    All editors, who love VE

    • Proposed solution: introduce new tag, which will be supported by VE
    • More comments: I was told the integration of notes is a problem, because the use same tag as references. This may overstep the problem.
    • Phabricator tickets:

    Discussion

    edit
    @Juandev: Please describe what "notes" are or provide an example, and explain which "same tag" is used, so we can make sure that we discuss the same thing. Thanks! --AKlapper (WMF) (talk) 20:42, 8 November 2017 (UTC)[reply]
    This is an example of notes.--Juandev (talk) 21:04, 8 November 2017 (UTC)[reply]
    @Juandev: It is already possible, notes are using ref tags with groups, like <ref group="notes">...</ref> :
    1. edit a page using VE
    2. insert a reflist ("Seznam referencí")
    3. in that reflist, on the "use this group" ("Použít tuto skupinu") field, type a group name (like "notes" or "Poznámky")
    4. somewhere in the text, insert a note
    5. when inserting the note, using the basic form ("Základní podoba")
    6. there is a field where you can now choose "notes" or "Poznámky".
    Hope this helps! Trizek (WMF) (talk) 09:42, 9 November 2017 (UTC)[reply]
    Umm, but than it needs to be tuned. If I edit the page, which allready had some notes (which were not created this way) I cannot edit them easily (because, they have different parametr).--Juandev (talk) 20:33, 9 November 2017 (UTC)[reply]

    Preview page without reloading

      Already done. This feature is available as a preference ("Show previous without reloading the page").

    • Problem:
      • The use of "Show preview" and "Show changes" needs to load the page
    • Who would benefit:
      • All
    • Proposed solution:
      • Make these buttons running on the same page without reloading the page (.i.e. the ability to see changes at any moment during editing without reloading the page)
      • The possibility of using both together
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Correct the sexism and unconstitutionality of Wikipedia with respect to the german constitution (Grundgesetz)

     N Poses legal question rather than a technical feature

    • Problem: Until recently the german constitution said, that every person born in germany has to be registered as male, female or without a gender entry. This is refelected by the wikipedia preferences options "Address me es he/she/(dont use an attribution). German Bundesverfassungsgericht has recently decided, that people who are nether male nor female have a right to be registered as belonging to a third gender (the name of which is left to the parliament to decide). The court gave a time frame of end of 2018 to change the law to this respect. With this change taking place the preferences options in wikipedia will be consdidered as an uncontitutional sexism in germany. wikipedia may be sued and sanctioned for this.
    • Who would benefit: german wikipedia users
    • Proposed solution: add another option in the preferences (the name of which will be decided later)
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    This is an interesting question, and one that people at the WMF should learn and think about. I don't think that this is appropriate for the Wishlist Survey -- if this is a legal question, then folks in the legal department should determine what the appropriate response is. I'm going to put this proposal in the archive. We've let Legal know about the question. Thanks for participating in the survey. -- DannyH (WMF) (talk) 18:20, 13 November 2017 (UTC) [reply]

    Linksto should be case-insensitive in the first character

      Done Completed while the survey was underway.

    • Problem: When using "linksto" with a title beginning with a lowercase letter on a wiki with $wgCapitalLinks set to true, no results appear at all.
    • Who would benefit: Users who want to find links as an alternative to WhatLinksHere, but do not want to force the first letter to be capitalized.
    • Proposed solution: The "linksto" keyword should behave the same as the other keywords. This means that "linksto:foo" (with an initial lowercase letter) should return the same results as "linksto:Foo" (with an initial uppercase letter).
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Could you add an example (link) where this is currently being used ? —TheDJ (talk • contribs) 00:03, 10 November 2017 (UTC)[reply]

    @TheDJ: Go to en:Special:Search/linksto:main Page and you'll see what I mean here. A proposed solution is at https://phabricator.wikimedia.org/rMW8c9fc89ce3d7e0b5064981623dab7fde770af4b2. GeoffreyT2000 (talk) 15:35, 11 November 2017 (UTC)[reply]
    Since the above patch has been merged, this wish is resolved. Max Semenik (talk) 19:18, 13 November 2017 (UTC)[reply]

    Improve TemplateData to ease description of lexical items

      Withdrawn by proposer [4]

    • Problem: Currently editing a Wiktionary article is difficult for new comers, as the structure of article is often rigid and heavily rely on many templates.
    • Who would benefit: Every contributor willing to change an article on a Wiktionary without having to cross a difficult learning curve or the need to often probe the documentation to remember how things are supposed to be wrote. Also, while suggestion made here are proposed with a clear goal, many other projects would probably benefit from this. Although, this result would not be expected as a direct result of the proposed solution, every Wiktionary version remaining free to use whatever they prefer, but at least it would make it possible.
    • Proposed solution: There is already a current work in progress attempt on the French Wiktionary to gather every data related to the same lexical item into a single template. So far it relies on a Scribunto module and a template using TemplateData. But TemplateData have currently several caveats which makes it far less practice:
      • there is no way to limit an entry to a given set, ever static or dynamic
        • a static list should not be that much difficult to implement, rendered as a dropdown list in the template edit popup
        • a dynamic list would be probably more difficult, but extremely useful
          • to avoid duplicate information like list of supported languages and their corresponding ISO code, which are already in a Scribunto module
          • even based on static list, it's interesting to be able to filter some entries, for example grammatical gender and number sets vary from one language to an other, once the user chose a language, only the relevant cases should be proposed
      • each field can be associated with a short descriptive help, but wikicode included in it won't be parsed, so it's impossible to add internal link to a documentation page covering the subject in depth
      • as far as the current above mentioned attempt goes, the template pop up editor of the visual editor is slow and don't display anything during loading, giving the impression that the page crashed or that nothing is happening
      • there is no way to properly manage numbered list, both intertwined and flat numbered list. For example definition.1.1.description might be used for describing the first subdefinition of the first definition. So far TemplateData require to explicit every single numbered parameter, so no generic parameter can be created to make a template scalable.
      • Improve VE editor for intertwinned templates. So far only the first level templates are editable with the TemplateData, templates which are called in template parameters are displayed as wikitext in each parameter value, with no way to deepen edition with new modals.
    • More comments:

    Community discussion

    edit

    Marking the pages as a "in progress" and users as "exist"

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Edit conflicts
      • Any page in any project may need some time to work on.e.g:Page needs a lot of time to complete, or to respond to requests Page
      • Any user can be a existing (can read and reply to messages) or not
    • Who would benefit:
      • All
    • Proposed solution:
      • Marking:
        • the pages as a "in progress" (I think that Commons is the most site needs to this because the large number of deletions and speedy deletion requests)
        • the users as "exist":to know the user state (I think that Commons is the most site needs to this because of the warnings about the violation images)
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:33, 13 November 2017 (UTC) [reply]

    Disabling userpages creation by anonymous

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Often, pages in user and user talk namespaces are created or vandalized by anonymous
    • Who would benefit:
      • All
    • Proposed solution:
      • Disabling pages creation by anonymous in these two namespaces
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Preventing anonymous users from creating user pages (or similar rules as preventing all non-autoconfirmed from editing other users's pages except talk pages) can easily be done via abuse filters. The benefit is, that it's flexible in the way, that any local exceptions to the rules can be incorporated by simply editing the filter code. --Teslaton (talk) 17:29, 10 November 2017 (UTC)[reply]

    @ديفيد عادل وهبة خليل 2: you have more than 3 proposals in the survey. Please mark all of your other proposals as {{withdrawn}} else we'd have to remove them ourselves. Thank you. -- NKohli (WMF) (talk) 20:02, 10 November 2017 (UTC)[reply]

    Even if it doesn't go against Founding principles (and it would certainly go against enWikipedia's protection policy) there is no indication of a benefit here. On the contrary, sometimes IPs need to start an user talk page to communicate with someone or they are static but don't like making an account and then make an userpage for themselves. Jo-Jo Eumerus (talk, contributions) 10:31, 11 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:34, 13 November 2017 (UTC) [reply]

    Editing edit summaries

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is not possible to edit or correct edit summaries
    • Who would benefit:
      • All
    • Proposed solution:
      • Enable editing edit summaries by their writer or administrators
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:35, 13 November 2017 (UTC) [reply]

    Add "MyGallery" options to "Special:ListFiles"

      Withdrawn by proposer (too many proposals)

    • Problem:
      • There are useful options on this page only, and can not be translated
    • Who would benefit:
      • All
    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:36, 13 November 2017 (UTC) [reply]

    Ability to transfer images from Google Photos

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Need to transfer own work photos from Google Photos to Commons
    • Who would benefit:
      • All
    • Proposed solution:
      • Ability to transfer images from Google Photos by URL2Commons
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    1. This proposal needs to be implemented
    2. Google Account can only be accessed by its owner and there is no difference between ways to upload a stolen image (If the picture is stolen, the method will not affect)

    Thank you --ديفيد عادل وهبة خليل 2 (talk) 14:39, 10 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:37, 13 November 2017 (UTC) [reply]

    Make files upload themselves without having to wait

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Some files need a long time to upload (especially videos)
    • Who would benefit:
      • All
    • Proposed solution:
      • The possibility of closing the page while leaving the upload works on its own and when finished I get a notification (includes all tools)
      • Making the upload does not slow down the network
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:38, 13 November 2017 (UTC) [reply]

    Log for watching and its interpretation

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The need to remember the name of a page the user was watching
      • The need to remember the reason for watching
    • Who would benefit:
      • All
    • Proposed solution:
      • creation of a log for registration watching pages and its interpretation
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:38, 13 November 2017 (UTC) [reply]

    Favorite logs (Watching logs)

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes, the user cares about specific logs and does not care about the rest
    • Who would benefit:
      • All
      • Creating a page includes important logs to the user
    • Proposed solution:
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    @ديفيد عادل وهبة خليل 2:- The problem statement is not clear. Can you elaborate on the problem please? You can type in your native language and we can find someone to translate if you are not comfortable with English. -- NKohli (WMF) (talk) 18:57, 10 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC)[reply]

    Put terms of watching

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes, undesirable pages added to watch list (by archiving or moving)
    • Who would benefit:
      • All
    • Proposed solution:
      • Exception of some cases (Such as a specified scope or pages with titles that contain specific words Such as "archive") of addition
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC) [reply]

    Watching pages when adding specific text

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user likes to add pages to the wathlist when adding specific text.For example:d:Q4847311
    • Who would benefit:
      • All
    • Proposed solution:
      • Adding a place to this page for the text required
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    @ديفيد عادل وهبة خليل 2: - I'm not clear what this proposal means. Can you not watch the page by clicking the watch checkbox when saving page? Or the icon on top? What specific text are you referring to? Also, a reminder that you are limited to 3 proposals only. Thanks. -- NKohli (WMF) (talk) 19:24, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): e.g. I like to watch the pages when using {{Delete}} and I need this page to be automatically watched when I add the template.Thank you --ديفيد عادل وهبة خليل 2 (talk) 19:50, 10 November 2017 (UTC)[reply]
    Okay. But do you think everyone will also like the same? Different editors have different workflows and others may not like it when pages get automatically watched. -- NKohli (WMF) (talk) 19:55, 10 November 2017 (UTC)[reply]
    Can this be done by having the template add works to a category, and then watching the category? —Beleg Tâl (talk) 01:23, 12 November 2017 (UTC)[reply]
    This seems like a duplicate of 2017 Community Wishlist Survey/Watchlists/More Options for Auto-Watching. Anomie (talk) 16:51, 13 November 2017 (UTC)[reply]
    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:39, 13 November 2017 (UTC)[reply]

    Watching included pages

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is a difficult thing to follow changes in the nominations pages
    • Who would benefit:
      • All
    • Proposed solution:
      • Adding a button for wathing included pages (in proiect namespace) and adding a button (in the watchlist and beside "Add this page to your watchlist") to show and hide these edits
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    @ديفيد عادل وهبة خليل 2:. What do you mean by "included pages"? -- NKohli (WMF) (talk) 19:20, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): See "MediaWiki:Centralnotice-templates-included".Thank you --ديفيد عادل وهبة خليل 2 (talk) 19:24, 10 November 2017 (UTC)[reply]
    I still don't understand. You want to watch transcluded pages/templates? -- NKohli (WMF) (talk) 19:26, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): I mean pages whose names are between {{}} --ديفيد عادل وهبة خليل 2 (talk) 19:43, 10 November 2017 (UTC)[reply]
    Those are templates and not pages. Why would you want to watch templates? They don't change frequently and are mostly code. -- NKohli (WMF) (talk) 19:54, 10 November 2017 (UTC)[reply]
    @NKohli (WMF): The target is the nomination pages which voters are interested in following --ديفيد عادل وهبة خليل 2 (talk) 20:37, 10 November 2017 (UTC)[reply]
    You will watch thousands of transcluded pages. IKhitron (talk) 11:59, 13 November 2017 (UTC)[reply]
    I suppose the idea is that someone could use the proposed option on 2017 Community Wishlist Survey/Watchlists and they'd automagically see all changes to every idea-subpage transcluded on that page, rather than having to manually watchlist each idea-subpage. The proposal as written is referring to pages like w:en:Wikipedia:Requests for adminship where something similar is done. Anomie (talk) 16:49, 13 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:40, 13 November 2017 (UTC) [reply]

    Linking with Wikidata with the creation

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It is not possible to link the page with Wikidata except after the creation
    • Who would benefit:
      • All
    • Proposed solution:
      • Merge d:Special:SetSiteLink with creation page (Make this page appears automatically on creation page) to make creation and linking occur together
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:41, 13 November 2017 (UTC) [reply]

    Make Wikidata obviates templates

      Withdrawn by proposer (too many proposals)

    • Problem:
    • Who would benefit:
      • All
    • Proposed solution:
      • Making Wikidata properties (1 2 3 4) appear Side link to the main topic automatically
      • Dispensing this template
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:42, 13 November 2017 (UTC) [reply]

    Search for properties in items

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Length of items (sometimes) and the difficulty of finding a property
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to search for properties in items
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    • It seems to me like you have made way more than the 3 proposals that are allowed by the Community Wishlist Survey rules. As far as this proposal goes, you don't really explain what you are seeking. Control+F can be used in every webbrowser to search a page. ChristianKl (talk) 14:25, 11 November 2017 (UTC)[reply]
    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:42, 13 November 2017 (UTC)[reply]

    Automatically merge items when redirecting locally

      Withdrawn by proposer (too many proposals)

    • Problem:
      • When merging pages locally, We need to go to Wikidata and merge items
    • Who would benefit:
      • All
    • Proposed solution:
      • Automatically merge items when redirecting locally without going to Wikidata
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:43, 13 November 2017 (UTC) [reply]

    Removal from the implicit permissions automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user has permission and implicit (indirect) permission (Such as administrator and rollbacker)
    • Who would benefit:
      • Bureaucrats
    • Proposed solution:
      • Removal from the implicit permissions automatically when changing userrights
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:43, 13 November 2017 (UTC) [reply]

    The possibility of undeletion images and categories automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Previously deleted images entering into Public domain and thus requested for undeletion
      • not used categories are need to undeletion when using
      • The need to c:Category:Undeletion requests
    • Who would benefit:
      • All
    • Proposed solution:
      • The possibility of Selection "undeletion automatically" (With the year selected in the images) when deletion images and categories
      • Dispensing c:Category:Undeletion requests
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC) [reply]

      Withdrawn by proposer (too many proposals)

    • Problem:
    • Who would benefit:
      • All
    • Proposed solution:
      • Button to remove links to pages with deletion
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC) [reply]

    Private protection

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The existence of userpages do not need to be edited by any user (except their owners)
    • Who would benefit:
      • All
    • Proposed solution:
      • Establishment of the level of protection to prevent editing except by the owner and administrators (like "Edit other users' CSS files" and "Edit other users' JavaScript files")
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:44, 13 November 2017 (UTC) [reply]

    Deleting "Talk page of a nonexistent or deleted page" automatically

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Keeping "Talk page of a nonexistent or deleted page"
    • Who would benefit:
      • Admins in all projects
    • Proposed solution:
      • Deleting these pages automatically with the deletion of the original page
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Different projects have different policies. For example on the Finnish Wikipedia we have a policy to delete talk pages of non existed pages, but sometimes we want to keep them for example if there was an important discussion. Stryn (talk) 16:54, 11 November 2017 (UTC)[reply]

    Possible solution: If there exists talk page for page, admin should be warned (talk page for this page exists, do you want to delete it too?) and should select checkbox. JAn Dudík (talk) 13:04, 13 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:45, 13 November 2017 (UTC)[reply]

    Sort translation pages by size

      Withdrawn by proposer (too many proposals)

    • Problem:
      • The large number of translation pages
      • The length of some translation pages
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to sort translation pages by size to translate short pages first
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:45, 13 November 2017 (UTC) [reply]

    Discussing edits

      Withdrawn by proposer (too many proposals)

    • Problem:
      • It's easy to thank the others, but it is difficult to object or discussion of a particular edit
    • Who would benefit:
      • All
    • Proposed solution:
      • The presence of a button next to thanking button to send a message to the owner of the edit in a specific text (Then we write the details manually) for discussion
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC) [reply]

    Prospective edit

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Some edits the user wants to make should be done later
    • Who would benefit:
      • All
    • Proposed solution:
      • The ability to edit with the delay of the save to a certain day.At the start of the day, I receive a notification
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC) [reply]

    The possibility of moving from editing page to editing section

      Withdrawn by proposer (too many proposals)

    • Problem:
      • Sometimes the user enters editing page and finds that he needs to edit only a section (Especially in long pages)
    • Who would benefit:
      • All
    • Proposed solution:
      • The appearance of "edit" beside text editing area
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    • Why? If you discover you only need to edit one section after opening the full page in the editor, then just make your edits to the one section instead of messing around with trying to re-open the editor from the editor and probably losing whatever edits you've already made. If the only reason is the automatic edit summary, it's generally easy enough to copy the section header text in between "/*" and "*/". Anomie (talk) 16:19, 13 November 2017 (UTC)[reply]

    The survey has a limit of three proposals per person; archiving this one at the proposer's request. -- DannyH (WMF) (talk) 21:46, 13 November 2017 (UTC) [reply]

    Make beta.wikiversity subdomains for each target language

     N This proposal contradicts an established policy.

    • Problem: Currently all Wikiversity versions which are in incubation phase are mixed up in the same Mediawiki instance. This makes it more difficult to track progress of each version, and sometime create minor problems like template name being already taken but coded in an other language.
    • Who would benefit: Every version of Wikiversity still in incubation and willing to make the move.
    • Proposed solution: Allow subdomain like zh.beta.wikiversity.org
    • More comments: beta.wikiversity.org might stay as a global instance for users unwilling to make such a move, just as wikisource.org stayed in place for some works.
    • Phabricator tickets:

    Discussion

    edit

    And, why not to propose zh.wikiversity.org instead of zh.beta.wikiversity.org?--Juandev (talk) 21:10, 9 November 2017 (UTC)[reply]

    Because, like other linguistic versions mixed on beta, it still didn't reach the criteria for going out of incubation. I would personally not have any problem with putting directly as sub-domain any language as soon a one person show an interest for creating it. But I don't fix this rules. Maybe there are excellent reason to do it this way, but I'm not aware of them. --Psychoslave (talk) 23:20, 9 November 2017 (UTC)[reply]
    Sub-subdomains are problematic. URLs would need to be something like zh-beta or beta-zh or whatever. No real opinion on the proposal otherwise. 😂 (talk) 03:18, 11 November 2017 (UTC)[reply]
    Can you explain what would be so problematic with subdomains? But would it be the only problem, zh-beta.wikiversity.org would still be better. Also wikiversity:zh:Sample should preferably lead to the page Sample on whatever the domain for zh beta would be. --Psychoslave (talk) 16:08, 12 November 2017 (UTC)[reply]

    How about beta.wikiversity.org/wiki/Wv/zh like wikipedia incubator? C933103 (talk) 18:32, 11 November 2017 (UTC)[reply]

    How would that solve any of the problem mentionned, which is consecutive to put everything under a single Mediawiki instance? --Psychoslave (talk) 16:08, 12 November 2017 (UTC)[reply]
    On incubators, there are tools that would allow filtering activity per languages and allow users set the language they're focusing on. By using same structure as incubator then I assume those tools should also be usable? Also you forgot to sign your name and have only added the date. C933103 (talk) 21:10, 12 November 2017 (UTC)[reply]
    Just having a look, it seems that stuff are still mixed up. For example starting typing "template:" in the search bar, templates are listed with language code prepended. That makes template use even more cryptic which is not fine for contributors. Nonetheless I'm interested to know what are the tools you are speaking about, at the very minimal outcome of this proposal, they could be installed on beta.wikiversity.org too. --Psychoslave (talk) 08:11, 13 November 2017 (UTC)[reply]

    Archived

    edit

    We have Incubator/Beta Wikiversity precisely so that we don't have to set up domains for languages that don't have community/content yet. Since this proposal requests a wiki for every beta language, it's not different from "let's create wikis in all languages that have one person supporting it", which goes against our language proposal policy. Thanks for participating in our survey, though! Max Semenik (talk) 22:29, 13 November 2017 (UTC) [reply]

    Watch particular user edits

     N Declined in a previous survey

    • Problem:

    A need for persistent watching of suspected user or IP edits, so you can check them in real time instead of remembering all the addresses and reaching the contribution pages from time to time.

    • Who would benefit:

    Patrollers and admins. The feature will not be available for users that are not patrollers.

    • Proposed solution:

    Adding all their edits to your watchlist, they are spread among all others there. Bolded like any other edit, until you have opened the diff page. To add or remove a user, click on the regular star on the user page or on the user talk page, which will not only bring you revisions to these pages, but also the user's own edits. So that you do not get millions of edits you do not need, and so that there will not be conflicts in the community, only users who are not autopatrolled will enter the list, because there is no point in checking the rest, that is, only new registered and anonymous. On the watchlist page itself, along with the rest of the filters, a filter will be set to show and hide user edits that I watch so that anyone who wants to can distinguish. And this filter will also appear in preferences, for persistent setting. These user names, or IP numbers, will have a new CSS class, so you can write a simple gadget that changes the formatting of names, or their edits, to anyone who wants to - background color, highlighting etc.

    • More comments:

    I do not think it's worth creating a special page for these edits instead of incorporating them into the regular watchlist for the following reasons: The first is comfort - if it's somewhere else, we'll be there less than when it's all in the same place. The second - the chance that it will be implemented as a separate page is falling dramatically, because this is a new feature rather than an existing feature expansion. Another reason is technical - the mess for edits to pages you watch done by people you watch at the same time. Where does it belong? What happens if we open the edit by watching people, we have lost all previous edits of this page in the regular watching, the page has already been marked as seen, and there is no way back. That is, it will make us miss a lot of edits in the usual watchlist.

    • Phabricator tickets:

    Discussion

    edit
    Thank you, Anomie. But I do not see in your links something about the restrictions I added exactly to avoid any kind of abuse. The wrong people will not have this feature, and the right people will not have it about their colleagues, only new on anonime users. Don't you think it solves the problem? I can't see any possible abuse using these characteristics. IKhitron (talk) 17:41, 13 November 2017 (UTC)[reply]
    Hi IKhitron, we did talk in 2015 about whether we could build this just for admins, and determined that wasn't enough. Here's a quote from the statement we published:
    "We could make this tool available to admins, which was suggested by several people during the survey. However, a lot of vandal fighters and mentors are not administrators. Also, to be honest, as active Wikimedians, we’re aware of many cases where admins have been part of personal conflicts. While the vast majority of trusted users would of course use it in good faith, it would create the perception of admins having a tool that could be used for stalking, which is invisible and inaccessible to other users and beyond their control. We’ve been strongly discouraged from doing this."
    We won't be able to build this feature, so I'm going to archive your proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 01:09, 14 November 2017 (UTC)[reply]
    Do you really think that admin can stalk an anonym, DannyH? And it's worse than this admin will delete many articles, something he can do know? Thank you. IKhitron (talk) 01:28, 14 November 2017 (UTC)[reply]
    Yes, it's possible that an admin can do something that's unfair. If they delete a lot of articles, that's part of a public log that people can use to raise questions. If an admin follows a new user around and disrupts every edit that they make, that's much harder to track -- an outside person wouldn't see it, but the user that's being targeted definitely would. This feature definitely would be helpful for the majority of people who would use it in good faith. Unfortunately, we know that some people would use it in an unfair way, even admins. -- DannyH (WMF) (talk) 19:02, 14 November 2017 (UTC)[reply]
    I see, DannyH. Thank you. IKhitron (talk) 21:01, 14 November 2017 (UTC)[reply]

    Live Clock

    • Problem: It would be nice to have a Wiki command {{Clock|Form|Country}}
    UTC date and time:
    Friday
    October
    8:50 am UTC

    to include a live analog clock in Wikipedia pages.

    • Who would benefit: All Wiki Pages talking about a country or a city could include this watch.
    • Proposed solution: As Clock presentation one maybe could use the famous Swiss Railway Clock
       
      Actual time in X-Land
    • More comments:
    • Phabricator tickets:

    Discussion

    edit
    How? (yep totally asking for my userpage) A Den Jentyl Ettien Avel Dysklyver (talk) 14:59, 9 November 2017 (UTC)[reply]
    @Hp.Baumeler and A Den Jentyl Ettien Avel Dysklyver: There are these existing templates on Enwiki, which could be copied to your homewiki w:en:Template:Clock, w:en:Template:Digital clock and date, w:en:Template:Calendar clock with Wikipedia stats and w:en:User:Shardsofmetal/Clock (analog), and a few more in w:en:Category:Clock templates. Quiddity (WMF) (talk) 17:53, 9 November 2017 (UTC)[reply]
    @Hp.Baumeler: Oh, I read the proposal and first comment too quickly. I now see that you specifically meant a template to use in article pages, and not userpages as the templates I linked above are intended for. However, technical editors at your local wiki should be able to help you create a template or infobox parameter for this, using JavaScript - see equivalent templates w:en:Template:Current minute in time zone for example code. Note, it would only work for readers who have JavaScript enabled. I will archive this proposal, as it doesn't require Community Tech to implement it. Thanks. Quiddity (WMF) (talk) 01:12, 14 November 2017 (UTC)[reply]

    Switching between dictionaries (religious, philosophical, scientific). Like switching between languages.

     N Requires community consensus

    • Problem: Any term refers to a dictionary. Currently, the Wikidata provides the user with terms from a mixture of dictionaries (religious + philosophical + scientific+common). The user can only switch between mixed dictionaries of different languages. He can not switch between dictionaries of one language (religious, philosophical, or scientific). But mixing dictionaries and increases chaos: worsens transitivity, leads to constant conflicts, struggle for the one whose dictionary should first point to the object being modeled (with the help of the Wikidata's virtual tool) (see human/Homo sapiens sapiens, god/God, origin of human, world, universe, etc.), 1/one, 2/two, etc.).
    • Who would benefit: Users who need transitivity.
    • Proposed solution: To make a choice of the dictionary necessary to the user (by analogy with a choice of the language necessary for the user). The user selects the language, then selects the dictionary (religious, philosophical or scientific) and makes a description. As a result, the same simulated object of the world (human/Homo sapiens sapiens) will only have one item (Q5).
      When you select a dictionary, the foreign link of the item (subclasses, properties, etc.) should be hidden. If you chose, for example, a religious dictionary, you should not see links to items that relate to the scientific and philosophical dictionaries. In this case, the concept of "neutrality" is not needed at all, for there will be no hostile points of view (they will remain each in their own dictionary).
    • More comments: Wikipedia does not have a switch even from one language to another. If the Wikidata will be able to switch between dictionaries (religious, philosophical, scientific, general), then Wikipedia will finally become atavism and rudiment, focused only on humans, but not on machine readability.
    • Phabricator tickets:

    Discussion

    edit

    What does the community think about this? Do you have consensus from those who are supposed to maintain this? Max Semenik (talk) 23:43, 10 November 2017 (UTC)[reply]

    I did not poll, I do not know how to poll all users who need transitivity. --Fractaler (talk) 17:45, 12 November 2017 (UTC)[reply]
    Do not endorse. I don't think the Wikidata community wants this, to the extent that "this" is even well-defined. ChristianKl (talk) 01:22, 13 November 2017 (UTC)[reply]
    Are you afraid of transitivity, because then the ideology of ontology based on properties will lose? Fractaler (talk) 17:59, 13 November 2017 (UTC)[reply]

    Archived

    edit

    I've archived this proposal because it requires maintenance of the proposed system by the Wikidata community, and therefore consensus. Without consensus, we can't start implementing the software parts. Thanks for participating in our survey. Max Semenik (talk) 02:25, 14 November 2017 (UTC) [reply]

    Delete the 10000 articles every Wikipedia should have from the 10 largest language editions of Wikipedia

     N An obviously destructive idea

    • Problem: As an incentive to new authors, authors are notified, if their created article is linked from another article. But all the important articles, that are likely to get linked have been written years ago. These high value articles are also protected/guarded by old contributers against any change that is not liked by these valued authors. While being important articles, they often contain material, that by todays standards would not be included in an article.
    • Who would benefit: Everyone wanting to read high class articles.
    • Proposed solution: Delete all the articles from the list of 10000 articles, that all Wikipedias should have in the 10 largest Wikipedia editons.
    • More comments: These articles have all been havily reused on other websites, so nothing will be lost. The new created articles will be free of historic ballast and make way for a better Wikipedia.
    • Phabricator tickets:

    Discussion

    edit

    Archived

    edit

    Nope. Just nope. Max Semenik (talk) 23:16, 14 November 2017 (UTC) [reply]

    Add en-us as a separate language

     N Proposes social/community change rather than a technical feature

    • Problem: The need to recognise that American (e.g. color) is not always the same as international standard English (e.g. colour). Currently many items in Wikidata are given English (en) names that are not used universally in English, but are uniquely American, and not used by (and are often detested by) English speakers in the rest of the world. Wikidata recognises en-ca for names that are uniquely Canadian and en-gb for names that are uniquely British, but does not admit the distinction of en-us for names that are uniquely American. This is a surprisingly frequent problem with the vernacular names of animals and plants, where one name is near-universal in English except for USA, where a different name is used.
    • Who would benefit: English speakers worldwide outside of the USA as reusers of Wikidata (e.g. lists of vernacular names on Commons)
    • Proposed solution: Create en-us as an additional language, so that uniquely American names can be indicated as such and no longer be passed off as universal English
    • More comments: This would help resolve the long-standing problem of American imperialism on wikidata, whereby uniquely American names are imposed as 'standard English' names on English speakers in the rest of the world (England, Ireland, Australia, New Zealand, South Africa, etc., etc.) against their wishes.

    Discussion

    edit
    • @Deryck Chan:It's possible for en-GB, en-CA but not for en-US or en-AU. Those would have to be added and our general process for doing so is a phabricator ticket. If there are disagreements about whether we want to add them, the forum would be somewhere on Wikidata. ChristianKl (talk) 16:17, 10 November 2017 (UTC)[reply]
    • While I share the concern about the symptom, I'm not sure it's really a technical problem, but more an editorial one about accepted language granularity. That is, the problem surely go far beyond en-US, as I would expect that even within US you will find regional linguistic variations. Actually, even in small town you might find notable dialectal variations. So surely recognize en-US would be fine, but this wouldn't solve the underlying problem. --Psychoslave (talk) 09:20, 12 November 2017 (UTC)[reply]
    • Having looked more into the issue, it's an issue that's entirely about policy. The Wikimedia Language Committee seems to have the opinion at the start of the year that en-US shouldn't be added. This leaves either the possibility to convince them to accept it or to change Wikidata policy to remove the jurisdiction about the decision from them. There's nothing the Community Tech Team can do about either. ChristianKl (talk) 01:20, 13 November 2017 (UTC)[reply]
    Yes, this is a policy matter rather than a technical proposal. Community Tech can't work on this, so I'm going to archive the proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 00:11, 15 November 2017 (UTC)[reply]

    Language

     N Proposes social/community change rather than a technical feature

    • Problem:

    Questionnaires, announcements etc. only in English

    • Who would benefit:


    • Proposed solution:

    Also in other tongues, like French or German

    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Archived

    edit

    This proposal is about a social/organizational change and therefore not suitable for our technical survey. Thanks for participating. Max Semenik (talk) 18:25, 15 November 2017 (UTC) [reply]

    Create global translation administrators

     N Proposes social/community change rather than a technical feature

    • Problem: Some wikis have much more active translation admins than others
    • Who would benefit: Every non-English speakers of the community.
    • Proposed solution: The idea would be to make global translation administrators on every WMF wikis with the translation extention on it. It would make the translation system faster, more efficient and flexible without sacrificing safety. After 6 month of inactivity, they would lost their rights.
    • More comments: A local translation admin with experience could ask Stewards these rights.
    • Phabricator tickets:

    Discussion

    edit

    This is not the purpose of 2017 Community Wishlist Survey. We can already do this, creating a new gloal user group. It was already discussed. Matiia (talk) 21:46, 9 November 2017 (UTC)[reply]

    Archived

    edit

    As explained above, we already have the technical means to do this, however there is no community consensus. As soon as there is consensus, this will be done. Thanks for participating in our survey. Max Semenik (talk) 22:29, 15 November 2017 (UTC) [reply]

    Photoshop wiki

     N Out of scope for the Community Tech team, too big

    • Phabricator tickets:

    Discussion

    edit

    There is plenty of free software to do this stuff already. I use both Gimp and Darktable for this kind of thing, and there is also Inkscape for SVG work -- Thennicke (talk) 02:30, 11 November 2017 (UTC)[reply]

    @Thennicke: We want a tool belong to us and translatable.Thank you --ديفيد عادل وهبة خليل 2 (talk) 08:48, 12 November 2017 (UTC)[reply]
    Beware NIH syndrome. Tools already exist, let's not reinvent the wheel. Anomie (talk) 16:27, 13 November 2017 (UTC)[reply]
    I concur with thennicke and anomie. The tools gimp, inkscape, darktable, imagemagick and others are opensource, they belong to everybody, so also to the wiki community. I am an occasional contributor to some wikipedia graphic labs and I find those tools are sufficient for the work needed here. Regards--Basquetteur (talk) 17:17, 13 November 2017 (UTC)[reply]
    @Thennicke, Anomie, and Basquetteur:
    1. These tools are not translatable; therefore, only a small group of contributors will benefit
    2. We want one tool to help us improve any file--ديفيد عادل وهبة خليل 2 (talk) 06:38, 14 November 2017 (UTC)[reply]
      Sure they're translatable. For example, here is a page about The Gimp's current translation status, and here is a document about how to contribute translations for Inkscape. As for "one tool", it's often better to have multiple tools that are good at one thing each than to have one tool that's mediocre at everything. Anomie (talk) 14:30, 14 November 2017 (UTC)[reply]

    Archived

    edit

    This is a huge undertaking that our team doesn't have the resources for. Additionally, there are lots of free graphics tools so the benefit from the proposed solution will be marginal at most. Thanks for participating in our survey. Max Semenik (talk) 00:26, 16 November 2017 (UTC) [reply]

    Ne plus utiliser a priori la notion de "harcèlement" ou de "harassment" mais définir clairement le problème supposé ou constaté

     N Proposes social/community change rather than a technical feature

    • Problem: Utiliser un terme aussi connoté, et connoté négativement, que "harcèlement" (en français) ou "harassment" (en anglais), dans la présentation d'une controverse, induit une certaine lecture qui oriente les opinions, soit sur le contributeur visé, soit sur celui qui le vise. Que d'autres contributeurs puissent par la suite suggérer, et non pas affirmer, que ça puisse être du harcèlement, est acceptable, que le contributeur rapportant le cas le fasse l'est moins. Disons, ce n'est pas aux parties concernées de définir une imputation aussi subjective. Les cas ressortant de faits évidents (tels que répéter trois fois une annulation de contribution) sont aisément qualifiables, ceux ressortant d'un sentiment le sont moins. (merci à quiconque voudra traduire en anglais ou en “globish” selon compétence)
    • Who would benefit: Tous les contributeurs.
    • Proposed solution: Aucune pour l'initiateur de cette proposition (disons, la proposition est la solution proposée).
    • More comments:
    • Phabricator tickets: L'initiateur de cette proposition ignore complètement ce que peuvent être des “Phabricator tickets” et n'a certainement pas l'intention de le découvrir, parfois l'ignorance est salvatrice.

    Discussion

    edit

    This isn't a technical proposal. It's not for the Community Tech team to tell communities how to define certain words or how to interact with each other – we can only do technical development on technical proposals. /Johan (WMF) (talk) 16:05, 16 November 2017 (UTC) [reply]

    New user right: Project sysop

     N Proposes a change in policy, rather than a technical feature

    • Problem: Many language versions of the sister projects have a small community and no or just a few active admins. In my case I am very active on Wikivoyage, I am admin and bureaucrat on four language versions. But I can not help other small Wikivoyages. I need admin rights for deleting spam and installing/configuring features. People ask me for help but I can not. If I apply for admin right on e.g. Vietnamese WV, it is limited to one or three month. I have to reapply on and on. This process makes me tired. Even my adminship on WV/uk is limited although I finished an application on this wiki. My global sysop application was denied due to no inter wiki skills, but I have no time to edit in other projects just to get these needed inter-wiki skills. A sysop right for a whole project (like Wikivoyage) would be extremly useful to help the small wikis and roll out own features (like our maps or listings editor)
    • Who would benefit: All small wikis.
    • Proposed solution: New user right.
    • More comments:
    • Phabricator tickets:

    Discussion

    edit

    Archived

    edit

    This is a policy proposal, and as such it's out of scope for our survey. Regardless, thanks for participating! Max Semenik (talk) 19:45, 16 November 2017 (UTC) [reply]

    أرجو أن أرى فقرة بعنوان "سؤال الأسبوع" في الصفحة الرئيسية لويكيبيديا العربية "كما في ويكي الأخبار :)

     N Proposes social/community change rather than a technical feature

    • Problem: المشكلة
    • Who would benefit: من الذي قد ينتفع
    • Proposed solution: الحل المقترح إنشاء فقرة "سؤال الأسبوع" أو "سؤال اليوم" للاستفادة من معلوماتهم السابقة
    • More comments: تعليقات أخرى تم إنشاء ذلك في "ويكي الأخبار" بالنسخة العربية حيث يتم تقييم الإجابة بعد أن يجيب الزائر على إحدى خيارات السؤال
    • Phabricator tickets: تذاكر فابريكاتور

    Discussion

    edit

    @A3bdula3ziz: This proposal sounds out of scope to me, as no software development is required. The Arabic Wikipedia community could just introduce this if they wanted, after discussion on w:ar:ويكيبيديا:الميدان? --AKlapper (WMF) (talk) 15:04, 10 November 2017 (UTC) [reply]

    Create a tool for merging global accounts

     N Not technically feasible

    • Problem: There is no way to merge global accounts now. During the SUL finalisation it happened often, that one contributor ended up with more global accounts. There can be other reasons as well, why one person has more than one accounts, and would like to merge them. As a bureaucrat and recently a global renamer I received several requests from many users in the last 10 years to merge their accounts, and I promised them that it will be possible soon (it is relative, but in some years), and I was waited for this feature as it was planned in the frame of the SUL finalization. Until end of last year when the developers announced that this feature doesn't work trustfully and won't be deployed.
    • Who would benefit: Contributors, who has more (global) accounts and would like to merge them.
    • More comments: Before the voting phase I would like to see if this request is technically possible or not. Please investigate if this is simply impossible for Wikimedia wikis or we need "only" to improve our software/hardware infrastructure to solve the problems.

    Discussion

    edit

    @Legoktm (WMF), Hoo man, Keegan (WMF), MarcoAurelio, and Nemo bis: I would appreciate your expert opinion on this topic. Samat (talk) 12:39, 18 November 2017 (UTC)[reply]

    We worked a lot on this but irreversibly broke accounts trying to merge them, see phab:T104686. For the tool, see further phab:T156584 and the tag usermerge on Phabricator. Best, —DerHexer (Talk) 13:23, 18 November 2017 (UTC)[reply]
    I think I know the earlier cases and the current situation, but this means only that it is currently not working and disabled. It is not clear for me, that the request is absolute not possible or just relative ( = hard to solve). Samat (talk) 14:04, 18 November 2017 (UTC)[reply]
    @Samat: You will not get an answer. It is a question of cost and benefit. What is the benefit? For some time now all new account are global. Only very old account would profit, and of those only that account that are still active, and of those only the ones that still want it. Let's say for the sake of the argument, that these are 200 people who benefit. What is the cost? It has been tried before, accounts have been irreversibly broken. Before it is tried again you need to test a new solution. You cannot test on production, so you will not break any more accounts. You need to create a replica for testing: 800+ wikipedias, with dozens of millions of users, with billions of edits. This test environment would need a hardware as big as that of production. That would cost millions, So instead you will run it on a smaller hardware. It will still run, but slow. The test of a single unification might take 2 days to complete. To test all 200 accounts may take 400 days. But if after 399 days of testing the system breaks, you have to correct the unification software and than start over. The correction might work, but in the end you may find another error, and you start again... Yes it is possible, No it will never be done. --𝔊 (Gradzeichen Diſk✉Talk) 23:57, 18 November 2017 (UTC)[reply]
    Thank you for your explanation. It is sad, but rational. Samat (talk) 00:30, 19 November 2017 (UTC)[reply]
    The tool exists, but there's a lot of legacy in the databases that prevent the tool from working on old accounts sadly, which are the ones that would really benefit from this. See phab:T49918#1933044 for details. That said, I'd love that now that we know the issues, try to work on fixing them if at all possible. —MarcoAurelio (talk) 20:30, 19 November 2017 (UTC)[reply]

    Hi Samat, it looks like this proposal isn't really technically feasible. I'm going to archive this before the voting phase. Sorry for the sad answer; thanks for participating in the survey. -- DannyH (WMF) (talk) 17:38, 20 November 2017 (UTC) [reply]

    Brainstorming for wiktionaries

     N Wishlist Survey isn't a good place for brainstorming

    • Problem:

    It is impossible from the current form of all wiktionaries to create a pdf book for:

      • lang to lang (definitions only, ex. Italian-English)
      • specialized dictionary of lang (ex. Greek medical dictionary, Magyar etymological dictionary)

    Also it is impossible to view a wiktionary only in the above mentioned way.

    • Who would benefit:

    Readers?

    • Proposed solution:

    Create a page for proposes on how to achieve this.

      • by creating gadgets?
      • by creating new mediawiki extentions?
      • ...

    Maybe one or more trial new (lang)projects that will collect (temporarily) data from some selected wiktionaries in order to make there trials.

    • More comments:

    Most wiktionaries differ in the way they present data. It is difficult to create a common gadget. That's why I am not proposing a gadget but a place to discuss problems and solutions specific to that direction.

    • Phabricator tickets:

    Discussion

    edit

    Hi Xoristzatziki: This is an interesting question, but the Wishlist Survey isn't the appropriate place for a brainstorming session. I'm going to archive your proposal; thanks for participating in the survey. -- DannyH (WMF) (talk) 17:53, 20 November 2017 (UTC) [reply]

    Science templates

    • Problem: Generally, all edits need a reference. But science is arithmetics, so F= °C, miles= km and meter= feet conversion templates are allowed.

    For example, cristalline minerals with a solved structure have a position for each atom. Chemical formulas need to be charge-balanced, but copies and typos make errors and these errors live forever (there are ions, but their half-life is less than one second). I think that in the next 25 years we should check more data on Wikidata. A scientist makes many experiments, he publishes some experiments, the papers are cited in a secondary literature, the secondary literature is cited in Wikipedia. The sources for errors are unbelievable infinite. Cristal structure, atomic volume and chemical formula are interlocked through arithmetics. There are many possible errors, at no time is everything right.

    • Who would benefit: science articles.
    • Proposed solution: the laws of physics should get more templates and bots.
    • More comments:
    • Citation (CNMNC Newsletter 39 (August and September, 2017)): "After the approval of the new mineral magnesiobeltrandoite-2N3S (IMA2016-073; see CNMNC Newsletter 34 (October and November, 2016)) the authors became aware that the approved chemical formula of the mineral was not charge-balanced."
    • Citation (rruff.info/ima): "Note that chemical formula is not charge-balanced in this report. The formula from the 1987 paper is kept."
    • Hogarth D D (2006) Fluoro-potassic-magnesio-arfvedsonite, KNa2Mg5Si8O22F2, from the Outaouais region, Quebec, Canada, The Canadian Mineralogist 44, 289-289.
    • Phabricator tickets:

    Discussion

    edit
    • How is this problem not solved by creating the templates and Lua modules yourself and having a community-run RFC for a find and replace? No development work is necessary. MER-C (talk) 12:50, 10 November 2017 (UTC)[reply]
      • This problem is huge (strategic). Science is arithmetics, Wikidata building must aim for interlocking its data. For example, the chemical formula would need a periodic table as data in the background. We do not have cristallographic data of a mineral structure, this would be a huge data input. Sure a programmer can make initial steps with templates and lua modules (maybe, the initial step should be physics). It is "just" a wake up call, and strategy is meta. --Chris.urs-o (talk) 05:53, 11 November 2017 (UTC)[reply]
    • @Chris.urs-o: If I understand correctly, you're talking about things like being able to, "list all statements citing a source that cites a specific journal article that was retracted"1 - if that is correct, see d:Wikidata:WikiProject Source MetaData and WikiCite for the people already working towards this. If I've misunderstood, please explain in a bit more detail. Thanks! Quiddity (WMF) (talk) 23:36, 13 November 2017 (UTC)[reply]
      • It is about strategy. Science is arithmetics. A chemical formula of a mineral should be charged-balanced. The measured density and the calculated density (atomic volume and mass) of a mineral structure should be the same; and so on... The physics of many numbers (data) should be interlocked to find out any typos. Something must be done in the future. --Chris.urs-o (talk) 04:54, 14 November 2017 (UTC)[reply]
        • @Chris.urs-o: Ah, now I think I understand. You are proposing something more akin to wolframalpha. This would be to help with various things within the existing content projects, such as prevent typing errors (perhaps by highlighting when an editor has typed something physically impossible, e.g. Al + O2 -> Al2O4 (should be Al203, per)). -- If that is correct (?) it is a grand idea, but much too big in scope for this wishlist process. I recommend starting a new page at Computational engine or similar, to give more detail to the idea and more time for slow discussion. I'll move this proposal to the archive section in a day or two. Cheers :) Quiddity (WMF) (talk) 20:31, 17 November 2017 (UTC)[reply]
    • Are you basically asking for arithmetic-based Wikidata constraints? --Tgr (WMF) (talk) 05:43, 18 November 2017 (UTC)[reply]

    Fixed markup for citation with in text attribution