Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Miscellaneous

< Community Wishlist Survey 2023
Community Wishlist Survey 2023
Miscellaneous
20 proposals, 248 contributors, 565 support votes
The survey has closed. Thanks for your participation :)



Add user-profile previews to page previews

  • Problem: It can be difficult to get a quick insight to who an editor is and access the information relevant to them.
  • Proposed solution: Expand Page previews with functionality to show a small profile of a User. It could show join date, user groups, edit count over last 30 days, if they are blocked or not, a link to their talk page and contributions, and maybe something like their mentor from Growth. All kinds of little helpful nuggets of information. There could also be an optional lede/intro and page image provided by the user.
  • Who would benefit: Makes it easier for editors to get some insight into a user really quickly, straight from talk/history/RC pages etc. Makes this functionality, which is already a feature of the 18 year old navigation popups and makes it available to all Wikimedia editors.
  • More comments:
  • Phabricator tickets:
  • Proposer: —TheDJ (talk • contribs) 15:46, 5 February 2023 (UTC)Reply[reply]

Discussion

Voting

Possibility of thanking for more subsequent edits

  • Problem: Somebody made subsequent edits in a single article in a short period of time. I see them in my watchlist and I can add "thanks" for a single edit. But when I open the diff (example), I must first go to history, select one of edits and thank for single edit only.
  • Proposed solution: For subsequent edits of one user, provide the [thank] link in the diff view.
  • Who would benefit: Editors and watchlist users
  • More comments: The notification could read "You received thanks for your edits in <compare link>".
  • Phabricator tickets:
  • Proposer: JAn Dudík (talk) 08:20, 31 January 2023 (UTC)Reply[reply]

Discussion

I would very much appreciate this. It's sort of stupid to thank someone for the last edit in a link, one that was probably a minor fix to spelling, when you really appreciated the series of edits. Daniel Case (talk) 00:00, 1 February 2023 (UTC)Reply[reply]

You could just thank the largest edit. I don't think thanking a range would be hard technically, but for a less experienced user the link to a combined diff might be less understandable than the diff to a single edit. They will still see the specifics of their last edit (timestamp, edit summary etc) as that's how range diffs are displayed. (The task for improving that is T14191.) --Tgr (talk) 03:55, 5 February 2023 (UTC)Reply[reply]

The problem is that I usually see only the last in a series of edits. Or no one edit is the one I found most helpful. Daniel Case (talk) 06:21, 18 February 2023 (UTC)Reply[reply]

Voting

Search bar at preferences

  • Problem: Too many preferences, no way to easily search through them
  • Proposed solution: Add a simple search bar to function as a filter
  • Who would benefit: Everyone
  • More comments: The title is self-explanatory.
  • Phabricator tickets: T313804
  • Proposer: Klein Muçi (talk) 13:55, 27 January 2023 (UTC)Reply[reply]

Discussion

This may be the same solution that phab:T53147 is looking for, just for all the prefences not just one tab of them. — xaosflux Talk 15:30, 27 January 2023 (UTC)Reply[reply]

  • Xaosflux, I'm not sure if T313804 has thought about this detail (it didn't look so with a quick glance at the comments) but I'd wish that the said search bar would work with the English terms no matter what language was chosen, same as English namespace terms work globally. A lot of time you'll read documentation or help pages referencing a specific preference that needs to be toggled but you'll have no idea what that preference is actually called in your language (documentation is usually provided in English). — Klein Muçi (talk) 16:45, 27 January 2023 (UTC)Reply[reply]
    It could probably be set to work the the canonical name (generally in English) and the label name. — xaosflux Talk 16:52, 27 January 2023 (UTC)Reply[reply]

Voting

