2017 Community Wishlist Survey/Miscellaneous

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

2017 Community Wishlist Survey

Miscellaneous
30 proposals, 67 contributors

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

Contents

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[edit]

  • 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)

A more user-oriented search bar

Edit proposal/discussion

  • Problem: The search bar currently shows the most probable pages ranked by number of hits.
  • Who would benefit: All Editors
  • Proposed solution: It would be good if the search bar could be oriented to the page most edited by me (ex: on typing User:F on Wikipedia the search bar should first show my name)
  • More comments: This can be adapted for anons to be a page which will be similar in topic( in the same category) to pages which they have clicked on before
  • Phabricator tickets:

Discussion[edit]

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[edit]

Improve DNS- and TSL(SSL)security

Edit proposal/discussion

  • Problem: Wikipedia is used around the world. Unfortunately not every country is a democracy and a constitutional state, but many countries are dictatorships and/or have no citizen rights (or not enough). Many of these countries (and a few of the democratic too) try to spy their own burghers, and which Wikipedia pages somebody reads (or what he writes about his leaders) is of course interesting for these bad countries.

While Wikipedia uses TLS (also knows as SSL) since a few years, this is not enough. Because many of these bad countries run default-trusted Certification Authorities (CA), which are able to generate certificates for every domain they like – including Wikipedia.

  • Who would benefit: In theory every users of Wikipedia (reader and writer), but especially users in non-free-countries.
  • Proposed solution: Implement DNSSEC for the DNS of the Wikipedia-domains as a first step. Than add TLSA-records (also known as DANE) to the DNS to secure the TSL. Then the users can install a plugin in their browsers that will warn them if somebody tampers with the TSL-certificate.
  • More comments: The work (without testing and documentation) should need less than 1 day. I can offer help, if needed.
  • Proposer: DaB. (talk) 20:52, 6 November 2017 (UTC)

Discussion[edit]

  • Contrary to the proposer's claim that this is a very easy thing to do, the WMF operations team considers this a serious amount of work because our current DNS server - gdnsd - doesn't support this. Max Semenik (talk) 23:34, 6 November 2017 (UTC)
    That sounds like a great opportunity to improve our infrastructure while also supporting 3rd party free software. :) Having the primary author of the said software onboard can only help, right?--Strainu (talk) 13:22, 7 November 2017 (UTC)
  • The author of gdnsd (BBlack) opposes DNSSec and has no plans to implement it. S/he points to this page as to why DNSSEC is a terrible thing. --stranger195 (talkcontribsguestbook) 09:44, 9 November 2017 (UTC)
  • Speaking of which I recall there were a period of time that Wikipedian in China was asking for exemption or deferral in SSL connection on Chinese Wikipedia because at the time Wikipedia article on some topics can still be accessed within mainland China as long as there are no targeted keywords but it would be inaccessible at all if HTTPS connection is usedC933103 (talk) 23:47, 12 November 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[edit]

  • 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)

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[edit]

  • 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)

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[edit]

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)

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)

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.
  • 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
    • partnership with institutions to 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[edit]

  • 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)

Transition from templates to metadata

Edit proposal/discussion

  • Problem: как опознать статью, имеющую те или иные свойства, например: содержащую орисс или копивио, слишком короткую, не имеющую иллюстраций, являющуюся заготовкой по такой-то теме, избранную или добротную, являющуюся дизамбигом и т.д.? Никак По шаблонам, вписанным прямо в код статьи! Такое решение, во-первых, неочевидно, во-вторых, легко вандализируется, в-третьих, не позволяет искать статьи по параметрам. Как мне найти все заготовки статей о горах, имеющие размер больше 5 КБ и не имеющие источников? Или как найти все добротные статьи без иллюстраций? Или все дизамбиги больше 10 КБ? Никак, это абсолютно невозможно. Существует некий инструмент поиска по пересечению категорий, но он откровенно убог и позорен, это уровень урюпинского колхоза "Красный Пусть", а не самого посещаемого в мире сайта.

