Commons talk:Requests for comment/Technical needs survey

No objection, but...

I have no objection to the survey going forward, but I have a great fear it will miss the point. I'll raise my concerns here, in hopes that they influence the structure of the survey. I may have more to add as I think more about this.

We have so little consensus on Commons' strategy and future directions that it is hard to see how we prioritize technical needs beyond the need for maintenance of critical or widely used existing functionality. I'd also add that we have very little knowledge beyond the anecdotal as to how people currently use the site, and that we have no one in particular to advocate for the needs of users who are not significant contributors (people who just look at the site but don't edit; people who want to contribute the occasional picture or make the occasional minor edit). Here are some questions where I don't think we have consensus:

• Can we say that some classes of content are significantly more important than others? A tiny portion of our content is officially designated as "featured" or "valued" but I personally would also give priority to:
  • Content that is likely to be used in sister projects, most notably the various wikipedias.
  • Content that collectively forms a solid body of documentation that may not be available elsewhere, or at least may not be available freely licensed elsewhere (e.g. photographs of the prominent buildings in a particular city, photographs of people who are notable in a particular field, historical imagery on a particular topic). Properly curated, images in such a collection can gain value as a relevant collection grows, almost independent of individual picture quality, in contrast to (for example) having the thousandth undistinguished amateur picture of the Eiffel Tower, an ordinary housecat, or an a normal human penis.
  • Content that is likely to be destroyed if we don't preserve it (e.g. the successful salvage efforts we've made a few times when an image repository was about to be taken off line, or materials that are liable to be suppressed in their home country).
• Will Commons become a major video host? If so, this will require enormous storage and streaming infrastructure compared to what we have needed so far. This will probably be enough of a budget issue that the Foundation is going to have to be involved in any meaningful decision to move in that direction.
  • Similar considerations probably arise for some sorts of 3D models; offhand I can't think of other likely content that presents such issues. (Audio probably does not.)
• What is the relative importance of supporting various uses of the site (including both viewing and content contribution) on mobile devices vs. PCs?
• Categorization vs. structured data and how search relates to either or both.
  • I know this is almost a religious issue, in particular for some who believe SDC should entirely replace categories. I personally think it is close to inevitable that both will continue to exist for a very long time, and we may want to think more about how they interact and how either or both can better support users in finding particular content.

Process questions: some of our biggest needs are process needs, rather than needs for particular technology:

• As far as I can tell, creation of bots and tools has been very ad hoc, and many crucial tools end up maintained almost entirely by a single volunteer, who is liable to drop support without notice.
• We absolutely need a way to identify priorities, but priorities cannot be driven just by "how much would we like this?" They are also "how much will it take to get there?" Also, with non-technical priorities unclear, people may have very different visions of what is desired. I think we can see this last playing out (badly) in the current redesign of the Upload Wizard.
• In particular, we need to be able to make sure immediate pain points can get taken care of and "low-hanging fruit" can be plucked without getting wrapped up in the level of scrutiny we would give to a feature that would take a major technical effort, or where we might not even have general agreement that it is desired.
• Sometimes what we need is just some common sense. The recent debacle at Commons:Structured data/Computer-aided tagging shows how hard it is to stop a bad idea from moving forward once it has momentum. This was widely recognized on Commons as a mess no later than late May 2023; the team at WMF seemed to have no need to be formally data-driven to pursue this direction, but spent 3-1/2 months and significant resources in arriving at a formally data-driven decision to turn it back off; meanwhile, we were left with over a million bad tags to clean up.

Jmabel ! talk 21:50, 3 December 2023 (UTC)

Just my thoughts. Take it or leave it.

• I couldn't agree more about your first point. Commons isn't served well by hosting the umpteenth dick pic or image of a modern building, product, or whatever that's already been photographs millions of times. The platforms strength is really in serving as a place to visually document things of historical importance where media related to it are either hard to find, not available anywhere else, or were the image being hosted on Commons allows for some type of novel usage that would be hard to do otherwise. For instance your project documenting locations in Seattle or what I'm working on documenting postcards and postcard publishers.