Improvements to requested articles pages

  • Problem: In my opinion, as a relatively novice user, the requested articles pages on English Wikipedia are a bit daunting. For example social sciences or music. There's a really long list of requested articles. Sometimes they're already completed but they're still listed. Other times they have a redirect but aren't completed. There can be a description or just a title. Sometimes there are sources with full names or just numbers. It's not easy to see what's actually a candidate for making an article versus just a request without any research. I only just today that there's even a list of rejected requests.
  • Proposed solution: I don't have a concrete idea of how this could be improved but I'd love to hear what others think.
  • Who would benefit: I think this would be helpful for users trying to request an article, for editors looking for things to write, and generally to encourage people to get involved by an easy first step like requesting an article.
  • More comments: Some small ideas include:
  1. A voting system, so people could show support for articles they want. This would be nice because I think many people want to write about things that many others are interested in.
  2. A way to automatically show people existing/past requests before they add a new one.
  3. A way to automatically remove articles (or suggest to remove them) one they've been created.
  4. A standardized way of listing sources (this and the following kinda fit into the category of making a template for requests)
  5. A standardized way of writing a description of the page and maybe even why you personally find it interesting.
  6. A field that would let people indicate if they have found something to be notable or not notable yet.
These are just a few rough ideas coming from someone who occasionally makes pages but would like to request pages more often and may be more motivated to make pages if I see others requesting it or voting for it.

Discussion

@RayScript: We just wanted to clarify with you if this is English Wikipedia specific? Thanks for your time in making this proposal! GMikesell-WMF (talk) 21:19, 1 February 2023 (UTC)Reply[reply]

I am not familiar with the requested articles process on other language Wikipedias. However, I assume that it's relatively similar so this would apply to multiple languages. RayScript (talk) 10:32, 2 February 2023 (UTC)Reply[reply]

Hey, Ray - I don't think this is a good fit for this survey in particular, since a change to the structure of this process on en.wp requires only local initiative, not developer time. If you want my honest opinion, the whole concept is just plainly moribund and no longer serves any particular purpose, if it ever did. Might be more productive to just try and stick a fork in it, since I'm not sure anyone would even care enough to object. Doctor Duh (talk) 22:04, 10 February 2023 (UTC)Reply[reply]

I totally get this and agree with some of it! About #2: There are a lot of cross links that are outrageous in content and organization. I think a forced template could fix this. The template would include these things and make them "required". It should check for duplicates or similarities rather than require the user to do so because most won't look themselves. I understand the popularity subjects #'s 1, 5 and 6, but what we want and what we need are two different things. For example, Wikipedia has become very popular with college students, who come here to research a subject. I myself use it for research. I believe #4 is being addressed in Citations, and that is probably the #1 complaint: the tediousness of adding citations. That alone deserves a vote. They're always a mess and editing is a nightmare. Magnoliasouth (talk) 23:59, 10 February 2023 (UTC)Reply[reply]

Voting

Add a new content model for member lists

  • Problem: When users join a user group, a WikiProject, etc., they usually sign on a particular page or section. However, users can be renamed. And after the renaming, the signatures on various pages won't change automatically. It can lead to trouble when trying to find a particular user on a list, especially after the renaming didn't leave a redirect behind.
  • Proposed solution: Develop a new content model or extend MassMessage lists, so that users can more easily sign up for a project. The page stores the user's user ID (and other data like timestamp). When being viewed, the page shows the signed users' current usernames.
  • Who would benefit: Users who sign on pages before renaming, users who wish to navigate others via lists on wikipages.
  • More comments:  
    1. The content model should allow "edit source." (i.e., if it uses JSON, we should be able to edit the JSON file.)
    2. Entries should include user ID (automated), note (optional), timestamp (automated). Should allow strikethrough and postscript (useful when user is announcing departure).
    3. Since some users would like to quit and join again, it should allow multiple signatures from one user.
  • Phabricator tickets:
  • Proposer: 魔琴 (talk) 09:56, 26 January 2023 (UTC)Reply[reply]

Discussion

  • Hi @魔琴:. This wish includes a lot of technical detail. I think it might be wise to rename it into something like "Allow changing signatures in old content" or something that at least be more understandable to the general voting audience ? —TheDJ (talk • contribs) 23:37, 26 January 2023 (UTC)Reply[reply]
    @TheDJ: I fear one will misterpret "changing signature" as the action you do in Special:Preferences. How about "Develop a sign page which auto-updates after username change"? --魔琴 (talk) 02:59, 27 January 2023 (UTC)Reply[reply]

