2017 Community Wishlist Survey/Miscellaneous

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

2017 Community Wishlist Survey

Miscellaneous
27 proposals, 416 contributors, 917 support votes

Go-previous.svg Editing  •  Mobile and apps Go-next.svg

Here are the 2017 Community Wishlist Survey results!
The voting phase has ended. Thanks for your participation :)

Contents


Get feedback using a yes/no microsurveying

Edit proposal/discussion

  • Problem: At the moment, it is not possible to have feedback from a majority of people, because:
    • they are not following community discussions boards
    • go to a given page is an effort, and everyone can have very good reasons not to express how they feel about something
    • there is no way to collect their opinion in a given context
    Some examples :
    • to leave feedback about a feature you have to be experienced. Users/readers have to understand the structure of the whole wiki to try to search for a page where they can leave some feedback (find it is not guaranteed).
    • help pages maintainers do their best to write Help pages (so as Editors on pages). But they don't know if those pages are useful for their audience, unless if someone understands there is a Talk tab and leave a message there (hint: it never happens).
    • ...
  • Who would benefit: Anyone, because the cases are multiple:
    • People who don't know they can express their opinion about something or help improving it.
    • People improving stuff, to get direct input about something very specific, on a given context.
    • Help pages writers to create better pages and people looking for more information, to give feedback about the page they are reading and then benefit about that improvement.
    • Developers and users for an easier feedback about a given feature.
    • Editors who want to know if a part of the page they are working on is easy to understand.
    • ...
  • Proposed solution:
    Have a way for anyone to be surveyed about something specific. It can be to say if they have found what they were expecting, how they feel about a given feature...
    It is just a yes/no question. This is the case for some on line documentation, like on Google help pages where you can say if you have found the page helpful. In the case there is a minority of no, a link should be added to point to a topic where people can explain what they were expecting.
  • More comments:
    • That task was first drafted as "have a way to know if people find what they are looking for on Help pages" but has been extended a but to have that yes/no solution as an unified practice
    • Some people may recall the Article feedback tool. That tool was very useful to collect feedback on help pages. That extension was not perfect, the wording used was prompting people to deliver unuseful feedback, and its focus was on articles. Removing comments curation would simplify the task a lot.

Discussion

  • This would be super useful but also a lot of work. I imagine the controls would end up of similar complexity to CentralAuth, except that you'd also have to collect/display results. Not really a wishlist level thing IMO. --Tgr (talk) 07:36, 28 November 2017 (UTC)
    Tgr, it can also be simpler, with a script called by a template, to leave opinions and comments on a sub-page. Maybe like the Support button used on this page, but as an extension. Trizek from FR 10:00, 28 November 2017 (UTC)
  • Salut Trizek,
    Ça fait un temps que je me dis qu'il faudrait un outil simple permettant d'obtenir du feedback des lecteurs. En effet, la plupart d'entre-eux ne connaissent pas la page de discussion des articles et ne savent pas comment y intervenir. Cependant, comme souligné dans les votes ci-bas, l'article feedback a été un retentissant échec à ce niveau.
    En quoi penses-tu que l'initiative que tu proposes aura un meilleur succès ? Simon Villeneuve 15:48, 29 November 2017 (UTC)
    Salut Simon, je pense qu'un outil plus simple, avec un usage non-systématique et ponctuel aidera a collecter des retours plus pertinents. Également, comme noté plus bas, la manière dont les choses étaient formulées a amené à pas mal de retours inutiles. Bref, un système auquel on répond par oui/non sera a mon avis utile et gagnant. Trizek from FR 20:53, 30 November 2017 (UTC)
  • Very good tool to have, indeed. Two comments-suggestions. •(1) As a user, I am always pleased to give my opinion, especially in a quick and easy manner. And therefore, I find a yes-no question proposition, a clever feature... as long as I am to reply "yes"; if it's a "no" for me, I feel frustrated if I can't explain my disproval or disagreement, since there are so many ways to not be "aligned" with a given solution (the one stated by the question) and only one to agree (welcome in our Ā-world (null-A)). This means I can't really participate to correction or improvment, and I feel this "no" like a useless "bark" ; simply adding the possibility to add a (discrete) link toward a discussion page or something equivalent, eventualy more user-friendly, in order to collect a few words of explanation, comment, growl, or of gratefulness, why not, would be fine ; a click toward a new window/dialog/ is not a puzzle when you are ready to type few words. •(2) As a potential user of the tool, making it a bit more universal, such as allowing for a quiz, a multiple choice question, would be really great, probably with not a great supplementary effort. Examples: completing the yes-no alternative by one or several (not semantically equivalent) choices such as "maybe", "no_opinion", "unconcerned", or a graduated answer such as "positively yes"-"yes"-"mostly agreing"-"balanced, undecided"-"mostly against"-"non"-"strongly no", or a "0 to 10" scale of agreement (but programing a slider is quite different than just a bunch of radio buttons, i guess). Whatever the answer, a level-0 tool, simple "yes-or-no" alternative, will be a great addition. --Eric.LEWIN (talk) 01:35, 30 November 2017 (UTC)
    Thanks Eric.LEWIN! Your to have a link to a talk page where you can expand what you think of the feature and explain your vote is definitely something to consider into the product definition. Have a dialog input may encounter the same problems the article feedback tool has, with usefulness comments. I also like your idea of having multiple choices, or a scale; that would be nice! Maybe for an iteration? Yes/No would be great as a first step that can go beyond. Thanks! Trizek from FR 20:53, 30 November 2017 (UTC)
  • There are a few hurdles with this onde, even if it is quite nice. There are even research papers about it! First, there must be a cost with a system like this, otherwise it turns into a like-system. Then the users must be allowed to vote on a scale to express how they feel about the question. Because different people express their feelings differently the votes must be normalized somehow. Lastly the scales are for different dimensions, which might be overlapping or duplicated, so they must be folded into a lower dimension to make sense. This folding to a lower dimensional space is non-trivial. (Yes you can use PCA, but it will most likely create a mess.) — Jeblad 00:02, 11 December 2017 (UTC)

Voting

  • Support Support Strainu (talk) 22:56, 27 November 2017 (UTC)
  • Oppose Oppose We've tried this with mw:Article feedback/Version 5; it turned into a glorified like button. No. MER-C (talk) 01:40, 28 November 2017 (UTC)
  • Support Support Helpful for assistance pages. --Omnilaika02 (talk) 10:46, 28 November 2017 (UTC)
  • Support Support, provided we don't revert to Article feedback (as MER-C, I felt Article feedback was just some kind of oversized "Like" button, all the more as Talk Pages and Good/Featured Articles procedures are much more effective to advance articles, at different stages of their development). But some easy feedback for new technical features, for instance, would probably be helpful. Still, I have some doubts about the exact scope as well as practical issues. --Azurfrog (talk) 11:49, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  • Support Support A good way to give new contributors an opportunity to express there needs, and thus stay at task in Wikipedia... Salix (talk) 13:33, 28 November 2017 (UTC)
  • Support Support Kurt Jansson (talk) 21:44, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:56, 28 November 2017 (UTC)
  • Support Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:22, 29 November 2017 (UTC)
  • Support Support MichaelSchoenitzer (talk) 19:57, 29 November 2017 (UTC)
  • Support Support I think the success of such a tool lies in the semantics of its use, in the phrasing and the wording of the question and its answers, not in the tool by itself. --Eric.LEWIN (talk) 01:42, 30 November 2017 (UTC)
  • Support Support Exilexi (talk) 15:07, 30 November 2017 (UTC)
  • Support Support Goodship11 (talk) 16:18, 30 November 2017 (UTC)
  • Support Support Yes ! Gonzolito (talk) 14:36, 1 December 2017 (UTC)
  • Support Support Simon Villeneuve 16:01, 1 December 2017 (UTC)
  • Support Support Pamputt (talk) 18:54, 1 December 2017 (UTC)
  • Support Support Lofhi (talk) 19:48, 1 December 2017 (UTC)
  • Support Support Ckoerner (talk) 21:51, 1 December 2017 (UTC)
  • Support Support Whats new? (talk) 00:16, 2 December 2017 (UTC)
  • Support Support --Benoît Prieur (talk) 12:51, 2 December 2017 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 15:53, 3 December 2017 (UTC)
  • Support Support FULBERT (talk) 19:16, 3 December 2017 (UTC)
  • Support Support like articlefeedback5? Gryllida 00:54, 4 December 2017 (UTC)
  • Support Support Excellent idea —— DePlusJean (talk) 17:22, 4 December 2017 (UTC)
  • Support Support WhatamIdoing (talk) 18:14, 4 December 2017 (UTC)
  • Support Support Elitre (talk) 17:00, 5 December 2017 (UTC)
  • Oppose Oppose per MER-C, and not a development priority. Kudpung (talk) 20:40, 6 December 2017 (UTC)
  • Support Support Ahm masum (talk) 21:40, 7 December 2017 (UTC)
  • Support Support Spinster (talk) 21:17, 10 December 2017 (UTC)
  • Support SupportJeblad 00:03, 11 December 2017 (UTC)
  • Support Support Psychoslave (talk) 08:06, 11 December 2017 (UTC)
  • Support Support Yohannvt (talk) 11:50, 11 December 2017 (UTC)

Word count on statistics

Edit proposal/discussion

  • Problem: We don't have an actual word count since 2014, and this is a basic statistic to calculate Wikipedia's size
  • Who would benefit: Statistic-lovers and everyone who want to show the size of Wikipedia
  • Proposed solution: Having a word count from the dump would be the solution
  • More comments:
  • Phabricator tickets:
  • Proposer: Theklan (talk) 22:40, 13 November 2017 (UTC)

Discussion

This is relatively straight forward, we already have the per-article word counts broken out (they are in search results), there just isn't a public way to ask for a sum. FWIW a sum on en.wikipedia.org content index currently reports: 3.049711774E9 EBernhardson (WMF) (talk) 03:17, 18 November 2017 (UTC)