• As I've said on the village pump I don't think that's served well by hosting video files. At least not to any major degree. The core purpose of Commons (whatever that might be) isn't served by turning it into a glorified, public domain version of PornHub. One of the things that really needs to be worked out is the platforms stance on "pornographic" images. On the one hand it should be free of censorship. But on the other allowing pornography or otherwise blatantly pornographic images really undercuts it's creditability as file host of educational content. I don't see how pornography could ever be adequately policed or otherwise reigned if we allow for video files either. Although it doesn't seem like there is the resources we'd need for hosting video files anyway. But it should be settled one or another regardless.

• 3D models are probably a separate issue. But it's generally better to do one thing well then do multiple things badly and there's already enough issue with image files without adding 20 other types of file into the equation. We should really focus on making uploading, view and working with images, and categories/SDC work well before taking more on then that. Otherwise it's kind of putting the cart before the horse. Like it's pointless to discuss allowing for video files if they can't even be uploaded in the first place because of how badly the UploadWizard works. So I'd say first iron out what the core purpose of Commons is, get the policy around pornography figure out, have the uploader fixed so it can upload large files to begin with, implement a modern way to categorize media, then maybe discuss allowing for 3D models and video. But in conjunction with how they would complement and serve the core purposes of the project, not just because 3D models look cool or whatever. --Adamant1 (talk) 04:15, 4 December 2023 (UTC)

For the pornographic content I already thought about creating a proposal to require VRT permission from the models of photos with nude people. With this we will have a much lower amount of content left where we have to discuss the scope. But that is of course independent of these technical questions. GPSLeo (talk) 06:53, 4 December 2023 (UTC)

That's a good idea. Although I think it's sort of related since there's no point in implementing or improving certain futures for specific groups of users, say educational or heritage organizations, if they don't want to contribute to Commons in the first place because we have the reputation of being a porn host. Like it would be cool if there were file statistics, but that would mainly benefit institutional uploaders who aren't really using the site to begin with. Not to say that's purely because of us hosting pornography, but is something I've read complaints about. So it's all related. Requiring VRT permission from the models would definitely help though. Clear voyeurism should also qualify for speedy deletion. But I'll leave it at that for now. --Adamant1 (talk) 07:21, 4 December 2023 (UTC)

I agree that not everything should be on Commons, and that historic importance must be taken into account. But modern buildings or products are also, or will soon become, part of history. Also, Commons isn't only an historic archive, so photos of many other things must also be here. But the thing here is about the number of images: avoiding unlimited pornographic or redundant images, but having only those needed to illustrate articles on Wikipedia and other wikis. I think that photos of, for example, buildings or cities, are almost always useful here, provided they are not excessively redundant (I think it's very nice to see people upload photos of all kind of neighbourhood buildings, that I hope that they will be able to be seen in the future, even if some of those buildings are no longer there, but on the other hand I have seen perhaps too many photos of sewer covers, that I find excessive, no matter how historical they are 😂). If we have many historic photos of 19th century, we should have many, many, many more of 21st century, because, fortunately, today is much easier to make photos, and we should try to preserve most of what is useful. We can see only just a small part of 19th or 20th centuries, but I hope much more from 21st century can be seen in future centuries. Finally, talking about redundant content, I think that sometimes too many photos of a celebrity in the same setting, or politicians in the same meeting, are uploaded, and just 1 or 2 photos would be enough, to avoid excessive number of files. MGeog2022 (talk) 20:38, 17 December 2023 (UTC)

I would possibly add a point how seriously we take curation as a priority. For example, we have tons (my estimate probably close to dozens of percents) of substandard quality photographs. We have criterion of keeping them which is "educationally useful" but it is interpreted extremely broadly from "has a chance to become a winner at a photographic competition" to "probably not out of focus and depicts what is states in the description". Do we want to have some better defined minimum standard, or we just store pretty much whatever gets uploaded? Ymblanter (talk) 12:11, 18 December 2023 (UTC)

I'd go as far as saying that we take curation as the only priority. There have been many complaints by 3rd parties that it is extremely difficult to host material in Commons and that even when you get it in there, it is mostly a black box. For a site promoting re-use of media files, we are very bad at actually allowing people to discover and re-use media files. There are for instance no usage statistics. And the entire File page is dedicated to curation. Gallery pages in wikitext are a terrible way to build galleries in our main namespace. Just compare it to a Flickr page and ask yourself where YOU would go if you needed an image. This also doesn't seem like something that the editors themselves care about a lot. —TheDJ (talk • contribs) 12:36, 20 December 2023 (UTC)

