Commons:Village pump/Proposals/Archive/2018/02

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

Proposal to increase the minimum requirements of activity for the administrators

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
After analysis of the votes the proposal is not adopted Christian Ferrer (talk) 18:18, 26 February 2018 (UTC)

Hello,

I propose that we increase the minimum requirements of activity for the administrators. I think that 25 or 50 are reasonable, but for the principle I will propose a set going from the actual requirement 5 to 10, 25, 50 and 100. Other projects like Wikipedia , Meta , ect… have similarly similar minimum requirements of activity, maybe even less demanding. However, although I am not aware of the work those administrators have to do in their project, Wikimedia Commons is a project that requires a very large number of logged actions, in the very great majority of cases to delete unwanted content (copyright or scope issues). I think that such a low threshold is not suitable to motivate administrators enough to be active in a project like ours where there is so much work. I show you below a quick analysis of the activity of his last 6 months trying to tell you what we have to gain and what little we have to lose by practising an increase in the threshold.

“An "inactive admin" is one who has made fewer than 5 admin actions on Commons in the past 6 months”
  • The Admin Stats for the last 6 month, between 2017-07-05 and 2018-01-05. I used these numbers to make the calculations below.
https://xtools.wmflabs.org/adminstats/commons.wikimedia/2017-07-05/2018-01-05

Note that I didn’t count the BOTs, this explains that the total does not reach 100%. And also note that I made these calculations manually so if I have one, two or three errors, it will not change the overall meaning of the numbers. (total administrators=234, total logged actions made by administrators=335927). And if someone is able to do automatic calculations in tables, so be welcome to correct the numbers exactly. Otherwise see the numbers above as a trend very close to reality:

97 administrators (41.45%) made more than 100 logged action
For a total of 332430 logged actions (98.95%)
22 administrators (9.4%) made between 50 and 100 logged actions
For a total of 1608 logged actions (0.47%)
118 administrators (50.42%) made more than 50 logged actions
For a total of 333971 logged actions (99.41%)
112 administrators (47.86%) made less than 50 logged actions
For a total of 1889 logged actions (056%)
30 administrators (12.82%) made between 25 and 50 logged actions
For a total of 1075 logged actions (0.32%)
149 administrators (63.67%) made more than 25 logged actions
For a total of 335113 logged actions (99.75%)
82 administrators (35%) made less than 25 logged actions
For a total of 814 logged actions (0.24%)
36 administrators (15.38%) made between 10 and 25 logged actions
For a total of 623 logged actions (0.18%)
46 administrators (19.65%) made less than 10 logged actions
For a total of 191 logged actions (0.05%)
26 administrators (11.11%) made between 5 and 10 logged actions
For a total of 161 logged actions (0.04%)
20 administrators (8.54%) made between 0 and 5 logged actions
For a total of 30 logged actions (0.008%)

82 administrators with less than 25 logged actions

You have 82 administrators with less than 25 logged actions for a total of 814 logged actions made by those administrators.
Let's see the next calculation, if we increase the minimum requirements of activity it is inevitable that we will lose some administrators, but it is also logical to think that some administrators will make the necessary effort.

Let's take the numbers just above : 82 administarors. If we lose those 82 administrators then we lose their 814 logged actions (0.24%)

But….

…to reach 814 logged actions with a minimum requirements of 25 actions you need only 33 administrators. Therefore on those 82 administrators if only more than 33 make the effort then we will be winners. And despite the fact that the number of administrators will decrease visibly the number of logged actions will increase, and mechanically the average shares made by the administrators will increase, and the differences between the most active and the least active will also decrease mechanically. This last point is a recurring concern in our community and many users have already said that they prefers administrators who are not too overactive. And although the impact will only be relative on the most active administrators, the percentage of total actions per administrators will go in the direction of a balancing, as low as it is.


Let's take again the calculations above :

82×25 = 2050
72×25 = 1800
62×25 = 1550
52×25 = 1300
42×25 = 1050
33×25 = 825 we will need only 33 admin make the effort to reach more than 814 logged actions
32×25 = 800

50 admin actions

Let's do the same kind of reasoning with other thresholds, example a minimum requirement of 50 admin actions:
112 administrators (47.86%) made less than 50 logged actions for a total of 1889 logged actions (056%)

1889/50=37.78

To reach 1889 logged actions we need that on those 112 administrators only 38 of them make the effort of 50 admin actions.

Summary

For those who have already tried to spend some time working in the Admin backlog (Copyright violations, regular deletions, or hunt down copyvios in pages such as User:OgreBot/Uploads by new users) they know it's only a matter of a few hours of work to reach the level of 25 or 50 logged actions. And we are talking about 6 months, in other words we are talking about a few hours of work for 6 months. Is it an exceptional sacrifice? really?

But let's hear, this is not a punishment for the non-active administrators, it's more to motivate them to be a little more active. And honestly, activity leading to more activity, I am sure that many of the administrators concerned will do more than these new requirements, even if we have to lose a little more administrators for inactivity than usual. And given the demonstration I made above we will not lose much.

  • We have to win:
a necessarily more balanced average of logged actions by administrator
an increase of the number of logged actions
greater involvement of those who want to keep the tools
  • We can lose:
administrators with low activity, in summary nothing essential... (furthermore they can go back with new Rfa)

Furthermore, the community might be more inclined to accept new candidatures if the current number of administrators were to fall. Thanks to the security of an increase the minimum requirements of activity the community will not be afraid to promote potentially inactive administrators, as we already have a collection. A kind of beneficial renewal.

Regards, Christian Ferrer (talk) 13:47, 5 January 2018 (UTC)

Votes

As it's something important i think it should stay open 2 or 3 months.

Keep the current 5 admin actions on Commons in the past 6 months

Extended content
  • Be clear, would you consider active an editor doing 5 edits on wikipedia in 6 months ? But he is holding a seat. We need to free seats so we get a wave of new faces. Yug (talk) 17:02, 6 January 2018 (UTC)

Results : 45 voters / 21 opposes / 24 supports = 46.66%  Oppose 53.33%  Support

Increase to 10 admin actions on Commons in the past 6 months

Extended content

Results : 40 voters / 33 opposes / 7 supports = 82.5%  Oppose 17.5%  Support

Increase to 25 admin actions on Commons in the past 6 months

Extended content

Results : 42 voters / 25 opposes / 16 supports / 1 neutral = 59.52%  Oppose 38.09%  Support 2.38%  Neutral

Increase to 50 admin actions on Commons in the past 6 months

Extended content

Results : 44 voters / 27 opposes / 17 supports = 61.36%  Oppose 38.63%  Support

Increase to 100 admin actions on Commons in the past 6 months