Translation: how to identify an article having certain properties like whether it contains original research or copyright violation, too short, lacking illustrations, being a stub, featured or good article, disambiguation page, etc? You can't By templates right in page text! Such solution is unobvious, easy to vandalize and doesn't allow you to search articles by parameters. How do I find all stubs about mountains having size over 5kb and having no sources? Or how do I find all good articles without illustrations? Or all disambiguations over 10kb? You can't, it's absolutely impossible. There's a certain category intersection tool, but it's not suitable for the world's most visited website.

  • Who would benefit: все редакторы и читатели. Translation: all editors and readers.
  • Proposed solution: предлагается уичтожить все шаблоны заготовок, дизамбигов, статусных статей, а также плашки с предупреждениями. Вместо этого предлагается создать параметры статей, которые редактировались бы отдельно от исходного кода (или параллельно с ним).
  1. Автоматические количественные параметры: статистические данные, которые невозможно править вручную. Например: размер статьи в байтах и символах, число правок в истории, средний размер правки, дата создания и т.д.
  2. Ручные бинарные параметры: свойства, принимающие значения "да/нет" (или 1/0, кому как привычнее). Содержит ли статья рекламный стиль? А машинный перевод? Была ли на ЗЛВ? Предлагалась ли к удалению? Если указан параметр "да", то над статьёй появляется соответствующий небольшой значок (если параметр некритичен, например, факт прежнего выноса к удалению, но не появляется). Эти параметры могут иметь свойства. Например: параметр "заготовка" или "дизамбиг", выставленный в положение "да", может иметь свойство "тема". Остальные параметры в качестве свойства могут иметь поле для произвольного комментария. Если параметр "вынесено к удалению" стоит в положении "да", то над статьёй появляется аккуратная красная полоса со ссылкой на дискуссию.
  3. Ручные многофакторные параметры: устанавливаются вручную и имеют несколько значений. Например: статус статьи (ДС/ХС/ИС/ИСП/нет), уровень важности (низкий/средний/высокий/высший) и т.д. Ручные параметры могут редактироваться всеми участниками, но некоторые можно защитить до администратора во избежание вандализма или случайных ошибочных действий.

Одновременно с этим запускается поиск по параметрам, где можно будет искать статьи по произвольному набору параметров.

Translation: I propose to eliminate all the stub, disambiguation, article status and issue templates. Instead, I propose to create article parameters that would be editable separately from wikitext (or concurrently with it).

  1. Automatic numeric parameters: statistical values that are impossible to change by hand. For example, article size in bytes and characters, number of edits, average edit size, creation date, etc.
  2. Manual binary parameters: properties that take "yes"/"no" values (or 1/0, whichever is most convenient to one). Does this article contain promotional language? What about machine translation? Have in been shown at Did You Know? Have it been nominated for deletion? If a parameter is set to "yes", a small sign appears above the article (if the parameter is non-critical e.g. whether it was nominated for deletion, it doesn't appear). These parameters could have properties. For example, a "stub" or "disambiguation" parameter could have a topic property. Other parameters could have an arbitrary comment field. If the "was nominated for deletion" parameter is set to yes, a neat red bar with a link to discussion appears above the article.
  3. Manual multifactor parameters: set by hand and can have one of multiple values. For example, article status (featured/good/none), importance (low/medium/high/top) etc. Manual parameters can be edited by by all editors but some could be admin-protected to avoid vandalism or mistakes.

At the same time release parametric search that would allow searching by arbitrary set of parameters.

  • More comments:
  • Phabricator tickets:

Community discussion[edit]

Add filters to edit 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
  • More comments:
  • Proposer: Renata3 (talk) 18:31, 9 November 2017 (UTC)

Discussion[edit]

  • 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)

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[edit]

  • 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)

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[edit]

  • 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)

Fix talk pages

Edit proposal/discussion

  • Problem: Wikipedia contributors without Mediawiki experience are irritated by the (lack of) a proper user interface talk pages.
  • Who would benefit: All contributors taking part in discussions.
  • Proposed solution: For example, there should be buttons to add a reply to an existing topic or to add a new topic. The structure (currently achieved through indentation) as well as the name of the user and the date of the contribution should be handled automatically.
  • More comments: The current talk page format follows the wiki philosophy, but when we want constructive discussions, this seems like romantic fundamentalism. Let's make discussions more approachable for everyone.
  • Phabricator tickets:

Discussion[edit]

  • How would this differ from the existing Structured Discussions extension (formerly known as "Flow")? Anomie (talk) 14:53, 15 November 2017 (UTC)
    • It probably wouldn't, although there may be other solutions to the talk page problem. I really want talk pages fixed as soon as possible, therefore I strongly support this wish. --Gnom (talk) Let's make Wikipedia green! 08:57, 16 November 2017 (UTC)
    • To be honest, I didn't know about Structured Discussion. The project does include my proposal, but adds a number of features. Looks quite ambitious to me. Should it be realized as planned - fine. Then I see, it was removed from en-WP one year ago: mw:Structured_Discussions/Rollout#Rollout. Maybe because it was too .. ambitious? --Bernd.Brincken (talk) 12:29, 18 November 2017 (UTC)

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[edit]

  • 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)