Can we try translating this into a proposal? Ymblanter (talk) 13:18, 20 December 2023 (UTC)

Thanks. I think this covers the main points I raised at the village pump. However, there is one point missing. We lack (or have but do not use) a process to discuss these issues in a structured way. On the English Wikipedia, I could imagine a group of two-three users preparing an RfC on any of the issues mentioned above (or any other similar scope issue which could come along), then have a cross-project notice which would guarantee at least a hundred participants of the discussion; the organizers would possibly open new RfC options if smth important comes along, and then the RfC gets closed and, if there is consensus for something, never gets reopened (barring some significant change of the situation). Here, we probably need to do smth similar, with also announcements on the projects (since many project users are not regular Commons users), but we are not protected from e.g. canvassing which may occur on the projects. Ymblanter (talk) 12:07, 18 December 2023 (UTC)

And, also, of course. AI - both for our strategy towards AI generated images (which ones are broadly in scope), and towards using AI tools. Ymblanter (talk) 12:13, 18 December 2023 (UTC)

I don't think the methodology of prioritizing is well-worked out. I'd have a ready-to-use way we could prioritize by structured linked arguments that I could describe and propose but don't think people would use that way anyway.

I just think one of the top priorities should be making the long efforts of volunteer contributors useful by improving how the site is shown in Web search results and how it can be used (proposal about that incoming). For example, most category pages barely get any page-views and are barely usable while lots of time is spent on categorization.

1. That relates to what my proposal will be about. Things to consider there are page-views and number of usages in other projects, especially ENWP, and year of latest data (vs outdated images). Other than that it's not easy to at-scale discern which things are more important. I think the site has both a pro-photographs bias and is severely neglecting scientific diagrams and illustrations and somewhat neglecting charts (could elaborate). Not sure what you're asking about there though.
2. There aren't many CCBY/PD videos so this question is irrelevant at this point and only concerns the future. Elsewhere I already proposed that if necessary one could maybe display files hosted on the Internet Archive if needed. However, that's very much within the current budget, the question would rather be how much it would cost and whether that would be a good way to spend it when compared to alternatives (such as software development or editor recruitment which however are currently both neglected anyway). 3D models aren't large, no problem there except that other filetypes should be allowed and textures too and that hosting them here may cost contributors' time and don't offer much benefit while some coding may be required.
3. One can't even see files' categories on mobile. This should be fixed asap. Mobile is at least as important as desktop but probably much more so since most users by now probably access the site this way. I don't think mobile uploads will ever be important since it's usually just low-quality photographs and most advanced contributors use desktop.
4. That is a major issue: as I probably have mentioned before: these should be synced so that work isn't duplicated and structured data isn't as gappy as it currently is. Unlike for categories I haven't seen a real-world major use-case so far and for many files there is problematic content in them. Search results relates to my upcoming proposal.

-

1. Tools should become integrated into Wikimedia Commons itself directly or via gadgets that you can enable by checking something in the preferences. This again comes back to the neglection of software development. There is an easy way to address it I have proposed many times and that is displaying a banner for recruiting volunteers at software-related Wikipedia articles (it could link to a campaign/contest for implelementing wishes and issues in MediaWiki code). I don't see why software development isn't a major priority of WMF.
2. One could also consider key weaknesses or key targets (like greater pageviews or active users) and how the issues relate to them. For example, other media websites have various useful features that WMC for some reason is still missing.
3. Don't know where you see a problem with the Upload Wizard redesign at this stage considering the feedback there.
4. One thing to consider is the effort required to solve, another would be the time of contributors saved for example. The immediate pain points are at the meta-level, specifically the lack of software development since all other proposals are tied to that. It doesn't even cost money to put up a note about an awards rankinglist event above a coding programming-related articles.

Prototyperspective (talk) 22:12, 28 December 2023 (UTC)

Proposal created as an independent page

