Jump to content

Community Wishlist Survey 2021/Miscellaneous

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2021
Miscellaneous
27 proposals, 405 contributors, 772 support votes
The survey has closed. Thanks for your participation :)



Make CentralAuth extension to log actions everywhere

  • Problem: The CentralAuth extension doesn't log some actions on every wiki but just the wiki from where the action was performed (for Wikimedia, It's Meta-Wiki). This also makes us to have a local Steward and a local Global Renamer user group on Meta to keep the logs on Meta. If someone wants to see the logs then they will have to visit Meta-Wiki, this is really annoying. List of logs:
· Special:Log/gblblock (globalblock), You can't see logs of global IP blocks from wikis other than Meta.
· Special:Log/globalauth/Special:CentralAuth (centralauth-lock), You can't see logs of global account locks/unlocks and hide/unhide (private, only shown to users with centralauth-lock) from wikis other than Meta.
· Special:Log/gblrename (centralauth-rename), You can't see logs of global account renames from wikis other than Meta, You can see log entry at Special:Log/renameuser only if the account is locally created.
· Special:Log/gblrights (globalgroupmembership/globalgrouppermissions), You can't see logs of global user rights and global group management changes from wikis other than Meta.
  • Who would benefit: Everyone
  • Proposed solution: Make CentralAuth extension to log actions everywhere. Some third-party sites who use CentralAuth may don't want this, so add option to disable it.
  • More comments:
  • Phabricator tickets:
  • Proposer: CptViraj (talk) 05:32, 17 November 2020 (UTC)[reply]

Discussion

Seems like this will either take a lot of technical work (to mirror everything) or it will require many more (hundreds more times) database entries - one for every wiki for every logged action. KevinL (aka L235 · t) 01:05, 11 December 2020 (UTC)[reply]

I'm wondering why this could not be implemented similar to universal login? - Jc37 (talk) 16:14, 15 December 2020 (UTC)[reply]

Voting

Default languages for Captions and Descriptions on Wiki Commons

  • Problem: When uploading new pictures on Wikimedia Commons, you have to click "Add a caption in another language" and then again "Add a description in another language" for each picture, and for each language. When you can speak several languages, and you want to contribute as much as you can, this leads to a number of unnecessary, annoying clicks and it takes too much time, if you upload more pictures at once, as you have to do this with every language for every picture twice.
  • Who would benefit: every contributor using more languages
  • Proposed solution: I propose to add option of default languages (with possibility to choose more languages) for user, so you could choose several languages you speak and use, and after uploading a picture, caption and description boxes in these languages would be added automatically to each picture.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lukáč Peter (talk) 21:51, 25 November 2020 (UTC)[reply]

Discussion

Voting

Expand signature length

  • Problem: The signature in Wikipedia is limited to some words. However, some users want a large signature consisting of more words. But they are bound to the short signature. I also faced the problem. And couldn't select my favourite signature due to its short length.
  • Who would benefit: Everyone
  • Proposed solution: Expand the length of signature to double or triple.
  • More comments: All above
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 09:04, 30 November 2020 (UTC)[reply]

Discussion

Although they work fine, I know. However, they should be a bit longer. Therefore, they must be expanded to a few more words or bytes. Thank you. Empire AS (talk) 09:59, 1 December 2020 (UTC)[reply]
Yes I can. In the past I wanted this signature (Empire AS Talk!) but due to the its length, I couldn't get it. And I used this signature (Empire AS Talk!) instead as it was shorter. Therefore, I made this proposal to expand its length. It was all that I explained. Thank you. Empire AS (talk) 07:30, 9 December 2020 (UTC)[reply]

Voting

Allow sanitized-CSS to use pointer-events

Discussion

@Pseudo Classes: I haven't looked into this, but this might be intentional, as it might not be desirable to fake certain pointer events and it might be used in situations of phising or something. Please make a better Problem description of where and how you would use this pointer-events (examples), so that the usefulness and risk can be eveluated. —TheDJ (talk • contribs) 11:01, 20 November 2020 (UTC)[reply]
@TheDJ: Sorry, I’m not sure I understand. Why pointer-events property might be abused? Pseudo Classes (talk) 02:49, 21 November 2020 (UTC)[reply]
K. checked. the reason why pointer-events is not supported, is because it is CSS that is part of the SVG2 module which is not included in the sanitizer right now. It will also be added to the upcoming CSS level 4, but the sanitizer only supports Level 3. —TheDJ (talk • contribs) 12:21, 21 November 2020 (UTC)[reply]
The pointer-events CSS property sets under what circumstances (if any) a particular graphic element can become the target of pointer events. If set to none, the cursor will not change. See https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events WhoAteMyButter (talk) 04:48, 13 December 2020 (UTC)[reply]

Voting

Input Forms

  • Problem: Currently, many Wikipedia processes require users to fill out information. This range from edit requests to edit filter reports to all sorts of nominations. The current solution is usually using preload templates, asking users to fill in details as template parameters. This can be very confusing to users unfamiliar with the template syntax, especially newcomers. “What does <!-- —>mean? Where do I fill in the page title?” some users may try to figure out how the seemingly baffling template syntax works, but most would probably give up, frustrated.
  • Who would benefit: Newcomers who have little understanding of template syntax and experienced users who could address the newcomers' issue more easily
  • Proposed solution: I could think of 2 ways to solve this. First way is an overhaul of the InputBox extension, allowing the creation of forms with multiple text fields and, if possible, even other controls (switches, checkboxes, etc.) The second way may be a gadget that displays an intuitive input form to users, in which the form is constructed by reading, for example, a JSON containing the form structure.
  • More comments:
  • Phabricator tickets:
  • Proposer: H78c67c (talk) 07:11, 17 November 2020 (UTC)[reply]