I think changing wikitext in old content would be way off here. It sounds like this needs 2 parts, that may not be "very hard":

  1. Have a way to stamp your userid to a revision (e.g. 魔琴 --> 14127964)
  2. Have a function to retrieve the current username for an id (e.g. 14127964 --> 魔琴)

Then someone could "sign" a page, and the display would be able to show their username. @魔琴: is that what the root of what you are looking for is? (i.e. that is, it isn't really about what style of 'signature' you have configured in prefences). The API is already able to access all of this, so it isn't secret - there just isn't a magic function for it. Of course, if this is in a page revision it wouldn't dynamically update until a purge or subsequent edit occurred. — xaosflux Talk 15:17, 27 January 2023 (UTC)Reply[reply]

@Xaosflux: Yeah, I think that's an economical way to do it. Suppose we have parser functions {{userId}} and {{username}}, we can sign with {{username:{{safesubst:userId}}}} or something like that. --魔琴 (talk) 16:04, 27 January 2023 (UTC)Reply[reply]
I think both of those magic words can be implemented quite easily. What makes this wish difficult is updating the HTML whenever the signature changes. In doing this we have to invalidate the cache. For someone like Xoasflux who has 13,000+ talk page edits on just one wiki, that's potentially 13,000+ pages that need to be re-parsed. User's signatures should not have this kind of effect of the job queue, which is why we discourage using templates in signatures.
Also worth mentioning is the talk pages project, which essentially cements the use of wikitext in on-wiki communication. If we were to change how signatures work, I can only assume mw:Extension:DiscussionTools (or at least the reply tool) would need to be radically reworked as well. MusikAnimal (WMF) (talk) 20:59, 30 January 2023 (UTC)Reply[reply]
@MusikAnimal (WMF): I don't mean changing the signatures on talk pages. I'm talking about the "members list" some WikiProjects or User Groups are using to list the users who participate in them. Like w:en:Wikipedia:WikiProject Chile#Members or Persian Wiki User Group#Participants. But the parser functions would be abused, now I'm aware of. Maybe a new content model, which would restrict the usage, would be better? --魔琴 (talk) 02:25, 31 January 2023 (UTC)Reply[reply]
@魔琴 Ah, I'm terribly sorry I misread this! That seems considerably more "doable" than auto-updating signatures across a whole wiki :) I don't really know exactly how hard adding a new content model would be, but it seems probably within Community Tech's scope.
I realize in your problem statement you clearly say "When users join a user group, a WikiProject, etc., they usually sign on a particular page or section", which I somehow skimmed over, but would you mind if we rename your proposal? A more fitting title might be "Add a new content model for signatures". I wonder what "SignPad" is and if that is that something voters need to be aware of? MusikAnimal (WMF) (talk) 03:58, 31 January 2023 (UTC)Reply[reply]
@MusikAnimal (WMF): I think it would be great! But maybe the word signature will still lead to misunderstanding. How about "member lists" instead? --魔琴 (talk) 05:12, 31 January 2023 (UTC)Reply[reply]
Even better! I agree, saying "signatures" could lead someone else thinking you meant replacing signatures everywhere, and we don't want to give that impression!
Before we rename it, let me run this by the team again tomorrow. With the scope now clarified and much smaller, I think we can probably move it back into Miscellaneous. Apologies again for the hasty assessment of your proposal. MusikAnimal (WMF) (talk) 05:24, 31 January 2023 (UTC)Reply[reply]
That would be great. Thank you for your effort. --魔琴 (talk) 10:39, 31 January 2023 (UTC)Reply[reply]
Done, and no problem :) MusikAnimal (WMF) (talk) 21:12, 31 January 2023 (UTC)Reply[reply]
  • @魔琴: This proposal would be out of scope for Community Tech. It is a valid proposal though, so I will move to Larger Suggestions. Thank you for participating in this survey! HMonroy (WMF) (talk) 22:56, 30 January 2023 (UTC)Reply[reply]
    @HMonroy (WMF): May I ask which criterion it meets? --魔琴 (talk) 02:30, 31 January 2023 (UTC)Reply[reply]
  • I think this essentially asks for the deployment of CollaborationKit. Which might or might not be a larger suggestion, I'm not sure about the state of that extension. T123028 has a very long list of resolved subtasks and nothing open, so that looks encouraging. --Tgr (talk) 05:32, 1 February 2023 (UTC)Reply[reply]
    @魔琴 Have you reviewed CollaborationKit as mentioned above, and if so, do you think it could suit your needs?
    I agree with @Tgr that CollaborationKit seemed fairly close to production, before apparently losing steam. The most recent security review was only two years ago. Regardless of how much code has changed, it does seem like a large ask for Community Tech to become familiar with this extension and its many quirks. I think it'd be awesome for us to shepherded it through to production, but we'd probably need someone familiar enough with it to help get us acquainted. MusikAnimal (WMF) (talk) 16:04, 1 February 2023 (UTC)Reply[reply]
    Maybe the CollaborationKit developers (@Bawolff, @Isarra, @Harej) have some advice on that? Tgr (talk) 20:12, 1 February 2023 (UTC)Reply[reply]
    To me this sounds kind of a bit like MassMessage delivery lists. Bawolff (talk) 20:45, 1 February 2023 (UTC)Reply[reply]
    It does, but the proposer specifically wants signatures. Perhaps the solution here is only changes to mw:Extension:MassMessage. That for sure sounds within CommTech's scope. MusikAnimal (WMF) (talk) 23:00, 1 February 2023 (UTC)Reply[reply]
    I guess so? But I don't know if it suits User Groups. I don't think it supports timestamps but they're not that necessary. It looks like a useful extension; why hasn't it been implemented? --魔琴 (talk) 14:21, 2 February 2023 (UTC)Reply[reply]
    @魔琴: We're not sure what the state of CollaborationKit is, but we pinged the relevant developers above. At any rate, I think we have enough to approve this proposal. I have made a few more slight tweaks, including suggesting that improving mw:Extension:MassMessage as a possible solution. As per above I think that's probably the easiest path forward. Does the new wording of the proposal look okay to you now? If so I will approve this propsoal and mark it for translation. Thanks, MusikAnimal (WMF) (talk) 17:20, 3 February 2023 (UTC)Reply[reply]
    @MusikAnimal (WMF): Yes, thanks. --魔琴 (talk) 03:23, 4 February 2023 (UTC)Reply[reply]
    Okay thanks! Done. MusikAnimal (WMF) (talk) 03:48, 6 February 2023 (UTC)Reply[reply]

