Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2021/11.

COMMONS DISCUSSION PAGES (index)
Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Change Media of the Day to Media of the Week[edit]

I propose to change Media of the Day to Media of the Week.

Reason:

  • we have much less high-quality audio/video content than we do images.
  • whereas POTD must go through the featured picture candidates process, MOTD has no quality-based criteria for inclusion. There is a parallel process, featured media, but it gets very little participation (not nearly enough to supply one per day).
  • we do not have enough people interested to surface what high-quality audio/video content that we do have, with people instead adding low-quality content
  • changing to a weekly vs. daily basis allows for more oversight and greater selectivity without the requirement of producing a new file every day.

Recent background:
Last month, Ellywa posted to the village pump about a low-quality video of an anti-vaccination protest being showcased on our main page. We displayed it, along with the anti-vax "freedom of vaccination" slogan to our users during a pandemic. Looking more closely at upcoming MOTDs, I noticed many poor quality videos, e.g. for September 11, a video which combined shaky cellphone video at the 9/11 memorial with a personal selfie slideshow. So I opened this thread. It was there that people suggested possible solutions, including several people suggesting cutting it down to one per week. Today I checked back to see that the same person who added the first anti-vaccination protest added another one, similar to the first, which we highlighted on our main page again on October 1. Regardless of whether one thinks that it is acceptable to actively promote anti-vaccination during a pandemic, the fact remains that the files we select for MOTD are very frequently low quality.

Change Media of the Day to Media of the Week (survey)[edit]

  • Support as proposer. — Rhododendrites talk |  18:26, 11 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support While the long-term solution is to improve the depth and breadth of featurable videos we receive as well as the vetting process, currently we do not have enough volunteer effort to maintain MOTD at a consistent quality on a daily basis. -- King of ♥ 01:20, 12 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support We should have implemented this sooner Commons:Village_pump/Proposals/Archive/2020/06#Turn_MOTD_into_MOTW 4nn1l2 (talk) 02:30, 12 October 2021 (UTC)[reply]
    • Ah! I had not seen that thread. Do we even need a new one, then, in order to move forward with this? — Rhododendrites talk |  02:38, 12 October 2021 (UTC)[reply]
      • Not sure if consensus was reached back then. Four users opposed explicitly, and at least 2 users opposed implicitly, while 9 users supported the proposal at that time. Let's just focus on the new proposal which seems to have more chance to succeed. 4nn1l2 (talk) 20:18, 12 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support per above. If some time eventually in the future we have a wealth of feature-worthy videos, it could be changed back to daily, but weekly seems better at present. -- Infrogmation of New Orleans (talk) 02:35, 12 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support It's clear we don't have the current throughput, or vetting process, to support a daily media. Pi.1415926535 (talk) 04:34, 12 October 2021 (UTC)[reply]
  • Support I think seven days is fine. If we have an excess of stuff too far into the future, we can expand back to one day but I actually think we'll get more picky which can be good. I also think we could use more batch uploading of videos and other media. Requests can be made at Commons:Batch uploading. -- Ricky81682 (talk) 07:18, 12 October 2021 (UTC)[reply]
  • Support if we somehow get too many (unlikely for the time being) we can always do what en DYK does and up the rate for a while.Geni (talk) 08:13, 12 October 2021 (UTC)[reply]
  • Symbol oppose vote oversat.svg Strong oppose even with 365 MOTD, the system is already strongly favouring media from Europe and North America. With any number less than that, this systemic discrimination will only be enforced and other parts of the world are de facto kept out of this.
This proposal is solving a problem of "shortage of users picking MOTD" by killing MOTD, which does not magically increase the number of users working on it.--Roy17 (talk) 11:44, 12 October 2021 (UTC)[reply]
People are really lazy in helping, but just wanna kill something nice.
A bot could even be created to spam MOTD with https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=webm+insource%3AUS+-%22of+the+day%22 for example. Roy17 (talk) 12:01, 12 October 2021 (UTC)[reply]
The problem is it's both highly visible and decidedly not nice. — Rhododendrites talk |  12:25, 12 October 2021 (UTC)[reply]
With any number less than that, this systemic discrimination will only be enforced and other parts of the world are de facto kept out of this. - How? I would think doing it once per week would allow the small number of users participating to take their time and select a more diverse range of videos. — Rhododendrites talk |  12:23, 12 October 2021 (UTC)[reply]
Are some people aware that there are 40+ countries in Asia and 50+ in Africa? One file from each country can easily make up a queue of 100.
Are some people aware that one year has 52 weeks? Roy17 (talk) 12:38, 12 October 2021 (UTC)[reply]
As and when we can get and curate one decent video per country we will worry about it.Geni (talk) 12:55, 12 October 2021 (UTC)[reply]
So before you can do that, you will just happily make this systemic discrimination much worse by killing off the chances of these countries getting featured?
Even though countries as small, secluded and neglected as Benin, Bhutan and Lesotho have at least a handful of videos already.
Benin https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=webm+insource%3ABenin+-%22of+the+day%22+-stamp
Bhutan https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=webm+insource%3ABhutan+-%22of+the+day%22+-stamp
Lesotho https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=webm+insource%3ALesotho+-%22of+the+day%22+-stamp Roy17 (talk) 13:11, 12 October 2021 (UTC)[reply]
I really don't understand your arguments here. You have a good point that we do not highlight enough content from non-European/North American places. But you haven't made any clear connection between that argument and the actual subject of this section. It's a good argument for you (and/or others) to get involved with MOTD (or MOTW) to make it more diverse. But there is no central authority saying "let's have more videos from Europe!" People are just grabbing what's easiest, and for the people volunteering, those videos may be European. You can change that. At least as often, people who upload videos are just placing their own videos in MOTD slots with little or no oversight. That's how we got two anti-vaccination videos in the span of a few weeks. We allow it because there's not enough participation, but nobody thinks this is ideal.
So right now it's arbitrary based on the personal interests and easy access of the people who volunteer. That could change if other people volunteer, but nobody has stepped forward.
There is no list of countries that we are working through, with European/North American countries at the top, and Asian/African countries at the bottom such that reducing the number of media displayed means we won't get to the Asian and African videos. Changing it to be weekly doesn't reduce the proportion of videos from Asian or African countries. If anything, it should increase them because even without additional volunteers, if there's no pressure to find something new every day, volunteers can be more selective and spend more time searching for higher quality content, and more diverse content rather than rely on the self-nominations of our disproportionately European/North American uploader userbase. — Rhododendrites talk |  13:35, 12 October 2021 (UTC)[reply]
Plus, except Lesotho, other examples are having FOP problems afaik. Liuxinyu970226 (talk) 04:00, 15 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support In this topic, I would agree KoH above that the depth and breadth need largely improves, just image: if you propose to turn Meta-Wiki Translation of the week to "Translation of the day", what will Meta Users think? The world's most strongly NOPE. So "of the day" series need to be dropped on Wikimedia step-by-step, just make this to be the first one. --Liuxinyu970226 (talk) 12:16, 12 October 2021 (UTC)[reply]
  • GA candidate.svg Weak support Ideally, we should strive to have enough good-quality media for a daily presentation, and I fear that this will not be a temporary measure until we are there, but rather "giving up". But I see that there is a distinct lack of presentable video content. Gestumblindi (talk) 12:51, 12 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support per nom - Disappointed to see yesterdays MOTD which was something along the lines of "no media chosen today" - new people don't want to see that, Anyway I support this and also echo KoHs sentiments - Changing this to MOTW gives people more time to pick videos and more time to pick diverse videos too and it also means the MOTW on the front page shouldn't be empty either. –Davey2010Talk 13:08, 12 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support Christian Ferrer (talk) 18:52, 12 October 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Going to one media file per week is far too drastic of a change. I could, at most, support one media file every three days, but even then I think this is not ideal. The occasional mess-up is not enough for me to support a 3x-7x reduction in media on the front page. I think the best solution is to 1) promote the featured media process, 2) make the featured media process easier by reducing quorum, and 3) limit media of the day to featured media, even if this results in repeated entries.  Mysterymanblue  21:17, 14 October 2021 (UTC)[reply]
    People may dislike the idea of seeing the same thing every 200 days, but I think that seeing the same file every day for a week straight is worse than seeing the same file every 200 days.  Mysterymanblue  21:21, 14 October 2021 (UTC)[reply]
    Every 3 days is hard, technically, and also normatively. Regarding your suggestions: (1) did that. several times. (2) did that, too. (3) To put some numbers to this, we have 203 total featured media. We have promoted a total of seventeen throughout all of 2021 so far. You're saying that we just repeat the same 200 videos over and over, adding a handful of new ones each year? That would be preferable to the current situation, I suppose, but a distant second choice to just reducing it to one new video per week. — Rhododendrites talk |  21:35, 14 October 2021 (UTC)[reply]
    Also, how do you think people may like the idea of seeing the same way on Meta-Wiki, to run a potential "Translation of the day"?!?!?! Liuxinyu970226 (talk) 03:59, 15 October 2021 (UTC)[reply]
  • Symbol oppose vote oversat.svg Strong oppose Once again we are having this discussion rather than having a discussion on "How to engage more people in MOTD?" ℺ Gone Postal ( ) 05:33, 17 October 2021 (UTC)[reply]
    @Gone Postal: So far, despite all our efforts, we have failed to engage more people in MOTD. The question becomes: do we feature more media on the main page and potentially have some of them be poorly vetted, or do we feature fewer media which are better vetted? -- King of ♥ 05:56, 17 October 2021 (UTC)[reply]
    @King of Hearts: I understand your position, your answer to your last question is "fewer media", mine is "more media". I will try to dedicate some time on MOTD. ℺ Gone Postal ( ) 06:05, 17 October 2021 (UTC)[reply]
    Regarding "more media", I'm afraid that this is more-and-more untouchable due to this problem. Liuxinyu970226 (talk) 10:09, 17 October 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose in favour of the other proposal to reuse older ones. Agathoclea (talk) 09:57, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support 182,239 videos vs. 70+ million images (see Special:MediaStatistics). No wonder we don't have enough high-quality content. Changing to weekly frequency will increase the quality of presented videos to 125,000+ daily visitors of the main page. Jklamo (talk) 16:45, 17 October 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Demotivating, wait time will be too long. — Racconish💬 06:17, 18 October 2021 (UTC)[reply]
    And how can anything on wiki be too short? Liuxinyu970226 (talk) 13:38, 19 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support Let's admit it: sound and video on Commons sucks in many regards. Celebrating weak examples on the front page makes us look like the bunch of amateurs we are and does not much to encourage people to produce better stuff. That spot should be reserved for the best of the best, and as moving to a weekly schedule would mean we could display our greatest media for longer, that's a win in my book! After all, as a visitor it's easy to snack a quick POTD, but audiovisual content takes much more time to get through. --El Grafo (talk) 07:36, 21 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support 1) uploading videos (large files) and converting is extremely difficult. 2) Let's spend the effort to pick media-of-everyday on other things. 3) I also suggest including images from other rigorous Wikimedia sites to make Commons' front page actually look like an image repository rather than some communist website. Thank you —Vis M (talk) 13:43, 22 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support Unfortunate, but until we get more participation in MOTx this is a prudent change to help resolve the problems listed in the nomination. If we ever get to the needed level of participation to support higher frequency, we can easily readjust the frequency again. -M.nelson (talk) 14:56, 25 October 2021 (UTC)[reply]
  • Weak Symbol oppose vote.svg Oppose, While I actually went into this wanting to support it, reading some of the counterarguments convinced me otherwise. I wouldn't be opposed to having a "Featured media" that rotates every three (3) or so days, but 52 (fifty-two) different non-image media files per year isn't enough, it won't truly represent the diversity of the Wikimedia Commons, I think that with a number of ideas posted below like re-using old featured media and some ideas above like more representation for non-European and non-North American media would be better. Having occasional low quality stuff isn't bad as long as they are extraordinarily educational. I do support changing it to more than a day, just not a week. Theoretically this could be solved with more outreach on places like Reddit, Instagram, TikTok, YouTube, the Facebook, Etc. where non-image media creators hang out, but until the number of contributors in this field grows I think that it will be wise to limit it to a new featured main page media every three (3) days which would be more than a hundred (100) files a year. MOTD isn't just videos, it is 3D works and other things like books, enough books were imported by user "" this year alone to have a different book at MOTD for years, though obviously it shouldn't only be books. An old manuscript or Bible in PDF every now and then is also preferable. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:43, 28 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support --A1Cafel (talk) 05:43, 12 November 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose After some thinking, no. Better to show some files several times (i.e. the ones which are Featured), and to include other content, not actually shown now (books, etc.). Yann (talk) 12:31, 13 November 2021 (UTC)[reply]
  • Symbol support vote.svg Support Contributers2020Talk to me here 06:43, 18 November 2021 (UTC)[reply]