Discussion

Voting

Make deleted edits visible to their author

  • Problem: Make the deleted edits visible to its author. Deleted edits are restricted to admins and checkusers. I think that a user should be able to see his/her deleted edits not of others.
  • Who would benefit: All users who would like to see their deleted edits
  • Proposed solution: Just make the edits visible to their authors.
  • More comments: All above.
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 07:01, 22 November 2020 (UTC)[reply]

Discussion

There should be some security problems, but at least I would like to see titles of deleted pages I had edited - useful eg in commons - according to name I can search it in log and maybe made new upload with correct licence. JAn Dudík (talk) 09:43, 23 November 2020 (UTC)[reply]

I think that there would be no problems regarding security. A user should be able to see only his/her edits, not of others. So, in future, he/she might stop the increase in his deleted edits. Empire AS (talk) 11:42, 23 November 2020 (UTC)[reply]
No. This will let people just posting their deleted spam / defamatory posts / vandalisms/ hoaxs etc more easier w/o the need to keep it somewhere else. Camouflaged Mirage (talk) 11:53, 23 November 2020 (UTC)[reply]
I support any version of this proposal that can provide me with a *minimum* of information about *which* of my edits were deleted (I agree here with JAn Dudík's comment). If I'm not mistaken, as it currently stands we can only find info about deleted pages but not deleted edits. I just need some kind of info for reference/tracking purposes, especially in order to understand what was deleted and *why* so that I don't repeat my mistakes again (I agree here with Empire AS's comment). And for added safety allow this function/privilege only to the authors of the deleted edits who are also *Extended-Confirmed* users. Cordially, History DMZ (talk) 19:33, 8 December 2020 (UTC)[reply]

@Martinkunev: Well you shouldn't be able to view deleted edits right now, you do not have admin rights on any Wikimedia wikis. The deleted edits here refer to the content of deleted pages and revisions, not text simply removed from the page and publicly visible on the history page. H78c67c (talk) 01:18, 9 December 2020 (UTC)[reply]

  • Editors wouldn't use these deleted edits to repost their 'deleted spam / defamatory posts / vandalisms/ hoaxs etc more easier' but they'll stop making such edits after knowing to them, I guess. I may tell an incident here that in the beginning when I was too new, I used Xtools to see my edits + the no. of deleted edits. However, the number of deleted edits was increasing day by day and I didn't even knew how or why it was happening. Therefore, I reached an admin who told me that most of my deleted edits are from my sandboxes. Then I understood my mistake that I didn't move the sandboxes to the articles but rather used copy-paste method and tagged sandboxes with G7. However, after knowing, I controlled the increase in my deleted edits by moving them. If I really knew this before (that was possible if I was able to see my deleted edits), then I wouldn't have big no. of deleted edits. Besides this, deleted edits would also help users to understand what sort and type of their content was deleted and why so happened. They would be able not to repeat such mistakes in future, and such content (like deleted spam / defamatory posts / vandalisms/ hoaxs etc) wouldn't be uploaded anymore. The backlog of WP:REFUND would also decrease. Thank you. Empire AS (talk) 10:00, 9 December 2020 (UTC)[reply]

Reading the opposing comments I'd just like to make a point: spammers could always have a copy of what they published, whether this feature is available or not. H78c67c (talk) 01:06, 10 December 2020 (UTC)[reply]

They could, H78c67c. But we don't need to help them, or to make it unnecessary to keep a copy. Cabayi (talk) 14:13, 15 December 2020 (UTC)[reply]

Do you mean you'd like the developers to develop :-

-- Cabayi (talk) 14:13, 15 December 2020 (UTC)[reply]
Those are lists of pages we created (which still exist). That sort of format would work, but instead it might show edits we made to pages which have now been deleted. To address other editors' concerns, we might not want to make the text available, just the editor, timestamp and edit summary (unless revdeled, of course). The proposal wouldn't give me access to anything secret: I can now download my contribution history daily and save it locally in case a page gets deleted, but the suggested change would be more convenient for me and avoid bothering the server by regularly downloading data I'll never read. Certes (talk) 14:28, 15 December 2020 (UTC)[reply]
I echo Certes here, the above format suggested by Cabayi (if applied to deleted *edits*) could work. It would include the timestamp, page title, and edit summary. But it's missing the log link with the admin's reason for deletion (see XTools example below, next to my vote). Cordially, History DMZ (talk) 15:43, 15 December 2020 (UTC)[reply]
@Cabayi: Yes, something like that, but I will see exactly this and you this. JAn Dudík (talk) 14:47, 16 December 2020 (UTC)[reply]
  • Exposing deleted edit content needs to be on a per-edit basis, set by an administrator, and only if the request is in accordance with a "what admins are allowed to let contributors see" per-project policy. I think the API already allows you to see certain meta-content of deleted edits, including who made them, how big the edit was, and the timestamp on the edit, tags, but not the edit summary or content. Making it easier to see this already-accessible content, perhaps via a gadget or external tool, would be a good thing. Davidwr/talk 16:29, 21 December 2020 (UTC)[reply]