Voting

Links for preferences

  • Problem: We have links for preference tabs. We don't have links for individual preferences in those tabs.
  • Proposed solution: Have links for individual preferences the click of which highlights the said preferences.
  • Who would benefit: Everyone, mostly new users.
  • More comments: Many times in help requests you'll need to toggle on or off certain preferences. You either get told to do so, or tell someone you're trying to help. Currently you can't link to individual preferences, only to their tabs. This complicates matters with new users who may get easily confused, especially when what you're talking about is not in the same language as the one they're reading their preferences in. Having links for them would make everyone's lives easier and greatly tone down the need for screenshots in these cases.
  • Phabricator tickets:
  • Proposer: Klein Muçi (talk) 17:29, 27 January 2023 (UTC)Reply[reply]

Discussion

  • Technically you can link to them, but it's not really useful without highlighting. The task is T295302. --Tgr (talk) 02:41, 1 February 2023 (UTC)Reply[reply]
    They can be highlighted, although only on a per-section level, not on a per-preference level. (See screenshot in said task.) —Tacsipacsi (talk) 20:08, 13 February 2023 (UTC)Reply[reply]

Voting

Add "No keyword" as the default option in the Gerrit search dropdown list

  • Problem: If the last word you entered in the Gerrit search box is part of a Gerrit keyword (e.g., "merged"), you would be forced to manually modify the URL after hitting the "Enter" key, because a dropdown list with Gerrit keywords (ending with colons) would pop up.
  • Proposed solution: Add "No keyword" as the default option in the Gerrit search dropdown list. That way, if you really meant to search for the word "merged", you would not be forced to enter a random date after "mergedafter:" and then manually modify the URL.
  • Who would benefit: Gerrit users
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 16:27, 3 February 2023 (UTC)Reply[reply]