Enlarging media to include also books[edit]

Change Media of the Day to Media of the Week (Discussion)[edit]

  • Pictogram voting comment.svg Comment, I am still convinced that this is something that would easily be solved if videos were more easy to be uploaded to the Wikimedia Commons, namely by supporting .MP4 files, a proposal that has recently gathered much support and little opposition. I think that temporarily downgrading it to 52 (fifty-two) per year might be a good idea as I found the anti-SARS-CoV-2-vaccine demonstrations on the main page to be a bit... odd, to say the least. But to me the issue is that it's a sign that we simply don't have enough contributors in these fields, we don't have bands re-enacting public domain music, we don't have people that search Google's YouTube to download good quality videos with free licenses, we don't have filmers ourselves that make video-recordings with their camcorders. We have those people, but not many, not enough, and I think that to some extend both the unfamiliarity of the Wikimedia Commons to these types of peoples and the technical restrictions cause these issues. While I think that this change, unfortunate as it is, is a necessary evil, I really dislike the fact that so little is being done to try to recruit more people to join the Wikimedia Commons to contribute more non-image media. Maybe present a few books or something on the main page, I am sure that there are plenty of books being uploaded that deserve that spot, it doesn't always have to be a video.
Likewise, 3D works are also something that could be showcased, I believe that I saw some, but I could have mistaken it. I just find it a shame that we are not actively trying to get more volunteers to join. We are not like Wikidata that we essentially have "too much people", in fact, the Wikimedia Commons tends to be a collection of missed opportunities and low investment from the WMF, at least in adding content and features. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:54, 11 October 2021 (UTC)[reply]
It would be good to make it easier (coincidentally, video2commons seems broken at the moment Update: the interface is returning errors, but the upload completed. Nevermind that.). It would be good if we had more people with video production skills. It would be good if we had more people interested in surfacing good quality videos. It would be good if we had more people looking around at other sites to find video to transfer. I agree with all of that. But we need to work with the situation as it exists now. If those things change in time, we can always reinstate MOTD, but for now IMO the best thing would be to remove the requirement that we display something every day, because we're not doing a good enough job at that. — Rhododendrites talk |  21:47, 11 October 2021 (UTC)[reply]
@Donald Trung: I agree that supporting MP4 videos would go a long way to making video contributions accessible to most people, whose best video recorder is their smart phone. Something I'll also note is that this proposal has no expiration criteria. So even if "temporarily downgrading it to 52 (fifty-two) per year" is a good idea, there is a significant chance that the inertia of "MOTW" will mean that we're stuck with it forever, even if work is done to improve video on Commons.  Mysterymanblue  01:45, 23 October 2021 (UTC)[reply]
MP4 is pretty much irrelivant to serious video since you are going to want to work on it in post and outputting to webM is trivial. Even if MP4 is your starting point en:HandBrake now transcodes to WebM so it can be done entirely with a GUI.Geni (talk) 08:41, 12 October 2021 (UTC)[reply]
  • I agree that one day seems too little... but seven days seems too much. Would it be possible to choose a new file every three days or so?  Mysterymanblue  04:37, 12 October 2021 (UTC)[reply]
  • Sort of. The template currently uses CURRENTDAY2 which could be switched to CURRENTWEEK. Once every three days would involve things being doing manually via the back-end.Geni (talk) 14:19, 12 October 2021 (UTC)[reply]
  • Once a week seems reasonable although it doesn't help that the back end is not very findable. The reality is that creating high quality video is much harder than creating high quality photos. To an extent photography can be brute forced. 100 photos an hour is quite doable (and desirable in an event like a classic car rally) and under ideal conditions 10+ will be good. Video is much more of a challenge. They straight up take longer, there are fewer viable subjects (videos of static objects don’t look great) sound becomes an issue. Lighting presents more of a problem (since it may have to be good in multiple directions) as does camera stability. Editing in post presents more of a challenge since it requires a greater skillset and significantly more computing power (particularly at higher resolutions). There’s a reason why most photography is done solo where as even moderately serious video work involves teams.Geni (talk) 10:39, 12 October 2021 (UTC)[reply]
  • The issues at the heart of this are longstanding and not easy to solve: Creating good videos (as this is mainly what "media" is about here) is far more challenging than creating good images (not only from the technical side, as noted by Geni, but also from the licensing point of view - you have to be very careful not to include copyrighted music etc.), and then the uploading to Commons is notoriously challenging, even with a tool like Video2Commons, which is intended to make uploads easier, but even I as an experienced user of many years and admin are often struggling with. As noted in my comment above, I'm not sure that we are going into the right direction by giving in / giving up in that way, taking pressure away from the "media of the day" instead of trying to finally make Commons more attractive for uploads other than images, namely for videos. I think I fully understand why this proposal was made, and I am supporting it, weakly, but I am concerned that it will only serve to make video on Commons even more of a marginal matter. Gestumblindi (talk) 13:01, 12 October 2021 (UTC)[reply]