Voting

  • Doubtful It is doubtful I am unsure whether it is a good idea or not. On one hand you allow them to learn why it was deleted. On the other hand, edits only get deleted if they're offensively bad from what I have seen, so if they can review their edits, they can just copy that and slap that back into the article on a new revision and the admins will have to delete that edit again. MarioSuperstar77 (talk) 19:40, 8 December 2020 (UTC)[reply]
@MarioSuperstar77: I don't think that it would happen anymore. As I can guess, an editor would use deleted edits to stop them from happening in future. Therefore, they would not repeat such edits anymore and admins would've no need to delete that edits again when they wouldn't be even made. Thank you. Empire AS (talk) 10:13, 9 December 2020 (UTC)[reply]
@Victor Schmidt: According to your view point it would happen. But as I see and can guess, I don't agree with you. Deleted edits visibility may help users to stop rehappening them and admins working here may help there in any other field of encyclopedia instead of deleting revisions that were happening due to not knowing the reason of their deletion. Thank you. Empire AS (talk) 10:26, 9 December 2020 (UTC)[reply]
@Martinkunev: the proposal isn't about live edits. It is about that edits that are deleted known as 'deleted edits' only visible to admins checkusers, oversighters etc but not to even their authors. Thank you. Empire AS (talk) 06:22, 10 December 2020 (UTC)[reply]

Display default/recommended values at Special:Preferences

Discussion

Voting

Improve pdf outprints

  • Problem: PDF does not work anymore
  • Who would benefit: Anyone who wants to use wiki in printed form
  • Proposed solution: Make PDF possible again. In older times there were two versions: text in one column including tables and text in two columns excluding tables. It would be desirable if the text could come in two columns and including tables as well as images in a suitable format (eg image (s) with text next to it in full page width). This would make the printout more "professional" in its design.

On the same occasion, the text should be corrected so that text arranged in list form (with numbers or hyphens) gets the same form as other running text (which was not the case before).

It is desirable if it becomes possible to edit a pdf layout and update the appearance until it gets the desired look prior to printing.

Discussion

Comment Comment It's possible to download PDF with Chrome, but not for Firefox. We need also to do a review of this. I'm not sure if it's the same problem or one different, but apparently are related. --Ganímedes (talk) 09:48, 17 November 2020 (UTC)[reply]

@Ganímedes: can you elaborate ? It works just fine for me. —TheDJ (talk • contribs) 11:45, 17 November 2020 (UTC)[reply]

Comment Comment I'm a teacher, I sometimes use wikibooks with my students and this could be an important improvement, because they often need a good print version in order to follow properly the activities during the lesson in class. The majority of students don't have digital devices so a good print would help a lot.--AGeremia (talk) 11:04, 17 November 2020 (UTC)[reply]

@AGeremia: I would file a separate request for book rendering to PDF, as this also requires combining multiple wikitext pages into a single document, which is a complex procedure with much additional logic. Please do file that as a separate request. —TheDJ (talk • contribs) 11:45, 17 November 2020 (UTC)[reply]

Comment Comment @Sven Halfdan Nielsen: "Make PDF possible again". PDF already is possible, most wikis have a "Download as PDF" link right in the left column. Can you be more specific perhaps about where and when it does not work for you ? I also see you'd with additional layout options, which seems like a separate request from 'make pdf possible again".. —TheDJ (talk • contribs) 11:45, 17 November 2020 (UTC)[reply]

@TheDJ: - when I made the proposal, I got the message, that it was not possible to download in pdf at all. But also: previously there were two different possibilities: one in two columns and one in full page. Later the two column possibility disappeared. I should like to see BOTH those possibilities restored. In fact, I should like possibilities to edit pdf-formats before saving/printing (but perhaps that is another theme). Sven Halfdan Nielsen (talk) 12:18, 17 December 2020 (UTC)[reply]

Comment CommentPDF versions could be a good choice if they did not release author private information. For more information, read this page at Wikimedia. --Doostdar (talk) 14:03, 20 November 2020 (UTC)[reply]