Extended content
If I recall correctly, simple wikipedia requires 100 actions total. Edits, and admin actions. Perhaps it would be prudent to have a mix of edits and admin actions totaling an amount, perhaps up to 100. Artix Kreiger (talk) 14:11, 5 January 2018 (UTC)
My proposal is for the logged actions, not for the total actions. We need active administrators in the Admin backlogs Christian Ferrer (talk) 14:26, 5 January 2018 (UTC)
That's for the entire year, not 6 months. --Rschen7754 03:04, 6 January 2018 (UTC)
  •  Support I really don't see it as a major issue, could easily be done in one day --Herby talk thyme 15:02, 5 January 2018 (UTC)
  •  Support - my preferred option. Green Giant (talk) 15:12, 5 January 2018 (UTC)
  •  Support Over six months, 100 logged actions is trivial. At the same time the community should make it a respectable and normal thing to run "no fault" reconfirmation RFAs rather than (as appears to be the case right now) thinking these would be a punishment. If someone is ill, busy, needs a long wikibreak or similar for several months, they should feel comfortable laying aside the tools and reconfirming when they feel ready again. Regular reconfirmations would give the chance for at least a basic level of accountability for past questionable actions. --Fæ (talk) 15:13, 5 January 2018 (UTC)
  •  Support --Steinsplitter (talk) 17:06, 5 January 2018 (UTC)
  •  Support Although I think 200 would be better. About 1 action per day IMO is not a high requirement. --jdx Re: 17:35, 5 January 2018 (UTC)
  •  Neutral  Oppose 100 actions threshold would de-admin 138 of the current ~235 admins. (#97 to #234, see here). Long tail also has advantages while cutting it just free up 25 seats compare to the 50 threshold. These 25 admins in range 50-100, while quantitatively lowly productive are in activity the average 2017 admin, they have various mother tongues, expertises and are leaders in various categories. Every skilled admin should be allowed to have have 6 months off between 50 and 100 actions. Let's not make it a race to numbers. Yug (talk) 19:07, 5 January 2018 (UTC)
  •  Support Natuur12 (talk) 19:46, 5 January 2018 (UTC)
  •  Support --Thibaut120094 (talk) 21:49, 5 January 2018 (UTC)
  •  Support - Tbh I think 100-200 would be better however at present this is a step in the right direction and this option is much better than the present one. –Davey2010Talk 22:18, 5 January 2018 (UTC)
  • 5 logged actions a day - times that by 4 (4 weeks in a month) comes to 20, then times that by 6 (6 months) comes to 120 ...... so when you break it all down you would only need to essentially delete 5 images a day (or 20 or so in a month) to remain as an active admin ..... that really isn't a lot to ask at all ..... –Davey2010Talk 13:47, 25 January 2018 (UTC)

Results : 45 voters / 31 opposes / 13 supports / 1 neutral = 68.88%  Oppose 28.88%  Support 2.22%  Neutral

Discussion

Please for a good understanding of all, discuss here and not in the sections above, do not create another additional section either.

A procedural remark. Instead of making this bulky switch–case construct above, shouldn’t we just record minimal numbers of actions per month proposed by each community member? The median value can be computed afterwards, with slight modifications for supporting (between 10 and 15)-like opinions. Incnis Mrsi (talk) 14:30, 5 January 2018 (UTC)

The idea is not bad, I did not think about it, sorry. But there is already a fairly complete choice, do you want more than what I already proposed? It's ridiculous to choose 12 or 23 or 55, do you want more than 100? 100 is already a very, very big change compared to the current status quo. But well, feel free to make a section "mark here your ideal number if it is not listed here" or any other additional choice you want, example 200. Add it to the list above, make as you want there is no problem. Christian Ferrer (talk) 15:34, 5 January 2018 (UTC)
The 100 is a good idea. However, it runs the risk of less admins overall since people have their own lives to deal with and sometimes, people will fall short within the 6 months. They would lose it and then but without admin tools. Thats the risk. Artix Kreiger (talk) 16:15, 5 January 2018 (UTC)

I am not against increasing the minimum requirements (and by any reasonable standard my bit is not going to be affected), just wanted to notice that our most problematic administrators are not inactive, quite the opposite.--Ymblanter (talk) 16:19, 5 January 2018 (UTC)

  • I  Oppose the raising of the minimum edit requirement. That limit is to make sure admins are still active in the project and we do not have accounts with special rights for users that moved on to other things, which can be broken into by some evil-doers. We do have admins that specialize in some narrow corner of Commons and took on responsibility of running or maintaining it, those tasks are best handled by people familiar with the process that have rights needed to do the job. I do not want to loose that expertise. Years ago someone at OTRS implemented strict edit limits and we have lost many OTRS volunteers, who were only occasional contributors, alienation many of them. Each time someone ask for more people to come and help with OTRS process we hear about how unfriendly OTRS is and how many people would have loved to pitch in, but they can't as they lost their access. We also have admins who are also active at other projects and only occasionally need admin tools for tasks they do on Commons. De-adminship should be reserved for admins which are no longer trusted by the community, not for users who are active doing tasks that only occasionally need admin tools. I would be fine with tracking number of edits on Wikimedia projects and removing rights from admins who no longer actively participate. 100 edits would be a good threshold. --Jarekt (talk) 16:50, 5 January 2018 (UTC)
    The trouble with this is that year after year after year, there are a small handful of "admins" who effectively phone it in and deliberately do the absolute minimum to stay an admin. Some of those admins have openly criticised Commons over a period of years, and apparently have no interest in doing anything positive for this project. Seriously, I don't buy the "I'm active on OTRS and it's useful to drop in on Commons rather than asking an active admin or discussing a case on IRC", let's just call it what it is, hat collecting. Considering how a couple of well known OTRS volunteers are now globally banned, that's hardly an automatic reason why the Community should place our trust in someone who has been inactive here for a period of years and may have a serious chip on their shoulder for historic reasons. --Fæ (talk) 17:20, 5 January 2018 (UTC)
    • Question though -- if they are intentionally just doing the minimum, couldn't they just keep doing that (it would just take a little bit longer)? If they are gaming the system now, they will probably continue to do so, I would guess. Or do you think this change would cause them to not bother? Is making the change over a small handful of admins worth it to lose maybe a few handfuls of other admins who work in lower-volume corners of the project but help it nonetheless? Today's low-volume admin could become tomorrow's high-volume one. I would err, strongly, on the side of having more admins who are maybe not as always active -- would seem healthier that way. The above discussions seem to group all "admin actions" together, but I would presume there are high-volume activities, but also lots of smaller-volume tracking categories and that sort of thing which maybe they specialize in. Is there any way to quantify that? Carl Lindberg (talk) 18:14, 5 January 2018 (UTC)
      Some will find it a drag and not bother. We are talking about moving the goalposts from laughably meaningless to expecting those with sysop tools to put in a minimum of a day per year to demonstrate they are genuinely interested in sticking around.
      As for "lower volume corners", nope, that's a fudge that does not withstand real scrutiny. Carl, no doubt you have been pretty shocked over the years about some of the things our "low volume" sysop hat wearers do not understand about how Commons works. Let's ensure that those holding the Community's trust are properly knowledgeable and interested in improving their skills rather than keeping a hat on top of the wardrobe to wear on Halloween. --Fæ (talk) 18:38, 5 January 2018 (UTC)
      Those who have exceptional skill and who make 5, 10 or even 50 outstanding actions that no one else could do are certainly very very rare, and firstly they can continue editing without the tools and second they can make edit requests. Furthermore for such administrators not enough active but essential to the project, they can make new Rfa, and the community could decide to renew the tools, or not, for these particular administrators. Christian Ferrer (talk) 18:53, 5 January 2018 (UTC)
    (edit conflict) I would like to distinguish the cases of hi-volume-contributor-low-volume-admin from just plain low-volume-contributor. I do not want to alienate the first group, the way OTRS admins managed to do while ago. I also agree with Carl that not all the admin tasks are created equal. Maintenance of javascript gadgets come to mind, as I am fine with 5-edits-per-half-a-year admin who just does that, because I do not how to do it and would prefer not to handle protected edit requests related to them. If we no longer trust some admin to use the tools wisely or if someone no longer contributes to Wikimedia projects, I am all for removing access to the tools. However if someone is active but goes through periods of doing tasks that requires admin tools followed by periods doing tasks that do not, than I do not see the need to alienate them, by some automatic rights removal process. --Jarekt (talk) 19:24, 5 January 2018 (UTC)
    Jarekt I also thought about this kind of things, and I agree that maintenance of javascript can hardly be done with edit requests. But firstly I have no doubt that you will be very easily reelected by new Rfa, if needed, second I'm sure that you can make easily 100 logged actions every 6 month. And it is already the case for you. Christian Ferrer (talk) 19:46, 5 January 2018 (UTC) + FWIW you should support a reasonable proposal, rather than letting others decide too much, IMO Christian Ferrer (talk) 19:48, 5 January 2018 (UTC)
    Furthermore for such useful administrators, as you are, we can imagine anticipating a confirmation before the loss of the tools, if in an extreme case you are unable to do the required minimum. Christian Ferrer (talk) 20:17, 5 January 2018 (UTC)
    @Christian Ferrer: , @Jarekt: : Christian, you made your proposal thinking the community will support RfA for specific mandate, scope and expertise such Jarek's profile's requires. I wish but I'am really not confident that the community will switch to this openmindness. The Unsuccessful requests for adminship has recent examples of RfA for such « specific mandate, scope and expertise », and were voted down by top-30 administrators on the ground of edit counts, and clear request that the admin should do quantity and get involved into RfD, vandalism and other general purpose tasks. As the writer of this proposal, you have the opportunity to point out straight that raising up actions threshold must go together with reactivity to provide admin rights, meaning easier access to admin tools since the new threshold provide a quicker check and removal of this tools. I do think, and it was my case, than most experts on specific scope would appreciate to have access to the tools once every 2 years, or "when needed", and let it go when not needed. We are all volunteer, there is no reason to hold onto admniship if not active. But when a trusful user need the tool for real work s.he should get it. Yug (talk) 20:09, 5 January 2018 (UTC)
    Yug The more I gain in experience, which is all relative (2years old administrator), the more I think we are too demanding with the candidates and not enough with those already elected. I think we should give more chances to the candidates, and who knows, could they become more active than we would have thought? Christian Ferrer (talk) 20:24, 5 January 2018 (UTC)
    @Christian Ferrer: , after some digging on « specific mandate, scope and expertise » on unsuccessful RfA in 2017: 1) XRay withdraw, 2) Effeietsanders_(2) on Wiki Loves Monuments 60%, 3) Esby_(2) on protected and complex templates, 4) Krishna_Chaitanya_Velaga asking for temporary admin rights on WikiLovesMonuments India got absolutely 0 votes with voters explaining "we want admins for life", 5) Raboe001 active on OTRS and nominated with 68% was rejected via 11  Oppose purely on the basis of no activity on DR, CSD and others ; 5) mine on the 17,500-files and chinese calligraphy based ACC and SO projects started to be rejected on the basis of no RD/CSD and edit count and when I called upon 2 relevant contributors to vote canvassing accusation was fired, killing it. Several admins and leaders systematically vote down any RfA with specific mandate, requiring from the volunteer (repeat: volunteer) applicant that s.he must get involved on DR, CSD and others. This is likely to continue. And these candidates, seeing that there are tools to ease their volunteer work but those are denied to them, with blackmailing « if you get into DR/CSD with me then I support », are likely to be driven away with their specific expertise.
    We need a top level « FBI » slaying of DR, CSD and other for sure, the top-30 admin truly do an amazing job on this and need our support. Also, we do need « local polices », with on the ground expertises within categories and communities, and process to accept specific mandates admins. (This may be for an other day and other proposal tho) Yug (talk) 20:55, 5 January 2018 (UTC)
    No, a FBI would be a bad idea. Those of us that have been around a long time know there are "FBI"-like unelected cabals elsewhere, they are non-accountable, have no independent governance procedures, and rapidly turn into power hoarding old-boy's clubs where to be on the inside you have to be a "friend" of an insider. Commons works in an open way, apart from discussions on IRC which itself is occasionally questioned and the necessary closed-door policy of Oversight.
    A general system of skill-badges might be useful for those that like badges, and may be worth discussing as a project, but the culture is more generally against them and you will find some of our most active contributors have very few userboxes on their user pages. Either you know what they do, or you don't, I guess. --Fæ (talk) 11:26, 6 January 2018 (UTC)
  • @Yug: Note that what you wrote is not really true because if there is indeed an increase of the requirement, then a significant number of administrators, not all, it's true, will make the necessary effort. So it's a little alarmist as analysis. I would have preferred that you do not put these numbers like this under the proposals. Christian Ferrer (talk) 19:19, 5 January 2018 (UTC)
  • Yes sure. ;) But it gives an order of magnitude. As for where I put the info I sincerely think it increase readability and informed votes. Yug (talk) 19:22, 5 January 2018 (UTC)
    @Yug: I prefer you to remove them, and you mark them here, in the discussion section, or sign your additions up there, please. Christian Ferrer (talk) 19:24, 5 January 2018 (UTC)
    @Christian Ferrer: : Possible and underway. Thanks for pinging me ! Yug (talk) 19:31, 5 January 2018 (UTC)
    ✓ Done. Yug (talk) 19:34, 5 January 2018 (UTC)
    Great, thanks you! Christian Ferrer (talk) 19:35, 5 January 2018 (UTC)
  • Strong oppose to significantly increasing the minimum. I am sure I am not alone in my pattern. I'm an admin and a very involved participant, but I rarely make "admin actions" as such. I make very good use of admin privileges to (for example) look at deleted images when there are queries about it; I also often use the Commons delinker, but the actions taken there don't end up qualifying as my actions because they are done by a bot. Also, I give warnings for bad conduct (for which I wouldn't technically need to be an admin, but it sure adds credibility), but more importantly I give a lot of coaching to people who don't quite "get" copyright issues (for which I don't at all specifically need to be an admin but, again, it is very useful to have that for credibility). I'm comfortably above the threshold of 5 admin actions in 6 months; I'm probably below the threshold of 100 admin actions in 6 months. I don't think there is any question that I am making positive contributions here and that my admin status is useful. If someone thinks I am not useful as an admin, I'd much rather they challenge my adminship directly than possibly take it away because perhaps I might only have, say, a dozen identifiable "admin actions" per month. - Jmabel ! talk 05:58, 6 January 2018 (UTC)
    Are actions in looking at deleted pages and files considered Admin actions? I think they should be.   — Jeff G. ツ please ping or talk to me 07:00, 6 January 2018 (UTC)
They require admin privileges, but AFAIK they’re not logged anywhere. I’m all in favour of requiring considerably more activity than “five actions every six months” would seem to imply, but I’m very leery of relying on this figure as the sole measure. Moreover a single logged deletion action, for example, might require as little time & thought as nuking a blatant attack page, or as much as assessing a 50,000-word, heated DR raising complicated policy questions. As with edit counts, the statistics are only loosely correlated with a user’s commitment, availability, &c. (and not at all with trustworthiness, but that’s another story).—Odysseus1479 (talk) 08:35, 6 January 2018 (UTC)
That's great. However all the evidence shows that administrators that are bumping against the inactivity minimum levels each year do not review "50,000 word DRs", they just do a handful of trivial admin actions to keep the hat. I have yet to find one example of someone holding sysop tools that has minimal admin actions that would damage the project if they took a tools "holiday" and had a reconfirmation RFA when they had a reason to be active again.
By the way, if we wanted each read access to deleted files to be logged, it could be. It is a use of sysop tools and it is audit-able, so could be a Phab task if it was going to be used. --Fæ (talk) 11:15, 6 January 2018 (UTC)
  • I just come from my daily "DRs closure", it took me exactly 12mn to delete 47 images. from 07:51, 6 January 2018 to 08:03, 6 January 2018. What a huge sacrifice?!? seriously? our administrators don't even want to try to spend an hour or two per 6 months? at least this illustrate well two different meanings of the word "volontaire", deliberate and determined. For who want to do theses 100 actions, it is very very easy to do, but of course one need to be a minimum determinated. And yes there is likely several ways to help, of course, but one or two hours of your time per 6 months is not exactly as if one ask you to change completely the way you contribute. Christian Ferrer (talk) 07:17, 6 January 2018 (UTC)
  •  Comment Some are deliberately determined to make small efforts, while some are deliberately determined to keep their freedom not to make the least effort, or at least not to do what they do not want to do. The eternal debate that inexorably leads to the exasperation of those who have chosen to make the necessary efforts. And the smaller the effort required, the greater the exasperation, because those who accept these efforts know very well that it is not so great a sacrifice, but just a question of principle. Christian Ferrer (talk) 08:16, 6 January 2018 (UTC)
  • Another comment. If the goal of the whole exercise is to have more administrators to handle the backlogs, then we are clearly looking in the wrong direction. The backlogs should not exist to start with. Looking closely at the bots uploading here everything with a free license is one thing - many things they upload is junk, an many licenses are fake and add to the backlogs. Introducing ACTRIAL so that only autoconfirmed users can upload files is another thing. Working on the interface so that uploading files would look more like uploading files and less like inquisition is yet another direction. Getting rid of the perception "Admin A works a lot on backlogs, and therefore they are allowed to make a lot of errors, not admit them, make personal attacks, and can get away with this" is yet another one. For a long time already, Commons became a place where AGF is just not practiced, and it is not a pleasure to work here. This is where we should be looking at.--Ymblanter (talk) 08:59, 6 January 2018 (UTC)
On "handle the backlogs", many of the so-called backlogs were created as a way of focusing attention on files that could benefit from review. Many of the backlogs are fundamentally questionable and potentially pointless categorization for the sake of it. For example the argument that closing DRs before 7-days helps the DR backlog, that's fundamental failure to apply simple logic, it actually wastes more administrator time than following policy. As a second example most of my projects with bucket categories have the main bucket category changed without discussion to a hidden category, then often most of the entire upload project is mass categorized by bot into an "uncategorized" category, often duplicating the function of review categories I added as part of the batch upload. This is wrong and pointless, it ends up corrupting any meaning of the automated uncategorized categories. I can't stop it happening, there are normally experienced administrators that believe they know better than I do how to manage uploads, so I wash my hands of those uploads and let them knock themselves out as they appear to not want or need my support or opinions as an uploader.
However, I do not accept that "backlogs" are evidence that we need administrators, that non-administrators could not be more encouraged to help out without running RFAs, or the assumption that the "backlogs" are an indicator of anything meaningful. A deeper analysis, should anyone get around to it, will often find smarter solutions. Thanks --Fæ (talk) 12:24, 6 January 2018 (UTC)
You actually seem to agree with me rather than to contradict me, but let me give one more example. We have thousands, possibly dozens of thousands files which can not be kept on Commons because of FoP reasons (I believe by far the bigger provider of these file is Ukraine, but I might be wrong on this one). Mostly people do not care about them, though sometimes some overzealous users mass-nominate these files for deletion, and, since these requests are typically uncontroversial, these files get deleted - and good administrators even add categories "Undelete in" of "FoP cases in the country X", and bad ones doe not add anything - but this is not even my point. My point is that these files should have not been on Commons to start with. Human uploaders should have at some point been asked a question like "Is this by any chance a building or a monument from a black-listed country which war recently built" or smth like this; bot uploaders should either sorth this out automatically or be stopped. This did not happen, and, again, nobody cares.--Ymblanter (talk) 12:40, 6 January 2018 (UTC)

 Comment IMO the vote is invalid because it will unlikely have a result that can be clearly evaluated. A valid vote should consist of a single yes/no question the criteria of which should be discussed beforehand), or anything that relies on a median. --Krd 11:43, 6 January 2018 (UTC)

I agree it is problematic, though it is easy to see there is a surge of opinion to significantly increase the current trivial criteria. @Christian Ferrer: would you consider an early close on procedural grounds, while summarizing the votes, then repitch a pre-discussed format? It may take a month before a sensible re-proposal should run, but as with this proposal, significant discussion was expected so adapting to it is no surprise. Thanks --Fæ (talk) 12:03, 6 January 2018 (UTC)
Yes but no, honestly the interest that people carry to express themselves is very revelatory on the fact that the subject is debatable and important to debate. I think that this should stay open several weeks, maybe 2 month. Don't you see success? it's been a long time since we've seen so many people (active and inactive) at the same time in the same place (lol), people have apparently a lot of thing to say about this topic. And and even if in the end the result can not be clearly evaluated (and who really knows what will be the result in 2 months?), at least we will have a trend, both on what kind of potential reform we should do, if any, or how to proceed more clearly. IMO leave that open, in the worst case people are expressing themselves, and at best we will have a consensus in one direction or another. Christian Ferrer (talk) 14:26, 6 January 2018 (UTC)

 Comment Ymblanter has some interesting approaches to reduce workload. Additionally: if you want to motivate people, use positive stimuli instead of “punishment“. Make needed admin actions visible and digestable. For me personally the pure “being a Commons admin“ is not important enough in my life as Wikipedian to dig deep into international copyright regulations (and Commons rules) with growing complexity to decide deletion issues even once a month. As in Wikipedia: if it's not fun or at least kind of positive extrinsic motivation (feeling as a valued member of a group), you won't force people to do anything in the long run. And as Commons might not be the “home community“ for most of the people, the “member of a group“ thing will not work as expected. --Elya (talk) 12:12, 6 January 2018 (UTC)

 Comment Honestly, it's not been easy as a Wikimedia Commons administrator to do it because other than uploading photos, or finding photos of mine taken from Flickr without being put in the proper category, it's rare I pay attention. I didn't know of the admin backlog till today, which I have bookmarked. I'm not going to vote one way or another, but now that I have free time due to being unemployed for almost 8 months and the fact that I never knew of such a thing. Hopefully there should be a spike in my admin actions. Mitch32(Never support those who think in the box) 17:21, 6 January 2018 (UTC)

You became an admin in 2009, that's eight years ago, and average about 1,000 edits in total each year. If admins were required to run reconfirmation RFAs every 3 or 5 years, do you think you would have investigated the Commons project more actively in those eight years, and kept more up to date on evolving policies and guidelines?
BTW, during your RFA you were asked to add Babel boxes to your user page, which you did. You then removed these in 2013 without explanation. Could you add them back please? Thanks --Fæ (talk) 18:17, 6 January 2018 (UTC)
I removed those when I redid my userpages for uniformity. My apologies. Those have been readded. As for the rest. If there were reconfirmation RFAs, I probably would've declined. Heck, we just passed the 10th anniversary of my English Wiki RFA passing on January 2, I've deleted 331 pages and blocked 71 users. However, the only main reason I keep on is because of the U.S. Roads WikiProject, I'm one of the very few Commons admins we have. Mitch32(Never support those who think in the box) 19:10, 6 January 2018 (UTC)

 Comment The real solution is to recruit more admins and keep the ones we have from leaving. Increasing the minimum actions will have minimal effect. PumpkinSky talk 17:24, 6 January 2018 (UTC)

I agree on that. --Leyo 20:36, 6 January 2018 (UTC)

 Comment I don't understand, nor what the alleged problem is nore what the increase is suppose to solve. Right now, I have a low level of admin activity as I value more quality than quantity and only do action when I'm pretty certain of what I'm doing within my available time. If this policy is adopted, it seems that I have two choices: do quantity over quality or loose my admin right (increase the loads for the other admins, and worse case scenario: risking a cascading reaction of loosing all admins), it will more likely be the second... Cdlt, VIGNERON (talk) 17:35, 6 January 2018 (UTC)

@Fæ: As I remarked above, at least the high end of the proposal here (100 uses in 6 months) would almost certainly result in my losing my admin-ship. I greatly admire your work on Commons, and I think you are familiar with mine (which has included categorizing literally thousands of photos that you uploaded with minimal categorization). If you honestly think I "phone it in," "do the absolute minimum to stay an admin", and/or "have no interest in doing anything positive for this project", please say so directly, rather than by creating a rule that may sound innocuous on the surface but would have the same effect. I won't even contest the matter, I'll resign my adminship immediately. But if you don't think that, then please recognize that this is why I believe this is not a good proposal. In my view, this sets a mechanical criterion that may not accurately reflect people's contributions; just because use of certain tools is easily measured doesn't mean it's a good measure. - Jmabel ! talk 17:51, 6 January 2018 (UTC)

Re-read to consider what I was referring to, it was not a minimum of 100 admin actions in 6 months but the current criteria. Rather than your case being a parallel, the assertion is rhetorical which I would rather not spend time on, nor do I believe the measure of your actions over six months is accurate, you may want someone to run a report.
BTW, keep in mind I'm not an administrator, so my voice is not especially important here. Thanks --Fæ (talk) 18:05, 6 January 2018 (UTC)

 Comment IMO, the only effect of the minimum increase will be that users who use the rights occasionally, because of their general low-activity or activity mainly in other fields/projects will be forced to ask others (admins) for help and/or resign of this activity. I do not see any positive effect of that. The backlogs may be even a bit larger. As we have no real candidates for very active admin (maybe except INC/DL) I do not believe they will magically appear when number of admins is decreased. Also I do not believe that any minimum increase will cause volunteers to spend more time on Commons backlogs. I seriously doubt if the backlogs will be shorter if we have 100 low-activity admins less or longer if we have 1000 low-activity admins more. I also do not see any problem caused by low-activity admins. Ankry (talk) 18:28, 6 January 2018 (UTC)

That was my fear as well reading the idea of Mods closing DR's. The idea of inexperienced admins isn't solved in my opinion by a lot of users inexperienced in closing DR/CSD's getting access at the tools. License review has helped with some of those backlogs and I've tried to find a helpful niche to contribute in reducing backlogs there but I don't see it as the same thing. Granted we're not talking about Blocks or page protections I assume, but the backlogs are not going anywhere and should gradually be reduced nor do I see the current major pressing issue concerning them. I am not an admin myself, nor have I voted yet. These are only my opinions as of now, and my opinion could be swayed by a good argument. -- Sixflashphoto (talk) 20:18, 6 January 2018 (UTC)

 Comment Too obvious attempt of an inner circle to unite even more potential "power" on a few. If successful, it would be a coffin nail for this project. The regulation of the volunteers must finally become less instead of more. Because this project only works with and through the volunteers. Increasing the claims on and on is devastating. Marcus Cyron (talk) 10:42, 7 January 2018 (UTC)

  •  Question @Romaine: you wrote several times : "Keep it as it is, I have seen nothing good coming from higher requirements on other wikis", can I ask what are these "higher requirements", what are these "wikis", and what do you mean with "nothing good"? Christian Ferrer (talk) 22:24, 7 January 2018 (UTC)
    • For example 10 logged admin actions is a higher requirement than 5. I can imagine that it is reasonable to ask for five admin actions, to be clear that someone has to be active. It is however an illusion to think that a higher requirement creates more motivation or would solve anything. The only thing we get more is a higher workload for remaining admins and procedure crap that is counterproductive and demotivating. Claims on our admins, volunteers, never ever creates motivation. The goal of admins on a wiki is to do maintenance. Having less admins because of higher requirements does not improve the maintenance or the quality on a wiki. Romaine (talk) 23:25, 7 January 2018 (UTC)
Romaine, I still wait for what for your example of these "higher requirements" that you saw on "wikis" that pushed you to think "nothing good coming"? your sentence as it is written suggests to us that you have a specific example, what you are just describing, you answer is neither near nor far what looks like a specific example. "I have seen nothing good" suggest clearly you saw something wrong, what precise thing you have seen? Christian Ferrer (talk) 05:28, 8 January 2018 (UTC) and the use of the plural suggests that you have lived many times these bad experiences, will you never decide to share these specific experiences with us? Christian Ferrer (talk) 06:23, 8 January 2018 (UTC)
I think you misunderstood what I tried to say with higher requirements. Also I did not pointed to one specific example, but pointed to the many wikis where I have been active in various languages. Romaine (talk) 08:43, 8 January 2018 (UTC)
You misunderstood you too my question and you still did not answer. Precisely in what manner the increase of requirements in "the many wikis where you have been active in various languages" gave negative results? If you can not give just one example of an increase of requirements that you have experienced, therefore for me that means you never experienced that. Therefore your point of view is an opinion and in no way based on experience or facts, even less in many wikis. "I have seen nothing good coming from higher requirements on other wikis" : this is wrong, you never seen any similar experience and your sentence is a nonsense. But of course you have the right to express your opinion, and the right to vote in accordance with your opinion. Finally I think I have my answer, I let you go about your business. Christian Ferrer (talk) 12:10, 8 January 2018 (UTC)

We have about 60 million pages and 30k users to take care of [3]. We do this with a team of 233 admins. And you want to kick the members of the team that are not active enough within a period 6 months according to statistics that only take into account some of the important acitivities? Not a convincing idea that a smaller team is better from my point of view. Groetjes --Neozoon (talk) 18:48, 14 January 2018 (UTC)

@Neozoon: The goal, as it is written a dozen of time above, is more to try to motivate them than to lose them : 1 administrator with 100 actions is more efficient than 10 administrators with 5 actions = more work done. Regards, Christian Ferrer (talk) 20:03, 14 January 2018 (UTC)

Hello Christian, that is nice that you want to motivate us, but that is a nice way to pressure people to do what you guys think has to be done. I am an admin on the german Wikipedia, I am an member of the OTRS Supportteam and I am an admin on Commons. If it is time to write an article in the german, english or dutch wikipedia than that is what i want to do. If I answer a lot of support-tickets often about files and permissions, than that is ok and helpful. Getting the admin-rights is an question of trust not a job. You are trusted by the community that you know the rules and can handle the issues. This trust is not lost directly if you are more active in other areas for an period of several month. Example: When I work on Support-tickets and someone asks me about deleted files, I have to be able to see the deleted content to answer the tickets properly, even when these kind of activities do not show up in the statistics. Short: changing the activities of volunteers into a perpetual forced amount of specific workload does not motivate many of us admins Best regards --Neozoon (talk) 20:32, 14 January 2018 (UTC)

Moderators

What about the idea of moderators? They would be between admin and normal users. They would have access to a few buttons, such as delete, but not all the responsibilities. This would fit people who would not really want to be an admin. This is like wikia (Fandom's Content Moderators) where they are not full admins but have some responsibilities that could help admins reduce work load. Artix Kreiger (talk) 12:43, 6 January 2018 (UTC)

 Support Love it. Yug (talk) 17:03, 6 January 2018 (UTC)
 Comment - I think it would be a bad idea. We have some additional rights, like 'rollbacker', 'file mover' and 'image review'. I think several users with those rights do a good job using them. But for tools like the deletion button, I think an RfA is necessary. On the other hand, such an RfA should not be a big deal. A user who is experienced in helping out with the maintenance of our project and has a good standing in our community, should in principle be welcome to have the admin tools. I think we do need more active admins, to spread the task and to lower the workload of the most active ones. Jcb (talk) 22:10, 6 January 2018 (UTC)
JCB, you're literally the most active admin here on commons. by a long shot. Technical details aside, moderator would require an RFA, but for the delete function instead of the full access. Personally, I think commons admins have a lot to do with respect to all their userrights, but could use more people who would be interested in closing DRs. Artix Kreiger (talk) 22:23, 6 January 2018 (UTC)
The deletion button is the only admin tools of which the result is partly hidden for most of the community (non-admins can see the logs, but not the content of the deleted page or the deleted file). I don't see why a lower level of trust should be applied to specificly this tool. And I agree with the doubts of Josve05a below. To be honest I would not know a candidate for such a half-admin function. I would rather invite trusted and experienced users to become a normal admin. Jcb (talk) 22:45, 6 January 2018 (UTC)
 Oppose If you can delete you should be able to have access to all the other functions. Further divisions like this only lead to a host of issues. This proposal also doesn't actually explain what a "moderator" would entail. What permissions are they getting? What support is necessary? Without an actual full proposal this seems incredibly underthought. I can't really support anything unless I know exactly what I am supporting. --Majora (talk) 22:26, 6 January 2018 (UTC)
  •  Comment I'm not sure who/how many users would fall in between the category of being able to pass an RfA and become an admin vs a user who would pass a RfMod after having shown to know about copyright rues and laws, as well as our deletion policies. In most cases, if you were to do that, then you would be supported to become an admin. Not sure how many extra tools and gadgets admins get, but the delete function is the biggest part of it on Commons. --Jonatan Svensson Glad (talk) 22:27, 6 January 2018 (UTC)
 Comment, it was just an idea. If you look here, it gives the functions on what could a moderator do. It is just an idea though. Artix Kreiger (talk) 22:43, 6 January 2018 (UTC)
 Comment This is a non-starter since the WMF policy is to only give access to deleted material to users who have passed an RfA or an equivalent community-based process.--Ymblanter (talk) 23:08, 6 January 2018 (UTC)
I'm guessing there would be a "RfA-light" type thing. That idea has always been ok with the WMF. Although I don't see why someone would want to go through any type of RfA if they can just do the real thing. And I could be wrong since the exact specifications were never actually proposed. --Majora (talk) 23:20, 6 January 2018 (UTC)
  •  Comment Hmm, it’s an interesting idea (and @Artix Kreiger: you shouldn’t hesitate to suggest ideas), but I’m not sure we need it as much as we need other changes. We have a number of existing user groups such as image-reviewers, file-movers, patrollers and rollbackers, which have been gradually created as admin tools have been unbundled. There is a possible comparison with Wikiversity Curators, who are not admins (Custodians) but can protect or delete pages (although they can’t undelete them). They are effectively a rollbacker/file-mover/patroller/deleter/protecter in one group. That said I can see a plausible argument for potential unbundling of some rights such as a semi-protect to make it easier for trusted users to temporarily protect pages so only confirmed users can edit them (until an admin can get onto the case), which wouldn’t be for very long. Another useful one might be searcharchive, which enables viewing of deleted pages. This would be helpful for non-admin OTRS agents so they can respond to emails about deleted files without having to request undeletion each time and waiting for an admin. Obviously these rights require a level of trust and as pointed out above, they would only be allocated after a community discussion of each candidate (and before anyone raises it, not all OTRS agents would get that right, just the ones that can show that they really do need it). I think there is certainly a debate to be had about this. Please see Special:ListGroupRights for details of which rights are allocated to which groups. Green Giant (talk) 23:59, 6 January 2018 (UTC)
 Oppose Do not think we need a baby-admin usertype - little trusted but not enough to join the Admin ranks. Best regards --Neozoon (talk) 20:24, 19 January 2018 (UTC)
 Oppose – potentially detrimental. If to unbundle deletion from blocking, then, quite contrary, I’d grant blocking right (at least limited) to LX and, possibly, some other nationals of Sweden (see here for explanation how Sweden is relevant). We possibly need more work-hands to block sock puppets, but no [delete] for users not trusted enough to have block privilege, please. Incnis Mrsi (talk) 06:11, 15 February 2018 (UTC)

Call

To fight the admin backlog, I would like to call for:

  • new volunteers to candidate for adminship
  • the voters to lower their expectations about the experience (e.g. number of contributions in DRs) a bit

As the number of “admin seats” is not limited, this approach is more promising than the one proposed above IMHO. --Leyo 21:40, 7 January 2018 (UTC)

  •  Comment Good idea although there are more people who seem interested in saving their little freedom here (or just expressing their heroic spirit of resistance), rather than to come and vote to support the candidatures that have recently failed. Candidates who would have been more active than a lot of voters who support to stay without any increase of requirement, included many administrators. I assume it's also their freedom not to come to support or not to vote, or even not to show a single interest to the Rfas of the new volunteers. We are not going to ask them more, besides? again a new requirement? no, no forget. They have more important things to do. Christian Ferrer (talk) 22:32, 7 January 2018 (UTC)
You do seem to have quite some issues with not so active admins. Amada44  talk to me 12:58, 13 January 2018 (UTC)
And I strongly agree that the requirements about candidate's experiences (e.g. number of contributions in DRs) is much too high in comparison to what we ask to the administrators in place on both behavior and contributions. And if I made this proposal, it is precisely because I think this thing as much as you, if not more. If at least we could have as much as participation in the Rfas than here, if at least we could have as much as participation in administrator's daily life than here, if at least... Christian Ferrer (talk) 12:37, 8 January 2018 (UTC)
Leyo, I support your call - but I don't have any hope. I saw in the last two years so much good candidates who failed, that I can't ask possible candidates with a good feeling. The inner circle of commonsians is too tight to let others in. AGF is outdated. ABF is en vogue. Actually we have 229 Admins. I think we need at least 400, better 500. But I can't see them. The only question in a RfA should be: "is this candidate a user who would do bad things with this position - or not". If not, we should support the candidates. Deadmin would be easy enough, if there would do someone really bad things. On the other hand: at least, it's hard really to destroy something. Having more admins would be better than increase the number of obligational admin actions what would lead to a great loss of admins in a near future. Wikimedia projects should become simplier to support in the future, than harder. Marcus Cyron (talk) 14:11, 8 January 2018 (UTC)
In Rfa there are people who are almost systematically vote oppose, and there are also those who shine by their absence. And it can be as well a trial or a candidacy. We are not likely to encourage the candidatures. Maybe that the only requirement for the administrators should be to come voting when there is a new Rfa. Oups I forgot "requirement" is a bad word :) Maybe invitation-to-vote messages should be sent to all administrators when there is a new RFa. Christian Ferrer (talk) 16:58, 8 January 2018 (UTC)

Results

  • Keep the current 5 admin actions : 46.66%  Oppose / 53.33%  Support
  • Increase to 10 admin actions : 82.5%  Oppose / 17.5%  Support
  • Increase to 25 admin actions : 59.52%  Oppose / 38.09%  Support / 2.38%  Neutral
  • Increase to 50 admin actions : 61.36%  Oppose / 38.63%  Support
  • Increase to 100 admin actions : 68.88%  Oppose / 28.88%  Support / 2.22%  Neutral

Conclusion

Although several experimented users have expressed reservations about this type of voting, this formula did not prevent the voters to express their opinions. And it is clear and undeniable that the majority wishes to keep the current minimum requirements of activity for the administrators. We can also welcome a relatively important participation which makes the result even more legitimate and should close this question at least for a while.

A different formula could have been. " Do you want to increase the minimum requirements ? yes or no, and in case of yes then chose a number" . But in my opinion this formula would have led to the same consensus to keep the current system. Then no regrets. Christian Ferrer (talk) 18:11, 26 February 2018 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
This section was archived on a request by: Zhuyifei1999 (talk) 00:56, 11 March 2018 (UTC)

Modern Art by David Adam Kess

Visual arts education is the area of learning that is based upon only the kind of art that one can see, visual arts—drawing, painting, sculpture, and design in jewelry, pottery, weaving, fabrics, etc. and design applied to more practical fields such as commercial graphics and home furnishings..

looking for support to keep my educacional art in wikimedia....thanks and gracais

Commons:Deletion requests/Files in Category:Modern Art by David Adam Kess

have a great day to the community of wikimedia....

footnote..https://en.wikipedia.org/wiki/Arts_in_education

— Preceding unsigned comment added by David Adam Kess (talk • contribs)

@David Adam Kess:
This is the wrong place. Please answer in the deletion request. Regards, Yann (talk) 12:46, 14 February 2018 (UTC)
You should be able to demonstrate the educational value of your art and make a case why they're within scope on the deletion request page, the fact that this is here is wholly my fault, I informed this user in a wrong manner. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:30, 14 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:55, 11 March 2018 (UTC)

Flooder permission

Would people be open to the idea of flooder right? It would be hiding a person from recent changes because they do repetitive tasks. For example, people do a ton of stuff through visual file change and it would flood it, temporarily. It would be helpful for people who patrol special:RecentChanges but don't want to see repetition. For technical issues, it would mean admins can grant it to themselves, and bureaucrats grant to others, in a similar vein to translation administrator right. Thoughts?


Artix Kreiger (talk) 20:28, 14 February 2018 (UTC)

This is what the bot flag is for. --Fæ (talk) 20:29, 14 February 2018 (UTC)
@Fæ: I tried to get that for User:JeffGBot, but was denied. :(   — Jeff G. ツ please ping or talk to me 06:43, 15 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:54, 11 March 2018 (UTC)

Upload issue: Summary header gets inserted twice

I mean =={{int:filedesc}}==. For example visible at File:Mursi Warrior.jpg. --Palosirkka (talk) 20:14, 24 February 2018 (UTC)

This is a bug: phab:T187302. --Steinsplitter (talk) 21:05, 24 February 2018 (UTC)
Thanks for the link. The bug is quite annoying. The line appears twice if it is at the start of what is submitted. I use the standard upload form with c/paste (not the wizard) and quite often derivativeFx and the duplication of the summary heading is so consistent that I've now started removing it from the form before I hit upload, thus leaving just the one that gets generated (when I remember). If it does get duplicated and I forget, a bot does usually come along and fix it later, though. -- Begoon 21:20, 24 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:53, 11 March 2018 (UTC)

What can we do to help User:Onan peyon & User:Onanpeyon140499

A quick goolge shows he is a photographer but because all his uploads are claimed to be 'own work' we can not tell which ones he took. He seems to be able to upload image here, just as easily as he can to his Instagram and Sinar Hoickon Photo Star accounts etc. However, we find it more time consuming to just keep deleting them. This is a futile waste of both his and our time. I and User:Alexis Jazz are thinking that some of our suggestion here on Commons:Upload Wizard proposals would help prevent the flood of these and similar copyvios. --P.g.champion (talk) 18:13, 25 February 2018 (UTC)

This seems barely like a proposal and a bit more like a question.
Those Upload Wizard proposals are not likely to help in this case. This is an issue similar to File:Stars selfie.jpg. If photographers don't want to or are unable to insert CC-licensing on their website or social media accounts and they have no (public) business email address, they are essentially not welcome here. Even if they somehow did get to OTRS, OTRS has a backlog of 37 days (according to COM:OTRS) which is exactly 30 days more than it will take to delete an image with {{No permission since}}. - Alexis Jazz 18:51, 25 February 2018 (UTC)
Yeah, but we can undelete it after. If they email OTRS to document that they are the same person as such-and-such account elsewhere, the OTRS people can do a reusable verification of identity: they don't need to do this for each individual photo. - Jmabel ! talk 20:10, 25 February 2018 (UTC)
If a photographer has some social media account they don't want to (or can't) add CC information to and a free email address that isn't publicly listed on the social media account* there is (as far as I can tell) nothing OTRS can do. No upload wizard can fix that.
*and they shouldn't, I'm still waiting for the money of my Nigerian royal uncle to clear so I can make some payments for my basement full of viagra
- Alexis Jazz 21:50, 25 February 2018 (UTC)
Just asking up-loaders on the Wizard if 'they' took the photograph or crafted the diagram by ticking a box would help, as in these two case, I've just found: User talk:Gregorybarry. Can't link to the images themselves because User:Túrelio was quick off the mark and had them deleted within 'minutes' of me finding them. I am find loads of files like these – every time I review. Remember too, I am only quickly skimming through. There must be many more that I miss. So, what are we talking about. I would say copyvios occur in over 1:150 up-loads. Surly this justifies some improvements to Wizard? --P.g.champion (talk) 22:28, 25 February 2018 (UTC)
It does, but if Onan Peyon registers with Commons that won't help. - Alexis Jazz 22:36, 25 February 2018 (UTC)
So, let us take one step at a time. Nothing will ever be fool-proof. Surgical nurses count every instrument and swab out and every one back in but some patients still find they go home with more than they expected. Even the USAF loose a thermonuclear bomb from time to time. This is no reason to ignore the need to improve WC protocols.--P.g.champion (talk) 23:10, 25 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:53, 11 March 2018 (UTC)

God has joined Commons!

"This file and any 3D objects depicted in the file are both my own work."

As you can see on the description page of the picture, it's true. The other image the user has uploaded was a copy of File:Img-20170123-wa0001.jpg (top image on https://swamidwarkadheeshashram.blogspot.com) so there would seem to be no question we are dealing with God here.

The actual proposal is to reconsider the wording of that template. Perhaps change "3D objects" to "virtual 3D objects". And maybe consider not even allowing it for photos, or at least not offer it as an option for photos by default. In a rare case where this template would actually apply to a photo, edit it in after the upload. - Alexis Jazz 22:03, 25 February 2018 (UTC)

Also looks like the chip-set in his phone is claiming copyright – that could be confusing. Is it possible for owners to reset it? --P.g.champion (talk) 22:39, 25 February 2018 (UTC)
@P.g.champion: You are brilliant. Jeff tried to speedy it. I wonder how many images we have lost over the years to this bullshit. - Alexis Jazz 11:00, 26 February 2018 (UTC)
Just remove the template, and add a friendly message to the uploader. Regards, Yann (talk) 06:31, 26 February 2018 (UTC)
@Yann: Have fun cleaning up pages and informing a couple of users each day:
I prefer just getting this fixed. - Alexis Jazz 09:01, 26 February 2018 (UTC)
Alexis Jazz: Most of these are either out of scope, missing permission, or both. One is already deleted. The rest is already fixed. Please don't make a mountain out of a molehill. Regards, Yann (talk) 09:35, 26 February 2018 (UTC)
@Yann: I don't. Some fairly simple changes can be made to stop all of these errors. It will take the developers a few hours at most but more likely about 10 minutes. You prefer to just notify hundreds of users for years and fixing pages until after many years somebody finally realizes: why didn't we just fix this when we found out it was broken? - Alexis Jazz 10:16, 26 February 2018 (UTC)
@Alexis Jazz: , I've filed a task to have the engineers take a look. To keep our relationship healthy, I'd like to kindly ask you to please don't estimate time on the behalf of engineers. It sets unrealistic expectations. (humor) CKoerner (WMF) (talk) 15:48, 26 February 2018 (UTC)
@CKoerner (WMF): Thanks! I actually do have some idea of how long it takes to implement certain features - assuming the code isn't a complete mess - but admittedly I exaggerated the amount here. The point was simple though: if we clean pages, warn three users each day and assume we spend a little over 3 minutes per user we will spend 10 minutes each day or 60 hours a year or 300 hours in 5 years. More than 12 days, 24/7. I think it would be safe to assume that what I propose can be done in less time than that, making it worth it. ;-) What I proposed really can be done in 10 minutes, I know it - but Bobby Tables may end up running amok when you work that quickly. So, it's better to take more time indeed. - Alexis Jazz 16:28, 26 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:52, 11 March 2018 (UTC)

Proposal for alt tags

Alt tags are not used often on enwiki. To increase use, I propose we add an alt field to Template:Information. Then, when you click the Use this file button, the alt tag would be included. While captions can vary based on what you are using the image for, the alt tag will be the same no matter what you are using it for, since you are describing the image. I think this will increase the use of the alt tag. Thoughts? Kees08 (talk) 01:48, 19 February 2018 (UTC)

Proposal to explain the official view of Commons regarding photos on coffins in the de minimis policy

It's quite common for a photo to be placed on a coffin, but it's not clear to me if Commons considers that photo in a photo of a coffin-with-photo to be DM or not. In more clear words: I mean the case where somebody makes a free photo of a coffin, but there is a photo placed on top or near of the coffin which can be seen as well and which is nonfree. I would find it useful if the de minimis policy would deal with this. - Alexis Jazz 00:12, 23 February 2018 (UTC)

Hi,
I don't think we should add that in the policy. It depends very much on the original picture, and how the photo of the coffin is taken. We should just use common sense (and if you are the photographer, do not focus on the original). Regards, Yann (talk) 04:14, 23 February 2018 (UTC)
I agree with Yann. Generally such photos are de minimis, but the uploader can also decide to blur it or mask it in a similar way. --Ruthven (msg) 10:16, 23 February 2018 (UTC)
Alright. But perhaps a note in some form could be added. I personally feel it is generally disrespectful to remove/blur the photo from such images. In a similar image that shows a photo in the image with similar size and focus but where the subject is a book signing instead of a funeral, I don't have many issues with removing or blurring the photo. It is quite common for photos to be placed on or near a coffin and photos taken of coffins are typically in scope. I think we should be slightly more lenient in allowing them as DM. I'd be OK with making the {{De minimis}} template a requirement for that. My point is that if we are just as strict on these coffin photos as we are on (for example) photos of book signings, it could be hard for Commons to continue hosting funeral photos. I believe we already are more lenient on this subject and I would like to see some sort of note on this in the policy. I agree no universal ruling could be developed, I'm not asking for that. - Alexis Jazz 11:00, 23 February 2018 (UTC)
I agree that picture is less likely to be within the scope of DM. I added DM to it anyway because it's not the main focus of the image (to me) and to inform anyone who wants to reuse it. If somebody nominates that file for deletion I won't strongly defend it: it is not used and we have similar photos of the same funeral that focus less on the coffin photo. So from an educational point of view, we don't really need it in this case. - Alexis Jazz 11:00, 23 February 2018 (UTC)

Merge the function of two templates

Can we import the unique functions of {{PeopleByName}} into {{Wikidata person}}, they duplicate a lot and it would be best to just have one template to add to a new biographical category. Wikidata person can become {{wikidata person|Q2092869|McGillivray|Perry}} By adding the sortkey function of PeopleByName to wikidata_person. We can skip the adding of "M" and "F" and import the gender from Wikidata. PeopleByName adds a sortkey on the fly "McGillivray|Perry|M" and one or two categories currently missing from wikidata_person. They both generate categories based on Wikidata information on the fly, as opposed to typing them in, so that when Wikidata is corrected the categories are automatically updated, the categories aren't really there when you hit the edit button. Wikidata_person was recently updated with functions from other templates and was originally based on template:Creator. The template wikidata_person and the information at Wikidata have recently improved image search on Google by including more biographical data in the categories, especially for people with commons names. Google Image distinguishes better John Smith, the baker from John Smith, the barber. RAN (talk) 19:09, 23 February 2018 (UTC)

@Richard Arthur Norton (1958- ): Or there's {{Wikidata Infobox}}. ;-) I've now added support for all of {{PeopleByName}} using info entirely from Wikidata, see [4] for an example of it in action. So if the category has a sitelink on Wikidata, and the relevant info is in the Wikidata entry (sex or gender (P21), given name (P735), family name (P734) at least, date of birth (P569) and date of death (P570) for the full set), it should just do everything by adding {{Wikidata Infobox}}. If there are any problems, please let me know and I'll look into them. Thanks. Mike Peel (talk) 22:45, 23 February 2018 (UTC)
@Richard Arthur Norton (1958- ): P.S. if the category isn't linked to the Wikidata entry, then you need to make an edit like [5] to link it. Category:Willard Dickerman Straight should work now. ;-) Thanks. Mike Peel (talk) 23:08, 23 February 2018 (UTC)
Excellent work. {{Wikidata Infobox}} is more vertical and {{Wikidata person}} is more horizontal, each good in their own way. Are you going to update {{Wikidata person}} also with your category and sort key changes? {{Wikidata Infobox}} now performs all the functions you would need when you create a new category. Now when Wikidata is updated, the categories will be adjusted, we have over 10,000 records where we have only the year of birth for a person, and roughly half of them are off by a year. They are generally calculated from the person's age in an obituary, when the exact birth is unknown. RAN (talk) 23:22, 23 February 2018 (UTC)
Thanks. :-) I'm not planning on editing {{Wikidata person}}, but you can see the code I wrote to do the {{PeopleByName}} include at [6], maybe @Jarekt: would like to incorporate it in {{Wikidata person}}. Personally, I'd like to merge that template into {{Wikidata Infobox}} at some point, as I think the latter is formatted better and it also works with categories that aren't about people, but we need to discuss that. With regards vertical and horizontal, personally I don't care, but I think we should standardise on one of the two and use that uniformly in categories. Thanks. Mike Peel (talk) 23:34, 23 February 2018 (UTC)
RAN, {{PeopleByName}} and {{Wikidata person}} are quite different. {{PeopleByName}} is meant to be substituted and {{Wikidata person}} does not. Also adding extra parameters to {{Wikidata person}} would make it much harder to use, as it's main feature is that it does not take any inputs other than item ID. I do not want to add surname and given name categories as they are added only if such categories exist. The code would have to be constantly checking that. I also do not like gender based categories, like Category:Men by name and would prefer not to use them. --Jarekt (talk) 05:36, 24 February 2018 (UTC)
Then why do we have {{PeopleByName}} and why do people add it to categories? We need to be consistent so when people look at a list everyone they are looking for is included. If we should not have gender specific categories, then we should get consensus to delete/retain them. If the surname category does not exist, it takes about 7 seconds to make it a subcategory of Category:Surnames and the red link is now blue. {{wikidata person|Q2092869|McGillivray|Perry}} is no needed, Mike Peel cleverly coded the sort key based solely on the Wikidata Q number in {{Wikidata Infobox}}, the vertical version of the category infobox. Men by name and Women by name, honestly no one actually uses it to search for a person, it is there more for web crawlers than actual human utility. RAN (talk) 05:49, 24 February 2018 (UTC)