Discussion

The following all work:

  • put the keyword in quotes
  • add an extra space at the end
  • hit ESC to hide the dropdown
  • hit a horizontal cursor key to hide the dropdown
  • hit a "noop" key (e.g. shift or insert) to hide the dropdown

--Tgr (talk) 00:08, 5 February 2023 (UTC)Reply[reply]

Also I'd recommend proposing this in the Gerrit issue tracker first, and making sure they wouldn't oppose such a change, as it would have to be done upstream. --Tgr (talk) 00:11, 5 February 2023 (UTC)Reply[reply]

Voting

Checksums of files at dumps.wikimedia.org

Discussion

Voting

Fix Wikipedia IFTTT integration

  • Problem: Wikipedia IFTTT integrations are broken
  • Proposed solution: According to phab:T294448#7584863, the code of the IFTTT service needs to be rewritten
  • Who would benefit: Wikipedia current and potential reader and editor using IFTTT
  • More comments: In 2015, WMF partnered with IFTTT to create a Wikipedia IFTTT channel with a bunch of applets to automate content delivery, e.g. get the word of the day sent to me as a text message, automatically update my Android wallpaper to the featured image of the day, etc. (https://ifttt.com/wikipedia). details see [1]. They are all broken after September 2021.

(Usage data from phab:T294448#7583788)

Discussion

  • Update from the phab ticket: there is apparently an updated fork by BDavis (WMF) which maybe able to be used as a replacement for the broken integration. Robertsky (talk) 09:53, 11 February 2023 (UTC)Reply[reply]

Voting

Vote and statistic server

  • Problem: Non-existent easily and quickly available voter statistics on vote.wikimedia.org
  • Proposed solution: Expand vote.wikimedia.org about voting and analytics tools.
  • Who would benefit: Provide statistics and results in one click (for non-technical election administrators). Bring better presentation of results example n. 1, example n. 2 or example n. 3.
    • Offered overall statistics for current elections and comparison of different ones with each other
    • Efficiency. The statistics and characteristics of the voters (like rights, aka home wiki, how the contribute wiki) are the same for every vote.
    • To have one expert position (as well as technically) in terms of statistics, which is known in the Wikimedia Movement.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dušan Kreheľ (talk) 20:37, 5 February 2023 (UTC)Reply[reply]

Discussion

Voting

Update TemplateStyles CSS rules to current CSS spec versions

  • Problem: The CSS specification is undergoing major changes. For example, CSS logical properties and values, CSS variables, etc. However, TemplateStyles has not kept up with the updated CSS specification. Therefore, when using these new properties and values, you will get the error "Unrecognized or unsupported property" and will not be able to save them.
  • Proposed solution: Update properties and values that are supported by all modern browsers (which can be found by checking Can I use) to correspond to TemplateStyles, unless experimental, deprecated, or cannot be supported for security reasons. If the CSS sanitizer requires significant effort to update to support all CSS, external tools (e.g., stylelint) may be utilized.
  • Who would benefit: Template authors who want to use new CSS properties. The same goes for Wikisource users who use Page styles.
  • More comments:
  • Phabricator tickets: phab:T322482, phab:T320322, phab:T277755 and others listed at https://phabricator.wikimedia.org/tag/css-sanitizer/
  • Proposer: Likibp (talk) 16:57, 31 January 2023 (UTC)Reply[reply]

Discussion

  • I was just about to propose something like "update TemplateStyles CSS rules to current CSS spec versions". I don't want to sort-of duplicate this, but I feel a TemplateStyle request could be more ambitious - most of the time required from CommTech would be figuring out how the whole thing works, once you get that, adding one rule vs. several rules is not that huge a difference. The last update was three years ago, a bunch of CSS specs have changed since then. Some features have been requested explicitly, but the most maintainable (and most mindful of the sanity of the person who will update it the next time) would be to just select some CSS specification versions which are currently reasonable well-supported and then compare them to the versions currently used by TemplateStyles and apply all changes. CSS spec drafts usually come with a section explaining what changed compared to the previous version(e.g.) and implementing that will be a lot more manageable in the long term than cherry-picking and trying to keep track of what's in and what's out. --Tgr (talk) 01:29, 2 February 2023 (UTC)Reply[reply]
  • @Likibp: We reviewed this proposal and before approving it we would like to ask you if you would like to update it to include "update TemplateStyles CSS rules to current CSS spec versions" as Tgr mentioned so that your proposal makes a bigger impact :). HMonroy (WMF) (talk) 22:11, 3 February 2023 (UTC)Reply[reply]
    Yes, I would like to be updated on that proposal. Likibp (talk) 17:13, 5 February 2023 (UTC)Reply[reply]
    Proposal updated.Likibp (talk) 13:17, 6 February 2023 (UTC)Reply[reply]
  • Some things I think updating this library needs to think about in general, which I think the previous maintainer was pretty correct about: 1) accepting changes only from revisions that have reached a certain kind of published status (e.g. not editor's draft but instead candidate recommendation); 2) not just updating the set of documents supported in the library already but the set of documents that have have been created since the library was originally devised. Izno (talk) 07:41, 13 February 2023 (UTC)Reply[reply]
    • Thanks for pointing that out. To a decent extent I was also guided by usage data (e.g. https://caniuse.com/): if there were high levels of browser support for something from a draft I'd be inclined to pull it in (particularly draft updates to an existing recommendation). And if a recommendation was published but hadn't been picked up by browsers for years, that was a negative sign. The other thing to keep in mind is the security aspect: any syntax allowing reference to an external resource needs to enforce filtering, which also means something like CSS Variables is difficult. Anomie (talk) 13:45, 14 February 2023 (UTC)Reply[reply]

Voting

Show syntax highlighting on View Source/protected pages

Discussion

  • I had a similar idea on WP's idea lab a few years ago: Allow previewing protected pages. SD0001 suggested that it had already been declined by devs on the grounds that it would be confusing to newcomers, but I don't buy that because we can show sufficient warning before they can preview it. Nardog (talk) 07:35, 25 January 2023 (UTC)Reply[reply]
  • Newcomers are a very important user group for us, that we are trying to accommodate as much as possible, so it might very well be that we decide in their favour. I do understand the thought of the wish though, it can be helpful to understand the template code. KSiebert (WMF) (talk) 10:54, 25 January 2023 (UTC)Reply[reply]
    • Note WikiEditor is already loaded on protected pages where CodeEditor is loaded (example). I imagine it would be a relatively simple flip of a switch. The absence of the "Publish changes" button already communicates the situation quite clearly, and, more to the point, I fail to see how loading of WikiEditor could affect newcomers' ability to understand it. Nardog (talk) 06:29, 26 January 2023 (UTC)Reply[reply]
    Not sure why syntax-highlighted wikitext would be more confusing to new editors than non-syntax-highlighted wikitext. I'd worry about performance implications though - CodeMirror can be quite slow for large pages. --Tgr (talk) 02:23, 1 February 2023 (UTC)Reply[reply]
  • It's a good proposal. It's probably too late for that, but I'd put it in the Editing section and not in Miscellaneous. --Amir E. Aharoni (talk) 11:58, 22 February 2023 (UTC)Reply[reply]

Voting

  •   Support Syntax highlighting is such a key part of learning to do something (even if it's just looking), that we should enable it for beginners. I do not think it signals that a page is editable. Femke (talk) 19:07, 10 February 2023 (UTC)Reply[reply]
  •   Support — DaxServer (t · m · c) 20:28, 10 February 2023 (UTC)Reply[reply]
  •   Support but better to allow previewing changes to a protected page. Use case: check whether my proposed fix to an article or template actually works before submitting an edit request. Certes (talk) 21:20, 10 February 2023 (UTC)Reply[reply]
    agreed DemonDays64 (talk) 00:26, 11 February 2023 (UTC)Reply[reply]
  •   Support Rtfroot (talk) 21:33, 10 February 2023 (UTC)Reply[reply]
  •   Support - excarnateSojourner (talk | contrib) 21:55, 10 February 2023 (UTC)Reply[reply]
  •