Voting

  • Problem: At the moment the link to Commons in the sidebars on Wikipedias and other projects is generated using the P373 ('commons category') property on Wikidata where there isn't a sitelink directly in the linked Wikidata item. P373 is frequently outdated and easy to vandalise, however, and using the sitelinks is a better way to provide the link (in particular, it is bi-directional and provides the links from Commons to the Wikipedias, and it is difficult to vandalise). Where there is a category for a topic, though, the Commons category sitelink is stored there rather than in the topic item, and does not get displayed without a P373 value. (For more background, see d:User:Mike Peel/Commons linking).
  • Who would benefit: Readers and editors going to Commons from Wikipedia articles
  • Proposed solution: The code should be updated to
  1. If there is a sitelink to Commons in the attached Wikidata item, use that (optional: unless it is to a gallery page)
  2. If there is a P910 ('topic's main category') value, follow that to the category item and use the sitelink to Commons from there
  3. If there is a P1754 ('category related to list') value, follow that to the category item and use the sitelink to Commons from there
  4. Otherwise, display nothing.

Discussion

Voting

Social interaction

  • Problem: Nowadays it is common for parseltongues to like, comment, rate and share content. These forms of interaction are essential for motivating people to contribute content on the Internet. But apart from the "thank you" function, there are no features in the Wikimedia projects that enable contemporary social interaction and feedback about content.
  • Who would benefit: People who feel motivated by likes, comments and sharing functions to contribute content.
  • Proposed solution: Which functions might be possible and useful would have to be discussed. The following functions could e.g. be considered:
    • A share button with which articles and multimedia files can be shared via email, messenger or in social media etc.
    • A like button for articles and multimedia files
    • A comment function for multimedia files that can be used to give personal comments on the content (in addition to the discussion page, which is used to improve the content).
  • More comments:
  • Phabricator tickets:
  • Proposer: Nicor (talk) 20:18, 24 November 2020 (UTC)[reply]

Discussion

  • Isn't this the purpose of user talk pages? :) In addition, Wikimedia projects are not social media sites, so I am not a big fan of adding functions that turn Wikimedia sites more social media site-like. Share buttons (provided by social networking sites) are also a privacy concern (read nightmare) to me. H78c67c (talk) 02:29, 25 November 2020 (UTC)[reply]
  • Your claim that "These forms of interaction are essential for motivating people to contribute content on the Internet" might be true for some web sites, such as Instagram. However, Wikipedia has had huge amounts of contribution from a huge number of people without the features you listed, so clearly they are not needed for motivating people to keep contributing to Wikipedia. For me personally, these features would just add noise. Silver hr (talk) 00:45, 1 December 2020 (UTC)[reply]
  • Web browsers already include an option to share. So does the Wikipedia app. --NaBUru38 (talk) 21:15, 10 December 2020 (UTC)[reply]
  • Just the fact that this is framed in terms of Harry Potter references is a bad sign.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:00, 15 December 2020 (UTC)[reply]

Voting

  • Neutral Neutral The thanks are enough in my opinion. MarioSuperstar77 (talk) 19:55, 8 December 2020 (UTC)[reply]
  • Strong oppose I don't think that wikimedia should turn into a social network. This creates the wrong incentive for users and I think this will impact user experience negatively as a whole. Martinkunev (talk) 20:30, 8 December 2020 (UTC)[reply]
  • Oppose Oppose as per my comment. Silver hr (talk) 21:36, 8 December 2020 (UTC)[reply]
  • Oppose Oppose We already have issues with people seeing Wikipedia as a social media site by adding needless personal commentary, not to mention vandalism. Neutral Neutral A "Share" button may be handy, but mostly as a shortcut to copy to clipboard for use as a reference. Jaguar83 (talk) 23:35, 8 December 2020 (UTC)[reply]
  • Oppose Oppose I support the "Like" button in principle, but not as something comparable to social media. Thanks and barnstars are good, but are pretty hard to miss and overall I think quite rare to receive. An anonymous, easy-to-find, and quick equivalent, I think, would see much more engagement and create a much friendlier community for editors. Likes on the articles themselves seem pretty pointless to me, though. I oppose big social media "Share" buttons as they tend to compromise user privacy and I oppose the comments on articles and files - take a look at Wikia's comments for how they tend to turn out. // Lollipoplollipoplollipop :: talk 03:28, 9 December 2020 (UTC)[reply]
  • Oppose Oppose Wikimedia should indeed not turn into a social network. JopkeB (talk) 05:05, 9 December 2020 (UTC)[reply]
  • Oppose Oppose We are not a social network. --Ján Kepler (talk) 14:12, 9 December 2020 (UTC)[reply]
  • Oppose Oppose - Wiki isn't social media. Cabayi (talk) 20:39, 9 December 2020 (UTC)[reply]
  • Strong oppose per others NMaia (talk) 01:06, 10 December 2020 (UTC)[reply]
  • Strong support Strong support --Ciao • Bestoernesto • ✉ 04:41, 10 December 2020 (UTC)[reply]
  • Strong oppose! Wiki is not social. Em-mustapha User | talk 07:03, 10 December 2020 (UTC)[reply]
  • Support Support share button; Oppose Oppose the others because of how they can be mis-used Libcub (talk) 19:41, 10 December 2020 (UTC)[reply]
  • Comment Comment @Libcub: You can already share those articles by using their URLs. This share button wouldn't improve Wikipedia either way. MarioSuperstar77 (talk) 12:29, 11 December 2020 (UTC)[reply]
  • Oppose Oppose Wikis is a different target audience and social website influence should be reduced, not increased. The WikiLove stuff implementation is bad enough. —  HELLKNOWZ   ▎TALK   ▎enWiki 22:35, 10 December 2020 (UTC)[reply]
  • Strong oppose Yeah, let's not turn this site into social media. Some1 (talk) 05:04, 11 December 2020 (UTC)[reply]
  • Support Support I sure would like to see a more 'user friendly' way of communicating with people who remove our additions and edits - this system is so NOT 'user-friendly'! One (myself included) gives up instead of even trying to provide proper supporting explanations for edits which stem from sources which are not from the normal beaten path (I shall give you an example: I belong to the descendants of several royal bloodlines. The wives in one branch of my family have catalogued events in what is called 'The Great Book of the Family' which contains centuries of events, details, dates of births, marriages, burials and more - it is extremely accurate and even answers that which we do not know about in many sources today. . . When I tried to make an edit on a biography profile of one of my royal ancestors using this rare hand-written historical record, my edit was removed and the arguments which I was given did not hold a pail of water while the person relied on misinformation which is repeated time and time again today and is simply not correct.. . . So, how do you handle something like this ...really. . .). Aside this, the 'sidebar' system does NOT work and the discussion forums suck - we need something BETTER than this! We need a BETTER means to communicate where those who remove our work can receive an E-mail from us (more discreetly) and this would contribute to reduce the level of stupidity I see in here where some 'monitors' (for lack of a better word) resort to threats when this is off-the-charts and highly unjustified as well as DAMAGING to the person complaining as oppositions are oft made with such venom it is damaging to many of those who try to work sensibly in here. FAR TOO MANY IN HERE ARE ON A POWER TRIP which has no place here... I see this happen with people who do NOT have the proper background nor education necessary to make such decisions while they arbitrarily go and make changes 'at will' and remove very valuable information. Aside this, I even noted some SLANDEROUS comments in the profile of a scientist who is a relative of mine (Personal 'opinion' in biographies here has no place either...) and while I pointed out this slanderous comment, NO ONE GOT BACK TO ME to tell me it would be removed! Wikipedia is peddling misinformation and slanderous comments which can be damaging to living human beings while there is NO JUSTIFICATION NOR MERIT FOR THIS! Some in here ought to be sued for such garbage posted with the highest wanton disregard. It is hard to 'navigate' and manage things in here and I oft decide instead to keep my material to publish in my own books later. . . The platforms in here need to IMPROVE. . . There also needs to a EASILY-ACCESSIBLE COURSE on HOW TO WORK WITHIN WIKIPEDIA - WITH explanations for ALL the codes, shortcuts, processes, etc., etc. - and this should be done using videos as well. . . —The preceding unsigned comment was added by RoyalSnowbird (talk) 09:16, 11 December 2020 (UTC)[reply]
  • Neutral Neutral I agree with the not a social network messages, and don't agree with the proposed solution, but I like the problem statement. This is what eg WikiLove aims to solve. Some people are motivated more by appreciation for their work. We use good articles / featured articles / barnstars for this mostly. But exploring more ways to make editors feel appreciated is certainly worth looking into, but I'm not sure likes/comments/sharing is quite the answer. ProcrastinatingReader (talk) 11:22, 11 December 2020 (UTC)[reply]
  • Oppose Oppose. --BoldLuis (talk) 15:32, 11 December 2020 (UTC)[reply]
  • Oppose Oppose There are already too many so-called social media in this world; please don’t turn Wiki* into another one. --Aristeas (talk) 16:35, 11 December 2020 (UTC)[reply]
  • Oppose Oppose No. --JonathanLa (talk) 17:48, 11 December 2020 (UTC)[reply]
  • Oppose Oppose We are not a social network. Francois-Pier (talk) 12:14, 12 December 2020 (UTC)[reply]
  • Neutral Neutral per Mario, Klaas `Z4␟` V:  16:18, 12 December 2020 (UTC)[reply]
  • Strong oppose any sort of embedding of social media buttons, which are just free advertisement for the companies along with the ability for them to collect information from us. — Bilorv (talk) 23:02, 12 December 2020 (UTC)[reply]
  •  Weak support I think the share button may be helpful, but that's about it. This isn't a social media site. Thanks, EDG 543 (message me) 15:11, 15 December 2020 (UTC)[reply]
  • Support Support I do find that sometimes wiki articles are too one-sided, or too oriented to a country that the creator is from, or fails to address criticism to the subject. What I do like about social media is that you get brutally honest opinions, which would be useful to improve wiki. Something like a plugin to corresponding topic in social media would be interesting. Sentiment analysis would be another side benefit. Wolfmartyn (talk) 14:51, 16 December 2020 (UTC)[reply]
  • Oppose Oppose Wikis aren't social medias, and there's already the "thank" button. Golmore (talk) 18:45, 16 December 2020 (UTC)[reply]
  • Strong oppose It will destroy Wikipedia as it would be lots of POV-pushing and meatpuppetry as there would be "wars" for who got more likes. Popular edits that are not neutral can get lot of likes while unpopular edits that are neutral will get nothing, disenfranchising people that tried to edit in a neutral way. Especially in highly polarizing article, this could reward bad behaviors but punish good behaviors. SunDawn (talk) 03:40, 17 December 2020 (UTC)[reply]
  • Oppose Oppose Such social features can be abused too easily and would in turn not bring much positive impact on encouraging editors. The issues with each individual function are:
    1. using sockpuppets to manipulate "like" count to discourage an editor
    2. spam or off-topic/personal attack messages in comments section (present in talk pages, but since talk pages are usually less visible to readers the impact is smaller)
    3. rate: pretty much the same issue as "like"
    4. share: privacy issues, many clients capable of viewing Wikipedia content already have native share capabilities --H78c67c (talk) 08:26, 17 December 2020 (UTC)[reply]
  • Strong oppose I fear that Wikipedia can turn into a battleground over likes and popularity. Positron832 (talk) 12:48, 17 December 2020 (UTC)[reply]
  • Oppose Oppose oneʼs motivation should be based on interest, not on how much fame or "likes" one gets. Seb az86556 (talk) 21:57, 19 December 2020 (UTC)[reply]
  • Oppose Oppose this is not a good idea.--Malvinero10 (talk) 03:19, 21 December 2020 (UTC)[reply]
  • Oppose Oppose We are supposed to be different than social media plattforms. Nachtbold (talk) 12:51, 21 December 2020 (UTC)[reply]
  • Support Support S8321414 (talk) 14:18, 21 December 2020 (UTC)[reply]

Support more OSM relation types in Extension:Kartographer

  • Problem: The Kartographer extension can only display OSM relations of type multipolygon, route, and boundary on maps. Other relations like waterway, superroute, network etc. can not be displayed.
  • Who would benefit: Readers and editors of wiki pages which can be improved with interactive maps displaying OSM relations which are now unsupported.
  • Proposed solution: Add support for more or ideally all OSM relation types in Kartographer. Especially waterway relations (typically rivers) and superroute relations (typically international routes) would be nice to display.
  • More comments: OpenStreetMap (OSM) have free geodata for most geographic features in many parts of the world. It can be a big help for many Wikipedia articles and Wikivoyage to have access to these data to generate interactive maps showing their topics.
  • Phabricator tickets: T156433
  • Proposer: Dipsacus fullonum (talk) 01:28, 21 November 2020 (UTC)[reply]

Discussion

Voting

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/sort edits by number of bytes added/subtracted
    • Show/hide my edits
    • Sort edits by IP/username
    • Show/hide selected user's edits (if this is deemed uncontroversial)
    • Show/hide deleted edits (for administrators only?)
  • More comments: Reposting from 2017 survey
  • Phabricator tickets: T18619, T97020
  • Proposer: Renata3 (talk) 02:38, 17 November 2020 (UTC)[reply]

Discussion

Voting

Add a tracker for CSS selectors

  • Problem: We don't have a query service for searching CSS selectors (e.g. id and classes). It makes really hard to clean up the legacy codes. Because of that, it took several years to supersede deprecated "prettytable" class in Commons. Until the legacy selectors are completely eliminated, we must keep the legacy codes for really long time. Also, we are not able to evaluate the impact of the style modifications.
  • Who would benefit: interface administrators and developers, template editors
  • Proposed solution: Add a special page to search pages using the specific id or class selectors
  • More comments:
  • Phabricator tickets:
  • Proposer: – Kwj2772 (msg) 14:56, 18 November 2020 (UTC)[reply]

Discussion

  • Hello Kwj2772! You should be able to identify use of CSS selectors by simply doing a insource search. For example, here is an example of where I'm searching for the wpFilterRules selector (I intentionally did not include the # (ID) symbol in case there was some JavaScript that used for instance document.getElementById()). You can also search via regular expression. If you need to search across multiple wikis, try the Global Search tool. That tool has a convenient link to search only JS/CSS/JSON as well. It also supports regular expressions, among other features. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 21:33, 18 November 2020 (UTC)[reply]
  • Kwj2772, what I have been doing recently is a search like this: insource:infobox insource:class insource:/class[^}]{0,25}infobox/ prefix:A. Basically, looks for insource:infobox and insource:class, then also insource:class followed by no template-end characters up to 25 times, then the word infobox, for all pages that start with A. Hope this helps in your future. --Izno (talk) 16:02, 11 December 2020 (UTC)[reply]

