Commons:Village pump/Proposals/Archive/2019/11

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

Limit suppressredirect for filemovers to a new user group

NOPE:

No consensus. All filemovers will get suppressredirect. Pinging again for a Chinese translation of template:filemovermessage/i18n. - Alexis Jazz ping plz 21:28, 2 November 2019 (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.

See also Commons:Village pump/Proposals#Allow file movers to suppress redirects.

Pinging @Jeff G., GreenMeansGo, 大诺史, Davey2010, Storkk, Donald Trung, CptViraj, BD2412, Masumrezarock100, Nemo bis.

The option of only giving suppressredirect to a new user group (like "extended filemovers") wasn't on the table from the start, but seems potentially supported or even required for some of the supporters of the original proposal. This new proposal can hopefully determine if suppressredirect should be given to all filemovers or to a new user group like "extended filemovers".

Limit suppressredirect for filemovers to a new user group: votes

Support means suppressredirect will be granted to a new user group. Oppose means all filemovers will be granted suppressredirect.

  • Symbol support vote.svg Support - Alexis Jazz ping plz 09:00, 24 October 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Having a singular right assigned to an entirely different group like this seems like overkill. It doubles the amount of work people requesting it would have to do and it would double the amount of work admins granting it would have to do. I'm fine having all file movers have this right provided they know that the suppression of redirects improperly is grounds for removal of the entire right. A mass message could be used to inform them if people want to go down that route. --Majora (talk) 20:16, 24 October 2019 (UTC)[reply]
  • Eh.. I'm inclined to Symbol oppose vote.svg Oppose. As above, it's lots of extra work. We have quite a few file movers who would need to reapply if they wanted it. Plus, how are people supposed to demonstrate competency in moves beyond what is necessary to get mover? GMGtalk 20:21, 24 October 2019 (UTC)[reply]
  • A check on the d/b seems to show I have made over 100,000 page moves and I cannot recall any incident where a move became an issue that needed debate. Many have had the redirects deleted later on by those with sysop access, and though these are at the ignore level so I have hardly ever raised questions about the deletions, it's probably correct to say that the majority of those unnecessary and potentially unhelpful redirect deletions. Many of the moves were trivial corrections, with our guidelines being very fuzzy about "harmonization", but by deleting the redirect, we presume that auto-generation of filenames by upload projects being intelligent enough to avoid recreating the same filename, even when the newly uploaded file is unique or when the moved file have been overwritten, say by being cropped, and so the API does not generate an automatic live duplicate error. A secondary issue that is frequently created is the breaking of thumbnails on image pages, this is a much "smaller" issue, as I am probably one of the very few batch uploaders that creates embedded cross-reference galleries, but the impact is highly visible and fairly hard to correct once redirects are deleted. Before a 'suppress redirect' were to be generally available, there probably needs to be far better guidelines about how to assess good or bad use of the facility. --Fæ (talk) 09:54, 25 October 2019 (UTC)[reply]
Symbol oppose vote.svg Oppose per Majora. But we need to make it clear in our policies that suppressing redirects is *only* acceptable when moving another file into its place. I see a lot of unnecessary and unwarranted speedy deletion requests for redirects so there certainly exists an awareness problems about redirects. Unfortunately, some of our admins also don't know our policies regarding redirects and grant those requests. We need to make sure, this does not become even more of a problem. Sebari – aka Srittau (talk) 10:20, 25 October 2019 (UTC)[reply]
  • Symbol support vote.svg Support per reasons given in the original discussion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:43, 27 October 2019 (UTC)[reply]
  • IMO there is no reason to assume if an user is trusted with file mover right, they can be trusted with suppressredirect. suppressredirect right can be used to suppress redirects to pages other than files. We'll have to develop separate guidelines. If we create a new group, I suggest to add additional rights to this (move-subpages and other rights) just like enwiki's page mover group and name it so. Currently move-subpages right is restricted to admins and I think giving this right to some non-admins would be helpful. For example, internationalized templates usually have a lot of subpages and if a translation admin (who is not an regular admin) wants to move a Internationalized page, they will have to move all subpages by hand. A Symbol support vote.svg Support if we add additional rights or else Symbol oppose vote.svg Oppose as I see no need for creating a new group. Masum Reza📞 04:45, 29 October 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose No need to create a hierarchy of user groups, with a spectrum of 'trustworthiness'. If you can't be trusted with the suppressredirect right they can't be trusted with filemove right either; the latter cause enough problems already and, if we make it clear when to use and not to use suppressredirect, like in Template:Filemovermessage/i18n, then suppressredirect won't cause much more trouble than filemove that warrants a new user group. --Zhuyifei1999 (talk) 06:47, 29 October 2019 (UTC)[reply]
  • Symbol neutral vote.svg Neutral after reading the comments above. 大诺史 (Talk/留言/토론/Discussion) 02:52, 30 October 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose per Zhuyifei1999. kennethaw88 • talk 19:18, 2 November 2019 (UTC)[reply]

Limit suppressredirect for filemovers to a new user group: discussion

@Majora: If you and other admins will be tough on improper use of suppressredirect and willing to remove the filemover right entirely in such cases, I'd be leaning more towards neutral. Also, it shouldn't be possible to enable suppression by default. - Alexis Jazz ping plz 21:09, 24 October 2019 (UTC)[reply]

I mean...I've always believed that abuse of a right is grounds for removal of that right. I do believe that we should tell file movers that they are a) getting this ability and b) what is expected with it so that they aren't blindsided. I can do a mass message to facilitate that but 1,400 messages is a lot of messages so I don't want to just do that without at least letting the community have some foreknowledge of it. As for defaulting, I just looked and "Leave a redirect behind" is the default option. I'm assuming this is probably a way to undo that but right now, mediawiki is set that way. --Majora (talk) 21:13, 24 October 2019 (UTC)[reply]
@Majora: As long as the suppression isn't a "remembered preference" or configurable in Special:Preferences, that part seems fine. When it comes to mass messages, we'll have to make sure we also get good translations. - Alexis Jazz ping plz 21:55, 24 October 2019 (UTC)[reply]
@Alexis Jazz: Indeed we would need translations. Thoughts on the core message (feel free to make changes)? template:filemovermessage/i18n --Majora (talk) 01:46, 25 October 2019 (UTC)[reply]
@Srittau: Do you have any opinions or suggestions on the message I'm planning on mass messaging to file movers? The template link is above. The way I see it there are a few additional reasons why the suppression of redirects would be warranted. Not many other reasons, but still. I'm probably going to mark up that template for translate later today. Once we get a good sampling of languages I'll set up the mass message as well. --Majora (talk) 20:26, 25 October 2019 (UTC)[reply]
@Majora: There is no Chinese translation yet, and several of our Chinese users (in my experience) don't comprehend English sufficiently to understand this message. - Alexis Jazz ping plz 16:14, 30 October 2019 (UTC)[reply]
Perhaps Zhuyifei1999 would be able to do this? I would very much appreciate it. --Majora (talk) 20:13, 30 October 2019 (UTC)[reply]
I'm really bad at idiomatic translations --Zhuyifei1999 (talk) 20:29, 30 October 2019 (UTC)[reply]
Pinging @Liuxinyu970226, Stang, Ruanlong, WhitePhosphorus. - Alexis Jazz ping plz 21:53, 30 October 2019 (UTC)[reply]
@Majora: Sorry for the late reply. Looks good to me! Sebari – aka Srittau (talk) 16:27, 30 October 2019 (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.
This section was archived on a request by: - Alexis Jazz ping plz 21:23, 2 November 2019 (UTC)[reply]

Namespace redirects TEM and MOD

ACCEPTED:

8 support for TEM:, 9 support for MOD: and no opposition. Both pass. Opening Phabricator ticket: phab:T237177. Split off UT: to its own proposal. - Alexis Jazz ping plz 08:18, 3 November 2019 (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.

After the creation of CAT: (for example cat:commons works now) , here are two more proposals. - Alexis Jazz ping plz 09:33, 27 October 2019 (UTC)[reply]

Namespace redirect TEM for template: votes

Not case-sensitive. (TEM: or tem: would both work)

Namespace redirect MOD for module: votes

Not case-sensitive. (MOD: or mod: would both work)

Discussion

Are the redirects automatic, or would they need manual creation? If they are automatic (e.g., TEM:Wikidata Infobox), then this seems reasonable, but if they need to be manually created then it sounds like it would be an unnecessary mess... Thanks. Mike Peel (talk) 15:24, 28 October 2019 (UTC)[reply]

@Mike Peel: They will be automatic. In fact, it isn't a "redirect", but another way to type the namespace's name (maybe we can call it an alias). It also works vice versa; you can type Commons:VPP instead of COM:VPP, there is no difference. Ahmadtalk 16:46, 28 October 2019 (UTC)[reply]
Thanks for the clarification. In that case, I'm neutral on these proposals. Thanks. Mike Peel (talk) 16:53, 28 October 2019 (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.
This section was archived on a request by: - Alexis Jazz ping plz 08:18, 3 November 2019 (UTC)[reply]

Enable Flow as a beta feature

WITHDRAWN:

I'd have opposed this too. Snow closing. If anyone feels the need to discuss Flow, start a new discussion on COM:VP or COM:VPT. - Alexis Jazz ping plz 08:01, 3 November 2019 (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.

As a user who likes the Flow system on wikis like MediaWiki, we should add the Flow system on this wiki. It would be opt-in. Calvinkulit • t • c 04:04, 3 November 2019 (UTC)[reply]

Symbol oppose vote oversat.svg Strong oppose Absolutely not. Flow is a horrible system and I want nothing to do with it. Even having it as opt-in means it would be on some pages that we'd have to deal with. No. Just no. --Majora (talk) 04:45, 3 November 2019 (UTC)[reply]
It might be a horrible system to you, but it may change. Calvinkulit • t • c 04:52, 3 November 2019 (UTC)[reply]
Could you elaborate more on the matter? You used "horrible" adjective. This must mean it is problematic or something like that. I'd like to hear full details, please. Masum Reza📞 04:56, 3 November 2019 (UTC)[reply]
It's buggy. The organization structure of the "threads" is backwards. It is featureless compared to regular wikitext and it was replaced with visual editing and/or the new wikitext mode anyways. Flow discussion boards are just that. They are either flow or wikitext based on the content model. So for someone to want flow on their talk page means forcing everyone that needs to leave them a message to also use flow. Having a bifurcated talk page layout like that is just a bad idea. --Majora (talk) 05:17, 3 November 2019 (UTC)[reply]
@Calvinkulit: Can you elaborate on what you mean "it may change"? Jura1 (talk) 06:00, 3 November 2019 (UTC)[reply]
Using it breaks search. Jura1 (talk) 06:00, 3 November 2019 (UTC)[reply]
Pictogram voting delete.svg I withdraw my nomination Calvinkulit • t • c 06:21, 3 November 2019 (UTC)[reply]

@Calvinkulit: If you are interested: Commons:Village_pump/Proposals/Archive/2018/01#Proposal_to_uninstall_Flow --Zhuyifei1999 (talk) 07:08, 3 November 2019 (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.
This section was archived on a request by: - Alexis Jazz ping plz 08:01, 3 November 2019 (UTC)[reply]

Using MediaWiki:WatchlistNotice to neutrally advertise advance permission requests

After a village pump thread was started regarding this topic I thought it would be prudent to just start an official proposal and let the community decide if this is an appropriate action going forward. There are four advance permission requests that would need to be discussed. Administrator, Oversight, CheckUser, and Bureaucrat. If announcements are approved by the community they will be translated into as many languages as possible and they will be neutrally worded. Proposed wording for each announcement is included in the specific sections below. In the rare event where there is a mix of requests currently open for discussion multiple notices will be posted to maintain translations. Please voice your thoughts, concerns, criticisms, etc. in the discussion section. --Majora (talk) 12:16, 6 November 2019 (UTC)[reply]

RfA announcements

Proposed wording: A request for adminship is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for adminship are currently open for discussion.

RfB announcements

Proposed wording: A request for bureaucratship is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for bureaucratship are currently open for discussion.

CU announcements

Proposed wording: A request for checkuser rights is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for checkuser rights are currently open for discussion.

OS announcements

Proposed wording: A request for oversight rights is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for oversight rights are currently open for discussion.

Discussion (notices)

This proposal makes the false premise that Watchlist notices are necessary. What's wrong with VP notices? --Fæ (talk) 12:29, 6 November 2019 (UTC)[reply]

Pretty sure that there are plenty of editors that just go about their daily business without ever having a look at the VP. They may not even understand the discussions there due to language barriers, but they would probably still like to be informed about ongoing votes. For self-proclaimed multi-lingual project we already have an incredibly strong bias towards the use of English. Standardized, translated messages for votes could be one way to reduce that a bit. --El Grafo (talk) 12:42, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support for RfB, OS, and CU votes. But NOT for RfA votes, as they should not be a big deal. No need to advertise adminship requests on Commons. Becoming an admin is relatively easy on Commons (unlike some infamous and failed projects) and I really like that. A minimum of 8 support votes for a successful RfA proves the self-confidence of this community to me (bad admins can be dealt with). No problem in RfAs --> No fixes. 4nn1l2 (talk) 12:31, 6 November 2019 (UTC)[reply]
  • Pictogram voting comment.svg Comment I miss RfA's on a regular basis because even though I've watchlisted the relevant pages, the single edit to that page that starts a new RfA easily gets lost among all the other things on my watchlist. --El Grafo (talk) 12:36, 6 November 2019 (UTC)[reply]
@Fæ: My personal view on the matter is that watchlist notices are just that, a notice. While a VP notice is a whole thread. Semantics, I know but an important distinction in my mind. Even if started neutrally it is impossible to keep threads that way and my personal belief is that all discussion about the permission request should remain on the subpage. Bifurcating the discussion only leads to problems. The watchlist notice is not a thread and cannot be edited by anyone other than sysops, and with a defined wording it can't really be edited to be non-neutral at all. --Majora (talk) 12:45, 6 November 2019 (UTC)[reply]
It would make sense if this proposal had no dependency on watch lists but were just about notices. How the implementation works is a separate issue. --Fæ (talk) 12:54, 6 November 2019 (UTC)[reply]
Sorry I had to go to work so my responses may be a little sporadic for a little while. That discussion is for disabling the gadget that assists in posting watchlist notices. The MediaWiki space and its behavior is created and set by the system itself. That is why they are called "system messages". You can't turn off a system message by disabling a gadget. It doesn't work like that. Watchlist notices will continue to be able to be posted regardless as they are part of the system. --Majora's Incarnation (talk) 13:04, 6 November 2019 (UTC)[reply]
Thanks for clearing that up! --El Grafo (talk) 13:38, 6 November 2019 (UTC)[reply]
@Majora: Um no? MediaWiki:WatchlistMessageCreator.js and MediaWiki:Gadget-WatchlistNotice.core.js are two separate things and neither of them are core. The linked discussion is to drop them since someone has to maintain them. --Zhuyifei1999 (talk) 17:55, 6 November 2019 (UTC)[reply]
@Zhuyifei1999: Fair enough. The actual watchlist notices are stored at MediaWiki:Watchlist-summary which requires no actual script to run. As I said, watchlist messages are part of the system. You don't necessarily need another script to produce them. --Majora (talk) 18:11, 6 November 2019 (UTC)[reply]
  • I have played with the idea of advertising some important stuff before. Because it couldn't be fully automated, I dropped it. Considering this proposal isn't fully automated either, perhaps it's time to pick that up again. The basic idea was simple: a notice box of some sort on all the village pumps/noticeboards or other high traffic pages (help desk?) that links to stuff. Users who never visit those pages could add the same notice box to their own talk page, it would be nothing but a template after all. - Alexis Jazz ping plz 13:24, 6 November 2019 (UTC)[reply]
    We have that already. Template:Centralized discussion. Nobody uses it though and judging by your post perhaps you didn't know that it has been displayed at COM:VP for quite some time? That is the problem with templates like that. Banner blindness eventually renders the entire space moot in one's mind. A disappearing and reappearing notice on a watchlist would combat that mental quirk. If you want something more automated I'm sure we can find a bot operator willing to set something up. That is what enwiki has. An automated watchlist notification system and, as I've mentioned before, their system is one of the very few things I like about their system of governance. --Majora's Incarnation (talk) 13:31, 6 November 2019 (UTC)[reply]
    Good grief, I just had a ghastly vision of piled up watchlist notices filling half my mobile phone screen, each hard to click on without going to whatever page I'm not actually interested in. If this gets passed in some fashion can we please ensure that notices are limited to a monthly quota, and that at least half the time there are zero watchlist notices popping up, just to ensure our real estate is not so littered with junk that we either become notice-blind, or end up disabling notices altogether? If necessary those requesting 'advanced' rights can always refrain from 'going live' until they have a notice slot. --Fæ (talk) 13:44, 6 November 2019 (UTC)[reply]
    Oh yeah. The vast majority of the time there will be no notice whatsoever and I prefer that. Requests for advanced permissions are relatively rare and requests for highly advanced permissions are even rarer still. Each notice can also be dismissed which is saved in a cookie so it does not reappear. In the rare event that there are multiple requests and the "multiple" notice has to be used when it is downgraded to a singular request the same cookie signature can be used so those that have dismissed it don't have it pop back up again. --Majora's Incarnation (talk) 13:57, 6 November 2019 (UTC)[reply]
@Majora: I indeed missed that. For two reasons, I think:
  1. It doesn't seem to be updated regularly. I'm not going to look at something that doesn't actually inform me.
  2. The template is buried by this massive "Welcome to the Village pump" box which is virtually useless for me and a completely irrelevant image of an actual bloody village pump. I have to scroll before it becomes visible. No, I'll never notice that because new messages are at the bottom of the page.
And seriously, that massive "Welcome to the Village pump" box is a total bore. Have I read the FAQ? HAVE I!! I don't use the "COMMONS DISCUSSION PAGES (index)" either. What's the blue bar at the top for, then? Why do we have two navigational templates? And what's the point of the daily headers anyway, besides needlessly inflating the TOC? - Alexis Jazz ping plz 14:31, 6 November 2019 (UTC)[reply]
  • WRT cookies, in the same day I might read or edit from phone, tablet, laptop. Cookies don't necessarily stop me from having to click off the same notice multiple times, in practice, I just ignore them unless they are really large and irritating (yes, some are annoyingly large, especially on mobile devices using desktop view rather than the cruddy mobile view). --Fæ (talk) 14:08, 6 November 2019 (UTC)[reply]
    Yes Template:Centralized discussion does not work, I just don't see it any more. Which brings me to my only concern about this proposal: The watchlist notice looks so much like the rest of the Watchlist that I don't see it either. (apparently on mobile that's a different matter)--El Grafo (talk) 13:46, 6 November 2019 (UTC)[reply]
    Unfortunately, it is going to be hard to combat that entirely. I don't really use mobile so I can't speak to that but in normal watchlists, at least for me personally, I saw the OS notice pretty immediately. I really do feel like this type of notice is rare enough to maintain a sense of novelty so that it is not ignored. And per above, I don't see them become so common as to cause issues as advanced permission requests are rather rare to begin with. --Majora's Incarnation (talk) 13:57, 6 November 2019 (UTC)[reply]
    Well, I could probably just edit my common.css to make watchlist notices pop out a bit more for myself … --El Grafo (talk) 14:09, 6 November 2019 (UTC)[reply]
  • (Edit conflict) I think Fæ makes a good point above. There are two separate but related questions to discuss and ultimately decide that are being mixed up a bit here:
  1. Do we want some kind of central notification of RfA/B/CU/OS?
  2. If yes, how do we implement this? (Watchlist notice is one option, but we also have Site notices, Template:Centralized discussion, and maybe more)
Personally, I would very much welcome some kind of systematic notification, but I'm not sure about what would be the best way to do it --El Grafo (talk) 14:03, 6 November 2019 (UTC)[reply]
I don't think site notices are the best option here as they appear on every page by design. You want to talk about banner blindness and intrusive announcements? Site notices inherently have both of those problems. If we want to try to use the centralized discussion template more that could be possible but we might have to redesign it so that people pay attention to it again. --Majora's Incarnation (talk) 14:22, 6 November 2019 (UTC)[reply]
Just want to make sure we consider all possible options … --El Grafo (talk) 15:47, 6 November 2019 (UTC)[reply]
  • The complaint about the proposal assuming we do want watchlist notices does rather suggest everyone is just going to vote rather than have a discussion first. Can we not do that please. I think all such requests should be posted and disagree with 4nn1l2 that adminship should be exempt. Quite often the only time I notice an adminship request is when someone closes it. The whole active community should be informed for all such posts. Also agree with Majora that VP posts are problematic, though we then need to make sure the Watchlist notice format is neutral. I don't think Majora's proposed notices are ideal because they do not name the user who is proposed. Therefore one will not easily tell that this is a different request to what you saw yesterday but forgot to dismiss. We have automated bots for processing feature picture nominations and a process for deletion requests, so I don't see why some clever person can't figure out an automatic way that new user nominations automatically create/modify the watchlist notice. I'm sure it isn't rocket science to combine if there are multiple concurrent requests. An automatic system could also detect a withdrawn nomination and remove the notice. As others have pointed out, it would be best if the notice was less invisible than it currently is. -- Colin (talk) 14:24, 6 November 2019 (UTC)[reply]
    Perhaps this question has too many facets to really be resolved with one proposal. Perhaps we should first have a discussion on whether or not we should have these notices at all. Since there appears to be disagreement as to which permission requests should have them. If that is decided in the affirmative then we can have a more focused discussion on the form and location. Do people think that would be more prudent here? --Majora (talk) 17:25, 6 November 2019 (UTC)[reply]
  • In my opinion the benefits outweigh the negatives, with user rights like these we want to make sure that those in these positions have "the consent of the community" which shouldn't be restricted to only a handful of users that happen to watch these pages. But de-sysop requests and other requests for the removal of rights should also be included. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:03, 12 November 2019 (UTC)[reply]

Votes (notices)

  • Symbol support vote.svg Support This would be useful, and matches what is used on enwp watchlists. Presumably the messages would display in the user's language? I think it would be better if usernames were specified in the watchlists, so that it's not necessary to click through to see if you know the person or not (as you're more likely to want to comment either positively or negatively if you know them), but I suspect there are good reasons for enwp not doing that. Thanks. Mike Peel (talk) 14:47, 6 November 2019 (UTC)[reply]
    I noticed this question wasn't answered. Yes, Mike Peel. The message will display in the user's language using {{LangSwitch}}. Something like {{RfX watchlist notice}} would be used. I just threw that together quickly so of course you should not assume that is the final product. --Majora (talk) 02:25, 12 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support - I support all of the above named user rights. Yes, RfAs are more common, but I miss them all the time. ~riley (talk) 19:22, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support -- CptViraj (📧) 02:50, 8 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support -- Eatcha (talk) 04:13, 8 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support but users should be able a to turn off these notices. If not, then Symbol oppose vote.svg Oppose. Masum Reza📞 10:23, 8 November 2019 (UTC)[reply]
    @Masumrezarock100: You can dismiss them but as of right now I'm now aware of a quick way you can fully turn them off without doing your own .css styling in your preferences. This would be true for all system notices. As mentioned above dismissal and hiding is done via cookies so it has its limitations. The .css styling to permanently turn them off is not hard (1 or 2 lines). So those instructions could be included somewhere such as enwiki does. --Majora (talk) 17:48, 9 November 2019 (UTC)[reply]
    @Majora: ..or stuffed into a gadget. - Alexis Jazz ping plz 18:13, 9 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support, sysops should have the mandate of the community and not just "Metacommonists" (those who watch these pages and other "community pages"), this will encourage wider participation of even more users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:05, 12 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support --El Grafo (talk) 10:04, 19 November 2019 (UTC)[reply]

Implemented by Majora --Hedwig in Washington (mail?) 08:52, 27 November 2019 (UTC)[reply]

This section was archived on a request by: Hedwig in Washington (mail?) 08:52, 27 November 2019 (UTC)[reply]
NOPE:

Snow closing because nobody is interested in Colin's smear campaign. Usually one would simply wait for the whole thread to be archived, but I guess we can't afford that luxury anymore.. - Alexis Jazz ping plz 17:26, 2 December 2019 (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.

Alternative proposal: remove "edit warring" from the blocking policy

Alternative proposal. Edit warring is just a form of disruptive editing. Commons:Blocking policy currently links to meta which is, as ~riley quite eloquently pointed out above, undesirable. Edit warring can be listed as an example of disruptive editing instead with a link to w:en:Wiki#Security wikt:edit war. "Vandalism" would be changed to "Disruptive editing" and vandalism itself also added to the list of examples. - Alexis Jazz ping plz 09:36, 23 November 2019 (UTC)[reply]

  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 09:36, 23 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose linking to meta, or removing the link, does not need a proposal. Vandalism is not the same thing as disruptive editing, unless by codifying the language we have stopped using plain English. --Fæ (talk) 13:08, 23 November 2019 (UTC)[reply]
@Fæ: So I guess you oppose the current policy as well, because that's where this comes from: "Vandalism. Disruptive editing or uploading may result in a block." This proposal would actually clarify that vandalism and edit warring are forms of disruptive editing. Also, errr, removing the link to meta does require a proposal, I think. - Alexis Jazz ping plz 13:36, 23 November 2019 (UTC)[reply]
Sorry, your proposal is muddied with several strands even though short. For example replacing a meta link to a link to an English Wikipedia article about wikis is less helpful as this is subject to editorial changes unrelated to Wikimedia related consensus. Pursuing improvement to the wording of BP on its talk page is fine. This is a tangent, but I agree that the current wording there is not the plain English definition where disruption may have no malign intent (like being the result of a technical problem or a misunderstanding) and may even be constructive to change, quite different to vandalism which is always intentional damage. Minor improvements like wording changes to BP, or adding or removing links to appropriate definitions, do not require a proposal, they can be discussed on the talk page so long as they do not change anything fundamental about the block policy that would undermine the original consensus. --Fæ (talk) 13:49, 23 November 2019 (UTC)[reply]
Goal of that Wikipedia link was to provide some definition of what an edit war is. wikt:edit war may actually be better suited for that though. And agreed, talk pages can often be used for suggestions, but the removal of the meta link may be problematic. In a way, by linking meta it implies we follow their policy. Not sure what the original idea was, but removal of that link probably requires consensus. - Alexis Jazz ping plz 14:15, 23 November 2019 (UTC)[reply]
  • Pictogram voting comment.svg Comment If anyone wants to start a poll on Commons that topic bans Alexis Jazz from starting polls on whatever random thoughts enter his head at a given moment, do let me know. -- Colin (talk) 15:40, 2 December 2019 (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.

No longer allow CommonsHelper imports from kowiki

Now that FileExporter (a Copy to Commons tool) is already a non-beta feature in kowiki, CommonsHelper is already redundant for that purpose in kowiki. Calvinkulit • t • c 03:04, 9 November 2019 (UTC)[reply]

Namespace alias T: for Template:

So, turns out that TEM is actually the language code for Temne, a language with 2.5 million first-language speakers.

Bummer.

T: as an alias for Template: is already in use by itwiki (Italian), hiwiki (Hindi), zhwiki (Chinese), and ruwiki (Russian) as well as some sister projects. English Wiktionary also has this alias. So if the WMF ever decides to create a new project with T: interwiki, they'll have to deal with all those projects anyway. This may even discourage the WMF from ever wanting to use T: for interwiki. - Alexis Jazz ping plz 08:50, 6 November 2019 (UTC)[reply]

Namespace alias T: for Template: votes

  • Symbol support vote.svg Support - Alexis Jazz ping plz 08:50, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support - per Alexis Eatcha (talk) 08:55, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support Now I support this proposal (which was the original proposal). To be clear, I oppose TEM‌ for Template, because it is too long as a shortcut for such a common namespace with 192,484 pages on Commons as of now. 4nn1l2 (talk) 09:56, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support -- Tuválkin ✉ ✇ 11:36, 6 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support.--Vulphere 04:34, 7 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose - I do not like short names and short aliases as they make things less readable. It is unclear to me what would be the benefit. --Jarekt (talk) 17:52, 8 November 2019 (UTC)[reply]
    The whole purpose of these aliases are to reduce the typing time of volunteers. And there are some lazy people who want this. Now then do you have any other reason for opposing besides w:en:WP:IDONTLIKEIT? Masum Reza📞 12:21, 11 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose - Per Jarekt. Multichill (talk) 22:04, 9 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support, But I wish we could have {{ as well. Sometimes I just type {{ in the search box, then I have to delete it and start typing Template: instead. Anyways, T: makes searching and typing easier, also per 4nn1l2. Ahmadtalk 12:03, 11 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support, + Ahmad252's proposal. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:46, 11 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose 1) Abbreviations tend to form a cryptic language readable only by experts. They can be a problem for new users if they are too many. 2) T: could also be an alias for Talk: namespace, and this illustrates that abbreviations are not really helpful. --Geraki TLG 14:54, 11 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support per nom. --A1Cafel (talk) 14:12, 22 November 2019 (UTC)[reply]

Namespace alias T: for Template: discussion

@4nn1l2: actually that original proposal wasn't for a namespace alias but only for a search box shorthand. Though I think most of us, including me, missed that. - Alexis Jazz ping plz 10:50, 6 November 2019 (UTC)[reply]
@Alexis Jazz: Sarang said When somebody uses e.g. the de:WP it should be well known that there are many 'search' abbreviations; as an example, H:T will make some suggested expansions, like Hilfe:Tabellen, or H:V like Hilfe:Vorlagen. That simplifies the access to many pages - not only to Help pages. H is indeed an alias for Hilfe (Help) namespace on the German Wikipedia
'+dewiki' => [
		'WP' => NS_PROJECT,
		'WD' => NS_PROJECT_TALK,
		'P' => 100,
		'PD' => 101,
		'BD' => NS_USER_TALK,
		'H' => NS_HELP,
		'HD' => NS_HELP_TALK,
	],
"Search box shorthand" is part of the package of an alias. 4nn1l2 (talk) 11:12, 6 November 2019 (UTC)[reply]
I'm only repeating what Sarang explained. I think most of us were confused. - Alexis Jazz ping plz 11:15, 6 November 2019 (UTC)[reply]

Don't allow LRs to grant Image-reviewer flag

License reviewers have right to grant Image-reviewer flag, but don't have right to remove it, I believe this is unhelpful and making extra work for sysops. If a LR closes a LRR and grants user the flag then an admin will have to remove redundant AP or patroller flag (Not necessary but most of admins consider removing redundant rights).[1][2][3] In another circumstance: If a License reviewer mistakenly grants someone IR flag then they can't remove it by themselves. We've admins who monitor COM:LRR regularly, so there is no reason for LR to close requests and I've seen requests being closed earlier by LRs. -- CptViraj (📧) 15:33, 13 November 2019 (UTC)[reply]

  • Symbol oppose vote.svg Oppose LRs are trusted users. If any mistake occurs, that can be easily dealt with. I don't like excessive controls and regulations which are common among hierarchical organizations. Wikimedia Commons should have self-confidence in its community. 4nn1l2 (talk) 18:37, 13 November 2019 (UTC)[reply]
  • Let's think outside the box: Why shouldn't we give LRs the right to remove redundant user-rights? 4nn1l2 (talk) 18:58, 13 November 2019 (UTC)[reply]
    Symbol keep vote.svg Agree. We can give license reviewers the right to remove (but not to grant) patroller and/or autopatrolled only when granting license reviewer. License reviewers are trusted and familiar with LR policy , so, why not? Ahmadtalk 20:17, 13 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Lets try not to find fault with things where there is none. Or, in other words, don't fix what isn't broken. Letting LRs grant the LR flag hasn't hurt anything that I can tell so far. If there are mistakes, which being humans (I'm assuming Face-smile.svg), there will be eventually then that can be easily fixed at that time. Otherwise, lets leave things as they are. As for also granting LRs the ability to remove redundant rights I would also oppose that for the same reason. I never really understood the need to remove redundant rights. If it is noticed when you are already modifying rights so be it but to create a whole new log entry to remove them seems like overkill. There is nothing "extra" you get by having the right twice. A LR/patroller isn't able to "double patrol" something. Giving LRs the ability to remove redundant rights puts on them the responsibility of admin actions (no matter how small that responsibility is). Frankly, I'd perfer to just leave things as they are. --Majora (talk) 21:16, 13 November 2019 (UTC)[reply]
    This [removing redundant rights] is, in my opinion, just a housekeeping task. Usually, when one becomes an admin, all their redundant rights (LR, file mover, patroller, rollbacker etc) will be removed. Having them won't break anything and will not give them any extra ability, but we remove them anyways just to keep the logs clean. Ahmadtalk 07:23, 14 November 2019 (UTC)[reply]
    @Ahmad252: I wouldn't mind keeping all the redundant rights. If someone is an autopatroller+license reviewer, it's easier to see what's happening. When some people are autopatroller, some patroller and some license reviewer it is less transparent. Also more complex if you want a selection of all autopatrollers, or all license reviewers which would be license reviewers and admins. To keep the logs clean, the log code should be changed to not show the redundant rights. Or even better!! it should say "+file mover" instead of "changed group membership for User from autopatroller, GWToolset user and rollbacker to autopatroller, file mover, GWToolset user, rollbacker and image reviewer". - Alexis Jazz ping plz 22:30, 22 November 2019 (UTC)[reply]
    @Alexis Jazz: Although I have no problem with redundant rights, I think the selection should be fairly easy. An SQL query can select the username of all autopatrollers, patrollers and license reviewers, and it will also show each username only once (auto duplicate-remover). But yes, I can see how redundant rights can be useful (like in Special:ListUsers). To my knowledge, the only technical difference between being a patroller and a license reviewer is an edit filter "pass" that license reviewers/administrators have (which isn't technically a "right"). About the logs, I can see both good and bad points in each method. Maybe someone can write a user script for it. Nonetheless, I think Special:UserRights is fairly old, it needs to be updated with an OOUI interface (like the new contributions page) and, maybe, some additional functionalities. Ahmadtalk 20:36, 23 November 2019 (UTC)[reply]

References

  1. ↑ Ref 1.
  2. ↑ Ref 2.
  3. ↑ Ref 3.

Photography taken in Azerbaijan

It´s possible that I might travel to Azerbaijan in the near future. What are the most important rules for photographs and photographers?--2A02:8070:A380:8E00:2DAD:3503:9DF4:68FB 21:33, 12 November 2019 (UTC)[reply]

COM:Azerbaijan gives a basic overview but I'd say a pretty important fact is that there is no freedom of panorama there. So anything still under copyright by their creator cannot be photographed even if it is in a public place. This includes works of art, buildings, etc. More of less be careful where you point your camera if you want to upload it here under a free license. Thank you for taking the time to ask beforehand though. For future reference, this type of question would be better suited at the copyright section of the village pump. --Majora (talk) 03:36, 13 November 2019 (UTC)[reply]
So this comes down that I can only upload the "old stuff". Does it apply also to modern gouvernment buildings like town halls or administrative buildings? Further more, is there a law that prohibits photos of military facilities or troops, police stations, jails etc. I tend to shoot not only the "nice" things but the controversial things as well. I don't want to go there, but just in case: Which law applies in Nagorno-Karabakh? It might be the case that I can shoot something out of the sky or from a nearby mountain with a long telephoto lens. And my last question does the copyright part also apply to city views. I mean it is impossible to shoot a panorama of the city without having some new buildings in the frame, that are protected by copyright laws.--2A02:8070:A380:8E00:383A:DBF9:5A71:752F 19:55, 15 November 2019 (UTC)[reply]
Yes it would. If the building has enough features as to meet what is known as the threshold of originality and it is new enough to still be within copyright then a photograph of it cannot be taken. What is considered "original" is often up for debate if the building is plain looking so overall I would say that you should avoid taking up close photos of newer buildings in general. As for other local laws, such as the prohibition of photos of certain places, we cannot tell you that here. We are not lawyers and while we have knowledge of copyright laws for certain countries other area of the law we just do not. If you have questions about that I'm afraid we can't assist you. Copyright laws are generally country based. Not regional. So the copyright laws of Nagorno-Karabakh would generally be the same as what is listed on the COM:Azerbaijan page. As for city views that is more complicated. A copyright concept called de minimis would apply here. If the copyrighted buildings are inconsequential to the overall photograph it doesn't matter and you can take photos of them. That is why I said "up close" in the sentence talking about building copyrights. You should really read the page on de minimis to understand this concept. As mentioned. It is rather complicated. However, if the building is not identifiable and its presence is just a consequence of the overall photo then it would fall under the first example listed at COM:DM#Guidelines. Although these photos are subject to deletion request review to glean the opinions of other members of Commons. --Majora (talk) 22:31, 15 November 2019 (UTC)[reply]
OK, this is what I understand: I can upload images of "old" buildings and artworks, but I need to check if "old" applies. Plain buildings, that have no special architectural features on them (as traditional kind of architecture or run of the mill architecture like standard bousing blocks) are not of much concern, even if they are more recent. I can upload panorama images showing copyright protected buildings if they are only a small and not dominating part of the picture, so as an experienced fotographer I understand and can apply the de minimis concept. You can not provide or are unwilling to provide lawful information about official buildings and/or military facilities, military equipment or troops or you are not aware that there is any regulation concerning these subjects.--2A02:8070:A380:8E00:EDB9:B1EE:9EC4:847 12:21, 16 November 2019 (UTC)[reply]
@2A02:8070:A380:8E00:EDB9:B1EE:9EC4:847: - hope I'm not too late with this! If you can get to the site shown in Photos 18-19 here (pdf) and get some photos of the endemic Pinus brutia subsp. eldarica (trees, foliage, cones), that would be brilliant! Also any other flora and fauna you can get, of course. - MPF (talk) 01:13, 30 November 2019 (UTC)[reply]

Add all rights of Autopatroller group to file mover, translation administrator, GWToolset users and template editor groups

The requirements for file mover, translation administrator, GWToolset users and template editor rights meet or exceed the requirements for the autopatroller group, so they should be trusted with the rights of an autopatroller. This also helps reduce hat collecting. MorganKevinJ(talk) 05:48, 13 November 2019 (UTC)[reply]

I think every user in these groups was in the autopatroller group before. (There are maybe just some special cases for GLAM Institutions or WMF staff.) --GPSLeo (talk) 15:20, 13 November 2019 (UTC)[reply]
@Morgankevinj: I researched this before for rollbackers. All but two or so were autopatrolled as well. While all those groups should be autopatrolled (and pretty much all of them are), I'm not so sure anymore about integrating those rights into file mover/rollbacker/etc because it's less transparent. - Alexis Jazz ping plz 17:32, 2 December 2019 (UTC)[reply]

Commons:Edit war

Commons does not have a policy or guideline on en:WP:EDITWAR, however, it does redirect to m:edit war. While this seems like an appropriate alternative for smaller wikis, I feel the community should have a policy/guideline that they agree on, rather than referencing to another project's policy (not that it appears to be a policy there). As well, having this on Meta wiki means it both gets less traffic and less translation. It can also be changed without input from our community. If there is support, I'd like to move ahead at wordsmithing our own guideline on edit warring. Of course, the page would be tagged with {{Proposed}} until voted in by the community through VP. Thoughts?~riley (talk) 05:10, 19 November 2019 (UTC)[reply]

I'm surprised that Commons doesn't have a EW policy. It would be good to create a local one or even to patriate meta policy over here. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 05:26, 19 November 2019 (UTC)[reply]
Examples of cases where it would be useful? It probably goes without saying but, if you write a proposal, please make it clear that it does not apply to files. An eventual general edit war policy should not be interpreted as contradicting the contested changes or upload war policy, which is well accepted and efficient. -- Asclepias (talk) 13:20, 19 November 2019 (UTC)[reply]
Far from needing examples, I think it's safe to say that we already operate as if we had an edit warring policy. That's usually a good sign that it's time to codify community norms. The page on Meta is imperfect for our purposes for a few reasons. First, it is specifically written with Wikipedia in mind, and appears to entirely disregard non-Wikipedia projects, of which there are many. Second, it's only been translated into seven languages, which is not ideal for Commons, our largest multi-lingual project. GMGtalk 13:29, 19 November 2019 (UTC)[reply]
I don't doubt that you have examples in mind, but still, instead of merely snapping "far from needing examples", would you be kind enough to give one, so ignorant people like me can finally say "oh, yes, now I understand what you mean and you're so right." -- Asclepias (talk) 13:49, 19 November 2019 (UTC)[reply]
Well, it looks like there have been scores of instances where edit warring or revert warring had been brought up in the noticeboard archives. GMGtalk 16:59, 19 November 2019 (UTC)[reply]
I think edit warring is currently covered by the general "Disruptive editing" clause on Commons:Blocking policy. I'm not sure an edit warring policy will help, because edit warring isn't easy to define. I think the editing on https://en.wikipedia.org/w/index.php?title=Corbiac_chapel&action=history wasn't edit warring according to w:WP:3RR (too much time passed between the reverts), but it was obviously edit warring. I'll give it a try: When someone reverts one of your contributions outside of your own user space and you disagree, you can revert that revert once provided you give a substantial reason in the edit summary. If your revert is reverted again you should discuss the conflict, for example on the talk page of the user or at the village pump. Reverting the revert without discussion is allowed when the initial revert is obviously vandalism, appears to be done in error (like an accidental rollback) or is reinstating content that is not allowed on Commons. In such cases, if your revert is reverted again you should notify an administrator. - Alexis Jazz ping plz 22:55, 22 November 2019 (UTC)[reply]
Another way..
Under what circumstances can you revert (undo) an edit? Note: the following counts all reversions in a conflict, regardless of who made them. Self-reverts don't count.
First reversion: always allowed provided you have a good reason.
Second reversion: always allowed if you provide a substantial reason in the edit summary.
Third reversion: allowed after discussion with the community or first reverting user. Also allowed when more than three reversions are allowed.
Fourth reversion and beyond: allowed in own user space, when there is community consensus, to remove content that isn't allowed on Commons and to revert vandalism. Typically you should notify an administrator when this happens.
That's perhaps more clear? - Alexis Jazz ping plz 23:06, 22 November 2019 (UTC)[reply]
Edit warring is currently covered by the "Edit warring" clause on Commons:Blocking policy, not the general "Disruptive editing" clause as you've indicated above - therefore a policy or guideline is needed. The proposal here is determining consensus to create a Commons-specific policy or guideline on edit warring, if and when there is support, we can begin wordsmithing before it goes in front of the community for approval. Using this thread to try to write the actual policy or define edit warring seems off-topic from the proposal at hand. ~riley (talk) 08:01, 23 November 2019 (UTC)[reply]
@~riley: how odd, how could I miss that? Anyway, it doesn't make too much of a difference. Supporting the creation of a policy that hasn't been created yet is.. odd for me. What if I supported it, only to see that whatever policy gets written is poor? Maybe I'd want to retract my vote at that point, but it would be too late. - Alexis Jazz ping plz 09:36, 23 November 2019 (UTC)[reply]
@Alexis Jazz: You are not being asked to support a policy that has yet to be written; this is a proposal to determine if there is a need for a policy on Commons. As previously stated (very clearly), if there was consensus for Commons to have it's own policy, one would be written, marked with {{Proposed}}, and voted in by the community. At that time, if you found it was poorly written, you could vocalize it and/or oppose. ~riley (talk) 09:48, 23 November 2019 (UTC)[reply]
@~riley: I know that, but by that time I may regret ever supporting Commons having its own policy. It's like asking "should we buy a new car?", well I don't know, what kind of car is it? But we can't know what kind of car it will be, because we'll only start looking into that after we have determined we do want to buy a new car. I don't know if I want a new car, I need to know what's on offer first. Maybe that's just me. - Alexis Jazz ping plz 09:56, 23 November 2019 (UTC)[reply]

Codification is likely to lead to gaming the system. A third revert rule or a 24 hours rule can be misused. A distinction of this project used to be keeping minimal bureaucracy, but as guidelines are never removed only accrue, we can no longer make that boast.

Other than making a new guideline, if the case that Commons is being disrupted because extra rules do not exist for when actions are needed during edit warring, then this may be as simple as adding to the two words in COM:BP about it, or even a couple of lines in COM:OWN. Noting that a case has yet to be made for specific rules in the way they exist on the English Wikipedia, which frequently lead to accounts being sanctioned over minor infractions or misunderstanding of when to count a 24 hour period from.

At the risk of extending discussion, Commons does have things like long, long overwrite wars. We see cases of this happening with political disputes about mapped territories. These may happen over years without resolution and each step in an obsessive overwrite 'war' may be days apart. This is still disruptive and for heavily transcluded images are potentially damaging for multiple projects that rely on them. Warning and sanctions may be needed in these cases where, eventually, discussion fails, but having a fixed generic codification would remove the intelligent role of an administrator assessing a case based on context and experience of the parties, and instead become a policing role. --Fæ (talk) 13:16, 23 November 2019 (UTC)[reply]

  • Seems like a fairly good compromise here would be to de-link the meta page, and provide a one or two sentence explanation on COM:BP. BP is actual policy, and does include edit warring, so we do currently have a policy against it, only one that consists of exactly two words, which is not very helpful, especially for the uninitiated who don't contribute to other projects that do explain the concept in detail. Something like:
Edit warring - Repeatedly reverting, undoing, or overwriting another user in a content dispute, instead of engaging in discussion and achieving consensus. This normally doesn't include things like reverting vandalism or changes made in one's own user space.
Seems like that should be pretty uncontroversial as a definition. I agree that arbitrary limits like 3 revert/24 hours can lead to gaming, and it's best to keep things subjective so that the community can evaluate each case individually on its merits. GMGtalk 13:42, 23 November 2019 (UTC)[reply]
@GreenMeansGo: but sometimes edit warring is allowed. (to some degree, at least) Rolling back vandals/socks who consistently insert the same message is a form of edit warring. In your own user space you may also revert another user multiple times. Repeatedly reverting good-faith edits that break templates isn't disruptive either. I think my proposal below isn't the worst. By putting edit warring under "Disruptive editing", it'll be up to the admin to determine if any particular series of reverts is disruptive. - Alexis Jazz ping plz 14:08, 23 November 2019 (UTC)[reply]
Well, I would say that things like vandalism don't count under a "content dispute". But that can be made more clear. See underlined addition. But I don't think that linking to en.wiki is an improvement over linking to Meta. At least Meta is also a multi-lingual project. I mean, we link to en.wiki policy all the time on en.quote, but that's a uni-lingual project linking to another uni-lingual project. GMGtalk 14:15, 23 November 2019 (UTC)[reply]
@GreenMeansGo: I linked en.wiki for a definition. In translations, that link should be changed. But Wiktionary (wikt:edit war) is probably better for this. - Alexis Jazz ping plz 14:21, 23 November 2019 (UTC)[reply]
I think the meta description is very poor and too informal. The definition on en:wp could be adapted quite easily for Commons. I only see merit in defining the term in its widest meaning, rather than getting bogged down in blocking protocol like 3RR. Many editors fail to appreciate they are edit warring on their first revert (Editor makes a change, change is reverted, editor reverts to restore their change). It is worth, like en:wp, mentioning exclusions to edit warring such as obvious vandalism, removing edits by blocked/banned users, living-person-defamation issues, user pages. -- Colin (talk) 15:40, 2 December 2019 (UTC)[reply]

Subproposal: Fast track desysop for misuse of tools in an edit war

If an administrator misuses rollback, deletion, and/or blocking in an edit war. There should be a quicker process to allow for their rights to be removed since it is very disruptive. This could require a majority vote by the Bureaucrats or allowing the creation of a desysop request without the prior discussion requirement. MorganKevinJ(talk) 20:06, 1 December 2019 (UTC)[reply]

@Morgankevinj: I agree (support), though I have been thinking about a more broad solution already. Actually I think the current version in my incubator is pretty much fine.. Should I put it up here? Any comment? - Alexis Jazz ping plz 20:42, 1 December 2019 (UTC)[reply]
I think it is too broad I will respond there later after thinking a bit longer about it. MorganKevinJ(talk) 23:35, 1 December 2019 (UTC)[reply]
It doesn't specify any particular abuse on purpose, if that's what you mean. Imagine an admin who starts calling everyone names: very undesirable, but not tool abuse. You can't specify every single undesireable action. - Alexis Jazz ping plz 01:10, 2 December 2019 (UTC)[reply]
If admins are abusing their abilities they can be blocked just like any other person, allowing for a full discussion about their user rights. If there is an emergency, such as a compromised account, stewards can be contacted on IRC for an immediate desysop. I don't really see a need for faster desysop procedures than we already have. --Majora (talk) 02:53, 6 December 2019 (UTC)[reply]
Especially now that you no longer can unblock yourself — let's say I am blocked by a compromised admin — all I can do on Commons is "blocking the admin who blocked me". (I may emergency-desysop on Meta if nobody else is around to do desysop on Commons but that is a different story.) — regards, Revi 04:16, 6 December 2019 (UTC)[reply]
How many cases occured in the last five years? What has been the damage due to a delayed desysop procedure? This is the most important questions to answer before going to change the procedure and have a big discussion about it.--Giftzwerg 88 (talk) 01:29, 8 December 2019 (UTC)[reply]

Displaying multiple images in the Wikidata Infobox using Javascript

Hi all. I would like to modify {{Wikidata Infobox}} so that it uses a Javascript switch to show the images that are linked to via image (P18), collage image (P2716), image of grave (P1442), image with frame (P7420), image of backside (P7417), photosphere image (P4640) and other properties. It will only show one image for each property. The current version displays some of these images, one above the other, so this change would simultaneously decrease the screen space that the infobox uses, and show more images that are linked to from Wikidata. The modification is coded up in {{Wikidata Infobox/sandbox}}, and you can see it live in these categories if you enable the 'Infobox' gadget in your preferences, for example see Category:Presumed portrait of Guillaume Filastre. Unlike the regular updates to the infobox, this requires a modification to MediaWiki:Common.js, and after a discussion with the interface admins, it seems that this requires community consensus to enable the javascript/gadget by default - hence this proposal. Please {{Support}} or {{Oppose}} below! Thanks. Mike Peel (talk) 21:07, 9 November 2019 (UTC)[reply]

Votes

  • Symbol support vote.svg Support --Eatcha (talk) 14:27, 10 November 2019 (UTC)π°[reply]
  • I like the idea in general, but as it is now it seems to take up an awful lot of space. Maybe just allow to skip through the pictures through a set of forward/backward buttons? Or at least shorten the descriptions a bit ("image with frame" → "with frame")? Assuming that this is just a work in progress, I Symbol support vote.svg Support making the changes necessary for further development. --El Grafo (talk) 10:26, 19 November 2019 (UTC)[reply]

Implementation

Thanks @Eatcha and El Grafo: for your support. I've now gone ahead and implemented this [1], it should be visible to all users now in categories like Category:Presumed portrait of Guillaume Filastre and Category:Sardinia Radio Telescope. I'll deploy the new version of the infobox to all categories shortly. Thanks. Mike Peel (talk) 11:29, 15 December 2019 (UTC)[reply]

@Mike Glad to hear. -- Eatcha (talk) 11:46, 15 December 2019 (UTC)[reply]

Add exception to COM:OVERCAT

In practice, there's an existing exception to COM:OVERCAT (over-categorization) which isn't mentioned in the documentation; I'd like that rectified. It is a fact that nearly all countries have both parent category and top category; for example Category:Dominica has both Category:Countries of the Caribbean (parent county) and Category:Countries of North America (top category). This is true about most countries, and countries should be noted as exceptions to the rule. The practice of doing this has happened not only as it helps the reader navigate Commons, but also as most solid sources state that indeed Dominica is a country in the Caribbean and is also a country in North America. The same exception occurs on Wikipedia. Other countries which have both parent and top category include:

The reasons for the over-categorization rule is to stop 'thousands of images' from appearing in the top category. As we don't have thousands of countries, it doesn't become a problem and therefore the rule is irrelevant; so let's make it an exception to reflect current practice.

I move that we include the wording that 'all countries are exceptions' to COM:OVERCAT (over-categorization). Llywelyn2000 (talk) 08:07, 14 November 2019 (UTC)[reply]

Pictogram voting comment.svg Comment The categories you have listed for Ghana, United Kingdom, and Zambia are parallel categories (e.g, both Category:Countries of Africa and Category:East Africa are subcategories of Category:Geography of Africa, not of each other) and don't violate COM:OVERCAT anyway. I don't have a particular opinion on this proposal, but those aren't good examples to justify it. Pi.1415926535 (talk) 08:37, 14 November 2019 (UTC)[reply]
Thanks Pi.1415926535. Both are geographical categories; but technically you're correct, because Category:Countries of East Africa doesn't exist, and it should, for consistency, imho, as does Category:Countries of South Asia. But you agree that the categories for India, New Zealand and Pakistan do violate COM:OVERCAT? If so, my suggestion stands. Llywelyn2000 (talk) 08:54, 14 November 2019 (UTC)[reply]
Symbol support vote.svg Support - Thinking specifically about countries of the United Kingdom, I can see the benefit of each nation being visible both as Countries of Europe and the United Kingdom as this would aid discoverability of content specific to each country. Jason.nlw (talk) 08:35, 15 November 2019 (UTC)[reply]
This can already be solved by adding "**" which would make it look like "United Kingdom (England * Northern Ireland * Scotland * Wales)", but why would a constituent territory of the United Kingdom be considered to be "a country" and not the republics of the Russian Federation or the States (Länder) of Germany and Austria? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:56, 17 November 2019 (UTC)[reply]
Pictogram voting comment.svg Comment Hi Donald Trung 『徵國單』 Thanks for the tip. Just so we are clear, Wales is very different to examples given. It fields 'National' teams in all major sports, has National Institutions like libraries, universities and museums, It has its own unique language, a 'National' Assembly with devolved law making powers, and a fabulous 'National' anthem, to give a few examples. You can see why many people might expect to find it in a list on countries.Jason.nlw (talk) 22:00, 18 November 2019 (UTC)[reply]
@Jason.nlw: I actually like this proposal and wanted to support it when it was listed, but the thing is that the constituent countries of the United Kingdom of Great Britain and Northern Ireland aren't sovereign States, in fact, the German words "Land" and "Länder" can be translated as "Country" and "Countries" as well. When looking at world maps created in the United States of America commonly depict its states in the same light as other countries, in fact the word “state” can also mean “country”. The states of the United Mexican States (UMS) are officially called “Free and sovereign states”. Many Spanish autonomous communities have their own cultures, languages, anthems, and even presidents. How can we determine which country subdivisions should be listed as “countries”, we simply don't have a simple definition for “country” other than sovereign state (excluding micronations). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:40, 18 November 2019 (UTC)[reply]
Hi Donald. I know hardly anything about the definition of USA states or the German use of "Land" and "Länder", but I do know that the ONLY criteria in selecting what is a country are the sources. If most reliable sources state that x is a 'country', then we on Commons need to accept that. Most reliable sources state that California, for example, "is a state in the Pacific Region of the United States"; the sources which note that California is today refered to as a "country" are very, very few, if any. And the same is true of all the 'Free and Sovereign State' of Mexico: perhaps you can give me an example of one, where today most reliable sources state that it is in indeed a country? Reliable sources should trump all other definitions. Please also remember that the Commons category is 'Countries', not 'sovereign states'; nowhere on Commons has it been accepted that 'countries' = 'sovereign states'. Indeed to do so would be highly political, and against the ethos of Wikipedia. However, if you think it may clarify the issue, then lets have both 'Category:Countries' (as defined by reliable sources) and Category:Sovereign states (also defined by reliable sources).
Regarding your question 'why would a constituent territory of the United Kingdom be considered to be "a country" and not the republics of the Russian Federation or the States (Länder) of Germany and Austria?' My answer would be simple: because the majority of reliable sources state that Wales is a 'country'. It would be up to individual republics of the Russian Federation etc to prove that the majority of reliable sources state that they are also defined as countries. Llywelyn2000 (talk) 06:59, 19 November 2019 (UTC)[reply]
Symbol support vote.svg Support I agree with both Jason and Llywelyn2000. 'Over-categorization', as far as countries are concerned is not a problem (unless at some point in the future, we do have 'thousands' of countries!!!) Really odd too that User:Pi.1415926535 hasn't yet bothered answering Llywelyn's question! It's obvious to all that the categories for India, New Zealand and Pakistan do violate COM:OVERCAT. Cell Danwydd (talk) 20:10, 15 November 2019 (UTC)[reply]
Symbol support vote.svg Support I do not see any problems of overcategorization for the category country; furthermore, making Wales invisible from all countries when it does stand on its own right does not play in favour of knowledge or diversity, but it rather looks like a shadow cast on all lying beneath (the UK umbrella). Iñaki LL (talk) 18:27, 18 November 2019 (UTC)[reply]
Such a rule is understood. It's not necessary to make it part of policy. It could be a suggestive guideline though.--Roy17 (talk) 21:19, 23 November 2019 (UTC)[reply]
  • Symbol strong support vote.svg ᔕɄρρ⊙☈☂ //Eatcha (talk) 10:04, 2 December 2019 (UTC)[reply]
  • Comment I think we need a larger solution, perhaps start having a country-specific set of instructions for categorization in general. For example, an instruction that "if you have a picture, put it into the photographs taken on date category and if there are X photographs of this country, create a subcategory" would be helpful. It does not make sense that Category:Photographs of Tanzania by date has so many categories with only one file when they could easily be moved into the larger month and photographs taken on pages while Category:Photographs of Germany by date has so many subcategories for the photographs categories while the Category:Photographs of the United States by date does not. I'll prepare a separate proposal about this. Then the question of Wales can be posted here and really discussed at a more proper instructional page to keep all related country issue discussions together. -- Ricky81682 (talk) 20:29, 18 December 2019 (UTC)[reply]
That's a very relevant, but separate issue, Ricky81682, as you suggest. 'Wales' is not even included in my proposal, as 'countries' refers to all countries, including India, England, Wales, New Zealand and Pakistan. As no rational arguments have been made against the proposal, I'll add the exception to COM:OVERCAT. Llywelyn2000 (talk) 19:15, 29 December 2019 (UTC)[reply]

We don't have enough videos, some proposals to Improve the issue of meagre video files on Wikimedia Commons

As per Special:MediaStatistics less than 1% of our files are videos, in size 4.97% of our total storage is video.
Q Why do we need more video?

  • A Visual stimulation grabs users’ attention, our goal of developing and maintaining open content, wiki-based projects and providing the full contents of those projects to the public free of charge is incomplete without educational videos.

Q How does a normal-user upload video (at present)?

  • A They either use FFmpeg(or any other video conversion tool) or upload via Commons:video2commons. Please note that new users are not aware of Video2commons and it's also restricted to AutoConfirmed Users for obvious reasons. Users editing through tablets/phones/phablets/cheap computers can't uses FFmpeg as it's slow.

Q Are we ignoring this problem?

  • A You know better, than I do.

Q Would it break WMF's server?

  • A Commons:video2commons runs on WMF server, it doesn't break it. WMF has enough processing power to handle the conversion.


Please feel free to oppose any of the following proposals, but don't forget to provide a realistic solution to increase the number of videos on Wikimedia Commons.

Proposal 1: Support conversion of MP4 files to open format like WebM & delete/nuke the MP4 file after uploading the transcoded Webm file

  • Most of the Video cameras record in MP4, smartphones record in mp4. The uploader is required to convert the video to Webm, otherwise, they can't upload to commons.
  • Conversion takes too much time(sometimes even days), expensive computers, etc.
  • It should be understood that videos would be recorded in MP4 no matter what we do, now conversion can either be done on the uploader's computer or WMF's servers.
  • By doing the conversion on the WMF server we can increase the number of video files. And by deleting the mp4 file, we are not hampering with WMF's goal of supporting open-source.
  • By not allowing the conversion on WMF servers we are certainly hampering upload of many educational videos.

Votes for Proposal 1

  • Symbol support vote.svg Support As the suggester -- Eatcha (talk) 10:08, 8 November 2019 (UTC)[reply]
  • Symbol support vote.svg yes, please. Many content creators can't upload educational videos to Commons because it doesn't support uploading of mp4 files. Masum Reza📞 10:51, 8 November 2019 (UTC)[reply]
  • Symbol support vote.svg Yes, please, I have tried uploading videos before discovering Video2Commons but gave up until I found out about the tool. A lot of newbies or just general users who do want to upload video files to Wikimedia Commons will be empowered to do so if this proposal gets accepted. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:43, 11 November 2019 (UTC)[reply]
  • I Symbol support vote.svg Support whatever of these proposals allows uploads of MP4. As it happens, the US government normally releases video in this format, and I have more than once downloaded and tried to upload a video only to remember that I forgot that the format isn't allowed. I'm not really qualified to comment on the technical nuances. GMGtalk 20:34, 30 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support same as GMG, proposal 1 or 2, it's mostly what developers think is more doable. Because that's usually the bottleneck. In fact, it may not matter what we vote anyway. We can't force any developer to work on it. - Alexis Jazz ping plz 20:50, 30 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Too complex procedure. It would make tons of additional backlog. – Kwj2772 (talk) 22:44, 1 December 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose - MP4 patents will eventually expire (around 2027?). We might as well keep the files around so we can use them once that happens. Plus we may want to re-transcode from the original sources at some point due to better codecs, fixes to transcoding bugs, etc. Kaldari (talk) 23:19, 31 January 2020 (UTC)[reply]
  • Symbol oppose vote.svg Oppose. Unless the WMF can't afford the storage space, there's no reason to delete the uploaded source files. They should be kept for future use, mostly re-encoding the VP8 and VP9 versions if such a need arises, generating versions for future formats such as AV1, and making future editing of the uploaded video files viable with less quality loss (see Commons:Lossy and lossless for why). Proposal 2 should be the short term solution, and Proposal 3 the long-term strategy. -- Veikk0.ma (talk) 14:42, 6 February 2020 (UTC)[reply]
  • Symbol support vote.svg Support the allowing of uploading of MP4. No position on whether we keep or delete the MP4 after conversion. Doc James (talk · contribs · email) 03:31, 10 February 2020 (UTC)[reply]
  • Symbol support vote.svg Yes, please - The first is a sure shot yes. Can someone quantify the cost per annum for having a mp4 to webM set-up? There are many "free online converters online" who support themselves via ad. So i don't think this will be by any chance the costs will run in millions of $. W.r.t second half - that can be debated. However, the first half is a definite yes.--Pratik.pks (talk) 03:08, 11 February 2020 (UTC)[reply]
  • Pratikpks I don't have stats for total minutes of videos but https://cloud.qencode.com/pricing tells that VP9 + Webm is the costliest combination supported on commons. AV1(in webm) is not supported but if we support that would be the costliest combination possible. If we we assume that every single video on commons is 5 mins, it would cost about $1 million(VP9+webm). For AV1 + webm itwould be about $2.5 million. Based on Special:MediaStatistics. PS: all these videos are uploaded in many years. -- Eatcha (talk) 05:33, 11 February 2020 (UTC)[reply]
  • Thanks for quantifying the amounts, Eatcha. So (VP9+Webm) costs $1 million to convert around 82,000 videos uploaded to date. So if we are to now apply these conversion for prospective videos, and assume 10K videos uploaded per year (it will costs $125K) or assume a bump in the number of upload to videos to 20,000 videos (due to easy conversion of mp4 to WebM) - it will cost ($250K). This pricing is based on an external provider, and if we do it on in-house servers, we could save around 50%, right? So the costs will reduce the ($62.5K - $125K per annum). Does that sound reasonable? Any further upward/downward adjustments in pricing? --Pratik.pks (talk) 02:45, 19 February 2020 (UTC)[reply]
  • Pratikpks $62.5K - $125K per annum is reasonable to me considering total donations, it depends on WMF. is it reasonable to them ? -- Eatcha (talk) 03:49, 19 February 2020 (UTC)[reply]
  • I don't have any numbers myself, but my gut feeling is that the numbers cited above are significantly higher than the true cost (especially if excluding any sort of salary of the people setting it up, and the fact that these servers already exist regardless of what happens with this proposal). I don't think we should make any assumption on cost of this proposal. If its unreasonably expensive WMF will tell us.Bawolff (talk) 11:13, 20 February 2020 (UTC)[reply]

Discussion for Proposal 1

With regard to the upload of a non-free mp4, these do not have to be visible on Wikimedia Commons, so the proposal as written is unnecessarily complex or negative.

The upload process puts the file on a WMF server where there are some checks and information like EXIF data is parsed in order to create the page that later appears on Commons. A video pre-processing stage can occur at that point, which can logically either reject the video file due to parsing errors, unrecognized codecs, any other type of error, or successfully release the webm version. The mp4 original could be retained in a file archive as a potential future reference, including the advantage of being able to automatically re-process the video should the pre-processing software be upgraded or indeed being able to release the mp4 should Commons policies change or the nature of the copyrights for that format change. --Fæ (talk) 11:08, 8 November 2019 (UTC)[reply]

The software, as written, mostly assumes that the initial verification stage is relatively fast, where transcoding can take a long time (possibly even hours for a long HD video). So making MediaWiki work that way, might involve some effort. That said, i think the effect of what you are saying is good, and perhaps can be accomplished more efficiently with slightly different technical implementation. Bawolff (talk) 02:47, 23 December 2019 (UTC)[reply]

Technical question: When I upload a long, high-resoluted video, I use CPU capacity of a Wikimedia Server. Is there any way for the upload website to use my own CPU for video conversion? --D-Kuru (talk) 16:07, 5 January 2020 (UTC)[reply]

Theoretically, yes. The problem is, the technology for doing so is mainly used to mine Bitcoin on unsuspecting users systems (one study found that literally half the use of Webassembly was to mine cryptocurrency.) I'm not completely familiar with Webassembly, but if there is a way to compile existing conversion code for the web, it's still going to be a lot of infrastructure that has to be written. If there's not, or it doesn't work well enough, doing it would be a huge project. So I wouldn't hold my breath for it.--Prosfilaes (talk) 02:10, 7 January 2020 (UTC)[reply]
So this is an interesting question. There's a couple points I'd like to make:
  • Wikimedia has lots of servers, at least several hundered. video scaling is a very small part of it. Part of the issue here of course, is not just that transcoding video takes a lot of cpu, but it takes a lot of cpu in a row (Some parallization is possible, but you can't just split it up amongst 10 different computers to take a tenth of the time).
  • Long ago there used to be a firefox extension called firefogg, which integrated with UploadWizard and caused videos to be converted as part of that.
  • WebAssembly can be used for this sort of thing. In fact, the reverse of that is kind of how we play videos/audio on iPhones where there is no other option [2]
  • Generally speaking, if we are creating transcoded assets (i.e. the resized videos), we would want to do it on wikimedia servers for quality assurance reasons. We wouldn't want a vandal to upload the 640p version to be something different than the original file.
Generally speaking I think w:WP:PERF applies here to a certain extent. Bawolff (talk) 11:08, 20 February 2020 (UTC)[reply]

Proposal 2: Allow uploading of MP4 files, only provide transcoded Webm files to download/stream.

  • Keep MP4 files, don't allow download of MP4 files nor streaming.
  • Instead, stream Webm version of the MP4 files and allow Webm version of the MP4 file to be downloaded.
  • It doesn't promote MP4, as we are disabling download and streaming. Users can no way get he MP4 file that was uploaded.
  • On August 26, 2010, MPEG LA announced that royalties won't be charged for H.264(patent expiring in 2027) encoded Internet video that is free to end-users.

Votes for Proposal 2

  • Symbol support vote.svg Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support Kaldari (talk) 16:00, 12 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support – Kwj2772 (talk) 20:22, 30 November 2019 (UTC)[reply]
  • Symbol support vote.svg Support, this would make uploading video files a lot easier as it is the de facto standard. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:36, 22 December 2019 (UTC)[reply]
  • Symbol support vote.svg Support I support this. I don't think the free content movement is well served by making it difficult for people to convert their works to free formats. I am strongly opposed to serving content in patented formats, but freeing content from patented formats seems like an obvious good. Additionally, the debian project seems to view MP4/h.264 as free enough to distribute transcoding software, which in my mind satisfies the requirement that Wikimedia's software stack should be forkable. Bawolff (talk) 02:52, 23 December 2019 (UTC)[reply]
  • Symbol support vote.svg Support - Tibet Nation (talk) 18:25, 29 December 2019 (UTC)[reply]
  • Symbol support vote.svg Support Keep, transcode and make available when patent issue is gone.--So9q (talk) 10:47, 16 January 2020 (UTC)[reply]
  • Symbol support vote.svg Support, with the exception of the proposal (all of these proposals, actually) conflating the MP4 container format and non-free video coding formats. A better wording would be non-free MP4 files or even better, specifying the video coding formats in question. MP4 is not non-free. Fully free MP4 files (AV1 + Opus) are possible and are actually served by Youtube, though I'm not sure whether Commons currently accepts them as uploads. -- Veikk0.ma (talk) 15:14, 6 February 2020 (UTC)[reply]
  • Symbol support vote.svg Support Good idea too Doc James (talk · contribs · email) 03:32, 10 February 2020 (UTC)[reply]
  • Symbol support vote.svg Support This is extremely useful. —Justin (koavf)❤T☮C☺M☯ 04:34, 10 February 2020 (UTC)[reply]
  • Symbol support vote.svg Support This is a brilliant idea, and a great balance between functionality and values. --Pratik.pks (talk) 03:05, 11 February 2020 (UTC)[reply]
  • Symbol support vote.svg Support Is there a holding-pen somewhere where the mp4 files can be saved until the patent expires? Archive.org maybe? Victorgrigas (talk) 19:06, 11 February 2020 (UTC)[reply]
  • Symbol strong support vote.svg Strong support Perfect. --pandakekok9 04:52, 11 March 2020 (UTC)[reply]
  • Symbol support vote.svg Support We need this. -Theklan (talk) 08:23, 16 March 2020 (UTC)[reply]
  • Symbol oppose vote.svg Oppose as worded. Doesn't make any sense, why keep a file nobody can view, when by 2027 there will/are certainly be better codecs (e.g. AV1) available? -FASTILY 22:21, 13 April 2020 (UTC)[reply]
    • @Fastily: All web video codecs use lossy compression (AFAIK), so the originally uploaded file will still be the highest quality regardless of what other codecs are available in the future (assuming that the uploader doesn't re-encode it from an uncompressed master and re-upload it once the newer codecs are supported). In other words, every time a video gets transcoded it loses quality, so retaining the original (and using it once we can use it) is desirable. Kaldari (talk) 01:02, 30 April 2020 (UTC)[reply]
  • Symbol support vote.svg Support but I would go further and allow downloads of original MP4 files (but no streaming and no server-side transcoding into MP4 of any sort). I am not a patent lawyer, but I believe that merely copying a file around verbatim does not make use of a patent in any way. Here I think our goal of avoiding non-free file formats is outweighed by the fourth freedom: the "freedom to make changes and improvements". Video compression is lossy, and any editing should always take place on the original file. -- King of ♥ ♦ ♣ ♠ 19:55, 22 May 2020 (UTC)[reply]

Discussion for Proposal 2

There is no advantage in "displaying" a mp4 that reusers cannot access, or viewers see. For this reason it's really the same as proposal 1 in my eyes, as the choice of whether to keep an original video in the filearchive is the same issue. --Fæ (talk) 11:12, 8 November 2019 (UTC)[reply]

I think the implied difference is that under this proposal the MP4 files would more easily be made available for streaming and downloading in 2027 (once all the patents have expired), without requiring undeletion of all the source files. Kaldari (talk) 16:00, 12 November 2019 (UTC)[reply]
Also saving the file in a MediaWiki way, allows re-transcoding if there is some bug in the transcoding process or we need to transcode to new formats later like AV1 (Its always best to transcode from original where possible). Bawolff (talk) 02:49, 23 December 2019 (UTC)[reply]

Proposal 3: Use AV1 codec instead of VP9/VP8 as the main codec, (AV1 is new and better free codec)

Tracked in Phabricator
Task T209437
  • AV1 is a new and better free codec then VP9, AV1 can use WebM, mkv, and mp4 as a container.
  • It was developed as a successor to VP9 by the Alliance for Open Media (AOMedia).
  • Tests from Netflix showed that, based on measurements with PSNR and VMAF at 720p, AV1 was about 25% more efficient than VP9 (libvpx).
  • Similar conclusions with respect to quality were drawn from a test conducted by Moscow State University researchers, where VP9 was found to require 31% and HEVC 22% more bitrate than AV1 for the same level of quality.
  • Facebook showed about 40% bitrate savings over VP9 when using a constant quality encoding mode.

Votes for Proposal 3

Discussion for Proposal 3

  • There is a lot of arguments here without any evidence. Masum Reza📞 10:20, 8 November 2019 (UTC)[reply]

@Masum Reza📞 Here you are:

There does not need to be a proposal agreed for this to proceed as a task on Phabricator. As this is a fairly technical point, and there may be operational issues that are not known here, but might be known to the Phabricator community, it makes sense to start the Phabricator discussion anyway. --Fæ (talk) 11:11, 8 November 2019 (UTC)[reply]

  • I think this should be left to the multimedia devs to decide. There's lots of technical considerations involved (Client support, maturity of implementations, different performance requirements for encoding) as well as technical work that someone has to do to make it happen. Bawolff (talk) 02:16, 23 December 2019 (UTC). Addendum: I would add, I doubt this proposal would address the issue. Most users do not know what AV1 is, lack of AV1 support is not the reason we have few videos. Bawolff (talk) 02:54, 23 December 2019 (UTC)[reply]
NO ACTION:

Snowball per objections below MorganKevinJ(talk) 01:50, 20 November 2019 (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.

Proposal 4: Integrate any open-source video conversion suite inbuilt the commons android/IOS app

  • It should facilitate the uploading of videos directly from smartphones, as users don't need to download an extra app to convert video. (It's gonna be very slow BTW, due to less processing power of phones)

Votes for Proposal 4

  • Symbol support vote.svg Support -- Eatcha (talk) 10:10, 8 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Idea is good but we want high quality and not fast encoded content. That is not possible on mobile devices. Even on a high end desktop most encodings can not run in real time. --GPSLeo (talk) 09:46, 9 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose I tried running this on OnePlus 7TP, and it can't even transcode the videos recorded using the device itself. And of course, you can fry eggs after transcoding 4K videos. Transcoding must be done on WMF servers. --Eatcha (talk) 15:15, 9 November 2019 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Legal hell. (actually not so much "hell" as "it's going to cost millions of dollars in patent licensing") - Alexis Jazz ping plz 16:03, 9 November 2019 (UTC)[reply]

Discussion for Proposal 4

Devolving processing to the client side may make sense, or not. I would like to see some trials of what the outcomes or (dis-)benefits to the user experience are. Expecting users to wait for an hour for a 4 minute video to be pre-processed and hogging resources on their phone during that time, would not be a workable scenario. --Fæ (talk) 11:16, 8 November 2019 (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.

Wrap up the proposal

The Proposal 2 was far accepted by the community, the 1 and 2 ca not coexist, so we can start the implementation of 2 by now.

The Proposal 3 is too aggressive, and can not talk to actual mobiles, they also do not cannibalise the proposal 2, with some acceptance of the community, can we set a date to it start in the future?

Eatcha can we close this proposal? -- Rodrigo Tetsuo Argenton m 22:26, 19 March 2020 (UTC)[reply]

There's nothing I can do, the proposal is indeed accepted by the community but WMF legal's stance is important, no one's going to start working on it till then, but video 2commons decodes the copyrighted format on wmf server maybe a community maintained API will do but I prefer a solution from WMF devs. // Eatcha (talk) 05:05, 20 March 2020 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2019/11&oldid=428194473"