I created a proposal by using the box, but it was created as an independent (and uncategorized) page (this page), instead of being integrated into "Commons:Requests for comment/Technical needs survey". Is this the expected behaviour? MGeog2022 (talk) 16:45, 17 December 2023 (UTC)

I don't know about "expected" but it's consistent. - Jmabel ! talk 19:25, 17 December 2023 (UTC)

@Jmabel, I meant that if, when creating a request, it was to be expected to be created on a separated page and not in "Commons:Requests for comment/Technical needs survey" directly (I was talking about expected behaviour by the form, not me). But I see that you added it also to the main page later. Thanks. MGeog2022 (talk) 19:36, 17 December 2023 (UTC)

This is indented as the main page could become to large if there are long discussions and allows moving and sorting of the requests. The same principle is also used for the daily and monthly deletion request pages. GPSLeo (talk) 20:09, 17 December 2023 (UTC)

"indented" => "intended", I presume. Took me a moment.

@GPSLeo: but the normal ways to add DRs transclude them to that daily page, which is within a monthly page. These seem to go nowhere, with nothing even pointing to them unless a user pastes it in, like I did. - Jmabel ! talk 00:03, 18 December 2023 (UTC)

Seem s to be that way, very surprising and inkonvenient.

Usually, if there is such a big blue button, it auto-magically includes the proposal to the page, here manual fiddling is needed, doable, but user-unfriendly. Grüße vom Sänger ♫ ^(talk) 13:20, 2 January 2024 (UTC)

Image and video thumbnails on servers

Why are thumbnails of different sizes generated on each file upload? Wouldn't be a much better behaviour to generate them on demand and store them in a cache, even if the first user has to wait for a few seconds? I think they must be a really big overload on total Commons size (many files are viewed only from time to time, and only in 1 or 2 of those sizes). Should a proposal be created for addressing this? MGeog2022 (talk) 20:31, 19 December 2023 (UTC)

In the past most complaints were about noch enough pregenerated and to slow generated thumbnails. As the thumbnails are very small compared to the original files there is no storage problem with them. The few time for a single file would not be a problem but for a gallery pages with many files even a tenth of a second per file would make the page unusable. GPSLeo (talk) 20:47, 19 December 2023 (UTC)

Image previews are pre-generated only to specific bucket sizes. These are generally the sizes listed below the original on the File page. All other sizes are generated on demand. They are not a big overload and more importantly, they are disposable (if required [and yes thumbnails have been deleted in the past for various reasons]) because they can be regenerated. The originals and archived originals are much more expensive as they can never be deleted. Similarly video derivatives (which take too long to generate on the fly when requested) and previews of all the pages of a pdf/djvu file are also really expensive to deal with. —TheDJ (talk • contribs) 12:44, 20 December 2023 (UTC)

Actually it is still a problem. MediaViewer uses 2160p thumbs and for large image files these are often not pre-generated and take longer to be generated than the time-out of MediaWiki. Often you have to flip through the images for some to actually appear in MediaViewer. Some are not shown ever. Same for large categories and galleries. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:23, 20 December 2023 (UTC)

@C.Suthorn: Would you be willing to share the names of some large categories and galleries where this is still a problem?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 17:22, 20 December 2023 (UTC)

Willing yes. But it is difficult. I often publish large numbers of large files from events. But then I found out that it does not happen, if I create an individual optimized Huffman table for each image. So I revsision uploaded this optimized images for better reuse of my images. I would need to look for uploads of other users that match the two criteria - and in doing so would trigger the generation of thumbs. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:47, 20 December 2023 (UTC)

@C.Suthorn P.S. it doesn't help to put 30KB of metadata, including a QR code 6 times (2 fields, both containing a text based drawing, an svg and a png) in all your files. That all has to be parsed, sanitized, stored in the database and requires more bytes to be transferred between servers before it can thumbnail the file. And uploading each image 8 times is also very wasteful as these older versions will never be deleted. —TheDJ (talk • contribs) 22:54, 20 December 2023 (UTC)

It does not help MediaWiki. But the images I publish get used outside of WM and nearly always they are not used AS IS, but the EXIF is nearly always changed - often removed completely - but in many cases some part of the EXIF remains. However it is impossible to know, what part of the EXIF will stay in the published file on another website. As a matter of fact the images I publish are used more outside of WM than in WM projects - I wouldn't know that without the EXIF. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 23:41, 20 December 2023 (UTC)