Voting

Add a Quick Settings Panel/Page

  • Problem: In order to change simple settings, you have to navigate through a fairly lengthy Preferences section with many pages.
  • Who would benefit: Readers (as in, people who come just to read, not to edit), less experienced editors, anyone who frequently changes a setting.
  • Proposed solution: I propose that their should be a sort of quick setting panel or page, one that is very straight forward and simple for just a regular, non-techsavvy person to do simple things, such as change font size, time, appearance, language, I don't really know, just whatever the most changed settings are. It would be very clean and simple, and maybe even customizable for logged in users to include a few of their favorite settings, but that last part isn't the main point. The main point is making it very easy for the average reader to change a simple setting.
  • More comments:
  • Phabricator tickets:
  • Proposer: Thanks, EDG 543 (message me) 15:52, 17 November 2020 (UTC)[reply]

Discussion

Pbsouthwood, well, it's not so much that the individual would need to change the setting over and over, I just was referring to a setting that any random user (non-editor) would likely want to change but couldn't because of there is no easy way for them to change it. I don't really know which specific setting the average reader would want to change, but it wouldn't be hard to conduct a survey or something. Thanks, EDG 543 (message me) 14:43, 30 November 2020 (UTC)[reply]
EDG 543, Thank you for clarifying. It would appear that the first step would be to establish a need and the settings that would be involved. Cheers, · · · Peter (Southwood) (talk): 06:00, 1 December 2020 (UTC)[reply]