Where did you find this number? -Theklan (talk) 17:57, 20 November 2017 (UTC)
I wrote a custom query against the elasticsearch cluster to aggregate the stored word count (as I'm a developer working on search at WMF). I've put up a patch in code review to integrate this into Special:Statistics. I would expect this to be merged and roll out sometime in December. This is only the raw word count of pages considered articles, not any of the more advanced things discussed below. EBernhardson (WMF) (talk) 19:09, 28 November 2017 (UTC)
@Theklan: This has now rolled out to all wiki's, you can get the counts from the Special:Statistics page. 2601:648:8402:C015:307E:5334:1490:C6B9 19:09, 15 December 2017 (UTC)
@EBernhardson (WMF): Are you sure that this number is correct? The number was considerably higher in 2014 according to Wikistats. -Theklan (talk) 00:57, 16 December 2017 (UTC)
@Theklan: Wikistats may have been calculating something different, would have to dig into what they counted. This particular count takes the content (main namespace), removes some non-content portions (tables, hatnote's, etc) and then counts the number of individual words (as determined by tokenization with lucene, the same used for full text search). If we were to include non-content pages the value would increase from 3.1 billion to 11.3 billion. EBernhardson (WMF) (talk) 17:58, 17 January 2018 (UTC)

I would suggest taking this further with basic readability statistics. there are various well-established metrics, but even simple things like average words-per-sentence and syllables-per-word would be helpful. T.Shafee(Evo﹠Evo)talk 11:02, 18 November 2017 (UTC)

Readability metrics are misleading and bullshit. Source: I built one. --Dispenser (talk) 18:03, 20 November 2017 (UTC)

Note: This idea was also suggested at wikitech-l a few days ago, and a reply pointed out a userscript that does a very simple version. Quiddity (WMF) (talk) 19:52, 20 November 2017 (UTC)

User:Dr pda made a byte and word counter years back and lists issues with counting "article text". The reason why people like word count is "100 words = 1 minute of reading" (without regard to textual difficulty). Naturally excludes infoboxes, tables, images, navboxes, etc. --Dispenser (talk) 21:10, 20 November 2017 (UTC)
Yes, but I don't want a script that measures the word count of a given article, but the global number of words in the whole Wikipedia project. There's a difference there! -Theklan (talk) 12:03, 21 November 2017 (UTC)

Voting

Responsive CSS/Template Framework for Media Wiki

Edit proposal/discussion

  • Problem:

Most of the help and meta pages are in Wikipedia and other WikiProjects are cobbled with strange copy'n'paste constructions of Templates, HTML and InlineStyles. This leads to an inconsistent, hard to maintain interface, that fails on many platforms. A lot of the editors maintaining these pages are not programmers. Since there is no simple comprehensible library where they can find all the buttons, boxes, grids and teasers. Most of them copy just what they find on other meta-pages - often without really understanding how it works.

  • Who would benefit:

Readers and Editors alike

  • Proposed solution:
    Create a simple but effective library of CSS-Styles (like Bootstrap) and MediaWiki-Templates, that enables editors to quickly create interfaces that work on all devices and screen sizes and has a consistent look and feel. Possible components are:
    • Buttons
    • Teaser-Boxes
    • Form-Elements
    • A Grid-System
  • More comments:
  • Phabricator tickets:

Discussion

If I understand correctly, this would be like T90687, except scoped for the content area, not the software/skin area. That would be a great thing to have, although potentially a lot of work (it would have to take into account different devices, different skins, RTL...) Developers would probably benefit just as much editors/readers as it would be easier to make assumptions about how articles look / wrangle the content to be appropriate for mobile screens.

@Martin Kraft:: The proposal could do with a less handwavy list of use cases IMO (forms and buttons are barely used in wikitext-generated content, and I imagine a grid and boxes would not be the only things to standardize; see also the various subtasks and blockers of T483).

For performance reasons this might depend on TemplateStyles (although if it's not too much overhead we might just prefer to load such a framework on all pages; especially if the original, software-interface-oriented version of T90687 does get done and uses the same rules). --Tgr (WMF) (talk) 02:09, 21 November 2017 (UTC)

Voting

Making Mediawiki MOOC-ready

Edit proposal/discussion


  • Problem: The Wikiversity missed the massive open online course (MOOC) train. Even the WikiMOOC, which teach how to contribute to Wikipedia, wasn't hosted on Wikiversity. For our movement to gains acceptance in the educational field, and eager of people to learn through MOOC platforms, Mediawiki needs a serious upgrade. This could be in the form of an upgrade to the MW:Extension:Quiz extension.
  • Who would benefit: The Wikiversity communities, of course, but also anyone looking for an inhouse MOOC platform. Plus, more contributors and content on a single linguistic Wikversity version make it far more likely to find benevolent translators through its skilled community and its already well tooled translation environment.
  • Proposed solution:
    • enable users to follow their progress by giving ability to record result of evaluation form
    • provide
      • ease publication of existing courses
      • possibly, way to validate knowledge/skill acquisition
        • online, with some strong identity control and avoidance of least elaborated cheat
        • offline, with tool which ease coordination of exam sessions in dedicated places
    • establishing a list of feature that a MOOC platform must have to be successful is part of this proposal, please feed the proposal
  • More comments:
  • Phabricator tickets:

Discussion

  • See also Wikimedia MOOC platform and related Phabricator project for an on-going discussion on this matter. —The preceding unsigned comment was added by Noé (talk)
    This could also just be an improvement of MW:Extension:Quiz to allow the exercises results persistence and consultation. JackPotte (talk) 18:03, 8 November 2017 (UTC)
    That's indeed one aspect to improve it. But it also should be improved in UX terms, so users might create forms with the VE for example. Also I don't remember if it's already possible to have a larger set of question than the one displayed so the user might face different set of questions each time. Adding a difficulty score to each question, one might also adapt questions to the user previous results. Probably a large bunch of that might be implemented with modules and templates which takes care of all the adaptive behaviour, but data persistence and form edit UX are less likely implementable without dedicated development in the extension. --Psychoslave (talk) 11:12, 9 November 2017 (UTC)
    The MOOC module has been implemented on Wikiversity in Portuguese, and we are now developing our first course. We have relied on the modules that were released on Wikiversity in English, for instance the course on Web Science. I agree these modules would benefit with some improving. --Joalpe (talk) 03:47, 9 November 2017 (UTC)
    Thank you I wasn't aware of that. I think that we should spread the word within versions of Wikiversity. --Psychoslave (talk) 11:12, 9 November 2017 (UTC)
  • I'd like to note that this proposal as it currently stands is very vague. What exact changes are you proposing? The community tech team works on software development, not partnerships with institutions. Is there consensus for what you're asking for? -- NKohli (WMF) (talk) 21:39, 20 November 2017 (UTC)
@Psychoslave: please see my above comment. -- NKohli (WMF) (talk) 00:24, 22 November 2017 (UTC)

Hi @NKohli:,

What exact changes are you proposing?
I think that the less vague demand is an improvement of the Quiz extension
  • it should allows users to keep a record of their previous results. The legal team should also take a look at this for privacy consideration I think.
    • A board which enable to have an overview of progress would be fine too.
  • editors should be able to use only visual editor to build quiz forms

For institutional partners, we actually already have some, at least on the French Wikiversity we have courses which were provided by the CNED like Mise en œuvre de l’accessibilité numérique and Convertir une formation existante au format MOOC. So no one seems against this kind of partnership. Providing more suited tools will only help to attract more release of courses by institutional structures.

Does this answer your demand? --Psychoslave (talk) 07:56, 22 November 2017 (UTC)

Yes, sorry for the late reply. You pinged the wrong person. I'll update the proposal description a bit according to your revised version. Thanks. -- NKohli (WMF) (talk) 23:38, 27 November 2017 (UTC)

Feels like Not Invented Here syndrome. Surely it is easier and more productive to fix an exiting, high-quality MOOC framework to use MediaWiki authentication, design and stats, than to implement some half-baked MOOC functionality in an extension... --Tgr (talk) 08:24, 28 November 2017 (UTC)

Voting

Add filters to history pages

Edit proposal/discussion

  • Problem: On some of the high traffic pages, due to volume of activity, it is difficult to identify true authors or find other editing patterns.
  • Who would benefit: Admins and editors investigating page histories.
  • Proposed solution: Add ability to filter/sort page histories, by for example:
    • Show/hide IP edits
    • Show/hide reverted edits and their reverts
    • Show/hide banned user edits
    • Show/hide bot edits
    • Show/hide minor edits
    • Show/hide edits by number of bytes added/subtracted
    • Show/hide my edits – definitely a necessity
    • Show/hide selected user's edits (if this is deemed uncontroversial)
    • Show/hide deleted edits (for administrators only?)
  • More comments:
  • Proposer: Renata3 (talk) 18:31, 9 November 2017 (UTC)

Discussion

  • Nice idea.
    • I had similar plans in background, since that wish came up once in a year in German Wikipedia.
    • There was no broad cry for such a feature.
    • I already mantain w:en:User:PerfektesChaos/js/listPageOptions modifying watchlists and “recent changes”, and I might extend that to history pages with similar options a watchlist already offers. Or mw:User:PerfektesChaos/js/resultListSort which is sorting about 30 special pages.
    • What is a “banned user edit”?
    • “reverts” are edits as any other; they bear no special mark and only full rollback uses a project dependant summary. Simple reverts offer editable summary.
    • IP / registered user, user him/herself edit, bot edit, minor edit, number of bytes less greater than, no summary, personal list of suspicious/interesting users (will need to be stored outside public pages for privacy reasons) – those may be subject to be shown or hidden; or, more likely, to be sorted, showing interesting things in one block together.
    • If this wish is not picked up, I ponder if and how I might implement this.
Greetings --PerfektesChaos (talk) 11:00, 16 November 2017 (UTC)

Added some possible filter options. --Vachovec1 (talk) 22:43, 18 November 2017 (UTC)

Ad PerfectedChaos comments:

  • Reverts: what? "Normal" revert (clicking on "undid" in diff interface) has editable summary, sure, but if not completely overwritten, the summary every times begins with words like "Undid revision (number) by (user)" (for English) or similar predefined sequence for other languages. But you probably can't indentify reverts made with "save this old version of page" method.
  • Banned user: I can imagine A) currently blocked user or B) user marked with template en:Template:Banned user (or with something similar).

--Vachovec1 (talk) 22:43, 18 November 2017 (UTC)

Introducing the edit filters already used elsewhere seems like a logical step UX-wise (although not sure how well the database would cope for large articles without major changes to our infrastructure). For reverts, see also T152434. --Tgr (WMF) (talk) 23:46, 18 November 2017 (UTC)

There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:38, 29 November 2017 (UTC)
  • The essential tool I always needed and didn't realise it was missing untill this poll. Would really save a lot of time. Very useful for COIN, SPI, and research into other persistent disruption. Up till now I have to copy an entire page history into a regex propgram and do it from there (and I'm not a regex or a Quarry expert like much of Wikipedia expects every normal user and admin to be. Kudpung (talk) 20:51, 6 December 2017 (UTC)
  • The efficient way to identify reverts is by using the digest. Anyway, the history should be collapsed when a revert is detected. It should also be collapsed for consecutive edits. Note also that "to identify true authors" is extremely difficult. What is a true editor. — Jeblad 01:09, 11 December 2017 (UTC)

Voting

Overhaul spam-blacklist

Edit proposal/discussion

  • Problem: The current blacklist system is archaic; it does not allow for levels of blacklisting, is confusing to editors. Main problems include that the spam blacklist is indiscriminate of namespace (an often re-occurring comment is that it should be possible to discuss about a link in talkspaces, though not to use it in content namespaces). The blacklist is a black-and-white choice, allowing additions by only non-autoconfirmed editors, or only by admins is not possible. Also giving warnings is not possible (on en.wikipedia, we implemented XLinkBot, who reverts and warns - giving a warning to IPs and 'new' editors that a certain link is in violation of policies/guidelines would be a less bitey solution).
  • Who would benefit: The community at large
  • Proposed solution: Basically, replace the current mw:Extension:SpamBlacklist with a new extension based on mw:Extension:AbuseFilter by taking out the 'conditions' parsing from the AbuseFilter and replace it with only parsing regexes matching added external links (technically, the current AbuseFilter is capable of doing what would be needed, except that in this form it is extremely heavyweight to use for the number of regexes that is on the blacklists). Expansions could be added in forms of whitelisting fields, namespace selectors, etc.
  • More comments:
  • Phabricator tickets: task T6459 (where I proposed this earlier)

Discussion

  • I agree, the size of the current blacklists is difficult to work with; I would be blacklisting a lot more spam otherwise. A split of the current blacklists is also desired:
  • I still want to see a single, centralized, publicly available, machine readable spam blacklist for all the spammers, bots, black hat SEOs and other lowlifes so that they can be penalized by Google and other search engines. This list must continue to be exported to prevent spam on other websites. Autoblocking is also most useful here.
  • The same goes for URL shorteners and redirects -- this list would also be useful elsewhere. This is one example where the ability to hand out customized error messages (e.g. "hey, you added a URL shortener; use the original URL instead") is useful.
  • The remaining domains might belong on a private list with all the options described above.
  • Please consider integrating the extension into core MediaWiki; it is already bundled with the installer. MER-C (talk) 11:57, 14 November 2017 (UTC)
    • Do note that there are a lot of domains on the blacklist which are not due to 'lowlifes' - quite a number of pornographic sites are blacklisted because of uncontrollable abuse, not because of them being spammed, let alone by site-owners or their SEOs. Also URL shorteners are blocked because of nature and abuse, not because of themselves being spam. In those cases I actually agree with complaints that these sites are penalized for being on the blacklists. I do agree that a full list of those domains that are due to the SEO/spammers/bots and other lowlifes should be publicly visible (note: COIBot and LiWa3 collect all the blacklists in off-wiki files for referencing purposes, it would be rather easy to publish those collective records on-wiki as public information). --Dirk Beetstra T C (en: U, T) 12:12, 14 November 2017 (UTC)
  • Another suggestion: one needs to have the option to match against norm(added_lines) instead for continued spamming of blacklisted links. I've seen forum spam that needs this solution, we need to have an equivalent here as well. MER-C (talk) 12:28, 14 November 2017 (UTC)
    • Check, but I think that that type of parsing is (partially?) in the current blacklist. I have seen XLinkBot-evasion by using hex-codes (which I subsequently coded into the bots). --Dirk Beetstra T C (en: U, T) 12:31, 14 November 2017 (UTC)
  • @Beetstra: For the sake of clearance: you want to replace AbuseFilter extension or you want to add a new extension based on AbuseFilter? --Vachovec1 (talk) 21:20, 14 November 2017 (UTC)
    • This proposes to replace mw:Extension:SpamBlacklist with this functionality. MER-C (talk) 03:03, 15 November 2017 (UTC)
    • @Vachovec1: I want add a new extension based on AbuseFilter (that seems to me the most logical start, as functionality in the AbuseFilter is quite appropriate, but too heavy for this), to replace the current spam-blacklist. --Dirk Beetstra T C (en: U, T) 05:22, 15 November 2017 (UTC)

My issue with this (as I have with supposed “spam-fighting”) is that it takes way too much collateral damage both when it comes to users as when it comes to content, many useful sites are blacklisted purely because a user is banned, and if a user gets globally banned the link 🔗 gets globally blacklisted and removed from any Wikimedia property even if it were used as a source 100% of the time, now let's imagine a year or so later someone wants to add content using that same link (which is now called a “spamlink”) this user will be indefinitely banned simply for sourcing content. I think 🤔 that having unsourced content is a larger risk to Wikimedia projects than alleged “spam” has ever been. This is especially worrisome for mobile users (which will inevitably become the largest userbase) as when you're attempting to save an edit it doesn't even warn you why your edit won't save, but simply says “error” so a user might attempt to save it again and then gets blocked for “spamming”. Abuse filters currently don't function 100% accurately, and having editors leave the project forever simply because they attempted to use “the wrong 👎🏻” reference is bonkers. Sent 📩 from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 10:15, 15 November 2017 (UTC)

Also after a link could be blacklisted someone might attempt to translate a page and get blocked, the potential for collateral damage is very high, how would this "feature" attempt to keep collateral damage to a minimum? --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 10:15, 15 November 2017 (UTC)
@Donald Trung: that is not going to change, actually, this suggestion is giving more freedom on how to blacklist and whitelist material. The current system is black-and-white, this gives many shades of grey to the blacklisting system. In other words, your comments are related to the current system.
Regarding the second part of your comment - yes, that is intended use of the system, if it is spammed to page one, then translating that page does not make it a good link on the translation (and actually, this situation could actually also be avoided in the new system). --Dirk Beetstra T C (en: U, T) 10:39, 15 November 2017 (UTC)
  • The blacklist currently prevents us from adding a link to a site, from the article about that site. This is irrational. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 15 November 2017 (UTC)
    • @Pigsonthewing: What do you mean, do I have an unclear sentence? If it is what I think, is that I would like per-article exceptions (though that is a less important feature of it). --Dirk Beetstra T C (en: U, T) 14:29, 15 November 2017 (UTC)
    • Ah, I think I get it, you are describing a shortcoming of the current system - that is indeed one of the problems (though there are reasons why sometimes we do not want to do that (e.g. malware sites), or where the link gets more broadly blacklisted (we blacklist all of .onion, which is then indeed not linkable on .onion, but also not on subject X whose official website is a .onion .. ). But the obvious cases are there indeed. I would indeed like to have the possibility to blanket whitelist for specific cases, like <subject>.com on <subject> (allowing full (primary) referencing on that single page, it is now sometimes silly that we have to allow for a /about to link to a site on the subject Wikipage to avoid nullifying the blacklist regex, or a whole set of specific whitelistings to allow sourcing on their own page), or on heavily abused sites really allow whitelisting only for a very specific target ('you can only use this link on <subject> and nowhere else'). --Dirk Beetstra T C (en: U, T) 14:35, 15 November 2017 (UTC)

Or just add an option to AbuseFilter to compare against a regexp list that's on a wikipage. (Would require some thought in that we might want to expose the matching rule in the error message and logs, but otherwise easy.)

More generally, it would be nice if we could standardize on AbuseFilter instead of having five or six different anti-abuse systems with fractured UX and capabilities. That's a bit beyond CommTech's scope though. --Tgr (WMF) (talk) 23:54, 18 November 2017 (UTC)

No, User:Tgr (WMF), using the current AbuseFilter for this is going to be a massive overload of the servers, it will still interpret the whole rule and we would probably have hundreds if not thousands of separate filters for this. It also would not allow for whitelisting (unless, again, you write a full rule with even more overload), namespace exclusion (unless ..), user-level exclusion (unless ..).
Making the AbuseFilter more modular may be an idea .. please read my suggestions above as a detailed request for capabilities. I am not familiar with the coding of the AbuseFilter to see how far this would need to go. --Dirk Beetstra T C (en: U, T) 11:00, 20 November 2017 (UTC)

Voting

  • Support Support per my comment above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 27 November 2017 (UTC)
  • Support Support MER-C (talk) 01:54, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  • Support Support Sadads (talk) 13:43, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:57, 28 November 2017 (UTC)
  • Support Support Darylgolden (talk) 14:24, 29 November 2017 (UTC)
  • Support Support MGChecker (talk) 22:14, 29 November 2017 (UTC)
  • Support Support --Dirk Beetstra T C (en: U, T) 08:01, 30 November 2017 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 11:25, 2 December 2017 (UTC)
  • Support Support Galobtter (talk) 12:48, 3 December 2017 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 16:10, 3 December 2017 (UTC)
  • Support Support This will fix multiple problems at once.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:37, 4 December 2017 (UTC)
  • Support Support Doc James (talk · contribs · email) 02:32, 5 December 2017 (UTC)
  • Support Support blacklist support needs some attention to make sure the system scales well and allows discussing individual links, etc. Also In the past I had issues with pages that had Public Domain images downloaded from website which was latter added to a black list. As a result, it was impossible to add and remove categories to the file without tripping the blacklist. Even for an admin. That issue might have been fixed, but we need a flexible system that can recognize new text from an old one and objection can be overruled if needed. --Jarekt (talk) 14:34, 7 December 2017 (UTC)
    @Jarekt: I guess what you mention has been resolved (pages with blacklisted links are editable, as long as one does not add the link again). What you describe is however one of the examples I had in mind - there are certain links which are fine on talkpages or on file-description pages, but not in mainspace (though those cases are limited). --Dirk Beetstra T C (en: U, T) 12:46, 10 December 2017 (UTC)
  • Support Support Ahm masum (talk) 21:27, 7 December 2017 (UTC)
  • Support Support X:: black ::X (talk) 10:42, 10 December 2017 (UTC)
  • Support Support — Luchesar • T/C 13:51, 11 December 2017 (UTC)
  • Support SupportNickK (talk) 17:01, 11 December 2017 (UTC)

Allow filtering of recent changes and user contributions by whether they have been reverted or superseded

Edit proposal/discussion

  • Problem: Vandalism fighting in Wikidata is tougher than in other WMF projects because edits tend to be small and numerous. The Recent Changes page has plenty of filters to focus in on things like unpatrolled changes and whether the change is still the "latest version". However, if a piece of vandalism is not the "latest version" there is no way to tell if it has already been reverted or not, leading to unnecessary duplication of effort by users trying to fight vandals.
  • Who would benefit: All wikidata users would benefit from better vandalism-fighting. Those who work on patrolling would have a much easier job.
  • Proposed solution: When an "undo" action is taken on an edit, that should be indicated in Recent Changes and user contributions, and filterable. When a "restore" action is done to an earlier version than the edit, that should similarly be indicated and filterable (the same indicator would be fine). Similarly for rollbacks. Ideally any subsequent edit that deletes or changes the value of a statement (if that was what the edit was) or the label or description (if the edit was to a label or description) or sitelink (similarly) would also show that the original edit action was overridden.
  • More comments:
  • Phabricator tickets:

Discussion

I don't see why this should be a Wikidata specific filter. Other projects might also benefit from being able to filter out reverted edits. ChristianKl (talk) 16:43, 9 November 2017 (UTC)

Yes I do think it would be a generally useful filter, but particularly useful with wikidata given the quantity of edits we have to deal with. Also the "superceded" portion of this is wikidata-specific (it's hard to judge on a general wiki page whether a damaging edit has just been replaced instead of an editor using 'undo' or 'restore', but in principle it could be done in wikidata). ArthurPSmith (talk) 18:14, 9 November 2017 (UTC)
I think in many cases it would be possible to judge also on Wikipedia that an edit is undone automatically. ChristianKl (talk) 20:16, 15 November 2017 (UTC)

ArthurPSmith: This is a good proposal, thanks for posting it. I think it would work for other projects as well as Wikidata, so I'm going to move it into the Miscellaneous category. Let me know if you think there's a different category where you think it would fit best. Thanks! -- DannyH (WMF) (talk) 18:21, 21 November 2017 (UTC)

Voting

Filter user contribution page by number of bytes changed

Edit proposal/discussion

  • Problem: It is difficult to identify "major" contributions of an editor, particularly if they are prolific editors and their edit history spans years and thousands of edits.
  • Who would benefit: Admins and editors reviewing user's contributions.
  • Proposed solution: Add a filter on user contribution pages to filter by the changes by number of bytes added/deleted. That way, for example, one could get a listing of user's contributions to the main space where they added more that 500 bytes.
  • More comments:
  • Phabricator tickets:
  • Proposer: Renata3 (talk) 18:42, 9 November 2017 (UTC)

Discussion

  • I wouldn’t say that this would be a particular benefit, profanity is usually added in smaller edits, and page blankings are already caught by various abuse filters. How would this benefit people more? --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 12:56, 10 November 2017 (UTC)
    • Good idea - you could identify the authors of larger changes more easily. I had this problem several times, i.e. when you want to propose a change or addition. --Bernd.Brincken (talk) 19:04, 14 November 2017 (UTC)
  • My tool mw:User:PerfektesChaos/js/resultListSort already offers sorting by page name/title of contributions.
    • As soon I find time I will extend this to sort contribution page alternatively back by date-time, by size, by summary.
    • Sorting is nearly the same as filtering but leaves the smaller number below. The page will be kept locally, but changes entry order as often as desired.
    • Note that this would work on existing result, not retrieving results from the server matching a condition.
    • There is already a filtering form, by namespace, by date, by minor, by current, by new accounts, by page creation. That might be extended by min/max size.
Greetings --PerfektesChaos (talk) 10:15, 16 November 2017 (UTC)
  • This is less useful, adding an infobox will bring a big change, and make translate or refine may be small or even reduced bytes. Period and sorting may be useful.--YFdyh000 (talk) 15:13, 28 November 2017 (UTC)
There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:39, 29 November 2017 (UTC)

Voting

Provide a tool to efficiently analyze the usage of a template

Edit proposal/discussion

  • Problem: Like last year, again I want to raise your attention to the fact that working with often used templates and making changes to them is a mess. Why? There is no tool or handy way to get to grips how the template has actually been used and which options one has to consider (or which pages where the template is used need to be edited) when rewriting a template. The tool https://tools.wmflabs.org/templatetiger/ written by User:Kolossos has been helpful for many years, but instead of providing live information it is based on dumps (most half a year old, some two years or even more), and there is no interface (you need to know how to manipulate the URL to filter the information). As someone wrote in last year's survey: While I have big respect to Kolossos' instrument, it's just not enough.
  • Who would benefit: Primarily users who curate and amend templates, secondarily authors who use templates in their articles
  • Proposed solution: Don't know if it is more likely to get Kolossos' tool improved or to get a whole new tool. Solutions that I'd like to see anyway:
    • For the timeliness of data: It'd be nice and a good start if there were at least a monthly update / a monthly dump that reliably gets fed into the tool. Having live data, of course, would be even more helpful.
    • Improving UX and usability: Please provide some interface to facilitate for example searching for a certain text in a certain template parameter, make the table sortable by mouseclick. The dream solution is an interface like the one we know from petscan.
  • More comments:
  • Proposer: → «« Man77 »» [de] 19:16, 14 November 2017 (UTC)

Discussion

  • This is a useful tool. Also ping en:User:Bgwhite who might be able to help with updating Enwiki dump to a recent version. Looking at Tools in /data/project/templatetiger/public_html .. there is no entry for enwiki in einspielen.sql .. is this due to disk space constraints on Tools? -- GreenC (talk) 19:58, 14 November 2017 (UTC)
  • If I want to update the data I have the problem that I lose the database connection after short time. I don't know why.
    We have also a problem with some complex templates in German Wikipedia, which kill the checkwiki script. For my motivation as a user from Germany it would be nice to find a solution for this problem. --Kolossos (talk) 09:42, 15 November 2017 (UTC)
  • templateparam by Bambots does something similar/related right ? —TheDJ (talkcontribs) 13:43, 15 November 2017 (UTC)
    • Related: Probably yes. Similar: Not too much. → «« Man77 »» [de] 16:42, 19 November 2017 (UTC)
      • @Man77: Can you clarify how your request is different than the information provided by templateparam? (I'm not familiar with templatetiger and couldn't figure out how to use it.) Kaldari (talk) 21:01, 20 November 2017 (UTC)
        • To be honest, I did not know that this tool existed when I posted my request, and so far I have not really understood how to work with it. Stalemate. A tool that only works with the English Wikipedia is, however, absolutely not what I am looking for. → «« Man77 »» [de] 21:32, 20 November 2017 (UTC)
          • bambots tool only starts collecting information upon request and then only parsing the pages that transclude the actual template. This might require you to wait a bit after initially requesting the information for the first time for a particular template, but afterwards, its more up to date and as a benefit takes significantly fewer resources. The tool also allows you to check validity of param keys and values, by matching them with their TemplateData where possible. Not sure why it's only available for en.wp. Templatetiger seems a more brute force solution that parses all template usage. Both have their advantages, I guess, but both have commonalities as well. It should be noted however, that templatetiger is excluded from backups (quite rare) because of its size. —TheDJ (talkcontribs) 14:59, 21 November 2017 (UTC)
            • For my purposes having the template information "on request" would be enough, but the support of templates without TemplateData is not a mere nice-to-have. → «« Man77 »» [de] 17:23, 22 November 2017 (UTC)

Voting

  • Support Support Dvorapa (talk) 09:26, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  • Support Support Matěj Suchánek (talk) 14:59, 28 November 2017 (UTC)
  • Support Support YFdyh000 (talk) 15:27, 28 November 2017 (UTC)
  • Support Support — Draceane talkcontrib. 18:20, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:58, 28 November 2017 (UTC)
  • Support SupportTheDJ (talkcontribs) 14:35, 29 November 2017 (UTC)
  • Support Supportputnik 01:33, 30 November 2017 (UTC)
  • Support Support Would much help deprecation or deletion of unused functionalities, or ones which shouldn't be used but are. --Izno (talk) 03:54, 30 November 2017 (UTC)
  • Support Support - yona B. (D) 08:18, 30 November 2017 (UTC)
  • Support Support Sunpriat (talk) 16:19, 30 November 2017 (UTC)
  • Support Support Ninovolador (talk) 22:09, 30 November 2017 (UTC)
  • Support Support DonBarredora (talk) 01:19, 1 December 2017 (UTC)
  • Support Support Theklan (talk) 18:42, 1 December 2017 (UTC)
  • Support Support Nabla (talk) 23:16, 1 December 2017 (UTC)
  • Support Support SEMMENDINGER (talk) 23:45, 1 December 2017 (UTC)
  • Support Support Wostr (talk) 10:55, 2 December 2017 (UTC)
  • Support Support ~Cybularny Speak? 12:23, 2 December 2017 (UTC)
  • Support Support Wolbo (talk) 13:14, 2 December 2017 (UTC)
  • Support Support«« Man77 »» [de] 14:01, 2 December 2017 (UTC)
  • Support Support Termininja (talk) 17:05, 2 December 2017 (UTC)
  • Support Support Waldir (talk) 10:44, 3 December 2017 (UTC)
  • Support Support Galobtter (talk) 12:50, 3 December 2017 (UTC)
  • Support Support Tacsipacsi (talk) 17:42, 3 December 2017 (UTC)
  • Support Support JAn Dudík (talk) 09:24, 4 December 2017 (UTC)
  • Support Support Anthonyhcole (talk) 11:52, 4 December 2017 (UTC)
  • Support Support Trockennasenaffe (talk) 20:51, 4 December 2017 (UTC)
  • Support Support Tools for analyzing template use would be great. I would also like to see some way of distinguishing direct and indirect use of the template. We have many "helper" templates which were not meant to be ever used directly but only by other templates. It is often not possible to find templates used directly in the wrong namespace. For example, find commons files that directly call c:Template:Creator or one of the templates that redirects to it. Some of the changes might need changes to the database tables where the data is stored. --Jarekt (talk) 14:49, 7 December 2017 (UTC)
  • Support Support bdijkstra (talk) 20:00, 8 December 2017 (UTC)
  • Support Support --jdx Re: 20:06, 8 December 2017 (UTC)
  • Support Support X:: black ::X (talk) 11:22, 10 December 2017 (UTC)
  • Support Support Ruslik (talk) 18:15, 10 December 2017 (UTC)
  • Support Support Jack who built the house (talk) 21:34, 10 December 2017 (UTC)
  • Support Support Serhio Magpie (talk) 21:34, 10 December 2017 (UTC)
  • Support Support Lone Guardian (talk) 22:12, 10 December 2017 (UTC)
  • Support Support Psychoslave (talk) 08:09, 11 December 2017 (UTC)
  • Support Support Facenapalm (talk) 12:50, 11 December 2017 (UTC)
  • Support Support --Meno25 (talk) 15:45, 11 December 2017 (UTC)
  • Support Support Yes please! As someone actively developing templates I want to know how many articles use a given parameter or which articles have a local value instead of one from Wikidata — NickK (talk) 17:03, 11 December 2017 (UTC)

Vertical writing support

Edit proposal/discussion

  • Problem: Scripts that are written vertically are not supported by Wikipedia interface.
  • Who would benefit:
    Users of language with vertically written script, include:
    1. American Sign Language SignWriting users and the ASL test wiki on incubator. The vertical writing support will also allow the ASL wikipedia to be actually created.
    2. Traditional Mongolian Script users, including general Mongolian user in Inner Mongolia as well as various different situation the could be used by usersin Republic of Mongolia.
    3. Historical scripts like Manchu, Tangut, Meroitic Monumental Hieroglyphic are also vertically written, supporting vertical writing will allow them to be more easily inputted into wikisource.
    4. Some Chinese/Japanese users might also prefer reading content in vertical writing direction.
  • Proposed solution: Support vertical writing direction in Mediawiki.
  • More comments: See also mw:Requests for comment/Vertical writing support.
    The ASL incubator wiki have already implemented their own custom way to try to display vertical writing onto their site.
    Some Traditional Mongolian script users for Mongolian language have also started their own mediawiki site that have already implemented their own method to support vertical writing onto their site.
  • Phabricator tickets: phab:T353, phab:T11436
  • Proposer: C933103 (talk) 06:56, 7 November 2017 (UTC)

Discussion

  • I endorse this demand which is clearly a must have for the global goal of our community. --Psychoslave (talk) 11:01, 9 November 2017 (UTC)
  • I am not sure if I am allowed to call myself a member of "the community", but I fully endorse this idea 💡. Personally I created a similar idea for only vertical reading but this one would be a lot better, in fact I find it somewhat odd that the Classical Chinese Wikipedia 🏛 isn't written this way as there are no ancient texts written "left-to-right and up-to-down. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 11:19, 10 November 2017 (UTC)
    I have archived the other proposal as a duplicate. Please feel free to copy over your comments here in the discussion MusikAnimal (WMF) (talk) 19:22, 10 November 2017 (UTC)

Voting

Mark red links to other WMF wikis

Edit proposal/discussion

  • Problem: Link to not existing page in the same wiki is marked red. But link to not existing page on Commons, Wikisource etc. is not red and there is only one way how to recognize it - click on it..
  • Who would benefit: All editors adding links to other wikis (like {{commonscat}}), readers, maintenace editors.
  • Proposed solution: Now exists script, which marks links to pages without Wikidata item. Maybe somethink like that would serve to this request. Another possibility is checking all these links during page rendering, usually there is not more than one or two per page. This link then can have eg. class="dead-wikisource-link" in HTML.
  • More comments:
  • Phabricator tickets:

Discussion

  • It should be noted that they are also not "blue" (aka 'exists') links. They are light blue and indicate "external to this wiki". —TheDJ (talkcontribs) 14:29, 15 November 2017 (UTC)
  • Doing this might be a performance concern, as each wiki linked to would require opening a separate database connection to that wiki's database. There might also be edge cases of pages that don't exist directly in the database but "exist" thanks to an extension, language variants, or something like that. And, of course, it would only work for local wikis unless you went one step worse and did an API query like third-party wikis do when using Commons images. Anomie (talk) 15:01, 15 November 2017 (UTC)
  • This would probably require some kind of global links table, similar to how GlobalUsage works. Personally I doubt the benefits would be anywhere near the effort required. --Tgr (WMF) (talk) 00:15, 19 November 2017 (UTC)

Voting

Allow 'thanks' notification for a log entry

Edit proposal/discussion

  • Problem:

Users can not send 'thanks' notifications to one user who made a useful action only shown by a log.

  • Who would benefit:

Registered users.

  • Proposed solution:
  • More comments:

The Phabricator ticket phab:T60485 has been created almost 4 years ago: its development is a big task.

  • Phabricator tickets:

phab:T60485 (and its duplicates phab:T74601, phab:T112483, phab:T139443, phab:T152218...)

Discussion

Voting

Implement deferred changes

Edit proposal/discussion

  • Problem: Aside from edits blocked by the edit filter, vandalism and other damaging edits can still be viewed on pages for a short amount of time before they are reverted. According to a 2012 study by the Signpost, around 10% of damaging edits are seen by more than 100 readers, affecting the credibility of Wikipedia. The persistence of vandalism and BLP violations on low traffic biographies of living people is a lingering problem. Despite anti-vandalism bots and semi-automated tools, a substantial proportion of those damaging edits is not identified and reverted in a timely manner. (w:Wikipedia:Deferred changes).
  • Who would benefit:

Readers, as they are less likely to view vandalized pages. Vandal patrollers, who will have more time to revert edits.

  • Proposed solution:

Implement w:Wikipedia:Deferred changes, delaying suspicious edits from being viewed by readers until they have been reviewed by an editor, or reverted, similar to w:Wikipedia:Pending changes. Classification of suspicious edits can be done with edit filters, m:ORES and ClueBot NG's classification system.

  • More comments:

This project has been previously developed mainly by w:User:Cenarium, and has gained near unanimous support (except for one oppose) in a 2016 RfC on enwiki. Development appeared to have been active in December last year, however the project seems to be inactive as no changes have been made since then. Cenarium themselves have not made an edit on the English Wikipedia since April this year.

  • Phabricator tickets:

Tasks

Commits

The finished commits are struck out.

Basic commits
For notification
For simultaneous use of regular patrol
  • gerrit:328111 Make patrol of reviewed changes optional
  • gerrit:315109 Don't autopatrol autoreviewed users in protection-based configs
For easier reviewing
Required for change tags support
  • gerrit:315344 Change tags support (in FlaggedRevs)
  • gerrit:190656 Allow patrolling of tagged changes with minimalist RC patrol (this adds 'problem' tags)

(copied from w:Wikipedia:Deferred_changes/Implementation)

Discussion

Voting

  • Support Support Tgr (talk) 08:25, 28 November 2017 (UTC)
  • Support Support Mahir256 (talk) 08:38, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  • Support Support --Ymblanter (talk) 16:21, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:59, 28 November 2017 (UTC)
  • Support SupportAmmarpad (talk) 06:48, 29 November 2017 (UTC)
  • Support Support Ermahgerd9 (talk) 21:14, 29 November 2017 (UTC)
  • Support Support Gulumeemee (talk) 09:35, 30 November 2017 (UTC)
  • Support Support קובץ על יד (talk) 12:15, 30 November 2017 (UTC)
  • Support Support Nabla (talk) 23:21, 1 December 2017 (UTC)
  • Support Support Termininja (talk) 17:09, 2 December 2017 (UTC)
  • Support Support It has not been explained why this well-supported proposal was droppedNoyster (talk) 20:09, 2 December 2017 (UTC)
  • Support Support Galobtter (talk) 12:35, 3 December 2017 (UTC)
  • Support Support Tacsipacsi (talk) 13:31, 3 December 2017 (UTC)
  • Support Support I think this would improve our CV measures along with existing tools and new features like the Recent Changes Filters. enL3X1 ¡‹delayed reaction›¡ 15:41, 3 December 2017 (UTC)
  • Support Support LikeLifer (talk) 18:32, 3 December 2017 (UTC)
  • Support Support Giraffedata (talk) 22:24, 3 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 01:03, 4 December 2017 (UTC)
  • Support Support Doc James (talk · contribs · email) 02:34, 5 December 2017 (UTC)
  • Support Support Also make it easier to review changes from watchlist NessieVL (talk) 19:18, 5 December 2017 (UTC)
  • Support Support PamD (talk) 10:32, 7 December 2017 (UTC)
  • Support Support --Jarekt (talk) 14:55, 7 December 2017 (UTC)
  • Support Support Dolotta (talk) 17:56, 7 December 2017 (UTC)
  • Oppose Contra Although I share the concern on the problem, I don't agree with what I understand of the proposal. Rather than hiding this changes, it would also be possible to show a little banner "this version as not yet been reviewed and my contain false claim that such a review could clean", plus a toggle button to highlight on/off text which wasn't marked as reviewed and a link to the last "marked reviewed" version. This is rather close with some feature already in production, for example in the Esperanto version, but take the reverse approach to show possibly problematic last version by default. So, this is a soft "against", I do Support Support to address the problem. —The preceding unsigned comment was added by Psychoslave (talk) 08:20, 11 December 2017 (UTC)
  • Support Support — Luchesar • T/C 13:56, 11 December 2017 (UTC)
  • GA candidate.svg Weak support. I like the idea but please avoid creating one more patrolling/reviewing system. In my view it might be a good idea to start with matching FlaggedRevisions with ORES — NickK (talk) 17:12, 11 December 2017 (UTC)

Allow additional password recovery methods

Edit proposal/discussion

  • Problem: Right now the only way to recover your password is via email, while it is not even necessary to save an email address with your user settings at all.
  • Who would benefit:
    • Occasional authors who forgot their password and did not supply an email address or whose email address has changed meanwhile.
    • The Volunteer Response Team that quite frequent gets inquiries for lost passwords and can often only respond with "you will have to create a new account".
  • Proposed solution:
    • Create a password hash that can be saved separate from the email address.
    • Create other recovery methods, e.g. by "secret questions".
  • More comments:
  • Phabricator tickets:

Discussion

IMHO "secret questions" make everything more insecure, as finding the answer to "What's the birth name of your mother?" etc. is simple social engineering to break into someone else's account. "Password hashs": w:en:Template:Committed identity might be pretty close to that? Have you considered w:Multi-factor authentication? --AKlapper (WMF) (talk) 20:47, 8 November 2017 (UTC)

Two-factor authentification... Would a "normal user" (one of those who forget to update their email address in the settings) do that? --Reinhard Kraasch (talk) 21:48, 8 November 2017 (UTC)
Since the possible "secret questions" are often the same across many different sites, https://xkcd.com/792/ seems relevant too. Anomie (talk) 15:23, 9 November 2017 (UTC)
Two-factor makes account recovery harder, not easier. --Tgr (WMF) (talk) 04:52, 19 November 2017 (UTC)
I only read about it in its early days. It was confusing enough to make *everything* harder... I hope it improved. Gotta read about it again someday. - Nabla (talk) 23:32, 1 December 2017 (UTC)
  • Most of this is easily solvable by just more strongly encouraging people to register and verify their email address. Have you seen those websites where once a year they ask "is this still your email address?". Similar reminders and encouragements can be given. In my opinion not registering an email address should be an active opt-out, not a lazy default situation. —TheDJ (talkcontribs) 20:48, 9 November 2017 (UTC)
    • That's a good point, sending a reminder to said folks should be pretty easy. And yeah, we should encourage it more heavily on the registration page. Not an a hard failure, but at least a "HEY ARE YOU REALLY F'ING SURE? HAVING AN EMAIL IS A GOOD IDEA YO" would encourage people to not skip out. 😂 (talk) 00:27, 10 November 2017 (UTC)
    • Maybe specifically when an online email service provide is known to terminating or terminated their service, a reminder can be given to those people? C933103 (talk) 20:04, 11 November 2017 (UTC)
  • Maybe send a person who doesn't register their email every 3 months a central notice asking them to fill out their email address? ChristianKl (talk) 17:29, 11 November 2017 (UTC)
    • But the proposal was about email address that have been registered but changed.C933103 (talk) 20:04, 11 November 2017 (UTC)

A password hash is basically a password, except it's impossible to remember. How would that help? If you care about your account being lost, set an email address and keep it up to date. If someone can't be trusted to do that, it's hard to imagine they would keep better track of their identity hash. +1 to nagging people with significant editcount to set/update their email address instead. (Also, maybe allow setting a secondary recovery email address?) --Tgr (WMF) (talk) 04:52, 19 November 2017 (UTC)

I'm not a fan of the proposed alternative recovery methods. Perhaps something like adding a phone number might make sense, although that's also not without its flaw in terms of people stealing other people's phone numbers. BWolff (WMF) (talk) 22:49, 28 November 2017 (UTC)

It is now well established that SMS is not secure enough for 2FA, but using it (or voice calls) for password recovery would be even more dangerous as not even the password would be required to break into an account. Admittedly, intercepting and redirecting messages or calls may be well beyond the abilities of a regular script-kiddie, but that's not the only group of possible attackers. This may in particular put people living in countries with oppressive regimes under especially high risk. Of course, entering a phone number may (and should) be optional, but still not everyone would be aware of the security implications, with many people happily assuming that nobody else should be able to read their text messages or hear their voice calls. Last but not least, by implementing something like this, we'll be going in the exact opposite direction of where everyone else is going nowadays (or should/will sooner or later be going, anyway).
— Luchesar • T/C 23:18, 28 November 2017 (UTC)
  • Better look into how proofs are done at Keybase. You can use multiple proofs to verify an identity, and if the proofs gives a sufficiently high trust, then revoke of credentials can be initiated. Please don't use SMS, but if you do, ask for an alternate return path. Note also that if an attacker asks for new credentials, then he already has a working attack vector for the special page at Wikipedia. — Jeblad 01:18, 11 December 2017 (UTC)

Voting

  • Support Support David1010 (talk) 11:03, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  • Oppose Oppose Regular reminders of emails and messages are good, the answer or hash to restore is not safe. Third party login (OAuth) can be reviewed. There is no more reason to retrieve a lost account.--YFdyh000 (talk) 14:51, 28 November 2017 (UTC)
  • Oppose Oppose While I recognize the issue, the suggested alternatives are not safe. I would be much more in favour of a solution where (selected) admins / power users can directly set a new password for users who cannot request a new password via mail. --Rcdeboer (talk) 15:23, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:00, 28 November 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose “Secret questions” are a disaster from security standpoint, especially if they would be mandatory. +1 for promoting use of e-mails and possibly also committed identity. The latter should also help when an account had already been overtaken by an adversary, though, admittedly, it's not exactly very user friendly (extending the documentation might help somewhat here). After all, the only safe user is the one who is aware of the security hazards around and makes reasonable effort to protect themselves. If they can't be bothered to do this, well, it's an indication that they don't value their (current) account that much anyway. And Wikipedia isn't like a cloud storage or web-based e-mail where a lost account means also lots of lost information, too (users with special rights, e.g. sysops, are obviously a different case, but the elevated rights do also come with an expectation of an elevated level of responsibility, so such users actually have no excuse to be lazy about keeping their accounts safe). — Luchesar • T/C 22:27, 28 November 2017 (UTC)
  • Support Support Sebastian Wallroth (talk) 07:31, 29 November 2017 (UTC)
  • Support Support (only Two factor authentication) ZellmerLP (talk) 22:18, 29 November 2017 (UTC)
  • Oppose Oppose Not safe! --Kusurija (talk) 22:21, 29 November 2017 (UTC)
  • Support Support קובץ על יד (talk) 12:37, 30 November 2017 (UTC)
  • Support Support Support the concept (better recovery), not any particular implementation. Nabla (talk) 23:27, 1 December 2017 (UTC)
  • Oppose Oppose the proposed solutions, but do support the idea of finding other ways for people to reset their accounts. 😂 (talk) 01:32, 2 December 2017 (UTC)
  • Oppose Oppose (Support Support reminding users about their email and stressing that they should add an email tho.) --Terra  (talk) 07:04, 2 December 2017 (UTC)
  • Oppose Oppose --Termininja (talk) 17:10, 2 December 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose, as secret questions would compromise the security of the accounts using them and the project itself when used by users holding relatively advanced permissions. --Kostas20142 (talk) 18:30, 3 December 2017 (UTC)
  • Support Support Could consider GPG keys verification, SSH key pair verification, or other methods, passwords are a bit 1990s perhaps? Gryllida 00:47, 4 December 2017 (UTC)
  • Oppose Oppose per above - It's not hard to find someone on a website and even if they don't have their Mums name on a website it can still be found by other means. –Davey2010Talk 17:14, 4 December 2017 (UTC)
  • Oppose Oppose no 'secret' questions. I'd support if it were sending password recovery by text or something. NessieVL (talk) 19:26, 5 December 2017 (UTC)
  • Support Support the general concept of improved password reset options, but like others, concerned about some of the specific solutions, so not necessarily supporting any specific solution.--Sphilbrick (talk) 15:16, 6 December 2017 (UTC)
  • Oppose Oppose secret question makes account more prone to be compromised because people will use simple family/personal/work related answers so as not forget and these data is easier to be compromised by several methods. This is good faith proposal, but its effect will create more problem than it intend solves. Ammarpad (talk) 10:50, 7 December 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose, As I already had many unrecoverable problems with all these methods (secret questions, mobile etc.) in other communities and sites. We just have to warn user that without email is probably unlike to recover hers/his password. --Xoristzatziki (talk) 20:51, 9 December 2017 (UTC)
  • Oppose Oppose Klaas `Z4␟` V:  22:23, 10 December 2017 (UTC) one would create a possibility to hack user/pw combinations
  • Support Support Ldorfman (talk) 16:54, 11 December 2017 (UTC)
  • Oppose Oppose, I think my mother's maiden name or my father's middle name are way easier to find out (our harassers have found information that was hidden much better) than to hack my email — NickK (talk) 17:16, 11 December 2017 (UTC)

Only show mainspace pages in Special:WantedPages

Edit proposal/discussion

  • Problem: As part of the Special Pages in every wiki, there is a section called Special:WantedPages. There, it lists non-existing pages by number of incoming links, in order to know which of these are the most desired. One problem is that non-articles are shown. The list includes files, Talk pages, project pages, etc., that are not useful to most people.

    On some wikis, when these pages are actually created, they are still shown at Special:WantedPages. This has caused the wanted pages list to become more and more useless over the years.

    Additionally, the places that the incoming links originate are also not necessarily legitimate links. Pages that are mentioned in a template are counted as a link with every template transclusion. It would be more useful to count actual direct links. To make matters worse, pages that are checked with {{#ifexist: are also counted as a link (that is the subject of this proposal). This causes false positives to show up. For instance, at w:en:Special:WantedPages, the top result (at the time of writing) is w:en:Talk:Jay Obernolte/GA1. In reality this is not really a wanted page at all, rather a popular template is checking whether or not it exists.

  • Who would benefit: Users who are looking for articles to write, or are interested to know what popular topics are not covered on the wiki.
  • Proposed solution: Only include mainspace pages, or at least offer options to pick a namespace. Secondly, only direct incoming links from the matching namespace should be counted. Finally, assuming the queries of this Special page can be made more efficient, it should refresh the list more often so that pages that now exist are removed.

Discussion

@Pencho15: Could you update the summary of this proposal by summarizing the current issues that you see? "Solve Wanted Pages issues" is a bit vague as it could be any issues... Thanks in advance! --AKlapper (WMF) (talk) 20:50, 8 November 2017 (UTC)

  • @AKlapper (WMF): Done, I hope its better. --Pencho15 (talk) 00:53, 9 November 2017 (UTC)
    • @Pencho15: This still needs further explaining. Let's take a look at en-wiki: there we have en:Special:WantedPages, en:Special:WantedFiles, en:Special:WantedTemplates and en:Special:WantedCategories. The pages are still updated (despite some of their headers claiming otherwise), the WantedPages list was lastly updated on 2017/10/26. So what do you exactly propose? More frequent actualization of WantedPages to eliminate newly created pages? And filtering out everything outside the Main namespace? --Vachovec1 (talk) 11:18, 11 November 2017 (UTC)
      • @Vachovec1: Sorry, my first language is not english. Perhaps you may help me on how to make this clearer.
  • In the case of the pages you mention, en:Special:WantedFiles, en:Special:WantedTemplates and en:Special:WantedCategories all work perfectly fine, and I don't think they need any improvement, they are useful and updated adequately. I understand it is the same on every other wiki, and I know it is the case in the Spanish one.

    My only request is with en:Special:WantedPages, if you look at the english page, all the top entries and most of the page is full of Talk Pages and Assessments. Those are not encyclopedical pages and are not actually needed in the Wikipedia. If they are sometime, then they will be done, but should not appear on this list which is meant to indicate us the pieces of information missing from Wikipedia.

    Besides Talk pages and assessments, you also find some wanted files that should not be there, as, since you have indicated, they have their own section. A further problem is that those listed files that have already been created do not dissapear from this list after it is updated, and they remain there forever. Spam reports and user pages also appear in some wikis, making all this section pretty useless, when it could be very useful as the Wated Categories, Wanted Templates and Wanted Files pages are.

    If you look at the current list in the english wiki, the first entry that should actually be there is the number 14 of the list, Rehavia Rosenbaum, and only that one and articles number 15, 16, 21 and 24 are actual encyclopedical entries that should be listed.

    So my proposition is to update that single en:Special:WantedPages section in all wikis to make it useful changing its configuration so that Files, Talk Pages, Assessments, Spam reports, Categories, Templates, User Pages and all other kind of special entries that are not actual articles dissapear from it. Perhaps you could help me on how to phrase this in a simpler way in english so my proposition is clear? --Pencho15 (talk) 06:09, 12 November 2017 (UTC)

    So, problem: In Special:WantedPages, wanted article are entangled together with other type of wanted pages, including talk pages, templates, non-content pages and Wikipedia pages.

    Thus, proposed solution: Make a new special page that would only display wanted pages from the main namespace. C933103 (talk) 21:21, 12 November 2017 (UTC)

    • @C933103:. Hello. I wasn't notified of your answer, sorry I did not see it before, but yes, your edition is perfect, thank you very much for making it. --Pencho15 (talk) 02:32, 30 November 2017 (UTC)
  • @Pencho15: I am familiar with the issues with Special:WantedPages, so I have copyedited your proposal to make it more clear what the issue is, and how it could be fixed. Hope this is okay!

    To elaborate on what I know: A while back I actually looked at the code for Special:WantedPages. It suffers from many problems, but the main one is that the query is very inefficient. If we narrowed it down to the mainspace, that should help. The other major issue is elaborated at the proposal Stop ifexist checks from appearing in Special:WhatLinksHere. This causes false positives to show up in the list.

    Also note that if we fix WantedPages as proposed, we should probably also add the necessary options to WhatLinksHere, too (exclude ifexist checks). Otherwise the number of links that are shown in WantedPages will not match the number of links shown at WhatLinksHere. MusikAnimal (WMF) (talk) 01:45, 21 November 2017 (UTC)

imo, We should allow filtering by namespace for all query special pages (That is do the query once for each namespace, and store the results for each namespace, and then add an index on qcc_namespace so we could efficiently show them). Bawolff (talk) 22:51, 28 November 2017 (UTC)

Voting

  • Support Support Jenks24 (talk) 09:23, 28 November 2017 (UTC)
  • Support Support But the previous functionality should be preserved as well. Sometimes users wants to know also missing/redlinked help pages and other namespaces. maybe there should be better a namespace filter or something. Dvorapa (talk) 09:29, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  • Support Support Sadads (talk) 13:42, 28 November 2017 (UTC)
  • Support Support Stryn (talk) 16:20, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:00, 28 November 2017 (UTC)
  • Support Support --Pencho15 (talk) 02:29, 30 November 2017 (UTC)
  • Support Support - yona B. (D) 08:20, 30 November 2017 (UTC)
  • Support Support Dromedar61 (talk) 21:05, 30 November 2017 (UTC)
  • Support Support Ninovolador (talk) 22:02, 30 November 2017 (UTC)
  • Support Support Metrónomo-Goldwyn-Mayer 22:04, 30 November 2017 (UTC)
  • Support Support DonBarredora (talk) 01:15, 1 December 2017 (UTC)
  • Support Support --Superchilum(talk to me!) 20:54, 1 December 2017 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 15:43, 3 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 01:05, 4 December 2017 (UTC)
  • Support Support With namespace filtering per Dvorapa JAn Dudík (talk) 09:12, 4 December 2017 (UTC)
  • Support Support or maybe show non-mainspace counts on the side? NessieVL (talk) 19:36, 5 December 2017 (UTC)
  • Support Support Jmmuguerza (talk) 20:00, 8 December 2017 (UTC)
  • Support Support Jack who built the house (talk) 21:07, 8 December 2017 (UTC)
  • Support Support Serhio Magpie (talk) 21:49, 8 December 2017 (UTC)
  • Support Support adding a namespace filter NaBUru38 (talk) 22:44, 9 December 2017 (UTC)
  • Support Support adding a namespace filter --Kaganer (talk) 22:47, 9 December 2017 (UTC)
  • Support Support for either adding a namespace filter or create a separate page that lists only the redlinks (and their number!) for pages in the article-namespace (maybe also only those which are placed in the article-namespace, i. e. also are linking from there). If a filter is used, also further filter options would be interesting (filtering out IPs or subpages) X:: black ::X (talk) 13:59, 10 December 2017 (UTC)
  • Support Support Ruslik (talk) 18:23, 10 December 2017 (UTC)
  • Support Support adding a namespace filter. I might be interested in wanted Help namespace pages either, for example — NickK (talk) 17:18, 11 December 2017 (UTC)

Use map for Nearby

Edit proposal/discussion

  • Problem: Special:Nearby is not really useful in its current form – it displays a list with some articles, but the user can neither broaden the area nor select a completely other place (or select any place if the browser doesn’t have the necessary API).
  • Who would benefit: Users not having the Android or iOS app who want to use Nearby.
  • Proposed solution: Use a map on Special:Nearby (or let the user chose between the list and map format).
  • More comments: Maybe a search field with traditional GET request could be added to make this function usable at all for JavaScript-less users.
  • Phabricator tickets:
  • Proposer: Tacsipacsi (talk) 16:33, 17 November 2017 (UTC)

Discussion

I'd also would just love to make it possible to easily enable this layer when you click on a coordinate in an article. I see it as just another navigation method. If you want, you should be able to just keep clicking on, deeper and deeper into Wikipedia. An article, a map, annotations in an image, or a timeline, it shouldn't have to be an article if I want to go to a related article ! —TheDJ (talkcontribs) 14:12, 18 November 2017 (UTC)

I think it should be opt-in in articles, as it might not be useful everywhere (e.g. if there’s a map with the US national parks, there should be only the national parks on the map, not every article about places in the US). Also it’s less useful as wikis may not use Kartographer, and it’s nearly impossible to develop it for all existing map techniques. Otherwise it would be great, but wikis should change to Kartographer to let it work. —Tacsipacsi (talk) 14:30, 18 November 2017 (UTC)

As a kind of straw man demo, i worked up a bare bones example of putting search results on a map combined with using search's nearcoord keyword to restrict results to the area currently being viewed some time ago when we first released the geo keywords for search. This is of course not a solution to this request, but perhaps something to start thinking about how much data we have available (although this limits markers to 50 at a time so they don't overlap so much, and it's currently hard coded to enwiki but could be changed). EBernhardson (WMF) (talk) 21:58, 28 November 2017 (UTC)

What about linking the wiwosm/osm-on-ol-tool (description) and metawikimedia:WikiMiniAtlas? --X:: black ::X (talk) 14:57, 10 December 2017 (UTC)

I would rather imagine a Kartographer-based solution as it’s already on-wiki (and its map looks much better IMO). —Tacsipacsi (talk) 22:39, 10 December 2017 (UTC)

Voting

Remember site notice dismissals

Edit proposal/discussion

  • Problem: When browsing Wikipedia with Firefox in private mode, the same site notices pop up again in each new session after logging in, presumably because dismissing site notice(s) is recorded in (a) cookie(s) that get discarded after closing Firefox. This also happens when using multiple browsers or devices.
  • Who would benefit: Registered users using session cookies and/or multiple browsers or devices.
  • Proposed solution: Record the dismissal of a site notice on the server as part of the user data so that this information is preserved between sessions and identical in multiple browsers and devices.
  • More comments:
  • Phabricator tickets:

Discussion

  • The dismissal works for me. Do you have some browser add-on installed that deletes cookies at the end of the session? Anomie (talk) 00:34, 20 November 2017 (UTC)
  • Storing the dismissal as part of user data would be useful even to those of us who don't use private mode. I view Wikipedia on a dozen browsers spread across nearly as many devices, and playing whack-a-banner gets tiring after a while. --Carnildo (talk) 23:31, 28 November 2017 (UTC)

Voting

Different password for changing email

Edit proposal/discussion

  • Problem:

Two-step login has its own problem such as

  • difficulty to log in when you don't have access to your phone or key generator.
  • some gadgets such as AWB and HUGGLE doesn't support it

so some users do not migrate to two-step login, on another hand we afraid of hacking our user account. In my opinion, If some one's account is hacked the hacker shouldn't simply change email. if changing email at user preference has separated password it will help the user to reset his/her account by the email.

  • Who would benefit:

The hacked user account can be restored by the email which has other password and the hacker doesn't have access to changing the email.

  • Proposed solution:

Define a different password for changing the email to make hard the hacking process of an account.

  • More comments:
  • Phabricator tickets:
  • Proposer: Yamaha5 (talk) 20:21, 8 November 2017 (UTC)

Discussion

@Yamaha5: Are you aware of any websites with a log-in that offer such an option, and could you please name one? I can see that w:Multi-factor authentication can be cumbersome sometimes (and so can be entering a password in general but safety and security comes with some costs). However I don't see yet why having to remember two passwords instead of one would be a better solution. --AKlapper (WMF) (talk) 20:54, 8 November 2017 (UTC)

@AKlapper (WMF): my bank's website after inputting the first password asks some question which is two-step password without a key generator. as I said Two-step password with a key generator has its own difficulty. you can check the statistics which shows how many percentages of the users migrated to it. finally, we have many users which aren't migrated to two-step password and we should concern their security and we can't force them.Yamaha5 (talk) 21:14, 8 November 2017 (UTC)
@MaxSem:: mw:Manual:Bot passwords is useful for huggle but for AWB I can't use it also I want to secure my account if it is hacked I can restore the password by email. now hackers after hacking the account at the first they change the email! Yamaha5 (talk) 21:17, 8 November 2017 (UTC)
@AKlapper (WMF): Now w:Multi-factor authentication is only active for sysop's and non-sysop users can't use it Yamaha5 (talk) 10:52, 10 November 2017 (UTC)
@Yamaha5: actually some usergroups other than sysops are allowed to use it, just thought I correct that statement. Zppix (talk) 17:30, 12 November 2017 (UTC)
@Zppix: thank you for your correction. please mention which groups have this access? Yamaha5 (talk) 17:32, 12 November 2017 (UTC)
@Yamaha5: Administrators, Bureaucrats, Oversighters, Central notice administrators, Global renamers, WMF Office IT, WMF Support and Safety Zppix (talk) 17:53, 12 November 2017 (UTC)
most of them have sysop rights and are upper level than sysopsYamaha5 (talk) 18:09, 12 November 2017 (UTC)
2017 Community Wishlist Survey/Miscellaneous/2 factor authentication for all seems like a better place to direct efforts to. --Tgr (WMF) (talk) 23:14, 19 November 2017 (UTC)

A different password does little to do hacking harder; also, if someone hacks your account it does not make too much difference (wrt the amount of damage they can do) whether they can change your email address or not. And as long as it happens rarely, we can just rely on manual recovery. --Tgr (WMF) (talk) 23:09, 19 November 2017 (UTC)

I'm of the opinion that multiple different passwords for different things would be too confusing to most users. BWolff (WMF) (talk) 22:53, 28 November 2017 (UTC)

Voting

A social wikipedia

Edit proposal/discussion

  • Problem: actually all contact with the other users it's only with discussion pages and articles, but isn't possible to follow the actions of users who problably are your wikifriends
  • Who would benefit: users with a long experience on wiki
  • Proposed solution: create a social connections with users. Possibility to check easily what they do and what they modify.
  • More comments:
  • Phabricator tickets:
  • Proposer: Codas (talk) 21:16, 8 November 2017 (UTC)

Discussion

  • Is this different than Provide a 'user-watchlist' that lists all recent contributions of a set of users which was voted into the top 10 in the 2015 survey? That functionality was investigated by the CommTech team and determined to be too easily abused by bad actors to be implemented. --BDavis (WMF) (talk) 06:08, 9 November 2017 (UTC)
    • It seems to be somewhere between that and Facebook-style friending. Anomie (talk) 15:26, 9 November 2017 (UTC)
  • wikimedia projects have many elements of social networks, even if some here vehemently deny this. I agree with the Proposer that it i s almost impossible to keep track of "friends", especially if you have many on busy projects. How to do this without enabling bad actors is another question. Ottawahitech (talk) 19:38, 9 November 2017 (UTC)
  • This is the problem of a wiki community itself. You can just create user categories for users from specific town, whith specific hobbies and working or school background. I have proposed the creation of such system years ago on cs.wp, but I had no stamina to discuss it. And it is also not about stamina, but also about free time, as you can discuss two month and you should argue with people, who say this is not needed, wikipedia is not social, or it is a load for WMF servers (what a bull...).--Juandev (talk) 21:07, 9 November 2017 (UTC)
  • One of the big part of why the user-watchlist was turned down was because it allows you to follow someone even if they don't want that you follow them. If you change the feature to be like friending on Facebook, people can easily prevent other people from following them. That way the feature can't be used for stalking. ChristianKl (talk) 23:24, 10 November 2017 (UTC)
@Codas: - what do you think of ChristianKl's comment? Is there a way you have in mind for doing this? There's no actionable way to do this defined in the proposal and I'd have to close it if it's still the same within the next 24 hours. Thanks. -- NKohli (WMF) (talk) 20:03, 20 November 2017 (UTC)
  • I think the best way is to consider connections like facebook. You can ask to follow someone and you keep a connection with him. So you can see what he does, which pages modify and articles create. So you can help him in some situations. Or for example you can remember a specific user for some arguments. For this reason should be good to create a profile with interests in wikipedia. But le't's keep discussion on first idea... --Codas (talk) 20:35, 20 November 2017 (UTC)
But user contributions are already public. How would this be different? I'm trying to understand what you mean by "create a social connections with users" exactly. Please clarify in the proposal. -- NKohli (WMF) (talk) 20:43, 20 November 2017 (UTC)
Yes they are public, but I think it’s necessary to have a link in your account to watch your connections. Actually you have to remember who is and search like all users. In this case is more easy to remind and keep,in touch. Or maybe a page with all modify from your favorite users. --Codas (talk) 07:22, 21 November 2017 (UTC)
The proposal still does not say what you mean by "social connection". Where will the other person's activity show up? In the watchlist? This proposal is very similar to User watchlist, as BDavis pointed out above. Several users have expressed concerns about this. -- NKohli (WMF) (talk) 23:59, 21 November 2017 (UTC)
  • Comment Comment Isn't this basically Facebook? As of now the only real difference between Wikipedia ans Facebook is that Wikipedia requires references, so I'm opposed to such an idea. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:12, 29 November 2017 (UTC)
  • Comment Comment The real mission isn't to be Facebook, but use the social connection to help each other or add your skills with similar users. --Codas (talk) 08:59, 30 November 2017 (UTC)
  • "Social" does not equate to "same as facebook". Facebook have not invented nor defines what social is. Actaully, is Facebook "social", really? So my support vote does not go for facebook-y whatchlists, or whatver features. It goes to: study what can be done so that "comunity" makes sense (because I doubt it does in most "social media"). Maybe we're already doing those studies, if so, this is moot. - Nabla (talk) 23:59, 1 December 2017 (UTC)
  • Potentially if this is abuse prone, require the second party consent for the first party to follow them. Gryllida 00:49, 4 December 2017 (UTC)
  • This is both the best and worse tool for bettering climate on-wiki. The best because it might actually work, people are social animals, and the worse because it invites to group building and stalking. Create a group of users you are following, and another group of users following you. Both groups should be public. Limit the number you can follow that does not follow you back. Allow the number of coreferences to grow if you cooperate with the users on some articles. Allow a user to block another user from following {him|her}self. — Jeblad 00:53, 11 December 2017 (UTC)

Voting

  • Oppose Oppose Go to Facebook if you want to friend G41rn8 (talk) 17:55, 9 December 2017 (UTC)
  • Oppose Oppose This is contrary to the purpose of Wikimedia sites, and would violate foundational policy over on en.wp. No. MER-C (talk) 01:46, 28 November 2017 (UTC)
  • Oppose Oppose per MER-C. Mahir256 (talk) 08:36, 28 November 2017 (UTC)
  • Support Support This is similar to 2015 top 10 wish, but I must support it. Ability to watch user actions of novices or vandals would be super-useful even if allowed only for e.g. admins (because of high risk of abuse) Dvorapa (talk) 09:33, 28 November 2017 (UTC)
  • Oppose Oppose Violates our privacy policy. --Liuxinyu970226 (talk) 13:11, 28 November 2017 (UTC)
  • Oppose Oppose Adding social networking functions probably would not help in the creation of content, since we already have talk pages and email with which to communicate and share usernames for actual social networks which aren't encyclopedias. It would also have probably adverse effects on Wikipedia Zero, and complicate/violate the WMF privacy policy. Jc86035 (talk) 14:16, 28 November 2017 (UTC)
  • Oppose Oppose WIKI is not FB. — Draceane talkcontrib. 18:27, 28 November 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose There are social media for that. --Sannita - not just another it.wiki sysop 19:45, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:02, 28 November 2017 (UTC)
  • Oppose Oppose because of privacy impacts Libcub (talk) 05:01, 29 November 2017 (UTC)
  • Support Support People are using Facebook right now, because they miss social media features in the Wikipedias. A lot of article discussion happens separated fro articles on Facebook. Sebastian Wallroth (talk) 07:34, 29 November 2017 (UTC)
  • Oppose Oppose – Completely unnecessary. This is not the purpose of wikipedia. Natureium (talk) 19:27, 29 November 2017 (UTC)
  • Oppose Oppose Terrible idea. Use Facebook. Nick Moyes (talk) 23:00, 29 November 2017 (UTC)
  • Oppose Oppose wikihounding extension. Wikipedia is not social media. --Ailura (talk) 07:16, 30 November 2017 (UTC)
  • Oppose Oppose Leave social tools to social media, please. --L736Etell me 08:18, 30 November 2017 (UTC)
  • Oppose Oppose M11rtinb (talk) 11:03, 30 November 2017 (UTC)
  • Oppose Oppose per Liuxinyu970226 and others. --Vachovec1 (talk) 17:56, 30 November 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose as this is against fundamental essence of Wikipedia. Ammarpad (talk) 23:15, 30 November 2017 (UTC)
  • Oppose Oppose because everyone else is doing it. Daniel Case (talk) 03:18, 1 December 2017 (UTC)
  • Oppose Oppose Wikipedia is an encyclopedy, not a social mediaBraveheidi (talk) 07:55, 1 December 2017 (UTC)
  • Support Support Theklan (talk) 18:43, 1 December 2017 (UTC)
  • Oppose Oppose WNSN. --Superchilum(talk to me!) 20:55, 1 December 2017 (UTC)
  • Support Support support noting that "social" must not equate to "same as facebook". Nabla (talk) 23:54, 1 December 2017 (UTC)
  • Oppose Oppose Szoltys (talk) 12:07, 2 December 2017 (UTC)
  • Oppose Oppose Wikipedia like social media? No, Wikipedia is an encyclopedy. Ented (talk) 14:43, 2 December 2017 (UTC)
  • Oppose Oppose --Termininja (talk) 17:24, 2 December 2017 (UTC)
  • Oppose Oppose As Ented. Wiklol (talk) 21:37, 2 December 2017 (UTC)
  • Oppose Oppose Let's not add things that distract users from working with the content. Matěj Suchánek (talk) 10:29, 3 December 2017 (UTC)
  • Support Support Gryllida 00:49, 4 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 01:22, 4 December 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose - We are not Facebook. –Davey2010Talk 17:02, 4 December 2017 (UTC)
  • Oppose Oppose If you have an urge to communicate about Wikipedia, that's what the WP:IRC is for. NotTheFakeJTP (talk) 19:15, 4 December 2017 (UTC)
  • Oppose Oppose Wikipedia isn't a social network. -glove- (talk) 16:20, 6 December 2017 (UTC)
  • Oppose Oppose : Wikipedia is just an encyclopedy. —— DePlusJean (talk) 05:48, 8 December 2017 (UTC)
  • Support Support I think that this idea sounds excellent. we do need this. Sm8900 (talk) 16:48, 8 December 2017 (UTC)
  • Oppose Oppose, this will be much more interesting for stalkers than for good-faith users — NickK (talk) 17:34, 11 December 2017 (UTC)

Improve the Score extension

Edit proposal/discussion

  • Problem: The Score extension is not particularly easy to use due to not having a graphical input option, and has not been updated in almost four years. Furthermore, the rendering is pixelated and PNG instead of SVG; and the image is hard to resize (a paper size has to be specified) and align (a div has to be made to align it and the audio player to anything). In addition, the double bass and possibly some other instruments are not playable. These are all limiting factors in its use, and partly as a result it is only used on 396 English Wikipedia articles and 873 English Wikisource pages, when it could be used to a much greater extent than is currently possible or desired. It is indisputably inferior to the MuseScore.com web app (closed source based on open-source software), which does not have any of the aforementioned problems, has an animated and scrolling score (entirely SVG), and was probably written by a few interns and MuseScore's permanent staff of three people.
  • Who would benefit: Wikipedia and Wikisource editors, and readers of music-related articles
  • Proposed solution: Any or all of: improving the extension so that the output is an SVG file and can be easily resized and aligned; adding an OCR helper for printed and engraved scores like the DJVU reader on Wikisource; allowing MIDI/MusicXML/MuseScore files from Commons to be read by the extension; adding a visual editing function; replacing the current extension with MuseScore-based renderer/playback.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jc86035 (talk) 15:45, 18 November 2017 (UTC)

Discussion

Voting

Kartographer improvements

Edit proposal/discussion

  • Problem: The development of the Kartographer tool should be continued. Main wishes are map internationalization (exchange of Latin and non-Latin labels) and the addition of zoom level 19. Minor wishes are the move of all controls to the left map side like nearby, full-screen, layers controls, adding an additional zoom-level control, several pushpin symbol improvements like usage of short strings, 3-digit numbers etc. A nearby map mode showing links to nearby articles should be added. Kartographer documentation should be improved.
  • Who would benefit: All wikis including Wikipedia, Commons, Wikidata, Wikivoyage, etc.
  • Proposed solution: OpenStreetMap supports map internationalization with, for instance, name:en tag in case of non-Latin names. International names can be fetched from Wikidata, too. Maybe a collaboration with OSM programmers is useful. Instead of complete graphical pushpins, pushpins with a text box should be added.
  • More comments: It is very difficult to estimate the developing time. I think minimumly a year, better two years are needed.

Discussion

It's a timely proposal. I would like to list two additional features, although not sure whether they are major or minor:

  • We need the functionality of reading and displaying POIs from several articles. The current version of Kartographer would only allow to display objects contained in one article. Retrieving information from multiple articles is needed for lists on Wikipedia (e.g., cultural heritage) and for travel guides (Wikivoyage).
  • We should be able to download coordinates as GPX or similar files for offline use. This feature is especially important for Wikivoyage, because travel guides are often used offline, but it may also have broader implications, because it is a general tool for re-using geo-data collected in Wikimedia projects.

--Alexander (talk) 19:17, 18 November 2017 (UTC)

Supporting this. It is unfortunate the development has been stopped.--Ymblanter (talk) 20:11, 18 November 2017 (UTC)
  • Can only support this and the general return to the development of Maps as one of the people involved in making the Russian Wikipedia the first major Wikimedia project to include interactive maps instead of Geohack links as a default option. It was really sad to see that just after we got the community consensus on this, the entire Maps team was set off IIRC. stjn[ru] 00:01, 19 November 2017 (UTC)
  • I would very much like for this to happen, and note that phabricator:tag/map-styles has a lot more styling bugs that need to be fixed. Jc86035 (talk) 01:44, 20 November 2017 (UTC)
  • I've added T155601 to the list above. This bug tracks the bugs the development team (or what's left of it) think are the most important. - Gareth (talk) 09:17, 22 November 2017 (UTC)
  • I've added T181604 to the list above. A pain for it:voy since long time. --Andyrom75 (talk) 08:07, 29 November 2017 (UTC)
  • I see a few issues with our current handling of maps, not all of which have existing Phabricator tasks. Kartographer seems to handle the cases where a territory is divided into multiple, colour-coded subregions poorly - to the point where even relatively-simple regions like voy:Adirondacks are using static maps instead of dynamic maps and (de-facto) a "star" featured article still needs a hand-made static map. GPX tracks (like the trail traced onto voy:Oregon Trail) need to be converted to GeoJSON and we don't have a good means of storing these (they're either in the article itself or on an external wiki); the switch to GeoJSON also means there's no easy way to download the trace from the article and load it onto a handheld GPS (as Garmin is natively GPX). There's no way to turn off OSM's POI's (cities, villages, hotels, museums...) if we want to replace them with our own, our POI markers are just generic circle-pointers instead of AIGA-style type-specific icons for food, lodging and attractions. The sequentially-numbered icons stop at 99, 99, 99... and the dynamic map provides no suitable fallback for the print version. Dynamic maps are a great idea, but they need work before they will ever replace the painstaking creation of hand-made static cartography. K7L (talk) 16:10, 29 November 2017 (UTC)

Important note from Community Tech

Hi everyone, There's a lot of excitement and support around this proposal, so I want to make sure that people understand the scope of what Community Tech will be able to do, if this ends up in the top 10.

This proposal and the discussion comments include a bunch of feature requests -- some small, some really big -- and the proposal specifically mentions this taking a year or two of the team's work. That level of a request is out of scope for the Community Wishlist Survey. We're responsible for addressing the top 10 wishes in 2018, so if this wish gets into the top 10, it'll be 1 out of 10 projects that the team works on. We can't turn the Community Tech team into a Maps team for a year. :)

It's hard to estimate the amount of work that's involved in all of these tickets and requests; that's investigation work that we would have to do as the beginning of the project. What I can say now is that we can investigate all the requests, report back with an explanation of what's feasible, and then do the work that we can feasibly do, given the size of the other 9 wishes in the top 10. We take all the top 10 wishes seriously, so it won't be a few easy fixes and then we blow the rest off; we'd want to make a significant improvement that honors the spirit of this proposal.

I should have posted about this before voting started -- RolandUnger, I'm sorry for the oversight. Let me know if folks have any questions. Thanks! -- DannyH (WMF) (talk) 20:34, 28 November 2017 (UTC)

@DannyH (WMF): Would the WMF consider bringing back the Maps team? Jc86035 (talk) 07:55, 29 November 2017 (UTC)
Maybe if this ends at #1 there is ;) —TheDJ (talkcontribs) 14:29, 29 November 2017 (UTC)
As far as I know, there aren't any plans to bring back a specific Maps development team. And -- sorry to contradict TheDJ -- I want to make it clear that voting for this wish will not lead to a Maps team. Decisions about a full-time Maps team are totally separate from the wishlist survey. But voting for this wish does mean that the Community Tech team will do some work on maps next year, which is exciting, and I'm sure we'll make some good improvements. -- DannyH (WMF) (talk) 18:08, 29 November 2017 (UTC)
DannyH (WMF), the goal of this proposal is having at least some of the pending Kartographer issues fixed. Independent of that, it would be good to know how to start a discussion about the full-time Maps team, which is clearly wished for by the community. --Alexander (talk) 19:32, 29 November 2017 (UTC)
@DannyH (WMF) you are not contradicting me. I'm saying that anything that ends up in the top 3 of the wishlist, wether or not the com tech team can take on the task or not, is likely to shape long term decision making in some form or another ;) —TheDJ (talkcontribs) 20:13, 29 November 2017 (UTC)
This proposal shows, what the community is eagerly awaiting for. Every mobile app is asking for access to the owners position. Every information is geotagged nowadays. Coordinates and the presentation on a map is essential to every information system. We maintain lists of e. g. monuments of every town or region on Wikipedia. Proper map features an the integration to the website (including the mobile version) are really important. -- DerFussi 21:25, 30 November 2017 (UTC)
Many thoughts, proposals and wishes are contributor orientated. We should think about the users and readers as well - because they do not vote here, because they do not know the meta wiki. -- DerFussi 21:42, 30 November 2017 (UTC)

Voting

Stop ifexist checks from appearing in Special:WhatLinksHere

Edit proposal/discussion

  • Problem:

#ifexist is a very useful tool - it lets you check if a page exists in template logic. However, doing the check also makes a link appear in Special:WhatLinksHere for the page whose existence was checked - and that causes problems for Wikimedians who are checking links to disambiguation pages, as there's no way to stop the link from appearing. This is part of a wider issue, as doing the same check in Lua also causes this problem.

  • Who would benefit:

People writing template code who want to use #ifexist to provide extra functionality, but can't. People doing disambiguation checking while people are using #ifexist statements.

  • Proposed solution:

Either stop #ifexist from creating a link in Special:WhatLinksHere, or create a new magic word that does the same as #ifexist without creating the link.

  • More comments:

This is a long-running problem: phabricator:T14019 was filed in 2007! It was also included in the 2015 Community Wishlist. I came across this more recently, when trying to use #ifexist to check for location redirects in Wikidata infoboxes, which caused problems e.g. see en:Wikipedia:Village_pump_(technical)/Archive_158#Wikidata_problem and is having to be manually worked around. It also caused problems at en:Template_talk:Infobox_journal#Links_to_DAB_pages with redirects to journal titles.

  • Phabricator tickets:

phabricator:T14019

Discussion

What's the use case that causes an ifexist check for a disambiguation page? How widespread is this issue? Max Semenik (talk) 21:40, 18 November 2017 (UTC)

@MaxSem: See the links I posted above. As an example of the case that introduced me to this issue, see en:Telescope Array Project - in the infobox, the desired wikilink for the location is to en:Millard County, Utah, however from Wikidata all I can fetch is en:Millard County, en:Utah (or the same text without wikilinks) - I can then find the desired link by checking {{#ifexist:Millard County, Utah}} and I can then use that link - however that exact same code used at en:Great Melbourne Telescope will be {{#ifexist:Victoria}}, which finds a link to en:Victoria, which is a disambiguation page. This then causes the problem described at [3]. This issue is a fundamental one that means that we can't use ifexist like this, which is a real shame. And, again, this was first reported way back in 2007 in other situations! Thanks. Mike Peel (talk) 21:58, 18 November 2017 (UTC)
In this particular case, it sounds like you should use the interwiki link from WD instead of trying to construct the county name by hand. Max Semenik (talk) 22:47, 18 November 2017 (UTC)
@MaxSem: @Nikkimaria objects to using "Millard County, Utah" rather than "Millard County, Utah" per en:WP:MOS, so I'll let them argue the case for that here. But regardless of that, #ifexist should be something that is *usable* by template developers rather than something that causes unnecessary problems. Thanks. Mike Peel (talk) 23:02, 18 November 2017 (UTC)
Probably the best way to solve that would be for the system to get the wikilink of the claim instead of ifexist (i.e. propertyX.wikipedia.en."Millard County, Utah" or whatever in Lua). Both are expensive functions anyway, so it's not like you would be trading performance. --Izno (talk) 04:38, 19 November 2017 (UTC)
I wouldn't narrow this just to disambiguation pages. I know about many usages where {{#ifexist:}} has been used for purpose of intentional not linking the non-existent pages, but linking if they exist (in other words blue link or plain text (instead of red link)). This is typically used in two cases: 1) when the page has been deleted and you don't want it to be re-created, 2) you have different mechanism to link to non-existent page, typically something like {{#ifexist:Page|[[Page]]|[{{fullurl:Page|action=edit&editintro=info&preload=template}} Create the Page]}} (mind that non-existent pages linked via the latter construction are not part of Special:WantedPages).
Danny B. 23:21, 18 November 2017 (UTC)

This problem is widespread in ruwiki where there are modules/templates that automatically check the existense of various pages (and link there if they exist). Instruments for checking unexistent linked pages (e.g. Special:WantedPages, tools that update wikiproject pages, like this one, relying on red links) fail when they come across pages that are checked by #ifexist (user complaints, in Russian). Jack who built the house (talk) 08:31, 19 November 2017 (UTC)

Maybe do not simply filter those ifexist links out of the result, but allow to filter them in or out. → «« Man77 »» [de] 14:11, 2 December 2017 (UTC)

Scribunto

It should be also noted, that Scribunto functions of title library which work with non-existent pages, also produce a record on Special:WantedPages. So preferably the behavior should be consistent in both cases of Scribunto and wikitext.
Danny B. 23:28, 18 November 2017 (UTC)

Scribunto doesn't do anything differently. I suspect you're mistaken about #ifexists not showing on Special:WantedPages. Anomie (talk) 00:42, 20 November 2017 (UTC)
I just checked it. #ifexists does indeed result in an entry on Special:WantedPages. Anomie (talk) 15:52, 11 December 2017 (UTC)

Why this happens

MediaWiki needs some way to know which pages need to be updated when a page is created or deleted. Usually this is because of a wikilink, so it can be turned from red to blue or vice versa, but it has to happen for things like #ifexist too. If someone were to implement this request, it would require either a new field to record the "kind" of link or a whole new table. Anomie (talk) 00:42, 20 November 2017 (UTC)

Voting

  • Support Support Tim Landscheidt (talk) 01:41, 28 November 2017 (UTC)
  • Support Support β16 - (talk) 11:22, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:11, 28 November 2017 (UTC)
  • Support Support (as proposer) Mike Peel (talk) 18:09, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:02, 28 November 2017 (UTC)
  • Support Support Wbm1058 (talk) 22:40, 28 November 2017 (UTC)
  • Support Support IKhitron (talk) 23:09, 28 November 2017 (UTC)
  • Support Support Dominic Z. (talk) 16:48, 30 November 2017 (UTC)
  • Support Support Ninovolador (talk) 22:00, 30 November 2017 (UTC)
  • Support Support«« Man77 »» [de] 14:11, 2 December 2017 (UTC)
  • Support Support Galobtter (talk) 12:39, 3 December 2017 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 15:49, 3 December 2017 (UTC)
  • Support Support LikeLifer (talk) 18:35, 3 December 2017 (UTC)
  • Support Support Joalpe (talk) 17:57, 7 December 2017 (UTC)
  • Support Support Metrónomo-Goldwyn-Mayer 02:14, 8 December 2017 (UTC)
  • Support Support Jack who built the house (talk) 20:44, 8 December 2017 (UTC)
  • Support Support Serhio Magpie (talk) 20:44, 8 December 2017 (UTC)
  • Support Support MBH (talk) 00:39, 9 December 2017 (UTC)
  • Support Supportputnik 13:30, 9 December 2017 (UTC)
  • Support Support 91.79 (talk) 20:36, 9 December 2017 (UTC)
  • Support Support Kaganer (talk) 22:45, 9 December 2017 (UTC)
  • Support Support stjn[ru] 21:34, 10 December 2017 (UTC)
  • Oppose Oppose Seems to be the correct behaviour — Jeblad 00:09, 11 December 2017 (UTC)
  • Support SupportVort (talk) 05:51, 11 December 2017 (UTC)
  • Support Support — Luchesar • T/C 13:59, 11 December 2017 (UTC)
  • Support Support On the one hand, ifexist shouldn't mark pages as wanted ones, and this problem really should be solved — that's why I support the proposal. On the other hand, server should clear page cache after creating or deleting page. Facenapalm (talk) 17:33, 11 December 2017 (UTC)
  • Support SupportNickK (talk) 17:36, 11 December 2017 (UTC)

Move orphaned revisions to the archive table

Edit proposal/discussion

  • Problem: Previously, from 2013 to 2016, when moving a page over a redirect, the redirect is left behind as an orphaned revision in the revision table. Nowadays (T106119), a deletion log entry is generated and the redirect goes in the archive table. However, even after that was resolved, there are still lots of orphaned revisions left behind.
  • Who would benefit: Users who do not want to see the orphaned revisions showing up when viewing the contribs in the mobile interface (see T151124).
  • Proposed solution: Move all the orphaned revisions to the archive table to match the current behavior. The ar_namespace and ar_title fields should only be approximations, as it might be the case that the same page title has been moved over more than one redirect title.
  • More comments:

Discussion

Voting

  • Support Support Jenks24 (talk) 09:35, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:11, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:03, 28 November 2017 (UTC)
  • Oppose Oppose because the long term best option is to not have the archive/revision split at all (cf: T57398, T30124, probably others). Additionally, this is not really a project for a team of folks to work on, moreso a request in Phabricator for some one-off maintenance to be done. 😂 (talk) 01:36, 2 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 01:28, 4 December 2017 (UTC)

Autoarchive provided

Edit proposal/discussion

  • Problem:
    • Millions of talk pages stretching indefinitely require editors to individually create archive settings for talk pages, so that older entries, closed discussions etc are archived.
    • This is a colossal waste of time.
    • This could be made a lot easier if semiautomated tools were provided
  • Who would benefit:
    • Wikipedia, by decreasing duplicate editing
    • Editors, by removing old or closed discussions
    • Editors using mobile and other devices, by decreasing the size of talk pages, making them easier to load
    • Articles, by ensuring discussions are up to date
  • Proposed solution:
    • As part of the editing toolkit an option to "Add auto archiving" is provided. The editor can insert some settings (eg how many threads to leave, how old threads should be before archiving, what style archive box should be used).
    • Selected settings are automatically inserted into talk page with a template that informs other editors of those, and a small box providing links to archived talk page entries
  • More comments:
  • Phabricator tickets:

Discussion

Structured Discussions can auto-archive :-) --Tgr (talk) 08:26, 28 November 2017 (UTC)

en:User:Anne drew Andrew and Drew/SetupAutoArchive exists for enwiki. Galobtter (talk) 12:43, 3 December 2017 (UTC)

Voting

  • Support Support Dvorapa (talk) 09:41, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 13:11, 28 November 2017 (UTC)
  • Support Support — Draceane talkcontrib. 18:30, 28 November 2017 (UTC)
  • Support Support Laboramus (talk) 20:40, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 22:03, 28 November 2017 (UTC)
  • Support Support Shizhao (talk) 03:09, 29 November 2017 (UTC)
  • Support Support Libcub (talk) 05:03, 29 November 2017 (UTC)
  • Support Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:08, 29 November 2017 (UTC)
  • Oppose Oppose we should properly fix discussions, instead of building quicksand solutions. —TheDJ (talkcontribs) 16:56, 29 November 2017 (UTC)
  • Oppose Oppose Often archiving is not desired / necessary. This is the work I like doing, as well as repairing broken weblinks ZellmerLP (talk) 22:24, 29 November 2017 (UTC)
  • Support Support קובץ על יד (talk) 12:39, 30 November 2017 (UTC)
  • Support Support Exilexi (talk) 15:03, 30 November 2017 (UTC)
  • Support Support Dromedar61 (talk) 21:12, 30 November 2017 (UTC)
  • Support Support Sahaquiel9102 (talk) 21:40, 30 November 2017 (UTC)
  • Support Support Ammarpad (talk) 23:19, 30 November 2017 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 14:56, 2 December 2017 (UTC)
  • Support Support only if there is option to disable it. --Termininja (talk) 17:28, 2 December 2017 (UTC)
  • Support Support Noyster (talk) 20:12, 2 December 2017 (UTC)
  • Oppose Oppose As ZellmerLP. Wiklol (talk) 21:35, 2 December 2017 (UTC)
  • Oppose Oppose Structured Discussions are the way to go. Matěj Suchánek (talk) 10:31, 3 December 2017 (UTC)
  • Oppose Oppose, Structured Discussions can auto-archive, and for other cases we have several bots. —Tacsipacsi (talk) 12:44, 3 December 2017 (UTC)
  • Support Support this should be very flexible Gryllida 00:51, 4 December 2017 (UTC)
  • Oppose Oppose Ciao • Bestoernesto 01:30, 4 December 2017 (UTC)
  • Oppose Oppose - Editors should have the choice of whether to archive or not, As for talkpages - Not all talkpages are edited and some aren't edited for over 5 years, Pointless proposal imho. –Davey2010Talk 17:05, 4 December 2017 (UTC)
  • Support Support Ronhjones (talk) 18:29, 4 December 2017 (UTC)
  • Support Support Talk pages over a certain size should be archived. Some people, you cannot use their talk page as it is too large to load. Doc James (talk · contribs · email) 02:28, 5 December 2017 (UTC)
  • Support Support --Sphilbrick (talk) 15:20, 6 December 2017 (UTC)
  • Support Support WWGB (talk) 00:33, 7 December 2017 (UTC)
  • Support Support Ahm masum (talk) 21:37, 7 December 2017 (UTC)
  • Support Support I regard it as important is to create an easier way for users to start archiving discussions on their personal talkpage. Default for personal talk pages must be that auto-archiving is turned off, so no unexpierienced user must wonder, where their talkpage content has disapperared to. Other talk pages should only be auto-archived when getting very large, at the same time manual or semiautomatic archiving of discussions maually flaged as closed should be possible. X:: black ::X (talk) 09:51, 10 December 2017 (UTC)
  • Support Support Le Loy 22:01, 10 December 2017 (UTC)
  • Oppose Oppose Klaas `Z4␟` V:  22:17, 10 December 2017 (UTC) various flexible tools are available on quite a few projects and manual archiving is in most cases easier than you think with the advantage you have all control. On many talkPages no archiving is necessary nor has it much value; even better to keep forever so same discussions have less chance to occur.
  • Neutral Neutral. On one hand, most wikis have their own tools (bots, scripts etc.) and its own rules (moving pages, copying content etc.), thus this would be hard to make unified. On the other hand, we cannot make it mandatory — NickK (talk) 17:38, 11 December 2017 (UTC)

Multiple protocol support in Special:Linksearch

Edit proposal/discussion

  • Who would benefit: Anyone who uses this special page.
  • Proposed solution: At the very least, linksearch should return results for HTTP and HTTPS combined when no protocol is specified.
  • More comments: Google now (rightfully so) boosts rankings for HTTPS sites and I am seeing HTTPS spam much more often as a consequence. Why do I need to ask the WMF to address glaring technical debt and software rot in MediaWiki three times and wait almost a decade for a fix?
  • Proposer: MER-C (talk) 12:26, 9 November 2017 (UTC)

Discussion

  • Much needed, small and tangible fix! Sadads (talk) 20:19, 11 November 2017 (UTC)
  • Simple and no brainer. Doc James (talk · contribs · email) 22:06, 13 November 2017 (UTC)
  • Lack of this feature is a roadblock to several tasks I try to perform. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:00, 15 November 2017 (UTC)
  • Checking for and cleaning up after spammers is a lot more difficult without this as mentioned. Similarly for tasks with interwiki mapping is made harder in the absence. Yes it only affects a smaller number of people, they are however, some of the real backroom workers that enhance the user experience.  — billinghurst sDrewth 23:09, 15 November 2017 (UTC)

Voting

2 factor authentication for all

Edit proposal/discussion

  • Problem: Currently 2 factor authentication is by default only available to users with elevated user rights, like sysops. This is due to multiple unsolved usability problems that caution us
  • Who would benefit: Registered users
  • Proposed solution: Solve the usability options and improve account recovery process.
  • More comments:

Discussion

  • Personally I don't forsee this happening, allowing anyone to enable 2fa could cause operations having to reset forgotten 2fa credentials constantly, for example if someone were to lose their scratch codes (which I've done before on wikitech) its a task that while may not to be hard, would get annoying and cause a lot of potiental extra work for the already busy operations team Zppix (talk) 17:40, 8 November 2017 (UTC)
    • Solving this, would indeed require that ops people are no longer required for a reset, simply because there is no UI to modify this part of the database. When you reset is rules that we will have to define. We could have a group with checkuser abilities for that for instance. Or require at least email verification + password verification, or submitting evidence to OTRS. There's options. —TheDJ (talkcontribs) 08:11, 9 November 2017 (UTC)
  • I do support this, though it should be optional and not mandatory. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:08, 29 November 2017 (UTC)
  • This can be solved for some of the users by using proofs like in Keybase. Probably several systems should be used to revoke a 2-factor authentication setup, but I'm not sure how this should be done. Only thing I do know; don't rely on SMS alone for a revoke! — Jeblad 23:50, 10 December 2017 (UTC)

Voting

Feed for search engines

Edit proposal/discussion

  • Problem: Currently, there is no newsfeed for several projects of Wikinews. That's why Wikinews is badly indexed in Google / Bing. There are some exceptions like English Wikinews, but feeds are installed by members of the project itself and not by wiki-software.
  • Who would benefit: People who are searching for news in search-engines. Also, Wikinews projects would benefits because a higher indexation in search engines.
  • Proposed solution: Introduce a general feed system for all Wikinews-projects
  • More comments:
  • Proposer: Livenws (talk) 12:13, 20 November 2017 (UTC)

Discussion

  • Its debatable that this why google doesn't index wikinews high. To be blunt, its probably because wikinews simply isn't popular. That said, this proposal should clarify what it wants which isn't currently available via mw:Extension:GoogleNewsSitemap and/or mw:Extension:FeaturedFeeds. Bawolff (talk) 22:42, 28 November 2017 (UTC)
  • Adding the feeds to the relevant Wikidata items might be a simpler solution for this. NMaia (talk) 12:57, 29 November 2017 (UTC)

Voting

  • Support Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  • Support Support YFdyh000 (talk) 14:58, 28 November 2017 (UTC)
  • Support Support Laboramus (talk) 20:36, 28 November 2017 (UTC)
  • Support Support Ymnes (talk) 21:01, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:56, 28 November 2017 (UTC)
  • Support Support Shizhao (talk) 03:03, 29 November 2017 (UTC)
  • Support Support Useful and simple - it will also be better to help us follow WikiNews Exilexi (talk) 15:05, 30 November 2017 (UTC)
  • Support Support Braveheidi (talk) 08:01, 1 December 2017 (UTC)
  • Support Support Lofhi (talk) 19:47, 1 December 2017 (UTC)
  • Support Support wikimedia sister wikis could have a single place with feeds that is indexed by search engines, explore feeds potential at wiktionary and other wikis and put it all in one place Gryllida 00:54, 4 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 01:48, 4 December 2017 (UTC)
  • Oppose Oppose Not a development priority. Kudpung (talk) 20:38, 6 December 2017 (UTC)
  • Support Support making Wikinews more useful — NickK (talk) 17:39, 11 December 2017 (UTC)