Don't notify a user if their edit on a user talk page is undone by the owner of the talk page

This page in a nutshell: When an edit is undone on a user talk page it means "got it, archive to nowhere" or the offending user needs to be given a personal message/ban. The automatic notification is useless either way.

When an edit on a wiki is undone, it usually means you've done something wrong. Or someone else before you did and your edit was part of the rollback as well. It makes sense to notify the user so they can try to figure out what they did wrong, or see if they need to re-add an edit that was collateral in a rollback.

Some users have a habit of using the "undo" function as a way of a "got it, archive to nowhere" button. Which is perfectly fine except the user who made the edit or made the DR for a file that the user uploaded gets a useless notification that their edit was reverted. For new users who are not familiar with this practice this could also lead to confusion - have I done something wrong? Should I not have nominated that file for deletion?

Notification for an undo/rollback on a user talk page is always useless. If it's a user saying "got it, archive to nowhere" there is no need to notify. If a user has done something very wrong on a user page, a message should be left on the talk page of the offending user to explain what they did wrong. That is if it's not taken straight to the vandalism board. The undo notification is useless for either case.

An alternative is to create an extra "got it, archive to nowhere" button. I think that'll just add to the clutter so disabling the undo/rollback notification when an edit on a talk page is undone by the owner of the talk page makes more sense to me. But I would be happy with either way. - Alexis Jazz 04:56, 24 February 2018 (UTC)