Voting

Global events calendar

  • Problem: It is hard to keep track on what events are planned, going on or happened, especially online ones (across time-zones) which leads to people that would have enjoyed, and constructively contributed to, are missing some events. This is due to several factors, and mostly in escalation of events (and meetings) online, as it makes it possible to attend previously local/physical events.
  • Who would benefit: All users that are (potentially) interested in organizing and attending events.
  • Proposed solution: A single place to promote and coordinate events. The most important part is that this calendar manage to capture all events in the entire movement, no matter what type they are or which part of the community is organizing it. This should be filterable by language(s) used, place and platform, but also possibly by project, theme, capacity, urgency or even custom #hashtag. The system should have few good calendar view options. A feature to export events to your personal calendar would be nice to have. Another nice to have feature (if it's not possible to the regular watchlist) is to subscribe to changes via email or via user talk page. Perhaps a feature that would really make this spreading across the projects quickly would be the ability to transclude a filtered selection of the events in another project.
  • More comments: There are some previous work in this topic, the best working solution in my opinion right now is Events calendar. On meta there is also Events and the experiment on Wikimedia Space was promising.
  • Phabricator tickets:
  • Proposer: ♥Ainali talkcontributions 09:55, 22 November 2020 (UTC) and Zblace (talk) 12:47, 22 November 2020 (UTC)[reply]