the point about the "anti-vax" video is void, because i upon seeing that in advance added two motd that are supposedly "pro-vax" in response: Template:Motd/2021-10-04 Template:Motd/2021-11-01.
anyone who's so obsessed about neutrality / balanced point of view / procedural correctness should add one more "anti-vax" video as motd.--RZuo (talk) 13:27, 12 October 2021 (UTC)[reply]
It's not about being "obsessed about neutrality" or some kind of "balance". We just shouldn't be displaying anti-vax propaganda during a pandemic. Displaying something pro-vaccination later doesn't change the fact that it was harmful. There is no "balance" to harmful. It's fine to host such a video, of course, but we should not be highlighting it on our main page. Perhaps when/if we move on from treating vaccination like a "both sides" political issue, it would be fine to display such a video for historical purposes, but we're not there yet. — Rhododendrites talk |  13:43, 12 October 2021 (UTC)[reply]
  • I oppose this change chiefly because it is bad for non-image media on Commons. Reducing the visibility of high quality media by a factor of seven will not improve Wikimedia Commons; it will only further discourage the creation and uploading of high quality media. Doing so without setting a clear timeline for a return to MOTD will also discourage people from attempting to contribute to or fix the featured media process, further entrenching the problem that it is seeking to address. This proposal amounts to a resignation that the issues that plague video on Commons are unfixable and that we should just accept that the amount of high quality media will always be this bad. Instead of taking this step to discourage media contributors, we should be making it easier for video to be captured, uploaded, and promoted to featured media/media of the day.
I will admit that Commons has tried to promote media contribution many times in the past with disappointing results. However, I do not think that we have done enough on this front.
Lowering quorum to approximately three would improve the featured media process. While participation in the FM process is wanting, it's not exactly obscure; there are more than enough people who check that page during the course of a nomination period to fulfill the purpose of a quorum: to prevent files from "slipping under" the community's radar and into featured status. A quorum of three would still serve this purpose effectively while ensuring that FM nominations cannot be unilaterally rammed through.
Critics of lowering quorum might point out that there have been many FM candidates with 3 or 4 positive votes that failed due to lack of quorum—they may point to the failed nomination of these "unworthy" files as evidence that the higher quorum serves a purpose. However, I believe that these comparisons are invalid because quorum impacts people's voting behavior. Of the many people who view FM candidate nominations, only a few vote on them. This is because they are aware of the effect of a higher quorum: "noes" and "lean noes" may abstain because they are aware that a file is unlikely to pass without their support, and "lean yesses" may withhold support because they believe that quorum is unlikely to be reached anyway. Lowering quorum will therefore promote discussion by making the clear success or rejection of a featured media candidate a tangible future possibility so that even the first support and oppose votes will be meaningful. It will force those who rely on abstentions to oppose featured media to voice their opinions in a public space where they can be discussed. This will end the limbo that many failed FM candidates are currently in, where it is unclear if their failure was due to unstated opposition or unvoiced support.
There is also a significant technical barrier to uploading media to commons. Video2commons is broken, and files over 600 MB fail, even in chunked uploaders. Additionally, the exercise of requiring users to convert video to only a few formats tends to be out of reach of most people. A “Wiki Loves Monuments”-style contest is essentially doomed to fail because the most accessible video recorders - cell phones - almost universally record in “patent-encumbered formats”.

 Mysterymanblue  01:34, 23 October 2021 (UTC)[reply]

Reducing the visibility of high quality media It does not currently do much for the visibility of high-quality media. We can continue to display low-quality media, which IMO is more discouraging than anything because it's supposed to represent our very best, or we can highlight a smaller number of actually high-quality media.
Doing so without setting a clear timeline Nothing would prevent a proposal to go back once it can be demonstrated that the state of media on Commons has changed sufficiently that we can both attract good content and surface it on a daily basis. I thought about framing this as a trial period, but, realistically, there's no indication anything's going to change.
resignation that the issues that plague video on Commons are unfixable - Perhaps some see it this way. I see it more that until we fix those issues we shouldn't just pretend that everything is going well.
This is because they are aware of the effect of a higher quorum - I'm someone who sees [almost] all of the FM nominations and doesn't vote on most of them. I do support some, and occasionally oppose, but more often I abstain because it's neither objectionably bad nor particularly good. We already have a much lower bar for FM as compared to FP (I'm talking about quality requirements, not number of votes).
There is also a significant technical barrier to uploading media to commons Agreed. This is part of the argument in favor, because there's no sign this is going to be fixed. If it does, and that affects the media we get, we can always revisit. — Rhododendrites talk |  12:50, 23 October 2021 (UTC)[reply]
There were 600+ films produced by USA alone in 1925, all of which have entered PD: List of American films of 1925. And the number of films going into PD from all countries would only increase year after year. We could well show two movies every day.--Roy17 (talk) 13:32, 26 October 2021 (UTC)[reply]
However, I would not be surprised to see some supporters talking about how studio-made films have low quality blah blah blah.
By now fellow Commons users should notice that some users are jumping up and down this thread to do nothing but finding every excuse for killing MOTD. Some users talk big about contributing but never made any effort curating MOTD, for example [1].--Roy17 (talk) 13:32, 26 October 2021 (UTC)[reply]
Yes, I am part of the "lack of participation" problem with MOTD, just like nearly everyone else. The thing is, MOTD affects everyone, regardless of whether they participate, and everyone sees the results via the main page. Everything here is only as good as the volunteer time put into it. Some processes work better than others for that reason. What we have in MOTD, however, is a mismatch between the amount of volunteer interest and the prominence/importance given to the process. If volunteers for a particular process want the output of that process to be given real estate on the main page, it's up to volunteers interested in that project to make it work. We don't put things on the main page and then say "ok now it's everyone else's fault if this doesn't work" -- no, it's up to people who want there to be an MOTD to make it work. Otherwise, we need to remove it from the main page or find another way to fix it (and yes, I say MOTD→MOTW is fixing, not killing; killing would be removing that section of the main page). — Rhododendrites talk |  14:46, 26 October 2021 (UTC)[reply]
  • @Yann: , per your new proposal above based on what I wrote, just to be clear, doesn't the MOTD today already mean all non-image media? I always assumed that it did because the MOTD isn't always a video as I've seen 3D objects and other non-video MOTD in the past. Though I am glad that you created that proposal, as it has the largest chance of actually saving the MOTD for now, as we have so many books, manuscripts, and other PDF files, perhaps also expand it to include all PDF, DJVU, Etc. files as for example a PDF of a scientific thesis that has had a major influence on the world deserves to be on the main page as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:52, 4 November 2021 (UTC)[reply]

Alternative proposal: Change Media of the Day to Media of the Year[edit]

One audiovisual file per year. Easy.--Roy17 (talk) 11:44, 12 October 2021 (UTC)[reply]

  • Symbol oppose vote.svg Oppose - I certainly don't agree with one video per year .... regualars will simply stop looking at the front page. We can do better than one per year. –Davey2010Talk 18:31, 12 October 2021 (UTC)[reply]
Symbol oppose vote.svg Oppose No reason to make "Saimoe"-like "of the..." for non moegirl-related Autonomous sites. Media of the Week is enough. Liuxinyu970226 (talk) 13:18, 13 October 2021 (UTC)[reply]
I think the "alternative proposal" is meant sarcastically, not in earnest. Gestumblindi (talk) 19:39, 13 October 2021 (UTC)[reply]
Maybe it's just me but this proposal doesn't sound sarcastic - I recall at EN taking the mick out of someones proposal before... only to to be told it was serious .... and when you've seen idiotic-yet-serious proposals on EN you begin to start believing everything you see. Meh it went over my head. –Davey2010Talk 22:43, 14 October 2021 (UTC)[reply]
But in this case, from the context of Roy17's other discussion contributions, it seems to be pretty clear. Roy17 argues for keeping the "media of the day", after all. Gestumblindi (talk) 07:42, 15 October 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose One media file per year is worse than one media file per week, in the same way that one media file per week is worse than one media file per year.  Mysterymanblue  01:46, 23 October 2021 (UTC)[reply]

upcoming media of the day[edit]

Does not seem to be an actual proposal. King of ♥ 19:41, 13 October 2021 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