I agree the notification for rollback/undo is disruptive for many wiki practices. I always disable it. It tends to encourage edit wars too, so I wouldn't oppose a feature request to disable it for all users on Commons. Would somebody miss it and why? --Nemo 14:41, 24 February 2018 (UTC)
I know of a good few editors who have disabled revert notifications for that very reason. They feel that the 'red-mist' these messages can inspire may make them more likely to edit-war or respond rashly, so they prefer to just rely on the watchlist because they feel that results in more sedate, considered responses. At least a couple of them, which I recall, have also said it's been "the best thing they ever did with notifications" or something similar. I can see their point, too, but I think it should remain a matter of personal choice for those like Jeff below, who prefer to receive them. I leave them switched on myself. -- Begoon 16:04, 24 February 2018 (UTC)
@Alexis Jazz and Nemo bis: Use of rollback against community translated templated user talk page messages on one's user talk page that are not clearly mistaken or self-generated (that is, constructive edits) is actually misuse per COM:RB (as such implies that the original messages were vandalism), and could result in loss of the rollback permission via COM:AN or the action of a single Administrator. I certainly want to be notified if someone else rolls back my such messages, but I don't care so much when someone undoes them, which action would just be antisocial and obfuscatory.   — Jeff G. ツ please ping or talk to me 15:10, 24 February 2018 (UTC)
Antisocial and obfuscatory to remove a templated message which one has read? Sometimes I can do nothing but shake my head at the things I read here. -- Begoon 15:56, 24 February 2018 (UTC)
I don't think that's what Jeff meant. If you edit the page and remove the message that way to perform the "archive to nowhere" I doubt anyone would have any problem with that. That will not send a notification and is also not tagged as "undo". And "undoing", at least from the outside, really seems like making something like it was never done. I know you don't mean it that way, but it can come across like that. Especially to users who are not familiar with how "undo" gets used here. - Alexis Jazz 17:13, 24 February 2018 (UTC)
Yeah, well that may be a fair point - I suppose I'd rather not trigger a notification in those circumstances and potentially upset or confuse someone. That covers "antisocial", in a way, and a couple of extra clicks is no issue. But hang on, now I'm being even more "obfuscatory" aren't I, by doing it quietly? My head is shaking less, but it's not completely still yet... -- Begoon 17:32, 24 February 2018 (UTC)
Ideally you would also enter "Got it, thanks" in the edit summary. Perhaps it's possible to create a script that saves a few clicks and keystrokes to do that. - Alexis Jazz 17:43, 24 February 2018 (UTC)
Ideally, yes, and I shall henceforth do it just like that. I do still have to say, though, that equally ideally folks would try not to throw around terms like "Antisocial and obfuscatory" and use some common sense - but we'll see how that goes... -- Begoon 17:52, 24 February 2018 (UTC)
Regarding Alexis' idea itself, it's maybe not altogether a bad idea, but I suspect that doing this solely for "own talk page reverts" might be difficult to "sell" as a concept in a feature request. It might be viewed (or "brushed off") as an overly complicated solution to a debatable problem. Nothing to stop someone asking, though... -- Begoon 16:14, 24 February 2018 (UTC)
If some people here would say "Yeah, makes sense" that would be a great support for a feature request. If everyone here is more like "meh", I don't see it happening. - Alexis Jazz 17:13, 24 February 2018 (UTC)