But you don't need 30KB for that. —TheDJ (talk • contribs) 23:42, 20 December 2023 (UTC)

@Jeff G. I now have an exmple: Category:Nicole_Schneider. Lazy loading does not do the job, i have to reload a number of times to get all the thumbs. The first pages of the cat should now show all thumbs, but the later pages not. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 19:11, 24 December 2023 (UTC)

@C.Suthorn: Hmm, on the first page of Category:Nicole Schneider (note the colon in the wikitext), I see two thumbs with just blank white rectangles that have shadow borders on right and bottom (as here) on the first page, and one each on the second and third pages. I start to see broken thumbnails about 2/3 of the way down the third page. All of the non-displaying thumbs are annoying.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 04:14, 25 December 2023 (UTC)

The (four) with the schadow border are broken uploads (file size is 1 byte short resulting in a "truncated PNG IEND chunk", but the (exiftool) "image data MD5" is correct). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:35, 25 December 2023 (UTC)

It's very unlikely that a thumbnail of that size takes so long that MediaWiki times out. More likely is that the page where you are on is trying to load too many new images at once and you are getting rate limited (unfortunately necessary because some people in this world think it is funny to see if they can take Wikipedia down). —TheDJ (talk • contribs) 22:17, 20 December 2023 (UTC)

@TheDJ: Uncomplicated cats can have 200 images on them, is that rate limited?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 22:28, 20 December 2023 (UTC)

What is an uncomplicated category ? —TheDJ (talk • contribs) 22:33, 20 December 2023 (UTC)

@TheDJ: A category page with no extra thumbnails displayed by the wikitext, like Category:Photographs taken on 2023-12-15. Three little icons don't count.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 23:12, 20 December 2023 (UTC)

Depends. I updated category page galleries this year to make use of lazy loading (so that it only loads images on the actual screen). A normal screen will only show about 30'ish images on screen at once. As long as you don't have the browser fullscreen on a 4K screen, or flick your scrollwheel to the bottom of the page too fast, you will probably be fine.

As a category for a date, it is however very likely to mostly contain unused images, which all still need their thumbnail for that size to be rendered for the first time. So compared to a category that is more topical like Category:Barack Obama (that people are more likely to visit) the chances of it happening on the example category page are relatively high. —TheDJ (talk • contribs) 23:41, 20 December 2023 (UTC)

Yes in most cases it does not matter but for some cases this is really annoying. One example are photo contests where you have a gallery with 600 photos and you want to view them on 4K display using the MediaViewer. If you skip to fast through the photos you run into the limit independent to what advanced users rights you have. I will create a proposal on this. GPSLeo (talk) 07:06, 21 December 2023 (UTC)

After reading a bit about "loading=lazy": The "LargerGallery"-Gadget seems to come without lazy loading and causing severe issues. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:01, 21 December 2023 (UTC)

Multiple renames to files

As I’m not an admin, I can’t submit a proposal. I’d like the ability to mass rename files. Though I’ve mostly succeeded in uploading my street photos to the correct names, occasionally I make a mistake. I’d like the ability to mass rename files using a pattern match. Is this something that might be proposed? - Chris.sherlock2 (talk) 12:24, 29 December 2023 (UTC)

@Chris.sherlock2: Assuming you have file-moving privileges, there's User:Jeff G./massrename.js with doc at User:Jeff G./massrename. And I can't think of anywhere on Commons where someone needs to be an admin to submit a proposal. - Jmabel ! talk 18:35, 29 December 2023 (UTC)

I tried to submit one here but the page is protected. - Chris.sherlock2 (talk) 22:02, 29 December 2023 (UTC)

Just realised, the template is protected. I thought clicking on the button would generate a new proposal. - Chris.sherlock2 (talk) 22:03, 29 December 2023 (UTC)

As a filemover I would like to add that massrename.js is an useful tool, but it's still far from perfect: it applies replace patterns on ALL files within the given category, it cannot work with really short replacements and stating the renaming rationale is not as easy as with the basic rename tool. — Draceane ^talk_contrib. 22:20, 3 January 2024 (UTC)