For what is currently on the way see Template:Motd/2021-10.Geni (talk) 12:11, 12 October 2021 (UTC)[reply]

  • Symbol oppose vote.svg Oppose - Seems more confusing tbh. MOTW is good enough. –Davey2010Talk 18:32, 12 October 2021 (UTC)[reply]
Symbol oppose vote.svg Oppose Per Davey, probably the "Template:Motd/$1" should temporary be blocklisted. Liuxinyu970226 (talk) 13:19, 13 October 2021 (UTC)[reply]
What exactly is being responded to here? this is just a link to the current MOTD backend.Geni (talk) 18:35, 13 October 2021 (UTC)[reply]
Yes, as I understand it, you didn't make a proposal here (that could be supported or opposed), but just posted the link for information, right? Gestumblindi (talk) 19:38, 13 October 2021 (UTC)[reply]
Apologies Geni I did indeed thought you were proposing a name change to "upcoming media of the day" - I didn't twig on you were actually telling people the upcoming media of the day so apologies for this. –Davey2010Talk 22:34, 14 October 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Allow a file to become Media of the Day (MOTD) more than once[edit]

Watching/listening to a good piece of work every few years is reasonably acceptable. This could serve as a fallback to fill an empty MOTD last minute. Simply go and pick an old one from more than 10 years ago.

AFAIK it's currently not forbidden to do this, but it's just a convention not to make a file MOTD twice.--Roy17 (talk) 09:05, 15 October 2021 (UTC)[reply]

  • Symbol support vote.svg Support Seems very rational. ℺ Gone Postal ( ) 05:37, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support for FM only. I view this proposal as orthogonal to the original, i.e. it can be implemented in addition to changing it to weekly. If MOTW passes, then I think all FM should be "reset" and become eligible for MOTW a second time; it's not fair that something doesn't get to be featured on the main page for a week just because it got featured for one day. If MOTW doesn't pass, then FM should just be eligible for an indefinite number of repeat MOTDs with at least 3 years in between. In either case, previous non-FM MOTD should remain ineligible; if it's really good enough to put on the main page twice, it should be good enough to get consensus for FM promotion. -- King of ♥ 06:03, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support Seeing the same file every few years is better than seeing the same file for a week straight.  Mysterymanblue  08:41, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support Just make sure there is a new one every week and rotate the rest through after a suitability check. Agathoclea (talk) 09:54, 17 October 2021 (UTC)[reply]
Pictogram-voting-question.svg Question Is there any ways to avoid nominating for MOTD same one file everyday within a long period, or at least within one month for just same one? If there can't have, I'm afraid that I will still oppose due to concerns with Special:RecentChanges spamming. Liuxinyu970226 (talk) 10:13, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support for FM only as an additional proposal. Symbol oppose vote.svg Oppose as an alternative proposal. The problem the original proposal intends to fix is the low quality of media in MOTW and chronically low participation at MOTW, even if a couple users pop up in these threads with commitments to turn it around. Allowing the same low quality videos to appear multiple times doesn't help anything. Nor does allowing FM to repeat, because that's FM repeating in addition to the low quality videos we'll continue to get. — Rhododendrites talk |  14:04, 17 October 2021 (UTC)[reply]
    • I've updated the heading to reflect this can be additional or alternative, depending on one's perspective. As just an alternative, which doesn't actually address (at least not directly) the reason for the original proposal, it's confusing and misleading. — Rhododendrites talk |  14:06, 17 October 2021 (UTC)[reply]
      • Sigh. Looks like Roy reverted my change to the header with the message "(Changes to my proposal need my endorsement.)" -- @Roy17: You don't own this proposal any more than I own the original. You did not ask for my endorsement to add an "alternative" as part of the proposal I opened, and I didn't ask yours to modify this, since it's clearly not just an "alternative". Both are fine. — Rhododendrites talk |  20:01, 17 October 2021 (UTC)[reply]
        • Reverted back to your version. Users don't own headings. 4nn1l2 (talk) 21:06, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support only as an additional proposal, and Symbol oppose vote.svg Oppose as an alternative. The MOTD should die and MOTW be born anyway. No objections to repeated MOTWs. This is a real problem that has surfaced N times, and it doesn't matter how many times you say "it will be fixed", because it won't and we know that. 4nn1l2 (talk) 18:41, 17 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support as well as an addition or an alternative. It's absolutely fine to present the same file again after a few years; I don't know how it's handled in English Wikipedia, but in German-language Wikipedia, featured articles can be repeatedly chosen as "article of the day"; it doesn't happen that often, but it is allowed. For example, de:Augustus was "article of the week" (before the switch to a daily featured article) in 2004, then "article of the day" in 2014 and there's already a proposal to choose it again for August 19, 2024. Gestumblindi (talk) 19:21, 18 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support, while I have no objections to changing the MOTD to MOTW as a provisional measure, this would allow us to showcase high quality media to the people that visit the main page. Sure, the Wikimedia Commons doesn't have as much page views as the English-language Wikipedia, but if we would work with that (Defeatist) mentality then nothing would ever get done. If this could save the MOTD it would be great, if this could ensure the quality of the MOTW it would also be great. Either way, this is a good proposal. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:28, 28 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support as an addition, not an alternative. Though I don't think this will be of much use in case MOTW passes, I nonetheless don't oppose using the same file again as MOTW in case we really have no new FM (which I think/hope is not going to be the case). That said, I think there should be longer intervals between using same FMs as MOTW. Perhaps 3 years for MOTD and 5 years for MOTW, should it pass. Ahmadtalk 20:27, 31 October 2021 (UTC)[reply]
  • Symbol support vote.svg Support only when the file was last used in MOTD/MOTW for like more than 3-4 years. Otherwise, Symbol oppose vote.svg Oppose Contributers2020Talk to me here 06:47, 18 November 2021 (UTC)[reply]

Supplemental proposal: Expiration criterion for MOTW[edit]

To be implemented only if the main proposal passes:

Media of the Week will revert to Media of the Day when there are two years' worth of daily featured media. That is, when the number of featured media is greater than or equal to 730, media of the day will be reimplemented.  Mysterymanblue  21:28, 22 October 2021 (UTC)[reply]

  • Symbol support vote.svg Support as proposer. The primary concern of MOTW supporters is that there is not a high enough quality, curated stream of media to spotlight every day. When the featured media process has matured enough, these concerns will be satisfied, and we should revert to Media of the Day. I chose 2 years worth of daily free media as the cutoff for this, but I will support an expiration criteria of any number of files, with preference toward a lower number.  Mysterymanblue  21:28, 22 October 2021 (UTC)[reply]
  • BA candidate.svg Weak oppose any sort of automatic change. At the rate we've been going, this proposal will be pending for several years before going into effect. We don't know what changes will happen (or won't happen) regarding uploading, the FMC process, FMC participation, etc. We may get more media, but maybe the FMC process won't function well enough to promote enough of them, in which case it may still make sense to restore MOTD. I would support simply saying that we'll revisit this in one year or two years, to make sure it's working as it should, but we can also just say that anyone who thinks things have changed sufficiently to restore MOTD can propose that in the future, regardless of specific metrics. — Rhododendrites talk |  12:56, 23 October 2021 (UTC)[reply]
    @Rhododendrites: The logic really flows both ways on this one. You say that without an expiration criterion, we could always have a discussion about reinstating media of the day in a few years. Of course, with an expiration criterion, there could also be a discussion as to why we should keep media of the week around for a little bit longer. An expiration criterion does not permanently bind the project to one course of action - it is meant to be a concrete starting point for thinking about the end of the proposal. It serves as an acknowledgement that this change has particular aims, is narrowly tailored to achieve those aims, and will be undone when those aims have been achieved.
    An expiration criterion also has the benefit of setting a goal for the project to regain media of the day. This would give featured media proponents something to work toward and would help mitigate the discouraging effect that removing media of the day would have on audiovisual contributions.  Mysterymanblue  22:47, 23 October 2021 (UTC)[reply]
A little Symbol oppose vote.svg Oppose, but setting a higher-than-de-facto bar may lead me to re-support. Currently there were probably also sockpuppets that were created {{Motd}} subtemplates, we need to make sure the accounts touching the bar are real different peoples, rather than a man who is using CDN servers to set up a sock army to touch that. Liuxinyu970226 (talk) 01:21, 24 October 2021 (UTC)[reply]
@Liuxinyu970226: You're welcome to say something like "Oppose 2 years, but will support 3 years or more."  Mysterymanblue  01:25, 24 October 2021 (UTC)[reply]
No time period changes I suggested, what I suggest is just same as the motto of WADA official site: Play true. Liuxinyu970226 (talk) 01:28, 24 October 2021 (UTC)[reply]
@Mysterymanblue: Also, under same reasons, you might want to change Meta-Wiki's Translation of the Week to Translation of the Day, isn't that? Liuxinyu970226 (talk) 04:47, 2 November 2021 (UTC)[reply]
  • Symbol support vote.svg Support, the Media of the Day feature should return when the Wikimedia Commons are ready, we have a lot of bad quality non-image media files being promoted today but this might change in the future, this could be one (1) year from now, this could be two (2) years from now, or this could be ten (10) years from now. Setting precedent today will mean that when we eventually do have enough high quality media for the main page that in a decade or so we won't have an army of users opposing the Media of the Day returning because "It has always been the Media of the Week, no need to change what ain't broken" and changing such a system would be an uphill battle once it's implemented. Already saying "Yeah, if this goal 🥅 is reached we can allow the MOTD to return" will allow us to adapt to a changing community climate that is more focused on non-image media. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:24, 28 October 2021 (UTC)[reply]
  • Symbol oppose vote.svg Oppose an automatic change; I don't like the idea of locking in some future change today. I would strongly support scheduling a discussion/proposal at some point in the future (e.g. 6, 12, 24 months) and evaluating then if we should increase the frequency. If the "goals" above are met and the issues in the OP are resolved, I would probably support such an increase at that time. -M.nelson (talk) 11:45, 13 November 2021 (UTC)[reply]
    @M.nelson if someone started a discussion again it will take months for that. Contributers2020Talk to me here 03:02, 15 December 2021 (UTC)[reply]
Symbol strong support vote.svg Strong support for this proposal. Contributers2020Talk to me here 03:01, 15 December 2021 (UTC)[reply]

Time for closure?[edit]

It's been more than a month for the original proposal, only two additional !votes this month so far, and a few days since anyone said anything. This would benefit from a formal closure from one or more uninvolved admins, I think. — Rhododendrites talk |  13:38, 16 November 2021 (UTC)[reply]

I agree @Rhododendrites. We got enough votes and discussion in order to now take this in action. Contributers2020Talk to me here 06:48, 18 November 2021 (UTC)[reply]
Let us see what changes should be made with consensus-
1) Main proposal of MOTD to MOTW- Symbol support vote.svg Support-17, Symbol oppose vote.svg Oppose- 7 = 70.83% = Proposal passed
2) Additional proposal of enlarging media to include also books- Symbol support vote.svg Support-5, Symbol oppose vote.svg Oppose- 0 = 100% = Proposal passed
3) Alternative proposal of changing Media of the Day to Media of the Year- Symbol oppose vote.svg Oppose- 6 = 0% = Proposal declined
4) Supplemental proposal of expiration criterion for MOTW- consensus do not agree for automatic changing, If manual changing occur- Proposal passes"'
Now please if any involved admin should just do it. It's two months. Pinging King of Hearts, Yann, Geni for immediate closure. -- Contributers2020Talk to me here 03:21, 15 December 2021 (UTC)[reply]
@Contributers2020: No, 1 is for MOTW, not MOTY.   — Jeff G. please ping or talk to me 04:26, 15 December 2021 (UTC)[reply]
Sorry @Jeff G. I fixed it. Contributers2020Talk to me here 05:05, 15 December 2021 (UTC)[reply]
Pictogram voting comment.svg Comment I have uploaded a lot of audio files in order to diversify and improve the MOTD quality. I also added 2 books at the end of this month. Yann (talk) 21:56, 15 December 2021 (UTC)[reply]
Probably doesn't matter, @Yann. It would take atleast 4-6 months for 1/20th being qualified for MOTD. Till then, lets continue with what consensus has decided, Contributers2020Talk to me here 06:38, 16 December 2021 (UTC)[reply]
Seriously Symbol wtf vote.svg WTF? Lets close this. This is so serious that this proposal is going on from October and no administrator seems to care. Please please, just make the necessary changes. Contributers2020Talk to me here 16:56, 19 December 2021 (UTC)[reply]
Likely to do that in a few days. Need to dig through more of the technical side first.Geni (talk) 20:37, 8 January 2022 (UTC)[reply]
What's interesting is that other than changing the Media of the Day (MOTD) to Media of the Week (MOTW) all the other (serious) proposals, which all passed, were specifically designed to save the daily rotation of non-image media, it might be that we'll soon have a surplus of MOTW and we could see another proposal. But then again let's first see how it will go and if there's demand for it it will probably revert back to MOTD if enough files are nominated for MOTW. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:42, 8 January 2022 (UTC)[reply]
MOTD is now filled up for one month in advance, which didn't happen for a long time. --Yann (talk) 09:06, 9 January 2022 (UTC)[reply]

Documentation[edit]

The main page is served from Template:Main Page Template

The media of the day is called by the section {{:Main_Page/motd|width=450|float=center|lang={{{langcode|en}}}}} which pulls the file from Main Page/motd