Change to text of Commons:File renaming policy

"Files with copyright issues should NOT be renamed until copyright issues are resolved. There is no reason to rename a file if it is going to be deleted on copyright grounds."

to

"Files that do not appear to comply with Commons policy should not be renamed and instead be nominated for deletion if they haven't been already, speedy where applicable. When a file was nominated for deletion but the file mover deems this nomination to be unlikely to result in actual deletion, the file can be moved." - Alexis Jazz 13:37, 28 February 2018 (UTC)

  •  Oppose Though renaming while a DR is open is considered poor practice, there are times when it is reasonable to do so, such as when the title may be defamatory. For this reason I would rather see the section changed to be weaker, it's stating a norm not a policy. The proposal wording does not specify which policy is the one not being complied with. It reads as if any file needing to be renamed would be deleted. --Fæ (talk) 13:52, 28 February 2018 (UTC)
"It reads as if any file needing to be renamed would be deleted." I don't see this. Can you elaborate?
I will clarify what triggered this proposal. It was File:Faith Hill on the Jumbotron (3972893368).jpg. I nominated it as it didn't even state which stadium this was so it seemed to be just a file for Faith Hill. After a comment in the DR I did some research, improved category/description and blurred Faith Hill. It is now a useful image, but it is no longer "Faith Hill on the Jumbotron". The renaming request was however denied because there was a open DR.
This means I would have to wait for the DR to be closed before I can have this file renamed. That could have taken weeks or even months and I could easily forget all this in that time. In this case as I've just learned I can close uncontroversial DRs myself I have done that. But it would be very reasonable to just rename the file. - Alexis Jazz 14:40, 28 February 2018 (UTC)
  •  Support Contrarily to Fæ, files can violate any number of Commons policies and guidelines which can lead to deletion. Typically, these include COM:L, COM:SCOPE, COM:TOO, COM:PRP, COM:FOP, COM:CRT, and the requirement in many source country licensing templates to have a corresponding template indicating the file is also free in the US. The majority of good faith DRs lead to deletion, and renaming a file subject to one of them can cause confusion in which the redirect is deleted but the renamed file survives, or a bluelink redirect to a deleted file is left in a DR. This proposal removes copyright as the single named specific reason not to rename, to the exclusion of all others.   — Jeff G. ツ please ping or talk to me 14:21, 28 February 2018 (UTC)