This inspired me to draft Commons:Requests for comment/Technical needs survey/"Building block" tool to select files. - Jmabel ! talk 01:05, 4 January 2024 (UTC)

Thank you! Great proposal. One thing that is missing is mass adding or modifying structure data. - Chris.sherlock2 (talk) 06:05, 4 January 2024 (UTC)

@Chris.sherlock2: Do we have any existing tool for that (and does it have a selection mechanism)? If so, please add it to the list. If not, that would be a completely separate proposal. - Jmabel ! talk 19:44, 4 January 2024 (UTC)

Sorry confused about voting

I saw some action here and voted on some proposals. There are some other votes floating around too.

I see the schedule that voting actually has not started! Oops! Bluerasberry (talk) 16:45, 16 January 2024 (UTC)

I will ping all people how voted during submission and cleanup phase and ask them to re add their vote during the regular voting phase. GPSLeo (talk) 18:20, 16 January 2024 (UTC)

I also over-read the part about a separate voting phase and just saw that other people already commented with votes. Wouldn't it be better if you let the existing votes standing, I think that would be better than just pinging people who had already voted which I think are mostly people who also submitted some proposal(s). Or maybe you could ping earlier commenters along with the vote underneath the proposals so they can add a shorter summary of their prior elaborations and discussions below it.

I think it may also be important to clarify that these are just some of the potentially most pressing issues; readers may get the impression there's not that much software development needed and that there's only few community proposals from seeing the small number of proposals (don't know if the best place to submit further would be VP/Technical; I've got many more incl some that may quite useful while not top-priority). Prototyperspective (talk) 12:01, 18 January 2024 (UTC)

@GPSLeo, I was just about to ask here about how voting worked. OK, I'll move all my votes to the new Votes sections of the respective proposal. I also added a Why I consider this proposal (mine) important comment to the end of Discussion section for some of my proposals, as a sort of "election campaign" to appeal to potential voters :-) MGeog2022 (talk) 13:54, 22 January 2024 (UTC)

@GPSLeo: Before reading that, I moved some votes to the voting sections. Sorry if I overstepped.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 14:14, 22 January 2024 (UTC)

@Jeff G., wasn't that what was supposed to be done? I've done the same, with all (I believe) my votes, and many votes from other users. If we can move them all to where they belong, the result will be OK as well, and voters won't be disturbed (but all Discussion sections should be reviewed to be sure nothing is forgotten). MGeog2022 (talk) 14:22, 22 January 2024 (UTC)

In this case it might be fine but moving comments and votes of users should generally not be done as the user who made the comment or vote might not agree with the move. The reason for the split was that I did not want that users vote on proposals shortly after they are created and might change in the proposal text. GPSLeo (talk) 16:48, 22 January 2024 (UTC)

Voting meaning

Just to clarify, we are just voting for or against the proposals, right? We aren't voting to have the N most voted proposals approved, and the remainder, dismissed. Any proposal with more votes for than against, will be taken into account (sooner or later, there's no deadline, of course), and any with more against than for, will be rejected. Is that right, isn't it? MGeog2022 (talk) 13:41, 24 January 2024 (UTC)