Establish global volunteer availability registry

Edit proposal/discussion

  • Problem: Many smaller wikis are starved for volunteers / many editor volunteers are starved for work they are interested in performing
  • Who would benefit: smaller/ lesser-known wikis that suffer a shortage of certain types of volunteers / editor volunteers who are looking for new challenges
  • Proposed solution: Proposed solution: establish a central registry where editors can post their qualifications/ limitations / requirements, sort of like a job website, and allow editors to shop for new/additional volunteer jobs.
  • More comments: Am I making sense?
  • Phabricator tickets:

Discussion[edit]

Does this require any software development? If so, what kind of development? Can this be achieved with a simple wiki page? Max Semenik (talk) 23:45, 9 November 2017 (UTC)

It's an interesting proposal, Ottawahitech :) My team has been inviting contributors to all kinds of volunteer paths for a long time now, from tech ambassadors to tech translators, from visual editor experts to Structured Data Commons enthusiasts. I think we still need better integration into Wikimedia Resource Center, and your proposal probably also goes into that direction. Elitre (WMF) (talk) 15:42, 13 November 2017 (UTC) PS: The "simple wiki page" would still need design, usability tests, etc.

Hi Elitre, I have not had a chance yet to look into any of your links which look really interesting, but wanted to reply here first. I have been participating in some less well travelled wikis in the last couple of months and sometimes it feels like travelling in foreign lands. After the hectic pace of en.wikipedia I first thought it was a piece of cake to participate in wikis where one can count the number of daily recent edits on one’s fingers (sometimes also toes). That was until I discovered that some of those wikis have histories (and ghosts who come alive) that must be unravelled before one is allowed to participate…
Back to the topic at hand, matching volunteers to wikis that need them. Yes it is a complex problem. Just like employers always complaining about how they just cannot find "qualified" workers, and at the same time unemployed people are complaining that employers who are said-to-be-hiring but do not even acknowledge people who submit a resume.
I am not sure who should take the intiative to post a request: the wiki that needs workers , or the editors looking for (additional) work. Admins who run wikis are way too busy and rarely have the time, let alone the awareness of their need, to think about what type of volunteers they want and what qualifications those volunteers need. Just like employers who rely on their social network when picking new employees, they are more likely to rely on editors they already know and try to poach them, instead of getting editors who are available…
Oops, my TLDR-meter has expired long ago, thanks for pinging me. Ottawahitech (talk) 13:53, 14 November 2017 (UTC) Please ping me
I believe your request may also be related to existing efforts. The first that comes to mind, for example, is Community Capacity Development. I will also ping User:Asaf (WMF) in case he wants to weigh in. Best, Elitre (WMF) (talk) 14:35, 14 November 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[edit]

  • 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)

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[edit]

  • 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)

Making Meta pages translatable by default

Edit proposal/discussion

  • Problem:

Current system is difficult to understand, hard to find and not user friendly. Only true insiders know what has to be done to make things multilingual in Meta.

  • Who would benefit:

Everyone, but mainly the community, who could have a culturally richer and more diverse system.

  • Proposed solution:

Making everything translatable by default.

  • More comments:
  • Phabricator tickets:
  • Proposer: Theklan (talk) 13:15, 10 November 2017 (UTC)

Discussion[edit]

  • It sound like you are asking you to make the system easier rather than just applying the current tool more widely as it is currently. I do agree with making it easier to use. See for example Phab:T131516 and numerous other tasks saying the same from a different point of view. –Nikerabbit (talk) 09:32, 15 November 2017 (UTC)
  • I agree on the sentiment. To make sure that "everything" also contains important content, we also need to make sure that e.g. Wikimedia Foundation content doesn't move to untranslatable spaces outside of the wikis. Currently an efficient multilingualism doesn't seem to be a criterion in communication decisions, see Talk:Wikimedia_Foundation_website/2017_update#Multilingualism. --Nemo 11:29, 15 November 2017 (UTC)

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[edit]

Allow disabling referrer info