Discussion

  • I would not mind seeing an option of also projecting tentative event plans in calendar just to avoid collisions and potentially have coordination (or even collaborations) of such events. Zblace (talk) 16:45, 22 November 2020 (UTC)[reply]
    That's perhaps a useful tool, but then it's not just a calendar anymore but almost a full-fledged project management tool. Let's keep this proposal to something smaller. ♥Ainali talkcontributions 16:51, 22 November 2020 (UTC)[reply]
    Awesome! Note that Wikimedia CH is developing this wiki-Calendar with federation in mind that may be our solution: Meta:Wikimedia CH/Cronos --Valerio Bozzolan (talk) 08:37, 24 November 2020 (UTC)[reply]
    @Valerio Bozzolan: would you mind writing some kind of introduction on that page? Like what is it for, who is building it and what is the timeline? Right now it's quite hard to get a grasp of and even though you posted the link here several times, I didn't understand the purpose of it. ♥Ainali talkcontributions 16:40, 3 December 2020 (UTC)[reply]
    @Ainali: Ouch... yes that homepage was terrible... is it better now? --Valerio Bozzolan (talk) 00:02, 4 December 2020 (UTC)[reply]
  • I totally support this proposal :) As more and more events are organized by various stakeholders, a real calendar tool is very much needed. As Jan mentioned, the attempt on Wikimedia Space was promising, but was mostly a blog post tool tweaked into a calendar, which came with issues, such as the unability to list events tagged with a certain tag in the order of the date. See also a former discussion about needs for a calendar tool for Wikidata-related events.
    I'd also mention the need of dealing with various time zones. For the Celtic Knot Conference 2020 we had a dedicated user script, for the Wikidata birthday we used an external website, none of these options are ideal. Lea Lacroix (WMDE) (talk) 17:06, 24 November 2020 (UTC)[reply]
  • I support this proposal. This allow small to large organizers notify the community on what event they plan to organize, and to make it easy for users to plan their commitments ahead of time. This also reduce the burden of doing an extensive search in meta pages & local language wikis. Exec8 (talk) 14:12, 27 November 2020 (UTC)[reply]
  • Yes! there have been a few attempts to do this, and it's harder than it seems because of issues of multilingualism and helping people know the calendar exists, but it's very needed. -- phoebe | talk 15:48, 27 November 2020 (UTC)[reply]
  • absolutely necessary to track all community meetings and events so people can allocate time as necessary Gnangarra (talk) 04:17, 29 November 2020 (UTC)[reply]
  • I've noted elsewhere, but it's worth reiterating that a highly valuable open source tool for collaborative event scheduling was developed for the open publishing fest. The full code and implementation is at this github link. If possible, it would be more efficient and effective to use this system compared to organising only on-wiki (e.g. ability to filter events by region, theme, and format). I am certain the devs (Julien Taquet, Yannis Barlas, Boris Budini & Kevin Muñoz) could be asked to assist in setting setting up. T.Shafee(Evo﹠Evo)talk 04:26, 29 November 2020 (UTC)[reply]
  • I completely support this proposal and invite volunteers to work on translating the same for a greater reach.Rajeeb (talk) 07:00, 29 November 2020 (UTC)[reply]
  • We truly need this proposed Events Calendar and I wholly support it. User:Buszmail (talk) 03:26, 30 November 2020 (UTC)[reply]
  • I su
  • While for face-to-face meetups we have the calendar already, but not so for online. This is a good initiative, in which we can have one centralized page of listing all of the online Wikimedia events which are open to public (anyone can join, not just by invitation). I believe we can have that based on sequential date and also by its language medium (if it will be done in English or other language). And also not to forget to list down the topic, preface or minutes from any previous discussion (if that event is a follow up ones). Time should be listed in that particular country timezone (usually the main organizer/speaker) and UTC/GMT timezone, plus we shall add a one-click timezone converter (for time & date adjustment). Chongkian (talk) 04:23, 30 November 2020 (UTC)[reply]
  • I totally support this proposal and we need this. Ninja✮Strikers «☎» 05:20, 30 November 2020 (UTC)[reply]
  • Hello, I'm Chris on the Movement Communications team at the Foundation. One possibly I've been talking with the Events team about recently is a central community calendar. Folks at the Foundation (like those on the Events team and myself in Comms!) agree that it's a problem for the movement to not have a centralized, well-supported, easy to use calendar. One possibility we're considering was a calendar in Diff, the community-focused blog. It's the successor in many ways to the Wikimedia Space prototype Jan mentioned. Diff runs on WordPress (open-source, pre-existing, and well-supported), is multilingual, open to participation, and soon you'll be able to authenticate with your Wikimedia account. While it's early in the discussions, I've been looking at something like The Events Calendar plugin (demo). I'd love to hear your thoughts. I personally think supporting a central resource like a community calendar is something the Foundation is well suited to do. :) CKoerner (WMF) (talk) 15:50, 30 November 2020 (UTC)[reply]
    @CKoerner (WMF): As already note (apologies) here a relevant prototype: Meta:Wikimedia CH/Cronos, that is a MediaWiki calendar trying to be accessible (no JavaScript), federated (support multiple sources - still needing some thoughts), and it works without extensions or gadgets. Could it be interesting? --Valerio Bozzolan (talk) 16:35, 30 November 2020 (UTC)[reply]
    Having a link named "calendar" beside the "logout" option on the upper right across all wiki projects (meta, wikipedia, etc) will allow any user peek though events of the movement. Exec8 (talk) 06:14, 1 December 2020 (UTC)[reply]
    @Exec8: Interesting feature. I want to bring your idea to the attention of the Meta:Cronos project manager. --Valerio Bozzolan (talk) 15:45, 2 December 2020 (UTC)[reply]
  • This would be a great proposal if it also offers reminders to be written on user talkpages. It could become part of a wider set of tools for remote participation, something that this corona year has shown to be very desirable. I think remote participation options can enable not just better documentation beforehand due to capturing and answering more questions beforehand, but also perhaps enable better documentation during and after the event, just because more people can attend. Jane023 (talk) 18:03, 30 November 2020 (UTC)[reply]
  • We (WikiDonne) tried to adapt Les sans pagEs's French calendar (in this moment I cannot find to give it as example) to our uses, but an international one to be used in all projects (with an icon for the related project which is refered) is much needed. --Camelia (talk) 16:44, 1 December 2020 (UTC)[reply]
  • This is so much needed!! From Europe, I pointed our fairly new Caribbean contributors to the Wikimedia North American conference which I happened to come across. I would have never seen that, had I not stumbled on the request for a CN banner on Meta. So yes: help the word get around and create one big overview! Ciell (talk) 16:07, 2 December 2020 (UTC)[reply]
  • I support this as it is so badly needed now that we do so many things virtual and not in person. However, any system must be flexibly editable via wiki or other platforms. That is, we need a system to sync up changes so that whether things are edited on wiki, or in a modern calendar system (Google, Airtable, whatever) they are reflected back out to the systems of users. Otherwise, requiring all the event content to be centrally locked up in one place would seem to defeat the purpose of such a system. -- Fuzheado (talk) 18:19, 2 December 2020 (UTC)[reply]
    It could be Wikidata Bridge like solutions right? Like, all the "actual" editing could be happening in only one place, but the user doesn't need to leave their wiki to edit. This removes the need of "syncing" since it's all stored in one central place (just like Wikidata). (And also, "locking things up centrally" in Commons and Wikidata was a great improvement even without Bridge and so I think a centrally edited solution would be an improvement even if it is not a perfect system.) ♥Ainali talkcontributions 08:03, 3 December 2020 (UTC)[reply]
    @Fuzheado: any system must be flexibly editable via wiki or other platforms: 100% sharing your values and working on this prototype to cover your ideas: it keeps everything on the wiki, allows to create or edit an Event using wikitext, using VisualEditor or add one event using one easy external web form but keeping everything on the wiki also in this case. Well, we can stay in touch to improve/test/fix some features to discover if this prototype makes sense. --Valerio Bozzolan (talk) 09:18, 3 December 2020 (UTC)[reply]
  • Just a note, I have moved this to the Miscellaneous category as it was the only proposal in Programs & Events. Best, MusikAnimal (WMF) (talk) 19:30, 7 December 2020 (UTC)[reply]
  • It is really interesting to observe how the same idea appears simultaneously in different places. In October, I started making a tool that could collect information about events from different pages: events.toolforge.org. And as it turned out, this is not such an easy task, because in the Wikimedia community there are dozens of different places and formats in which planned events are announced (most of them are not machine-readable). It also turned out that we globally do not announce recurring events, and in the end I decided that the best option at that moment was to improve the Events calendar. There is also a @wikimedia_events Telegram channel works now and it broadcasts events from the calendar, but there are still problems with the update timeouts (we also use similar announcements in one of the Russian-language channels). But all these actions are just an attempt to somehow improve the current situation with a complete lack of communication between different parts of the Wikimedia community. I'm not sure which solution we need: will it be a tool for adding events or a tool for parsing events, or maybe we just need to ask all the Wikimedia teams and organizations to just start publishing their events in one of the existing places. But we definitely need a solution that allows users to be aware of all the events that take place within the Wikimedia community. — putnik 17:30, 9 December 2020 (UTC)[reply]