On the other hand, I think it would be fine, once this survey ends, to have an open debate about the proposals that are approved, if they have details yet to be specified. That is, to have the opinion of proposers and Commons community at large, not only that of technical people in Phabricator (though I would be willing to create a Phabricator account (if that's open to the public) if I find my proposals go in a very different direction from the original approach, and it's needed to provide useful ideas). Also, I think the Commons community could surely make many interesting contributions to all proposals (starting with mine ones), that we probably won't see in the same way in Phabricator. MGeog2022 (talk) 14:03, 24 January 2024 (UTC)

The voting is to get an ordered list to be used when talking with the WMF about our most urgent needs. In the order the number of opposing votes is not taken into account be we would of course need to consider if one of the top proposals has a large opposition. GPSLeo (talk) 17:17, 24 January 2024 (UTC)

@GPSLeo, thanks for the information. From what you said, I understand that no proposal is rejected unless it has a big opposition: if it has few votes, it's simply considered of lower priority than others. If it worked otherwise, I think it could be counterproductive, since voting for a proposal would be in some way as voting "against" other proposals (I would retire some of my votes if that was the case). I hope all useful and feasible proposals are eventually fulfilled. MGeog2022 (talk) 19:05, 24 January 2024 (UTC)

Why put a time limit on it?

I've requested the creation of this survey several times before and I'm glad that we finally have what the Meta-Wiki and German-language Wikipedia has, but a strong limitation of those technical surveys is the time limit. To me, it would simply make more sense to make submitting proposals and voting on them an indefinite process akin to how the Wikimedia Phabricator is run. Good ideas aren't just conjured up during specific periods and people can always advertise their ideas in the village pumps. Every month we can re-rank the ideas and add that month's "most voted on ideas" in a separate list. Both volunteer contributors and Wikimedia Foundation (WMF) and Wikimedia Germany (WMDE) staff can pick and choose from the suggestions which ones to implement and that could be listed in a special sub page called "#Adopted" or "#Implemented". The time limit has always been the largest limiting factor and the number of votes always reflect what the (technically active / aware members of the) community desires the most.

Perhaps the first (1st) round could be time limited, but I think that it's important going forward to leave this open as a general technical idea box where proposals and votes are always open. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:20, 14 February 2024 (UTC)

Nothing stopping us from doing another, but this started from some people in the WMF dev group asking us to give them a clearer wish list. If we don't bring it to some sort of conclusion, it really doesn't achieve what was asked for. - Jmabel ! talk 03:12, 14 February 2024 (UTC)

Comment on the results

The participation in this was not massive, but I think it was probably pretty representative. Although not everything I supported "won", I think this is (for the most part) an accurate reading of what the community cares most about. The only thing I suspect was an anomaly was because CropTool was in crisis at the time of the polling, it probably got more votes than it might have at another time.

@Sannita (WMF) and Selena Deckelmann: you should certainly have a look at the results of this survey. - Jmabel ! talk 18:34, 16 February 2024 (UTC)

Thanks @Jmabel! I appreciate all the work everyone did to produce the survey and tabulate the results. I will review with great interest.

Separately, I am also interested in the perspective shared at the top of this discussion page which highlights the struggle with strategy, and thus problems with how to prioritize without articulating a clear strategy. I really appreciated and learned from that thread. This is a recurring theme of challenges I observe throughout Wikimedia Projects.

I'm curious about how we can explore possible strategies together. My experience with this kind of work is that it is valuable, and very difficult because of the time commitment and level of detail needed to produce useful insights. I would be excited to work on this with Commons volunteers, and am curious how you all might envision a successful process for exploring strategies.

My view is that strategy is always a tradeoff, and choosing one will be the hardest part of any process. If we could determine how to choose up front, my guess is that the strategy generation and exploration process will be enjoyable and participatory. And I recommend that working together on time frames for milestones that are significant, rather than setting a date for the strategy to be set, as we might want to explore a few different hypotheses, and those are usually best not rushed to judgement. SDeckelmann-WMF (talk) 19:14, 16 February 2024 (UTC)

Well, although I could be more, I'm satisfied with the results. I hope my proposal (process request with 8 votes, 2nd place in its category) will help to make media dumps to exist in the medium term (a Phabricator ticket already existed before my proposal). I also hope that votes for Jmabel's proposal about Massive support for video (or not) have been enough for it to be taken into account, and Commons eventually can improve its support for a relatively large amount of long videos. My proposal about File verification is at the back area of feature requests, but I want to approach it in a positive way: perhaps this technical needs survey wasn't the best place to address it, and more customized solutions are needed for problems that are very specific to certaind kinds of files (I'll probably talk about it on village pump later). Finally, my proposal Checkbox to mark new files as current on upload is even lower in the rank for feature requests, and, frankly, I don't mind it too much (I created it in response to an user being frustrated due to the changes in file overwriting permissions, but it wasn't something I was too concerned about, as long as these frustrations don't lead to policy changes).

These are the points I was personally most interested in. I hope overall results are the best for guiding the next steps of Commons. MGeog2022 (talk) 13:50, 18 February 2024 (UTC)