Jump to content

Community Wishlist Survey 2017/Miscellaneous

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2017
Miscellaneous
27 proposals, 416 contributors



Get feedback using a yes/no microsurveying

  • 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

[edit]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]

Voting

[edit]

Word count on statistics

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

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)[reply]

Where did you find this number? -Theklan (talk) 17:57, 20 November 2017 (UTC)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
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)[reply]

Voting

[edit]

Responsive CSS/Template Framework for Media Wiki

  • 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

[edit]

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)[reply]

Voting

[edit]

Making Mediawiki MOOC-ready

  • 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

[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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
@Psychoslave: please see my above comment. -- NKohli (WMF) (talk) 00:24, 22 November 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Voting

[edit]

Add filters to history pages

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

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)[reply]

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

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)[reply]

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)[reply]

There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:38, 29 November 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

[edit]

Overhaul spam-blacklist

  • 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.
expanded solution
The following discussion has been closed. Please do not modify it.
  1. Take the current AbuseFilter, rename it to SpamFilter, take out all the code that interprets the rules ('conditions').
  2. Make 2 fields in replacement for the 'conditions' field:
    • one text field for regexes that block added external links (the blacklist). Can contain many rules (one on each line, like current spam-blacklist).
    • one text field for regexes that override the block (whitelist overriding this blacklist field; that is generally simpler and cleaner than writing a complex regex, not everybody is a specialist on regexes).
  3. Add namespace choice (checkboxes like in search; so one can choose not to blacklist something in one particular namespace, with addition of an 'all', a 'content-namespace only' and 'talk-namespace only'.
    • Some links are fine in discussions but should not be used in mainspace, others are a total nono
    • Some image links are fine in the file-namespace to tell where it came from, but not needed in mainspace
  4. Add user status choice (checkboxes for the different roles, or like the page-protection levels)
    disallow IPs and new users to use a certain link (e.g. to stop spammers from creating socks, while leaving it free to most users).
  5. Leave all the other options:
    • Discussion field for evidence (or better, a talk-page like function)
    • Enabled/disabled/deleted - not needed, turn it off, obsolete then delete
    • 'Flag the edit in the edit filter log' - maybe nice to be able to turn it off, to get rid of the real rubbish that doesn't need to be logged
    • Rate limiting - catch editors that start spamming an otherwise reasonably good link
    • Warn - could be a replacement for en:User:XLinkBot
    • Prevent the action - as is the current blacklist/whitelist function
    • Revoke autoconfirmed - make sure that spammers are caught and checked
    • Tagging - for combining certain rules to be checked by RC patrollers.
    • I would consider to add a button to auto-block editors on certain typical spambot-domains (a function currently taken by one of Anomie's bots on en.wikipedia).

This should overall be much more lightweight than the current AbuseFilter (all it does is regex-testing as the spam-blacklist does, only it has to cycle through maybe thousands of AbuseFilters). One could consider to expand it to have rules blocked or enabled on only certain pages (for heavily abused links that actually should only be used on it's own subject page). Another consideration would be to have a 'custom reply' field, pointing the editor that gets blocked by the filter as to why it was blocked.

Possible expanded features:

  1. block or whitelist links matching regexes on specific pages (disallow linking throughout except for on the subject page)
  2. block or whitelist links matching regexes when added by specific user/IP/IP-range (disallow specific users to use a domain)
  • 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.

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)[reply]

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)[reply]
@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)[reply]
  • 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)[reply]
    • @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)[reply]
    • 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)[reply]

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)[reply]

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)[reply]

Voting

[edit]

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

  • 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

[edit]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Voting

[edit]

Filter user contribution page by number of bytes changed

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

Discussion

[edit]
  • 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)[reply]
There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:39, 29 November 2017 (UTC)[reply]

Voting

[edit]

Provide a tool to efficiently analyze the usage of a template

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

Discussion

[edit]

Voting

[edit]

Vertical writing support

  • 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)[reply]

Discussion

[edit]

Voting

[edit]
  • 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 (talk • contribs) 14:29, 15 November 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

[edit]

Allow 'thanks' notification for a log entry

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

Voting

[edit]

Implement deferred changes

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

Voting

[edit]