Edit proposal/discussion

  • Problem: HTTP referrer info is detected by simply clicking an external link to a website, risking privacy compromise and spamming. The majority at this year's enWP RFC discussion favored the "silent referrer" option (i.e. never sending domain info to other website), while some others favored sending either the full domain option, like "en.wikipedia.org" (the current status quo), or full URL referrer option. However, one of the WMF staff says that there are no plans to change the policy about referrer info anytime soon out of concerns over impact on "technical efforts".
  • Who would benefit: Users whose browsers (such as Microsoft Internet Explorer and Microsoft Edge) don't disable referrer info and/or don't support add-ons to disable referrer info, those who want to reveal info to external websites, and others.
  • Proposed solution: Instead of proposing a policy change, I would like to propose two solutions for users' preferences settings.
    1. Primary solution: multiple option referrer info can offer silent referrer info, full URL, full domain, and partial domain (e.g. "wikipedia.org") and maybe more (according to this site) as options for a user to choose in the Preferences settings.
    2. Alternative solution: a gadget to simply disable/opt-out referrer info by (probably) clicking a box in the settings.
  • More comments: The HTTP referrer is not easy to describe in simple words, and I'm not sure whether the general public knows what "HTTP referrer" is. I was told that browsers (if not websites, including external ones) can still detect IP addresses, regardless of how referrer info is sent.

Discussion[edit]

@George Ho: Rephrasing the summary for clarity is welcome. "Referrer info" already exists, so you probably don't ask for it to be added/supported. :) "Allow disabling referrer info" or something like that? --AKlapper (WMF) (talk) 12:27, 7 November 2017 (UTC)

Renamed the title, Andre. BTW, thanks for the clarity suggestion, but I don't know which part of summary to re-clarify. --George Ho (talk) 16:19, 7 November 2017 (UTC)
"Allow disabling referrer info" is already much clearer, thanks a lot! :) --AKlapper (WMF) (talk) 16:24, 7 November 2017 (UTC)

I'll caution commenters that the linked enwiki discussion is very large, disorganized, and full of errors, misinformation, and FUD. A summary of the salient facts:

  • By default, when following a link browsers may include "referrer" metadata in the request. Many sites use this data for various analytics purposes, e.g. to identify external sites that drive traffic to inform decisions about partnerships.
    • For links from sites served over HTTP, this data consists of the full URL of the page containing the link.
    • For links from sites served over HTTPS to HTTPS targets, this data consists of the full URL of the page containing the link.
    • For links from sites served over HTTPS to non-HTTPS targets, no referrer data is sent. This is sometimes called "dark traffic".
  • When Wikimedia wikis were changed to HTTPS-only in 2013, this caused all traffic from our wikis to non-HTTPS sites to become "dark traffic". In some cases this is a significant amount of those sites' traffic.
  • Web standards provide a solution: a site can instruct the browser on which of certain predefined options it would like the browser to use when sending referrer data. Most browsers honor these requests. Popular browsers such as Firefox and Chrome have addons that allow users to instruct the browser to ignore website requests.
    • In 2015, Wikimedia wikis began using this mechanism to request that browsers send only the domain of the page (the "origin", in technical web-standards terminology) as the referrer data in all cases. This was seen as a good compromise between privacy and visibility for the global Internet ecosystem. The Wikimedia Foundation's Security and Legal teams both approved this decision.
  • Then we come to the enwiki discussion. It was driven by a heavily one-sided presentation, inaccurate technical information (e.g. that Wikimedia itself actively sends this referrer data, that some options were even possible, the actual current behavior with respect to HTTPS destinations, that spammers have no workaround for the withholding of referrer data), presentation of options that are more complex and worse for privacy as if they were better for privacy (e.g. collecting data that would be vulnerable to subpoena and data retention orders), irrelevancies, and heavy bludgeoning with hypothetical situations where people affected would be well advised to use other solutions to apply to all their web browsing (e.g. the above-mentioned addons) rather than relying on one website (Wikipedia) to do the "right" thing.

This proposal itself begins with some similar issues, including suggesting impossible options ("partial domain") and irrelevancies (IP addresses, phab:T172009, and many of the linked search results). HTH. Anomie (talk) 14:31, 7 November 2017 (UTC)

Struck out the irrelevancies that you mentioned, Anomie. --George Ho (talk) 16:19, 7 November 2017 (UTC)

Anomie and AKlapper, if the multiple-options solution is impossible, I will soon strikethrough the "primary solution" and revise the proposal to just a gadget to enable/disable referrer info. Sounds good? --George Ho (talk) 23:57, 7 November 2017 (UTC)