If a file fails to be deleted as a result of a move that is a software problem and a bug report should be made. Of course, there are more reliable ways of making this happen. - Alexis Jazz 14:40, 28 February 2018 (UTC)
Huh? "Contrarily to [me]" seems unrelated to what I wrote above. There are many policies related to deleting files, why anyone would think that I was denying this seems weird. --Fæ (talk) 15:11, 28 February 2018 (UTC)
I don't know for what reason Jeff said it, but "The proposal wording does not specify which policy is the one not being complied with." can imply there must be one specific policy the file does not comply with in order to refuse a rename. I don't see the point of that, if a file is not copyvio but it is out of scope, why would you bother renaming it? - Alexis Jazz 15:20, 28 February 2018 (UTC)
@Fæ: What I meant by "Contrarily to Fæ" was that you were opposing, meaning you were for the status quo, which specifies only copyvios can prevent renaming. I also do not understand your conclusion "It reads as if any file needing to be renamed would be deleted" - can you please explain that conclusion and what led to it? — Jeff G. ツ please ping or talk to me 18:55, 28 February 2018 (UTC)
@Jeff G.: Fixed your signature.. I really suspect that what we have here is a case of The dress. You read the same thing I read, Fae and Steinsplitter are reading something completely different. It's nearly impossible for us to figure out on our own what they are reading. - Alexis Jazz 19:45, 28 February 2018 (UTC)
I am not for the status quo and I am against this proposal, these are not mutually exclusive. Criteria 4 of FR would be better removed entirely. A red flag that policies or guidelines are badly written is the inclusion of "deems" when the "deemer" has no defined authority. It would be nice to see proposals that reduce our bureaucracy. Most users and, based on their actions, many administrators, find the current guidelines and policies hard to follow or are not interested in following them as written. --Fæ (talk) 19:56, 28 February 2018 (UTC)
@Fæ: I get your point but I don't fully agree. The "deemer" in this case is a file mover. (or admin etc) They are not asked to make a ruling on the deletion of the file. It merely asks them to use some common sense (I'm aware sense ain't common but you get my point) to determine that if they move a file despite the fact there is an open DR for it, they are making a constructive edit.
If your point is that moving a file that the file mover suspects will be deleted anyway for whatever reason is so stupid it should not require being pointed out in the guidelines I understand that. I will be happy to support a proposal to remove criteria 4 or replace it with "Never forget to use common sense when trying to determine if a file should be moved." or something like that. - Alexis Jazz 21:43, 28 February 2018 (UTC)
@Steinsplitter: Can you or anyone else please explain to me what the issue is that Fae has? And why a request to rename a file that is out of scope should be carried out but a rename for a copyvio should not? - Alexis Jazz 17:03, 28 February 2018 (UTC)
See Fae's oppose, he explained it very well. --Steinsplitter (talk) 17:21, 28 February 2018 (UTC)
If this is a joke I don't get it. I had already replied to that. I did read it. I don't get it. I ask for somebody (Fae or anyone who understands it) to explain it. Maybe I'm reading it wrong. Maybe you and Fae are reading the proposal in a way different from me and Jeff. Maybe it needs to be reworded yet again. But "per Fae" does not help me to do that.
It's like I just walked into the Twilight Zone. - Alexis Jazz 17:34, 28 February 2018 (UTC)

Proposal to bot-deploy Wikidata Infobox

<nowiki>telescopio Lovell; Télescope Lovell; Telescopi Lovell; Lovell-Teleskop; Telescópio Lovell; Teileascóp Lovell; تلسکوپ لاول; 洛弗尔望远镜; Lovell Teleskobu; ラヴェル望遠鏡; Telescópio Lovell; радиотелескоп имени Б. Ловелла; 洛弗尔望远镜; Лавелівський телескоп; Lovell Telescope; 洛弗爾望遠鏡; Lovello radioteleskopo; Lovell Telescope; 洛弗爾望遠鏡; Telescopio Lovell; تلسكوب لافيل; Lovellův teleskop; Lovellov teleskop; radijski teleskop na observatoriju Jodrell Bank v Cheshiru na severozahodu Anglije; teleskop radio di Britania Raya; радиотелескоп в обсерватории «Джодрелл-Бэнк» (Чешир, Северо-Западная Англия); radiotelescopio no Observatorio Jodrell Bank, en Cheshire (Inglaterra); مقراب راديوي في المملكة المتحدة; Radiotelescopio; radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England; رادیو تلسکوپ در بریتانیا; radioteleskop na observatoři Jodrell Bank, hrabství Cheshire, Spojené království; Jodrell Bank Gözlemevi'ndeki radyo teleskobu; Sir Bernard Lovell Telescope; ラベル望遠鏡; Téléscope Lovell; Telescope Lovell; Lovell Telescope; Radiotelescopi de Jodrell Bank; Radiotelescopi Lovell; Telescopi Mark IA; Telescopi de 250 peus; Telescopi Mark I; 250 ft telescope; Radio Telescope at Jodrell Bank; Mark I telescope; Locell Telescope; радиотелескоп Ловелла; 250-футовый телескоп; радиотелескоп в «Джодрелл-Бэнк»; Марк-1; 250 ft telescope; Mark I telescope; Lovell Telescope; Lovellov daljnogled</nowiki>
Lovell Telescope 
radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England
The Lovell Telescope
Upload media
Instance of
Part of
Named after
LocationGoostrey, Cheshire East, Cheshire, North West England, England
Operator
  • Jodrell Bank Centre for Astrophysics
Heritage designation
Service entry
  • 2 August 1957
Significant event
  • construction (1952–1957)
  • first light (1957)
Diameter
  • 250 ft
Frequency
  • 5 GHz
Area
  • 4,560 m² (primary mirror)
Different from
official website
Map53° 14′ 10.5″ N, 2° 18′ 25.74″ W
Authority file
Wikidata Q555130
BabelNet ID: 03860635n
Structurae structure ID: 20049578
National Heritage List for England number: 1221685
Edit infobox data on Wikidata

{{Wikidata Infobox}} displays a small box containing basic information drawn entirely from Wikidata, such as the one on the right for Category:Lovell Telescope. It is inherently multilingual - change the language you're browsing Commons in, and the info in the box will be shown in that language. It works in commons categories (and also galleries) that have a Commons sitelink on Wikidata, and it's been designed so that it should work for any subject (with a special switch to handle humans, including auto-categorisation through {{PeopleByName}}). It also sorts out interwiki links for categories linked to a Wikidata category item (through auto-including {{Interwiki from wikidata}} when needed). Suggestions for improvements and reports of bugs are welcome on the template talk page.