The twitter link is handled by {{#ifexist:File:{{Motd/{{#time:Y-m-d|today|en}}}}|* [https://twitter.com/share?url=https:{{fullurl:File:{{Motd/{{formatnum:{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY2}}|R}}}}}}&via=WikiCommons&text={{urlencode:{{{Tweet text motd|Check out today's #MediaOfTheDay on Wikimedia Commons at}}}}}&related=WikiCommons,Wikipedia '''{{{Tweet|Tweet}}}''']|}}

The previous media of the day and RSS feed is not dynamic.

Main Page/motd calls up each day's template with {{#ifexist:File:{{Motd/{{#time:Y-m-d|today|en}}}}|[[File:{{Motd/{{#time:Y-m-d|today|en}}}}|{{{width|300}}}px|{{#ifexist:Template:Motd/{{Motd/{{#time:Y-m-d|today|en}} thumbtime|thumbtime={{#time:Y-m-d|today|en}} thumbtime}}}}]][[File:Magnify-clip (sans arrow).svg|14px|link=File:{{Motd/{{#time:Y-m-d|today|en}}}} There are a couple of other dynamic calls in there with a similar format.

In theory switching it to {{#ifexist:File:{{Motd/{{#time:o-W|today|en}}}}|[[File:{{Motd/{{#time:o-W|today|en}}}}|{{{width|300}}}px|{{#ifexist:Template:Motd/{{Motd/{{#time:o-W|today|en}} thumbtime|thumbtime={{#time:o-W|today|en}} thumbtime}}}}]][[File:Magnify-clip (sans arrow).svg|14px|link=File:{{Motd/{{#time:o-W|today|en}}}} should be the main change but that pulls up the existing system for months (at least until we are 12 weeks into the year). Probably easiest option is to do something like built a new setup at motd2. But really we need someone who knows their way around parser functions.Geni (talk) 20:56, 11 January 2022 (UTC)[reply]

Tool to help with [Category:Maps of <location> by <year>][edit]

Request
Help with creation of categories in the {{Map of <location> by <year>}} (and/or decade/century) schemes
(Since I don't know which village pump is the best to bother with my request, I first go here. Please feel free to move my request to any place better suited, if I'm too wrong here.)

My current problem is that I wish to categorize maps as precise as possible. This again requires extensive knowledge of existing categories because you NEVER know which categories already exist. Sometimes, there are already detailed categories in place where you can put an "Old map of Madagascar" right into the Category:16th-century maps of Madagascar; or an "Old map of France" right into the year Category:1892 maps of France, or an "Old map of Russia" into the Category:1760s maps of Russia. More often however, the intended category doesn't yet exist. That leaves the categorizer two options:

  • Number one, create the category tree yourself on the spot, which means quite a bit of research how the other categories of that tree are defined and then copy the templates from some other already existing category, get it wrong three times, and sometimes even adjust several other categories that missed important parent categories or whatever. Which takes quite a lot of time and is quite a punishment for the categorizer.
  • Number two is the lazy route where you don't do anything and drop your still uncategorized map smack-dab into "Category:Maps of the United States" (for example; that one has currently 1266 files of all years, map types, etc.). From there a map eventually gets moved by another more dutiful categorizer into "Category:Unidentified maps of the United States" (currently 1165 files), or directly into the correct state, or year, or both. Most categorizers choose this lazy route, because the more specific subcategory doesn't exist and you want to get some work done. Until I recently created century-subcategories for London, the "Old maps of London" contained about 800 maps from the 15th to the 20th century. That's quite a punishment for anyone who uses the categories to search for a map of some place+time and has to click through several hundred files, and it invalidates the purpose of categories.

So what can we do to create an easy-to-handle system? I have two suggestions:

  • First, to have lots of yet-empty categories created in advance: Category:1712 maps of France and Category:1916 maps of Idaho may still be empty, but you can expect that it will at some point have content, since 1711 and 1713 maps of France; and 1915 and 1917 maps of Idaho already exist. This would require a clever user to guide a bot which categories should be pre-created, based on which countries or sub-divisions existed at which point in time. Which means that it makes no sense to create "1692 maps of Uganda" - that's nonsense - but there needs to be provision for categories like the 1692 maps of HRE, Ottoman Empire and Prussia; and then again prevent 1962 maps of these countries. After such an organized creation, we'd have several thousand empty categories, but ready to be filled.
  • Second, have a bot searching for red categories that match the right parameters: IF a category like "Maps of <place>" already exists AND that category already has more than <threshold> subcategories (about 10?), the bot would recognize red categories of "YYYY maps of <place>" with the same <place>-Keyword and create the according category tree. In practice: if next year someone categorizes a new map as "2022 maps of Nigeria", the category would remain red for a while until the helpful bot creates that category as "{{MapsNigeria|202|2}}", plus the "2020s maps of Nigeria" and the "21st-century maps of Nigeria", as needed. Meanwhile, a "2022 maps of Birmingham" (map-of-category exists but has too few subcategories) would not yet create its own subcategory, and the bot could change this tag automatically into "Maps of Birmingham|2022" which allows for a later subcategorization if really needed.

--> As far as I can see, the structure of maps by year/decade/century is standardized and distinct enough to make both outlined approaches somewhat feasible. No concern is given here to the other sorting criteria (projection, topic/theme, language, etc.) as these require different and more elaborate categories. The same could theoretically be done with the "YYYY in <place>" categories (Category:2017 in Bogotá vs. Category:1968 in Kathmandu), but here I see a few more potential implementation problems. All the best, --Enyavar (talk) 18:49, 8 December 2021 (UTC)[reply]

Maps of <location> by <year> categories should be burned with fire. They are the best example of overly-specific-categorization on Commons and they typically make it impossible to efficiently browse maps on Commons. For somewhere like New York City, these categories make sense, but for most locations, we end up having 1 map per category, which is pointless. Nosferattus (talk) 00:31, 1 January 2022 (UTC)[reply]
The problem is two-fold, yes: The super-categories like "Old maps of France/Germany/England" burst with hundreds of files, because it is so much hassle to create smaller subcategories on your own. ("London" or "Madagascar" for example had no sub-categories for centuries until I created and filled them this year, just to name examples) So, because no more specific subcategories that are readily available, people pile their stuff in the super-categories, which I find hard to browse. I shudder each time I open Category:Old maps or Category:Maps of the world. These unspecific categories are pretty pointless, too.
However, I agree that there should be a helpful tool that also lets you browse through all content of all tiny subcategories in once glance, for example from Category:1660s maps of Germany. A "show me all"-Button would be another great help, and probably even more important than a tool to help breaking down the big super-piles. --Enyavar (talk) 21:51, 1 January 2022 (UTC)[reply]
This is a problem with all by-year categories, and other systematic subcategorisation. In categories with a few dozens of files it is usually easier to just browse through them, while a suitable breakup helps when there are hundreds of files (but the same breakup is seldom usable for all categories or uses). Pre-creating categories will result in the frustrating categories with 0–3 files each, one of which may be – but usually isn't – the file you are searching for. A general technical solution is needed. If we have the year and the substance category, a suitable tool should be able to find any relevant file. We need such a tool integrated in the user interface.
Ah! I notice the page banner is asking for ideas for tools. Isn't this one that should be highly prioritised? Does anybody have an outline ready, or the experience to describe the needed tool well?
LPfi (talk) 13:01, 11 January 2022 (UTC)[reply]
@LPfi: I created this one, to answer that question. --Enyavar (talk) 10:02, 13 January 2022 (UTC)[reply]
@LPfi: The more general solution will be faceted search, through the search function, powered by structured data. If somebody really wants to search for images by year, that should be low-hanging fruit for such a system. By for maps, surely it's more common to want to see a curated view of maps of a particular thing, across quite a range of dates. And that is what suitably-organised categories can lend themselves well to, with their collation of what are the natural "things" that have tended to be repeatedly depicted. Jheald (talk) 18:33, 11 January 2022 (UTC)[reply]
Symbol oppose vote.svg Oppose. 10000% agree with User:Nosferattus. In my view everything finer than "by century" should go. Hard agree that "Maps of <location> by <year> categories should be burned with fire" (And I speak as somebody trying to prep two very large sets of map uploads). It was catastrophic that User:AnRo0002 in particular in 2019 created so many of these "by decade" and "by year" categories.
Categories should bring together things that are useful to browse together, not split them apart.
IMO the two things that are most needed are (i) have categories encompassing a meaningfully broad period, and sort them by date; (ii) split out maps depicting part of the <location> from maps depicting the whole location.
That way one brings together maps of the same thing - eg England as a whole, or London as a whole, or the continent of South America as a whole - and has the chance to see how the depictions of those places evolved. (And, equally, how previous maps got reissued decades or centuries later). And it helps us to see at a glance what is in the category that should be moved to a geographically more precise category, rather than it being lost across a million hard-to-explore different micro sub-categories. Jheald (talk) 18:20, 11 January 2022 (UTC)[reply]
Hard disagree on "Maps by century are sufficient". Sure, you can't find many maps from the 6th century, so there's no problem with that. But for some centuries (like "world maps of the 21st century"), we'll get inundated with maps, and I already started to classify new world maps I encounter by the year (like Category:2011 maps of the world) I only just started doing so while doing the unidentified maps, and I expect hundreds more maps incoming; for each year since 2000. Again, that statement I make exclusively for the 21st century maps of the world.
Some other granularities would be old maps by decade: Here I find it important to distinguish a 1800s map from a a 1890s map. Maps, their styles and what they are able to express change significantly over time, and if you are searching for a map of some (larger) place around the 1800s, I find it easier to go for the narrower decade-categories (i.e. search the maps between 1790 and 1809) than the broader century-categories (i.e. search the maps between 1700 and 1899). My two example decade-categories are already decently filled, and we know there are many files that would match the criteria, but are still entirely uncategorized. What you suggest is to sort hundreds of thousands of maps by adding the year like this [[Cat:<18th-century maps of place>|1724]]. That is just not feasible, someone tried doing that with the "Old Maps of London" once, but they failed to do so over more than a mere hundred of the maps of London. While there are thousands. The regular uploader just gives us [[Cat:Maps]], and while we have some volunteers who do little else but sort those maps - my observation is that most do so only very superficially, and don't care about subcategories. It also doesn't help that the map-category tree is never the same. How do you expect that the regular categorizer will follow a guideline to sort (old) maps by year?.
While I would love a better way to simply say "it's a <map> of <extent> from <year> about <topic>... the structured data tool is plainly unusable, requires even more arcane knowledge and also needs a lot more data-input efforts than the existing category-tools. It'd be great IF we had a "cat-a-lot for structured data". And then some automatism which automatically translates between structured data and categories. But we don't, neither.
Again, I'm referring you to this submission which should help browsing while still keeping whatever level of granularity any category currently has. You'll note that this cat and its subcats could also benefit from such a thing, which is aside from mere maps. --Enyavar (talk) 10:02, 13 January 2022 (UTC)[reply]
Until we have the working tools, the problem is when only one (or a few) of the subcategories have a suitable map. I might prefer a map from 1739, but what I mainly care of is that a certain place is included with suitable context, enough detail, certain aspects (topography/roads/coastline/rivers/whatever I happen to need), and that the map is intelligible at the scale I need. A map from 1830 may be the one that suits my needs the best – as there probably is no suitable map from 1739, and if there is one, it might not be in that category – and having a zillion of categories about maps showing roads, topographic maps etc. will not help, unless the specific category includes the map I am searching for. I won't be browsing through thousands of images, so a category where I am more likely to find my map helps, but going to the next page of a category is easier than to click on a category, get back to the parent and click on the next one, which is frustrating if the subcategories are small or deep. — Preceding unsigned comment added by LPfi (talk • contribs) 12:28, 13 January 2022‎ (UTC)[reply]
@Enyavar and LPfi: I think the structured data tools perhaps may get there sooner than you think -- especially as structured data / search / querying is the (unique) area of Commons that WMF have any central developers at the moment.
I don't know if you've used search recently, but already a search for say "Oxford" [2] comes back with prompts to refine the results by Licence / File Type / Image size / Community Assessment. Full general faceted search is hard; but adding options to narrow by image type (eg general photo / painting / print / diagram / map / etc) or by date or by maker would IMO be low-hanging fruit (along with some others), and I know that eg User:Multichill has very much been pushing for the search team to take more steps in this direction. Not least because it would start to show some real pay-back for all the investment that's gone in on infrastructure for SDC.
The more SDC starts becoming visibily useful, the more I think people will start building all manner of ways to transfer information into it -- including taggers, and tools to automatically add information of a particular type for all files in a particular set. So I think this will drop, and I think that when it does it will move surprisingly quickly.
On the other hand, what I think may be harder will be to teach search hierarchical information; and what is appropriate amount of hierarchical generalisation to include (eg should a search for "animals" return insects ? Should a search for "Oxford" include returns for every object in an Oxford collection? How should they be prioritised, compared to eg a general skyline view of Oxford, or a random streetview?) For these reasons, I do think categories will be around and continue to be important for the foreseeable future (even if some eg Multichill might disagree). Though I suspect we might see tools to filter category contents by particular SDC fields -- eg by date or date range, image type, location proximity, materials, etc. Which might favour larger categories over a larger number of smaller ones.
Even with the tools we have, eg m:PetScan I think it is already easier to find intersections between categories (eg "Old maps of London" and "1724 maps"), rather than to combine together a large number of small categories. PetScan can do the latter (eg return all files in a given category or up to 3 levels of sub-categories below it), but the more steps you go down a category tree, the more chance that it may have taken a turn in a quite unexpected direction. So in general I would say intersections are better.
Given that we start where we do, like User:LPfi, I think in general it is much less likely that I would be searching for a specific year, more likely that I would be searching for a particular type of map or subject of map over a range of years that would be acceptable. Having those maps together in a category makes that possible. Spreading them out over a myriad number of micro-categories essentially doesn't.
Possibly interestingly large libraries seem to think similiarly, so that in the systems of subject headings used for searching by eg the Library of Congress or the British Library the standard cutter they use is "Early Maps to 1800", giving rise to subject headings like "Chester -- Maps -- Early Maps to 1800" (their equivalent of categories), grouping together all maps of a place up to 1800, rather than even splitting them by centuries as proposed above.
As to whether date-sorting categories is manageable, I think it is. For one thing I have already got a script (see Commons:Bots/Requests/JhealdBot (7)) that can add |year sort keys for a particular category for a particular list of files, if the data is there in their file description page. And I suspect it was me that did at least some of the previous ordering of "Old maps of London", even if I may not have come back to it very recently. Once a category has been sorted into order, it's not so much work to deal with a few extra files at the end that may have been added since. And when people get the idea that Old maps categories should be sorted into date order, then people will do that, for tidyness.
I don't see a problem with a category having up to two to three hundred images, so long as they are sorted in an understandable way. (And it helps if they are of a similar thing, which is why I think categories like Category:Old maps of whole Wales (alone) or the categories in Category:Old_county_maps_of_England are worth separating out from the general "Old maps of Wales" or "Old maps of County X" categories.
At least this way one can see relatively quickly what there is; and, also, be able to identify quickly things that should be moved into different categories. Contrast that with eg things like Category:1750s maps of England which doesn't contain a map of England at all, but rather File:Bournemouth area 1759 map.jpg, which has a more precise categorisation, namely Category:Old maps of Dorset.
To me the by-year and by-decade categories are not helpful; and they are getting in the way of accurate classification of what the maps are actually of, by overwhelming us with so many categories that the maps which ought to be bubbled down to more precise geographical categories become no longer collected in one place, and no longer visible. Jheald (talk) 20:01, 17 January 2022 (UTC)[reply]
Discussion mentioned on the Wikimaps telegram group. Jheald (talk) 20:13, 17 January 2022 (UTC) [reply]
Discussion also noted on the Wikimaps facebook group Jheald (talk) 20:39, 17 January 2022 (UTC) [reply]
  • Symbol oppose vote.svg Oppose per @Jheald: . Let's not make more narrow category trees that aren't necessary. Thanks. Mike Peel (talk) 22:40, 18 January 2022 (UTC)[reply]

Renaming file-related templates[edit]

✓ Renamed, clear consensus. -- CptViraj (talk) 05:35, 23 January 2022 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The names of some file-related templates, like {{Image permission}}, {{Image source}}, and {{Image license}}, are terribly outdated, from the time when namespace 6 was named "Image", before it was renamed "File" in December of 2008. I propose renaming them {{File permission}}, {{File source}}, and {{File license}}, with redirects.   — Jeff G. please ping or talk to me 14:28, 28 December 2021 (UTC)[reply]


The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Category:Structures at night and Category:Illuminated structures[edit]

Currently, images of structures and buildings lit up by architectural/artistic illumination at night are divided into the categories Category:Structures at night and Category:Illuminated structures, with most of them in the former.
Now, technically illuminated structures are still structures at night, but if this distinction is made, I propose that Structures at night should only have images of unlit or functionally lit structures at night, and all the images of artistically illuminated structures and buildings be moved into Illuminated structures and their subcategories.
By architectural/artistic lighting I'm referring to dedicated lighting fixtures, usually using colored light, installed for aesthetic purposes, either emphasizing the structural forms (like File:Riga-railroad-bridge-night.JPG), or lighting up buildings for visibility (like File:Olavinlinna800.jpg). This does not include structures lit by functional or incidental lighting like street lights (like File:Cathedral bridge.jpg). Nelg (talk, contribs) 02:45, 8 January 2022 (UTC)[reply]

Replacing PD-textlogo for logos considered ineligible for copyright[edit]

Many logos have {{PD-textlogo}} applied to claim that the image is in the public domain. However, for public domain works Wikimedia Commons only accepts media that are in the public domain in at least the United States and the source country of the work (Commons:Licensing). Whether a particular logo can be considered in the public domain due to ineligibility in the source country depends largely on the copyright and threshold of originality 'rules' of the country in question; these rules are vary variable between countries and can be complex, usually relying on judgement based on precedents. Unfortunately, PD-textlogo does not convey this complexity and does not require the user to consider these requirements in addition to the US requirements when applying the template. Additionally, many countries do not have sections for their threshold of originality 'rules' to use to make a judgement, and the guidance for some countries is very limited.

It seems sensible that a new template is used in place of PD-textlogo for such files (such as {{PD-ineligible-logo}} or something similar), with the declaration of the country of origin being a mandatory parameter. This would mean logos match other areas with dual declarations and the template could then display like say {{PD-signature}} or {{PD-old-auto-expired}}, making a US declaration and a source country declaration (if not the US). PD-textlogo could then be depreciated and eventually usage could be transitioned to the new template. Given there are ~160,000 transclusions of PD-textlogo just updating that template might cause issues with enforcing new usage, plus the name is deceptive (it is not just used on logos which are only text).

Hopefully such a change would result in public domain claims only being made when they are appropriate to do so in line with Commons:Licensing. Comments welcomed. mattbr 15:38, 9 January 2022 (UTC)[reply]

Symbol oppose vote.svg Oppose Things are already complex enough. For some countries, our rules are quite ridiculous, and only based on extrapolation from irrelevant court cases. Do we have examples of take down notices for logos? I have not seen any. In addition, this proposal means reviewed 160,000 files for country of origin. Not really practical. Regards, Yann (talk) 16:10, 9 January 2022 (UTC)[reply]
I appreciate the rules might be complex, but surely an attempt should be made to comply with them and Commons policies? PD-text logo can be applied without being seen to try to consider them, and could be seen to over-simplify what can be quite complex. Should files be accepted for which the copyright status is not known? Commons:Project scope/Precautionary principle should be noted. I also appreciate that depreciating PD-textlogo does mean that a large number of files would need to be reviewed over time, which is why I have suggested depreciating its usage rather than updating that template. I don't think that this should stop a change being made which is for the good of the project. mattbr 16:36, 9 January 2022 (UTC)[reply]
Symbol support vote.svg Support in principle, though I would recommended we update licensing guidance on this before we start changing templates.  Mysterymanblue  21:00, 9 January 2022 (UTC)[reply]
Yes, suitable guidance should be developed, something similar to the intent of Commons:When to use the PD-signature tag perhaps would be a start. mattbr 20:10, 10 January 2022 (UTC)[reply]
I genuinely would want to see a page entitled "Commons:When to use the PD-textlogo tag", in fact we should have a lot more for all the tags we have. This page can then be used in deletion requests pointing to the thresholds of originality documented there making an easy page for uploaders, patrollers, and admins to consult. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:32, 13 January 2022 (UTC)[reply]
Symbol oppose vote.svg Oppose per Yann. This will just create even more work than there already is. 1989 (talk) 17:39, 10 January 2022 (UTC)[reply]
The need to state the country of origin is consistent with other PD templates and Commons policies. The most important aspect I think is to change the requirements for new usage, and because a large number of files are not suitably marked should not stop a change being made for new usage. It makes the problem worse than it already is. The tagging requirements for logos should not be any different to a signature or artwork where there is clear precedent for such declarations. mattbr 20:10, 10 January 2022 (UTC)[reply]
Would it help to add a country parameter to {{PD-textlogo}}, adding suitable wording, and recommending its use in the documentation? In deletion requests, the local standards, if known, should be used, but knowing what jurisdiction to research is helpful, and uploders and reusers might have use being notified of the issues mentioned above. –LPfi (talk) 12:49, 11 January 2022 (UTC)[reply]
I think that this would be the best solution, British copyright laws use extremely low thresholds while many other copyright laws require there to be creative input, explaining this and perhaps creating a dedicated page of examples of PD-textlogo's per country would be a better solution than depreciation. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:29, 13 January 2022 (UTC)[reply]
Yes, that is an option. It might make it difficult to 'enforce' usage though as there are already ~160,000 files which don't state the country of origin. mattbr 20:14, 13 January 2022 (UTC)[reply]
Yes, but we can simply add a new parameter option to the original template that categorises all non-country specific ones in a hidden category to be checked, this option is better than all out depreciation. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:28, 18 January 2022 (UTC)[reply]

Exempt user and user talk namespaces from being indexed by search engines[edit]

I propose to exempt user and user talk namespaces (2 and 3) from being indexing by search engines such as Google and Yandex by default on Wikimedia Commons. This has at least two effects:

  • It helps users to increase their privacy, and not fall victims of outing and especially doxing;
  • It nullifies the efforts of some spammers in promoting themselves or their products at their userspace.

Please note that currently users are able to add __NOINDEX__ to their userpage and exempt themselves from search engines indexing, but many users do not know this magic expression. Conversely, users can still add __INDEX__ to their userpage if they prefer to have their userpage indexed by search engines in case we change the default behaviour. 4nn1l2 (talk) 00:29, 18 January 2022 (UTC)[reply]

  • Symbol support vote.svg Support as the proposer 4nn1l2 (talk) 00:29, 18 January 2022 (UTC)[reply]
  • Weak oppose All activity on here needs to be documented: that's a feature, not a bug. Spamming is definitely bad but is this really a big problem? —Justin (koavf)TCM 01:44, 18 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support Yahya (talk) 08:04, 18 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose The purpose of these pages is to represent yourself like on an own website or a social media page. Hiding these pages would be against these purpose. You should never publish any information anywhere on Wikimedia projects you do not want to be public. --GPSLeo (talk) 13:17, 18 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support In general, and also particularly for the growing problem of CV spammers. Andy Dingley (talk) 13:20, 18 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose, Wikimedia Commons images and other files are used throughout the internet (and elsewhere) and many users leave instructions on their user pages for attribution and if someone sees "Picture attribution: User:Example, Wikimedia Commons" and if someone would search "User:Example, Wikimedia Commons" one would then no longer find the original uploader in the search results, it's how I found handy pages like "User:Russavia/Flickr-letter", "User:Fæ/email/American Red Cross". As for the idea that it would stop CV spammers, that's not true, the English-language Wikipedia also no-indexes user pages by default and it doesn't stop spammers, all it does it punish photographers in good standing from being discovered in the hope that it might stop a few bad apples. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:26, 18 January 2022 (UTC)[reply]
Another issue I have with this is that it's essentially "a slippery slope" for soon also having all Commonsspace pages no-indexed, pages which are really handy for researching national copyright legislature and how to contribute to the Wikimedia Commons and attribute to the Wikimedia Commons' contributors. In case of Wikipedia it's already impossible to find Wikipedia's rules, guidelines, standards, and information on how to participate via search engines, and if people only see finished sausages without knowing how the sausage of made it's no surprise that so many will make bad sausages because the instructions on how the good sausages should be made are already "hidden". As for outing, people who don't wish to be identified tend to already be careful with what they share online. The Wikimedia Commons is already "an unknown website" to most of the world who think it's either Wikipedia or don't know it exists, hiding even more of it seems counterintuitive. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:30, 18 January 2022 (UTC)[reply]
  • Still thinking about this. English Wikipedia already noindexes userspace (you can read the discussion about it here), and I support that. It's not just to discourage spammers, it's to make it so lousy information (ads, attack pages, hoaxes) that lives in someone's userspace isn't easily accessible by the world. But Commons isn't a place where people typically do that kind of stuff very often, so what would be saved? Are there many cases of people spamming on userpages? I don't understand the outing concern -- if there's personal information on your userpage, it's still pretty easily findable. — Rhododendrites talk |  13:56, 18 January 2022 (UTC)[reply]
    Outing not on Commons, but other places, say, Twitter using data extracted from Commons or Wikipedia. 4nn1l2 (talk) 14:02, 18 January 2022 (UTC)[reply]
    If you want to find potential real life relations between users you can do this if the pages are marked to be indexed or not. Most contributors are active photographers, as photographer with a strong need for privacy there are much more bigger issues then the user page. --GPSLeo (talk) 18:13, 18 January 2022 (UTC)[reply]
    Any photographer who wants to showcase their works or promote themselves can still add __INDEX__ to their userpage. This is just a matter of opting in or opting out. 4nn1l2 (talk) 18:18, 18 January 2022 (UTC)[reply]
    Wouldn't an opt in system then be better? I often click "Random" and see lots of photographs by photographers that seemingly never edit "Meta pages" (Commons namespace and all) and might only be aware of copyright pages, I have had a discussion with a WikiGraphist who has been here for 15 (fifteen) years and didn't know how to edit his signature until I explained it with screenshots to him. I can easily see many prolific photographers complain "Hé, why isn't my Commonswiki profile visible to the world anymore?". We should have a page called "Commons:Privacy" where we explain to people how to can opt into privacy settings. To stop spam we could easily have a rule that all user pages are no-indexed until a certain number of contributions have been reached, this would easily stop all spammers, like "Only index user pages of users with the "extendedconfirmed" user right". User galleries also become invisible, many users maintain galleries of their best images which would be easier for outside re-users to select, of course only if they could find these galleries. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:59, 18 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose We're a public wiki, trying to hide things by excluding them from search engines doesn't make any sense. Thanks. Mike Peel (talk) 22:42, 18 January 2022 (UTC)[reply]
    There is a difference between content pages and meta pages. Files are content pages and should be visible. Hiding meta pages from search engines completely makes sense as German Wikipedia and many other projects do so. 4nn1l2 (talk) 22:52, 18 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support per 4nn1l2. Strakhov (talk) 23:20, 18 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support good Idea --Isderion (talk) 02:24, 22 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose, is userspace spam a really big problem. If the users want to increase their privacy on commons, why would they put anything private on the userpages. And I believe we should not be hiding spam by exempting userpages from being indexed, instead I'd like to have some sort of policy that will govern what type of content is acceptable on userpages to directly fight these spammers. Thanks, Hulged (talk) 18:34, 25 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose, at least in respect of the User namespace. Donald Trung's argument is persuasive: pictures from Commons are often credited on other sites to the authors on Commons, and allowing searches to turn up the user page is helpful to let people find the authors of pictures. I'm not convinced by the privacy argument because user pages are not just public, they're meant to be public. A user page is where you put information with the intention that it will be found. I'm Symbol neutral vote.svg neutral on the user talk namespace (and other talk namespaces) because they're less carefully curated, more likely to contain overlooked privacy violations, and less likely to be a source of useful search results. --bjh21 (talk) 19:07, 25 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose hiding all this kind of stuff from google really messes up a lot of general searches, for everyone, including editors. I really don't see the point and if ppl still don't know that using their full name in public on the internet exposes them,, well they can always make the result disappear from google (the most popular content suppression that wikimedia gets exposed to apparently). It was a dumb idea at English Wikipedia and it's not much better here. I don't often agree wholly with Donald Trung, but on this I do. —TheDJ (talkcontribs) 09:38, 26 January 2022 (UTC)[reply]
  • Probably the proposer came to commonswiki to post this proposal after finding that the userpage was "NOINDEX" by default on some wikipedia projects. Well, this is a good point that NOINDEX do somehow protect user from receiving spam message etc, but we should remember that commonswiki is different from other project - it is a project which host free educational-purpose files, and many people will reuse these files. At this time, the attribution of files is really important. As Donald Trung said, index userpages will help other people find the original creator (photographer) - only a small number of those people know how to use special:search function, so I think it is not so good to "NOINDEX" userpages by default. Stang 21:27, 29 January 2022 (UTC)[reply]
    I have personally been subject to a lot of harassment on Twitter. I have now noindexed my own user pages, but I thought that it might be useful for other users too. If Commons community does not want it, so be it. It's not just because I want to imitate some other WMF projects in this regard. I understand that many Commons users are photographers who may need some sort of publicity and may not find noindexing their user pages useful. That's sensible and I accept that. 4nn1l2 (talk) 13:57, 30 January 2022 (UTC)[reply]
Symbol oppose vote.svg Oppose per many above. Bad idea.   — Jeff G. please ping or talk to me 22:48, 29 January 2022 (UTC)[reply]