I haven't looked at technical feasibility for offering a user preference to make it configurable. The impossibility I referred to is the fact that there is nothing at https://www.w3.org/TR/referrer-policy/#referrer-policies that allows for "partial domain". The options available are:
  • No referrer.[1][2]
  • No referrer for HTTPS→HTTP, full URL for HTTPS→HTTPS.[3]
  • Full domain (e.g. "en.wikipedia.org").[4][5]
  • No referrer for HTTPS→HTTP, full domain (e.g. "en.wikipedia.org") for HTTPS→HTTPS.[6][7]
  • Always send the full URL.[8]
In all cases it's possible to make an exception, sending the full URL for local links (e.g. links from one page on enwiki to another page on enwiki). The current setting on Wikimedia wikis uses this exception, FYI. Anomie (talk) 15:09, 8 November 2017 (UTC)
Modified the "primary solution" proposal. May I leave in struck text, or must I remove it? --George Ho (talk) 19:06, 8 November 2017 (UTC)

Edit Warring - a better solution

Edit proposal/discussion

  • Problem:

On EN wikipedia we go through four levels of warnings before we block vandals, but we have a hair trigger for blocking edit warrers. This is crazy, we rarely turn vandals in to useful editors (OK some come back when they've grown up) but almost all edit warrers are useful members of the community who just get over enthusiastic.

  • Who would benefit:

Everyone who gets into editing disputes, everyone who tries to resolve such disputes and those who wish we could resolve things without always first going to a block.

  • Proposed solution:

A new level of page protection - protect v named individuals. Admins would be able to resolve edit warring incidents by protecting the page where the edit war was taking place against editing by particular named accounts. This would need to be independent of whether the page was also under pending changes, semi protection or extended confirmed protection. Blocking would still be an option, but we would now have an option to resolve things with less grief.

The edit warrers would then be free to edit elsewhere.

This tool would also be useful for some cases where interaction bans apply.

  • More comments:
  • Phabricator tickets:

Discussion[edit]

"almost all edit warrers are useful members of the community who just get over enthusiastic"

That doesn't make it ok. Edit wars are counterproductive, antagonistic, and stressful, and drive people away from editing. Needlessly aggressive behavior like edit warring should be heavily discouraged. — Omegatron (talk) 02:24, 11 November 2017 (UTC)
Agreed, and stopping people from editing that page would still be heavy discouragement. But why continue the current system where we deal much more harshly with edit warring than we do with vandalism? Even with this proposal most vandals get a warning on first, second, third and fourth offences, whilst an edit warrer would currently get a block on first offence and under this proposal instead of a series of four warnings would start with the page being protected against them with escalation to a block. Both edit warring and vandalism are wrong, why do you want us to treat edit warring so much more harshly? WereSpielChequers (talk) 09:46, 11 November 2017 (UTC)
WereSpielChequers, would it be okay if we retitled this proposal "Per-user page blocking"? It's not as eye-catching as "Edit Warring - a better solution", but it's a more neutral point of view. :) -- DannyH (WMF) (talk) 21:53, 13 November 2017 (UTC)
Hi Danny, how about "page protection v specified accounts" as I'm keen to have this considered a form of page protection rather than a type of user blocking. WereSpielChequers (talk) 22:20, 13 November 2017 (UTC)
I have encountered few Edit wars in my time on wikipedia, but I did encounter problematic editors who reverted my edits on sight. My usual reaction was to walk away because of the hassle involved in reporting edit-wars to the "authorities". If this proposal will simplify the process and not be prone to abuse, it may save a whole lot of cumulative editing time. Ottawahitech (talk) 14:29, 14 November 2017 (UTC) Please ping me
This Addition makes a lot of sense, while it may not be easy to implement. Anyhow, let's put it on the wishlist. --Bernd.Brincken (talk) 19:11, 14 November 2017 (UTC)

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[edit]

Commits[edit]

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[edit]

Who to whom in the Flow

Edit proposal/discussion

  • Problem: In the big discussions in the Structured Discussions (Flow), the conversation turns into a wall of text. And it is not easy to understand who is talking to whom, since the answer to the last comment in the branch and the answer to the first message of the branch will be the last comment in the branch.
  • Who would benefit: Readers of discussions
  • Proposed solution: Store in the comment data about clicking on which "Reply" it was created. When you hover over the child comment, additionally show the author's nickname of the parent comment (when you click on it to scroll to the parent comment) and highlight the parent comment. e.g.
  • More comments:

Discussion[edit]

  • Just getting rid of the atrocious system of ‘structuring’ the Structured Discussions would help a lot more in solving issues with understanding the system. No other comment system does have an approach more complicated than this add-on (not an extension) on wiki engine. stjn[ru] 15:42, 11 November 2017 (UTC)
  • It would help if replying to the last message in the flow would actually indent instead of simply a new message C933103 (talk) 23:56, 12 November 2017 (UTC)
  • I like this idea, and it is very common in other discussion systems as well, that there is an indicator of who you are replying to, or even allowing you to quote a particular fragment. I'd welcome such a change. Indentation is limited and people don't consider how that works on mobile viewports, so I do not consider indentation a complete solution to this problem. —TheDJ (talkcontribs) 13:35, 15 November 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[edit]

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)
  • 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)

Solve Wanted Pages issues

Edit proposal/discussion

  • Problem: As part of the Special Pages in every wiki, there is a section called Wanted Pages, which happens to be a mess. There, the non existing pages that have more links to them are listed in decreasing order of links, in order to know which one of them are more needed. The problem is that, besides the encyclopedic articles. The wanted pages includes files, Talk pages, Wikiprojects and other pages that should not be there.

Besides, when one of this files or talk pages is actually created, it is never deleted from the list, and it remains there forever. This has caused that the Special Pages in every wiki has become more and more useless through the years, and this is an issue that has remained unsolved for years.

  • Who would benefit: Users and editor of every Wikipedia
  • Proposed solution: It shouldn't be very hard to make sure the files and talk pages already created dissapear from the section, and change something to make sure they don't appear again, and that only missing encyclopedic pages are listed.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

@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)

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)

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[edit]

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)

Multilevel Flow

Edit proposal/discussion

  • Problem: In the big discussions in the Structured Discussions (Flow), the conversation turns into a wall of text. And it is not easy to analyze and read.
  • Who would benefit: experienced editors, discussion readers
  • Proposed solution: Give editors the opportunity to choose the presentation of the discussion as they are used to. (user settings or single board settings) Store in the comment data about clicking on which "Reply" it was created. Show as we do in Wikitext: display 15 levels (or at the choice of the editor), then start the ladder again on the left with the initial indentation and the transfer designation en:Template:Outdent. In mobile form, this can be with a reduced indentation of the nodes of the ladder and remove the indentation where the ladder is without nodes of branches.
  • More comments:

Discussion[edit]

  • It's no problem. Flow indent's system is fine. —Be nt all (talk) 17:56, 11 November 2017 (UTC)
    • Not for all. Many people say that there is a lack of logic and narrative threads in serious big discussions. Messages appear in the heap, analyze the dependencies in which for people (especially those who did not participate in the discussion, but who read it) excess work. --Sunpriat (talk) 11:01, 12 November 2017 (UTC)
  • Indentation model of Flow is good. There is a problem with a storage model of Flow, that stored discussions as a plain lists of messages with indentation values.--Tucvbif (talk) 22:42, 11 November 2017 (UTC)
  • Going to disagree with commentators above, the indentation model of Flow is not good at all, it does not make sense to any person that is already familiar with commenting systems on other websites. When I click ‘Reply’, I expect the message that gets sent out to be on another level from the message I am replying to, not in some preferential order that this system is using. It generally looks like a bug in the system every single time. stjn[ru] 11:14, 12 November 2017 (UTC)
  • Simply disable Flow, ordinary structured discussions, as they take place on normal talk pages, are far better manageable for editors. OK, not for bots, but they should take second row always. Flow is just a weak forum impersonation without any real structure, far too little indentation levels, not clear ratios between posts in longer discussions, no possibilty to rearrange the structure of meandering discussions, completely inflexible so far less useful. OK, machines seem to deal better with this rigid, inflexible corset, but machines are irrelevant compared to humans, and disussions are for humans, not for machines. Grüße vom Sänger ♫(Reden) 22:22, 14 November 2017 (UTC)

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[edit]

Render external links in edit summaries

Edit proposal/discussion

  • Problem: When an external link such as [https://www.google.com/ Google] is used in an edit summary, it renders as plain text instead of showing a link.
  • Who would benefit: Users who would like to make it easier to visit links.
  • Proposed solution: Make the external link syntax in wikitext also work in edit summaries as well.
  • More comments:

Discussion[edit]

  • This would probably make spam fighting harder though.. —TheDJ (talkcontribs) 14:07, 18 November 2017 (UTC)

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[edit]

@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)