Wikimedia CH and Cronos, the cross-wiki calendar

Hello everyone, I confirm that the problem of a cross-wiki calendar was a very sensitive issue for Wikimedia CH which immediately proceeded to find a solution already in 2018 for a cross-wiki calendar to serve all communities. Not having a single Wikipedia community, as Switzerland is multilingual, the issue had a high priority as we have a calendar for German community, another for French community, another for Italian community, another for the association and another for Wikidata community. We currently have a calendar but it requires manual updating and, like all calendars, it can't sync with others.

We looked at the existing solutions but they didn't satisfy us for several reasons. For example, it required the installation of a gadget or someone was not adequate on mobile but the main issue is that they were not able to be federated.

So in 2018 we dedicated part of our budget and set an expert team (Valerio Bozzolan and Wiki Valley) to create a new solution for us that had these characteristics:

  • possibility to include the calendar in every wiki using a template
  • facilitated insertion/update through a single form for all wikis but allowed only to users logged in through Oauth
  • easy configuration of the federation of calendars
  • responsive interface
  • no installation of gadgets or configuration of JS by the user

The project has been completed in its first version and will be released shortly on our pages. The same project can be used safely by any Wikimedia community. We are working on better documentation. --Ilario (talk) 10:59, 11 December 2020 (UTC)[reply]

  • Evidence that the support button does not work properly. It has put it here, instead of in the right place.

Export and zoom - videoconferencing

Voting