Since I started it just over a month ago, we've had a very positive village pump discussion about it, and it's now been manually added to over 1,000 categories across a wide variety of topics by a number of editors. We can continue to manually deploy it, but as it just relies on the existence of a Wikidata entry with a commons sitelink, we could also bot-deploy it to categories that have such a sitelink. We could either do that for all categories that have such a sitelink (which would be circa 2 million, as that's how many times P373 is used on Wikidata) - obviously, in steps, not all at once! Or we could pick category trees to add the box to, and do it one topic at a time. We can avoid categories that use other approaches (such as {{Wikidata person}}, add it alongside other templates that offer similar functionality (e.g., {{Authority control}}) and/or we can replace them with this one.

What does everyone think? I can write the bot code and start a bot request, if that's what we want to do, but we need to discuss it here first as this is a broad, and fairly fundamental, topic.

(pinging those that participated in the previous VP discussion: @Strakhov, DarwIn, Jheald, Pigsonthewing, Jmabel, and Incnis Mrsi @ערן, Christian Ferrer, Rama, John Cummings, and Jeff G. @Llywelyn2000 and Donald Trung)

Thanks. Mike Peel (talk) 22:54, 25 February 2018 (UTC)

 Support I like it. Useful, low-impact, and promotes Wikidata. Sebari – aka Srittau (talk) 23:13, 25 February 2018 (UTC)
 Support Very useful, Mike is the right person to do it. John Cummings (talk) 23:20, 25 February 2018 (UTC)
 Support It provides good information in a nice, standardized format. Currently, information on category pages are ad hoc and, as far as my experience goes, may be outdated. I am happy this possibility is being put forward, as I believe it really helps. I also like the maps a lot. Mike, full support to your bot request! --Joalpe (talk) 23:38, 25 February 2018 (UTC)
 Support - Jmabel ! talk 23:52, 25 February 2018 (UTC)
 Support, of course. I would also like to see discussion of merging with other templates: {{Wikidata person}}, {{Authority control}}, {{Object location dec}}, et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:14, 26 February 2018 (UTC)
  • I like it and I think Mike Peel did great. I have concerns with replacing templates that already use wikidata codes, because of some potential issues I shared with Mike Peel. Leaving aside that, I  Support bot-adding {{Wikidata infobox}} to categories not using "...wikidata person, wikidata place, authority control, objet location ..." right now. Merging them it's desirable in the medium term, but we can wait to see how the deployment develops, we are not in a hurry after all. strakhov (talk) 01:57, 26 February 2018 (UTC)
 Oppose Warning: Default sort key ", Henri" overrides earlier default sort key "Demonchy, Henri". - Alexis Jazz 02:41, 26 February 2018 (UTC)
@Alexis Jazz: This one is now fixed. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
 Support - it will translate into every language under the sun, it's useful, compact, without drawing attention to itself. Great stuff! Llywelyn2000 (talk) 06:19, 26 February 2018 (UTC)
 Support The sort key issue has to be fixed, but I don't think it should not prevent the deployment. Regards, Yann (talk) 06:23, 26 February 2018 (UTC)
 Support Generally this is good idea and would be nice to see short additonal info on the topic based on Wikidata using this template. We should take care when depoloying the issue Alexis pointed above - either skipping pages that contain keys for now with the bot, or merge it with the template as parameter. Eran (talk) 06:34, 26 February 2018 (UTC)
 Oppose, supporters cut short this discussion but came here now. Incnis Mrsi (talk) 06:56, 26 February 2018 (UTC)
 Support with reservations. You may carefully proceed with deployment, but may not refer to this proposal as to sanction to override objections mounted for each particular case (such as classes of objects where sorting is important). Incnis Mrsi (talk) 11:18, 26 February 2018 (UTC)
@Incnis Mrsi: This was about whether we should have local copies of the Q-numbers. I thought this discussion had run its course, particularly since using the sitelinks is computationally cheaper than using local qids, but we can continue it if you'd like - I'd suggest at Template talk:Wikidata Infobox rather than my talk page. Thanks. Mike Peel (talk) 11:13, 26 February 2018 (UTC)

 Comment

Full list

Warning: Default sort key "Hinojo, Àlex" overrides earlier default sort key ", Àlex".
Warning: Default sort key "Ganivet, Angel" overrides earlier default sort key "Ganivet, Ángel".
Warning: Default sort key "Berchmans, Emile" overrides earlier default sort key ", Émile".
Warning: Default sort key "Palicki, Adrianne" overrides earlier default sort key ", Adrianne".
Warning: Default sort key "Agatha of Sicily" overrides earlier default sort key ", Agatha".
Warning: Default sort key ", Alejo" overrides earlier default sort key "Vidal-Quadras, Alejo".
Warning: Default sort key "Barbazán, Andrés" overrides earlier default sort key "Barbazán Ferreiro, Andrés".
Warning: Default sort key ", Antoine" overrides earlier default sort key "Charial, Antoine".
Warning: Default sort key "Lockwood, Belva Ann" overrides earlier default sort key "Lockwood,".
Warning: Default sort key "Lovell" overrides earlier default sort key "Lovell, Bernard".
Warning: Default sort key "Medialdea, Bibiana" overrides earlier default sort key ", Bibiana".
Warning: Default sort key "Könberg, Bo" overrides earlier default sort key ", Bo".
Warning: Default sort key "Nocedal, Candido" overrides earlier default sort key ", Cándido".
Warning: Default sort key "Hamilton, Carl B." overrides earlier default sort key "Hamilton, Carl".
Warning: Default sort key ", Claude" overrides earlier default sort key "Vulpian, Claude".
Warning: Default sort key "Vulpian, Claude" overrides earlier default sort key ", Claude".
Warning: Default sort key "Perea, Daniel" overrides earlier default sort key "Perea y Rojas, Daniel".
Warning: Default sort key "Feijo, Diogo Antonio" overrides earlier default sort key ", Diogo".
Warning: Default sort key ", Dominique" overrides earlier default sort key "Teixier, Dominique".
Warning: Default sort key "Teixier, Dominique" overrides earlier default sort key ", Dominique".
Warning: Default sort key "Lynden-Bell, Donald" overrides earlier default sort key ", Donald".
Warning: Default sort key "Carlsson Löfdahl, Emma" overrides earlier default sort key "Löfdahl, Carlsson, Emma".
Warning: Default sort key "Baquedano, Enrique" overrides earlier default sort key ", Enrique".
Warning: Default sort key "Ravilious, Eric" overrides earlier default sort key ", Eric".
Warning: Default sort key "Möller, Erik" overrides earlier default sort key ", Erik".
Warning: Default sort key "Flyborg, Eva" overrides earlier default sort key ", Eva".
Warning: Default sort key "KALILI, EVA" overrides earlier default sort key ", Eva, Ewa".
Warning: Default sort key "Sabatini, Francesco" overrides earlier default sort key ", Francesco".
Warning: Default sort key "Cubas, Francisco de" overrides earlier default sort key ", Francisco".
Warning: Default sort key "Granados, Francisco" overrides earlier default sort key ", Francisco".
Warning: Default sort key "Dibnah, Fred" overrides earlier default sort key ", Frederick".
Warning: Default sort key "Coppede Gino" overrides earlier default sort key ", Gino".
Warning: Default sort key "Gaensly, Guilherme" overrides earlier default sort key ", Guilherme".
Warning: Default sort key "Sabanci, Guler" overrides earlier default sort key "Sabancı,".
Warning: Default sort key "Rohr, Hans Christoffer" overrides earlier default sort key "von Rohr, Hans".
Warning: Default sort key ", Henri" overrides earlier default sort key "Demonchy, Henri".
Warning: Default sort key "González, Ignacio" overrides earlier default sort key "Gonzalez Gonzalez, Ignacio".
Warning: Default sort key "Mundebo, Ingemar" overrides earlier default sort key ", Ingemar".
Warning: Default sort key "Gardner, Isabella Stewart" overrides earlier default sort key ", Isabella".
Warning: Default sort key "Mayor Oreja, Jaime" overrides earlier default sort key ", Jaime".
Warning: Default sort key "Ertsborn, Jan" overrides earlier default sort key ", Jan".
Warning: Default sort key "Pateau, Jean" overrides earlier default sort key ", Jean".
Warning: Default sort key ", Joaquín" overrides earlier default sort key "Almunia, Joaquin".
Warning: Default sort key "Rucoba, Joaquín" overrides earlier default sort key ", Joaquín".
Warning: Default sort key "Klabo, Johannes Hosflot" overrides earlier default sort key "Klæbo, Johannes".
Warning: Default sort key "Ortega Lara, José Antonio" overrides earlier default sort key "Ortega, José".
Warning: Default sort key "Ortega y Gasset, José" overrides earlier default sort key "Ortega, José".
Warning: Default sort key "Urioste Velada, Jose" overrides earlier default sort key "Urioste, José".
Warning: Default sort key "Imaz, Josu Jon" overrides earlier default sort key ", Josu".
Warning: Default sort key "Guerra, Julio" overrides earlier default sort key ", Júlio".
Warning: Default sort key "Klein, Lori" overrides earlier default sort key ", Lori".
Warning: Default sort key "Cabello Lapiedra, Luis Maria" overrides earlier default sort key ", Luis, Luis María".
Warning: Default sort key ", Manuela" overrides earlier default sort key "Carmena, Manuela".
Warning: Default sort key "Arnholm, Maria" overrides earlier default sort key ", Maria".
Warning: Default sort key "San Gil, Maria" overrides earlier default sort key ", María".
Warning: Default sort key "Conde, Mario" overrides earlier default sort key ", Mario".
Warning: Default sort key "Azevedo, Militao Augusto De" overrides earlier default sort key ", Militão".
Warning: Default sort key "Iceta, Miquel" overrides earlier default sort key ", Miquel".
Warning: Default sort key "Cornwell, Patricia" overrides earlier default sort key ", Patricia".
Warning: Default sort key "Vega, Paz" overrides earlier default sort key ", Paz".
Warning: Default sort key "Jerald, Penny Johnson" overrides earlier default sort key ", Penny".
Warning: Default sort key "Gahrton, Per" overrides earlier default sort key ", Per".
Warning: Default sort key ", René" overrides earlier default sort key "Fontès, René".
Warning: Default sort key "Haddad, Roger" overrides earlier default sort key ", Roger".
Warning: Default sort key "Abascal Conde, Santiago" overrides earlier default sort key "Abascal, Santiago".
Warning: Default sort key "Macfarlane, Seth" overrides earlier default sort key "MacFarlane, Seth".
Warning: Default sort key "Marthe, Tamara" overrides earlier default sort key "Shy'm, Tamara".
Warning: Default sort key ", Sol" overrides earlier default sort key "Sanchez, Sol".
Warning: Default sort key ", Teodoro" overrides earlier default sort key "Gascon, Teodoro".
Warning: Default sort key "Acketoft, Tina" overrides earlier default sort key ", Tina".
Warning: Default sort key "Le Guin, Ursula K." overrides earlier default sort key "Kroeber, Le Guin, Ursula".

So that needs to be sorted first anyway. If it does get sorted, I'm not entirely sure. It feels like it doesn't nicely fit in the layout. I'm also not sure I will find it useful. Perhaps some good examples can convince me.
Another issue I have is that this error occurs on 71 category pages out of 1078. That's 6.59% of all category pages yet this bug was not spotted. This thing needs way more thorough testing before deploying it on two millions pages. - Alexis Jazz 07:14, 26 February 2018 (UTC)
Alexis Jazz: This list is useless. Please create a maintenance category instead. Regards, Yann (talk) 09:06, 26 February 2018 (UTC)
You tell me I "make a mountain out of a molehill" in response to my perfectly sane proposal and you call a useful list (you can't easily search for these errors) useless. With this list you can more easily pinpoint all possible causes for this issue. If you want a list that also links the category in question, no problem, you would have only had to ask.
So far I have been (and will be, at least for some time) constructive on this wiki. But you create vandals. You treat people this way while being an administrator, you make people want to break this wiki. - Alexis Jazz 10:31, 26 February 2018 (UTC)
@Alexis Jazz: Thanks for catching this error; this part of the code was only added very recently. The ones with the missing surnames should now be fixed (I added an extra if statement to avoid auto-categorising these). The others, I'd appreciate feedback on - they are due to mismatches/errors in data here and on wikidata, so they can be resolved individually by an edit here or on Wikidata, or I can remove the defaultsort code from this template, I'm happy with either approach. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
Very good. I see for example Category:Ángel Ganivet indeed still shows the error due to the difference between "Angel" and "Ángel" and it takes a human to figure out which is right. What are the implications of removing the defaultsort code from the template? Will this cause problems, either now or at a later time? What is the reason this code is currently part of the template?
I think the infobox should not be added when it can cause this error which requires a human to fix it. If allowing these inconsistencies to exist is a bad idea (and I suspect it is) you could perhaps generate a list of the categories where this error occurs. (or add a hidden cat to those categories) When (human) users feel like it they can make the data consistent and enable the infobox. - Alexis Jazz 11:27, 26 February 2018 (UTC)
@Alexis Jazz: Defaultsort was added through the use of {{PeopleByName}} (see the discussion at #Merge the function of two templates above). I've now copied that code into this template, which gives more customization options. I've added a "defaultsort=no" parameter that, if set, will hide the defaultsort from this template and add the page to Category:Uses of Wikidata Infobox with defaultsort suppressed for tracking purposes. The plan would be that the bot would set that if it detects a conflicting defaultsort already in the category. How does that sound? Thanks. Mike Peel (talk) 22:06, 26 February 2018 (UTC)
@Mike Peel: That sounds good, I think some more implementation is in order.   — Jeff G. ツ please ping or talk to me 00:12, 27 February 2018 (UTC)
 Support Very much agreed with Sebari. Rama (talk) 09:11, 26 February 2018 (UTC)
+1, also helps editors focus on non-duplicative work to improve our metadata. --Nemo 11:21, 26 February 2018 (UTC)
 Support Obviously, tread gently. Move slowly into new areas of categories for new types of things. Be aware that these may reveal issues, that will then need adaptations to resolve. But in general, I support; and I have great confidence from what I've seen so far, that the team behind this (namely Mike!) are indeed very sensible and highly responsive. Widespread infoboxing will add greatly to the informativeness of category pages for all, as well as making Commons far more multilingually friendly. If it also adds an incentive for editors to add more sitelinks from Commons categories to items on Wikidata, that would be a valuable thing just in itself. Jheald (talk) 13:59, 26 February 2018 (UTC)
 Neutral Changing my vote from oppose to neutral. I just don't know if I will find these useful personally. Maybe I will, I just can't think of any case right now where I would wish there was an infobox. If there would be an option to somehow disable these infoboxes just in case I don't like them, I would change my vote to support. I do mean actually disabling them, not just hiding, because something could happen that somehow slows down page loading. Hiding won't help in that case. - Alexis Jazz 14:14, 26 February 2018 (UTC)
@Alexis Jazz: Hiding's the best I can do, I'm afraid. If you add "#wdinfobox { display: none;}" to User:Alexis Jazz/common.css, that will hide the infobox. Thanks. Mike Peel (talk) 22:17, 26 February 2018 (UTC)
Thanks. I will stick with the neutral vote, simply because I am personally not sure I will be using it. Maybe it'll grow on me, who knows. My support won't be needed for this anyway so it makes no real difference. - Alexis Jazz 10:41, 27 February 2018 (UTC)
 Support I was skeptical at first and resisted the early iterations because I had my own fave infobox format that used a horizontal format. Now this is my preferred. It replaces the 6 items I would use to create a new category, each requiring me to fill in information by hand. It also helps catch incorrect people by supplying their short descriptions from Wikidata. So when you see an image of a guy wearing boxing gloves and the infobox says he is a politician, you know to double check that two people have the same name and are being mixed up. Or if you see a contemporary photograph and see that the person lived in the 1800s. RAN (talk) 14:54, 26 February 2018 (UTC)
Um, if I support eating meat (instead of being a vegetarian) I will be responsible for millions of animals being slaughtered and incredible animal cruelty all around the world every day. I will be solely responsible for all that because I support it. And because I support lighting some fireworks on the Fourth of July, I am responsible for tens of thousands of people who get seriously injured every year in accidents all over the world. And imagine the implications of having the wrong stance on gun control.. I must be a very bad man. - Alexis Jazz 11:14, 28 February 2018 (UTC)
  •  Support, but cautiously. I've added this template to a few categories (mostly places), and when it works it's magical. It interacts slightly poorly with some other templates, though, so I'd start by adding it to categories whose pages contain only parent categories and work up from there. --bjh21 (talk) 19:13, 1 March 2018 (UTC)
  •  Oppose for implementation reasons only. Striking oppose per threaded discussion. I'm normally not fond of adding more content to categories than is necessary to identify it, but this concept is so good for internationalisation that I have to drop my objection. Adding them manually, therefore, sounds like a great idea. But how is a bot supposed to know what's what? Sounds like you're adding it to a category that merely has a link to a Wikidata item; what if a category has a link as a means of clarifying something else, e.g. "Place X is a town in Galicia"? You wouldn't want to end up with the Galicia (Spain) data just because someone included a link to d:Q3908, its data page. Nyttend (talk) 11:50, 3 March 2018 (UTC)
    • @Nyttend: The bot would only add it to pages that have a commons sitelink on Wikidata, not just a link to Wikidata. That's the same sitelink that causes the interwiki links to appear in the left-hand bar. So for Galicia, it would add the infobox to Category:Galicia (Spain) as that's what is sitelinked - not any other page that happens to link to Q3908. Thanks. Mike Peel (talk) 14:05, 3 March 2018 (UTC)
      • Mike Peel, so you mean that it wouldn't get added unless the data page's "Commons category" section linked to the category in question? If that's the case, no complaints. Nyttend (talk) 16:21, 3 March 2018 (UTC)
        • @Nyttend: It's the 'Commons' link under 'Other sites' on the right (the other one is a property, not a sitelink), and it's only if that points to a category. But basically, yes. Thanks. Mike Peel (talk) 16:27, 3 March 2018 (UTC)
          • Okay, since it's merely doing it with pages that are already linked to the Wikidata record, you've shown my objection to be baseless. Thank you :-) Now that I understand it, I can see that it should be simple to implement. Nyttend (talk) 19:03, 3 March 2018 (UTC)
  • Note Given the support here (thank you all!), I've drafted the bot code and started a bot request at Commons:Bots/Requests/Pi bot 1 to ask for feedback on the code and any potential technical issues. Of course, this discussion is still running, and the bot run won't start until this discussion reaches a conclusion. Thanks. Mike Peel (talk) 23:57, 3 March 2018 (UTC)

Portraits of Wikimedians

A proposal: each positively contributing Wikimedian has right to keep one photo of self on Commons, not necessarily used on any wiki page within Wikimedia. Sufficient conditions for “positive contributions” should be one C-class (at least) article or few dozens good essential edits (not just spelling/grammar fixes). Here was a portrait of the guy who wrote Anumantharayan Kottai. Not really a huge contribution, but let’s stop, at last, this vandal deletionist DoS attack by the infamous troll condoned and even overtly supported by certain elements among legitimate Commons users. Which Wikimedia members does the community respect: those who build something, or those who destroyed others’ works and made provocations during their career? Incnis Mrsi (talk) 19:27, 16 February 2018 (UTC)

So you want to modify COM:INUSE? I'm perfectly fine with allowing personal images if they are used on user pages for identification purposes. That has long standing agreement and I'm all for that. I also for making exceptions. This particular case seems like a tad much though. If I'm getting everything right you are talking about Lalwilson007 who has all of four edits to Commons and a total of 16 edits across all projects. Tying it to article ratings is also not really going to work as those are not monitored and completely subjective based on the whims of whomever rates the page. I understand the DENY aspect of trolls. And to be honest, I'm not really all that comfortable with someone else taking over their requests. But that doesn't mean we should stop all such requests. Else the trolling can cause a lot more damage the other way. In short, if a legitimate user brings this to the attention of the greater community I'm not quite sure I'd agree with your point of view here. The photo wasn't even in use and it doesn't appear that the person has edited any project since May of last year. Again, I'm all for making exceptions but not really in this case. Blanket changes to policy like this are probably not the best option here. If you come up with a more tailored approach I'd probably support. Sorry. --Majora (talk) 19:46, 16 February 2018 (UTC)
I agree with P199. If a personal file is uploaded by a user who is not active in any project it should be deleted. We are not and should not be a social media site. I nominate a lot of personal files for deletion, I just don't nominate any in use in any project. Personal files from vanity uploaders are not within the scope of the project. Really a lot of this could just be soled by carefully checking a DR before closing it as Delete. For instance say someone uploades a file having no contributions and not connecting the file to any project whilst within the week starts making a large amount of good edits to a project and connects the file to the User page. The nominator was not wrong for nominating the image (but should withdraw the nomination if new facts are presented) but the file should still be kept. As far as Lalwilson007, this user has 16 total edits across all projects-on en:wp only 3 were in the mainspace and on commons 1 file was not a photo of a person. The 2 photos of a person are not in use. This is not the hill to die on. Your other 2 case studies are better. -- Sixflashphoto (talk) 20:52, 20 February 2018 (UTC)
Meh, or apply commonsense, stick to being Mellow, and not delete everything it is possible to delete, especially when an inactive user seems to have always acted in good faith and the releases are correct. I'm pretty good at guesstimates, I'd say we were talking about perhaps 0.03% of the images on Commons might be described this way. If anyone wants to seek out media to delete, how about focusing on copyvios that are a problem that is a thousand times larger? --Fæ (talk) 21:07, 20 February 2018 (UTC)
  • Oppose as written, but agree that it would probably be sensible to introduce a new CSD criterion (i.e. F10) which would allow for:
F10: deletion of personal images either unused or used only by a single user's namespace (in any number of projects), if that user is not also autoconfirmed in at least one project. This would be a minimum threshold, obviously, and others may be suitable for DR rather than CSD, but the objective criterion combined with existing definitions of "personal image" would likely cut down on a lot of the social media-style content we see uploaded on a daily basis. It also operates under the assumption that the autoconfirmed user right is implemented on most, if not all, projects (I believe it's a MediaWiki default, but could be wrong). — Rhododendrites talk |  00:50, 21 February 2018 (UTC)
@Rhododendrites: It appears to be a WMF default, please see the last paragraph of m:Registered user.   — Jeff G. ツ please ping or talk to me 02:21, 21 February 2018 (UTC)
Most projects define an autoconfirmed account as "existing" for four days. No edits required. I'm not entirely sure that is a good threshold here as it requires nothing more than an account on one of the projects that give out autoconfirmed that way. --Majora (talk) 02:40, 21 February 2018 (UTC)
  •  Oppose yet more deletion drama - don't trust DR? don't want a consensus? "this" is a disgrace? i guess we have different views of what commons should be ashamed. Slowking4 § Sander.v.Ginkel's revenge 14:07, 23 February 2018 (UTC)
  •  Comment @Incnis Mrsi: I would suggest something different. No strict "1 picture" limit, but a FUP. Users who have contributed a lot could have more non-educational images than new users. In addition: if a user decides to upload a photo of themselves, they must (also) upload one photo on which we can see the user is aware of Commons. This could be achieved in various ways, for example the user could write "Commons" on their hand and make a selfie which includes that hand, or we could agree on some hand gesture. But there is an infinite number of ways. I don't want another Ameily Radke. Admittedly this won't make any difference for existing images. - Alexis Jazz 18:38, 23 February 2018 (UTC)
    Alexis’s concern about “… es vato” pictures is grounded on personality rights and privacy. I advocate another cause, namely, to stop disparaging and disrespectful treatment of genuine Wikimedia contributors—who have hence a low probability to commit deliberate privacy violations and hoaxes. Whereas photoshops uploaded—with unspecified sources—by blatantly promotional zero-merit accs are frequently kept by certain sysops. Incnis Mrsi (talk) 18:58, 23 February 2018 (UTC)
    Partially. I may not have been completely clear, but if there would be a photo included on which it is made clear the person pictured is aware of Commons (or, for example, a photo exists of a Wiki meeting that also shows the person) that would make the pictures of that user ineligible for deletion, within a FUP. So it also achieves part of what your goal is, it just offers no solution for all the images from abandoned accounts uploaded so far. To be honest I'm not sure how useful it is to have those images around. I see no reason to delete them (they are not removed from the WMF drives, they still take up space) but I can't think of any good reason to keep them either. May I ask: why should such images be kept? If there is a good reason (for example, if the trolls are partisan when nominating abandoned pictures) I may support your proposal. - Alexis Jazz 19:27, 23 February 2018 (UTC)
  • Perhaps 1 unused personal photograph per 100 or 1000 edits? Anyhow I would  Support this as the policy needs updating. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:26, 6 March 2018 (UTC)
  •  Oppose changes to policy. Commons:Project_scope clearly states that "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project." and I think that policy is sufficient. I would not have closed Commons:Deletion requests/File:Lal wilson J.jpg as "Delete", but I was not the one closing it. I assume it was deleted because it was not in use and did not meet requirements of the policy. However If someone wanted to actually use it, I think it would be fine to re-upload. --Jarekt (talk) 16:52, 3 April 2018 (UTC)
  •  Oppose the policy change. It's true that a well-categorized photo can be found without being on a user page, but if categories are the only place it exists, it seems like its usefulness is so limited that it's not worth bothering with. If this were to become policy, then image patrollers would have to waste their time perusing people's contribution histories to decide if their contributions are "good enough". It also creates an unnecessary gray area—I can foresee deletion requests where people are debating whether or not a user has made enough positive contributions. This is a silly thing for us to waste time on, especially since the user could just take 5 seconds to put the image on a page, and the whole discussion would become moot. –IagoQnsi (talk) 15:16, 12 April 2018 (UTC)

Proposal to stop Special:Upload and Special:UploadWizard from adding headers to file description pages automatically

The first annoying header uses code "== {{int:filedesc}} ==", which evaluates in English to "Summary". It only makes sense to have it if you have other headers.

The second annoying header uses code "== {{int:license-header}} ==", which evaluates in English to "Licensing". Licensing should be in the information or other template's Permission parameter.

This proposal builds on the work of multiple authors of COM:VP#Upload automatically adding section headings, including @Nyttend, Begoon, and Perhelion, and is related to phab:T187302, wherein @Fæ noted a lack of consensus for addition of such headers the first place.   — Jeff G. ツ please ping or talk to me 13:56, 28 February 2018 (UTC)

By "headers", I mean section headers or headings.   — Jeff G. ツ please ping or talk to me 19:02, 28 February 2018 (UTC)

Headers proposal !voting

 Support It's rather unclear to me where I'm supposed to stick my {{Trademarked}}, {{De minimis}}, license etc anyway. I think it looks better when those are in the permissions field of {{Information}}. - Alexis Jazz 14:44, 28 February 2018 (UTC)

 Oppose, at least in respect of Special:UploadWizard. The Upload Wizard constructs its own wikitext, and I think it's perfectly reasonable that it should include these headings, since doing so is in keeping with common practice on Commons. I'd need to investigate the behaviour of Special:Upload a little more to have an opinion on it, but I think it should be possible to use it in a way that causes the created page to contain precisely the text typed (or pasted) into a single text area. --bjh21 (talk) 16:39, 28 February 2018 (UTC)

@Bjh21: but these common practices are only common because that's what the upload pages do. We cannot make Y common practice because X is common practice. - Alexis Jazz 17:08, 28 February 2018 (UTC)
True. In that case my argument is simply that there's insufficient rationale given for causing a change in common practice. --bjh21 (talk) 17:43, 28 February 2018 (UTC)
@Bjh21: I am not proposing a change in how humans construct file description pages, only in how two pieces of automatic software do it. I think it is already acceptable for humans and other pieces of automatic software to avoid the section headers and put licenses in the permission fields.   — Jeff G. ツ please ping or talk to me 19:00, 28 February 2018 (UTC)
  •  Support unless you're using some setup that automatically adds headers. For example, if you're using Special:Upload and you don't specify a license in the free-text area, but you pick a license from the dropdown, it automatically adds a "Licensing" header, and in that case, the "Summary" header is useful. Surely it's not that hard for the system to detect whether the system is doing something. And if I understand rightly from Bjh21, the UploadWizard automatically has section headers, so that makes sense. But bjh21, I always paste my content directly into the Special:Upload box (I write it up in a Notepad file, and when I'm done I paste it in), and I'm always still getting the header. It's now impossible to avoid. Nyttend (talk) 22:55, 28 February 2018 (UTC)
  •  Oppose, these headers make it quite easy for novice users (especially for the UploadWizard), but if users with more non-conventional licenses and descriptions then this be able to be optionally removed, but not by default. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:55, 1 March 2018 (UTC)
@Donald Trung: A user who uses the Upload Wizard never even sees these headers? - Alexis Jazz 01:25, 1 March 2018 (UTC)
  •  Oppose I like structure. That's why we have categories. I'm not keen on huge undemarcated blocks of text. But licensing is not only highly important, it is critical to Commons. That's why it should have its own visible paragraph on the page, with an appropriate section header, rather than being buried in the information about location, description, photographer, source etc. I don't see a compelling case to change what we do, because I suggest it is helpful. Rodhullandemu (talk) 18:32, 1 March 2018 (UTC)
  •  Oppose I find useful the "edit" and "edit source" options this header displays ...when I need to fix something in the {{Information}} template. They come in handy. I'm used to embedding permission/licensing templates in {{Information}}, though. strakhov (talk) 18:39, 1 March 2018 (UTC)
  •  Support There is a long history behind these useless sub-headings. We can see in the documentation of Template:Information that "license" was initially placed in "permission". But when people started to use custome license tags which are big, some people in Commons didn't like it. They decided to move it outside the template "information" and "permission" is remained for uses like OTRS and other markings. This makes the permission parameters split into two places and less informative to re-users. Who knows what the difference between "permission" and "license" with entirely different information in two different places? Fortunately I'm using cusom upload templates and place all licensing information (license, other non-copyright warnings, FOP and any other information) in one place "permission". Jee 06:51, 2 March 2018 (UTC)
    @Jkadavoor: Right, the licenses available for selection by users using these tools should not be so big as to require placement outside the "permission" field.   — Jeff G. ツ please ping or talk to me 10:31, 2 March 2018 (UTC)
  •  Oppose I find much better to separate legal information (license, trademark, FoP template, etc.) outside of the description. The headers could be displayed or hidden automatically with CSS when we will have structured data, but keep them for now. Regards, Yann (talk) 08:27, 2 March 2018 (UTC)
  •  Oppose - the license does not belong to the permission field. Did you know that is disappears when using the script for an OTRS tag if the license is there? The permission field is for permission information. - Jcb (talk) 08:35, 2 March 2018 (UTC)
    @Jcb: That would be a bug in the script for an OTRS tag.   — Jeff G. ツ please ping or talk to me 08:47, 2 March 2018 (UTC)
    If you want to place license out side of "information template", please place the OTRS permission, license review, etc. too below it. Please don't put related information scattered into several places so that reuser need to be a gymnastic to club all these pieces of information. We have plenty of license tags with OTRS and/or license review merged with it. Jee 09:36, 2 March 2018 (UTC)
    I did not write the scripts, but the current situation (already for years) is that if you apply an OTRS received or PermissionOTRS tag with the script from the 'tools' menu, that the tag lands in the 'permission' field. Jcb (talk) 09:41, 2 March 2018 (UTC)
    @Jcb: I reported your 08:35 statement above in a bug report at MediaWiki talk:Gadget-PermissionOTRS.js#Removal of old contents of "permission" field.   — Jeff G. ツ please ping or talk to me 10:08, 2 March 2018 (UTC)
    (Edit conflict) I know. That's why I wrote above "there is a long history behind these useless sub-headings." It was not thus in the beginning; but introduced later without knowing the copyright requirements that TASL (Title, Author, Source and License) should be clubbed together to provide ideal attribution. Only recenty we started to take care of proper attribution. Many of us feel that current "information template" is inadequate and started using Template:Credit line to override this limitation. But it is difficult to inject that template in all our pages; the better solution is to keep "TASL" together in information template. Jee 10:19, 2 March 2018 (UTC)
  •  Support you can already do almost all what you want with the current template (or with one of its derivatives). No need of any header. Furthermore there is no TOC in files page, no need of different sections, even for a structural page concern. If the current template is not sufficient or not visually good, then develop it. Christian Ferrer (talk) 17:31, 2 March 2018 (UTC)
  •  Oppose, i see no harm. --Steinsplitter (talk) 17:44, 2 March 2018 (UTC)
  •  Oppose, per Yann and Steinsplitter. -- Tuválkin ✉ ✇ 15:51, 3 March 2018 (UTC)
  •  little oppose, if there's a way to make it possible in another way on mobile (I don't like the unofficial app, as I'm a fan of MobileFrontend view) I may consider support. --Liuxinyu970226 (talk) 13:01, 12 March 2018 (UTC)
  •  Oppose I prefer file pages with clearly delineated description and license sections. --Jarekt (talk) 16:28, 3 April 2018 (UTC)
  •  Oppose, very helpful --Schlurcher (talk) 03:29, 5 April 2018 (UTC)
  •  Support, in Special:Upload. I know I've been caught by the automatic adding of those headers before. It would be great if this more advanced form worked in a more predictable way. I have to abstain from any change one way or the other for Special:UploadWizard because I'm not as familiar with it, though I am inclined to vote to remove the automatic headings from there as well. ~ PaulT+/C 04:01, 16 April 2018 (UTC)

Headers proposal discussion

No, I've not. In fact this is the tool that, after to have generate all the appropriate templates and links, lead me to Special:Upload basic, I've not the choice. But my problem is minor, I just have to remove the header that is too much. It's really not much to do. Christian Ferrer (talk) 05:13, 2 March 2018 (UTC)
  •  Comment - This whole discussion seems to have been prompted by a couple of comments by Nyttend and myself to the effect that we didn't think Special:Upload (the manual form) should be adding the int:filedesc heading to every upload, because it's, you know, the manual form, and folks who use it really expect just what they put in the freeform field to be used, just as it used to be. Like Nyttend, I copy/paste wiki-text and having this unavoidable automatic addition is a bit inconvenient sometimes. At that point we were only talking about one thing that just started happening, just with the manual form. Somehow that has expanded to a discussion about the wizards, where licenses should go, OTRS scripts and all sorts of other things. It's all very interesting, if somewhat tangential to the point that seems to have initiated it... -- Begoon 16:45, 2 March 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2018/02&oldid=301577577"