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

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

OTRS member permissions

Add more guidance at Commons:Deletion requests

In view of some recent discussions (which we needn't discuss here, hopefully, so I won't link to them), it seems clear that it would be helpful to have a little more guidance to administrators about the community's expectations of how deletion requests are handled. I propose adding to Commons:Deletion_requests#Instructions_for_administrators:

Administrators are encouraged not to close requests where discussion has stopped but unresolved issues remain. Administrators should always be aware that even a strong consensus can never trump copyright law nor override Commons Policy.
Administrators closing deletion requests are expected to provide adequate explanation for their decision. In many cases, where there is little discussion and no disagreement with the request, no details are required. However the more complex a discussion, and the more users have argued for the opposite outcome than the administrator's decision, the more a clear explanation of the decision is required. In any event, administrators are expected to clarify or explain their decisions on request.

The context for this addition can be seen here. I believe my addition is not any new requirement, just a description of what the community expects. It is carefully worded not to create any simplistic requirement admins must remember in closing discussions, just general guidance. The only firm part of the wording is the requirement to explain or clarify on request, which surely cannot be controversial. Note also that Commons:Deletion requests is not formally a policy or guideline, which perhaps limits how controversial it should be to make such additions to it. Rd232 (talk) 17:21, 31 October 2011 (UTC)

OK, this risks getting more complicated than I expected. I'm going to split the proposal into two parts, and I've taken the liberty of moving relevant comments into a subsection. Rd232 (talk) 12:17, 1 November 2011 (UTC)

Explanation


Discussion

Conclusion

Proposal: add

Administrators are encouraged not to close requests where discussion has stopped but unresolved issues remain. Administrators should always be aware that even a strong consensus can never trump copyright law nor override Commons Policy.


Discussion
Deletion requests must be decided at some time, also when there is no consensus. When discussion has stopped, there is no point in keeping the DR open. I agree with the second part, about giving a rationale for the decision. /Pieter Kuiper (talk) 17:29, 31 October 2011 (UTC)
Discussion can stop without reaching a conclusion. What I'm trying to suggest is that administrators should be encouraged to ensure a conclusion is reached, and not just close a discussion with unresolved issues by counting heads. I didn't want to go into too much detail, but I didn't mean just leaving such situations open indefinitely, but actively trying to move them forward - for example when there are unanswered questions, by trying to get answers to them, either from the people they're addressed to, or from others. Maybe an extra sentence would help explain that. Rd232 (talk) 17:36, 31 October 2011 (UTC)
If we are to accept that rule, though, there would have to be a time limit. At some point it makes sense to acknowledge that there is simply no consensus for something and/or that people aren't interested enough to comment/work towards a consensus. There shouldn't be any long-term deletion requests - it's just unprofessional. --Philosopher Let us reason together. 21:39, 31 October 2011 (UTC)
I wouldn't use the word rule; this is guidance on what is expected of administrators, not rules requiring something. Administrative discretion and judgement is expected. Perhaps you're right though that some guidance on time limits is needed. There could be a two-step time limit combined with some way of bringing extra attention to these particularly difficult DRs. Something like: if there's no conclusion in 1 month, list the DR for extra attention (in a manner to be agreed), and give it a further month. If it's still not resolved then, default to keep if it's a scope issue, and default to delete if it's a copyright/permission/licensing issue. Allow exceptions at administrator discretion if there is a specific reason to give more time. Of course, this is going into different territory than I had in mind, by creating new guidelines, but maybe that's necessary. Rd232 (talk) 22:01, 31 October 2011 (UTC)
There is just the question: "Which way should a DR where is no consensus/ not enough copyright knowledge should be decided?" And I am sure there is no general answer to this question. Should possibly unfree files being kept? Should we delete those files that are, additionally probably highly used? That's why I would not favorize a "time-limit". Those conroversal DRs should be on a more prominent place, maybe — in order to get more people engaging in discussion. -- RE rillke questions? 12:07, 1 November 2011 (UTC)
OK, we could just have a time limit for making the DR more prominent, say 1 month, and then leave it open-ended. How can we get DRs that need it more attention? (How many of these old DRs are typically open?) Rd232 (talk) 12:20, 1 November 2011 (UTC)

Pieter will be shocked to hear that I agree with him. Personally, I think the first sentence is way too vague, open to abuse, and is frankly a solution in search of a problem. In discussions where there is an unresolved issue and it is being meaningfully pursued (someone is chasing down OTRS, someone has volunteered to make inquiries with a source, etc. etc.), discussions are almost always left open. I just find the first sentence to be an unnecessary level of instruction creep. I have always seen admins use common sense when closing such discussions. Automatic arbitrary time extentions seem pointless - strikes me as simply a vehicle to allow copyvios to linger unnecessarily, or properly licensed/public domain images to remain in purgatory. If there are discussions that would benefit from wider participation, perhaps we should have a noticeboard of some kind that would allow either people to solicit more input. If a DR gets listed, then perhaps there is an automatic 7 day extension before it is closed, although these discussions typically last as long as they need to (a mandatory month is just silly). But there should be some sort of proactive step before anything gets triggered (either a participant who would like further input or a closing admin who sees that the issue is not fully resolved). --Skeezix1000 (talk) 12:53, 1 November 2011 (UTC)

The second sentence is redundant. The instructions already say: "The debates are not votes, and the closing admin will apply copyright law and Commons policy to the best of his or her ability in determining whether the file should be deleted or kept. Any expressed consensus will be taken into account so far as possible, but consensus can never trump copyright law nor can it override Commons Policy. " /Pieter Kuiper (talk) 13:00, 1 November 2011 (UTC)
Fair enough. I have no problem repeating it, but others may see that as unnecessary. --Skeezix1000 (talk) 13:06, 1 November 2011 (UTC)
I'm aware of the redundancy; I see the first mention as more directed at participants, the second specifically at admins to emphasise that closure is not by headcount but by substance. Rd232 (talk) 13:27, 1 November 2011 (UTC)
Normally I'd say that making it harder for admins to decide issues is a bad idea. But after reading the de-sysop discussion elsewhere maybe you have a point. –Be..anyone (talk) 11:06, 4 November 2011 (UTC)

Ideas to help reduce OTRS backlogs

The proposal above, Commons:Village_pump/Proposals#OTRS_member_permissions, on extending key admin rights to OTRS volunteers (the ability to view and possibly even undelete deleted material) has failed due to WMF opposition on legal grounds. I suggest we should discuss some alternatives to help reduce OTRS backlogs, particularly in relation to OTRS volunteers not having admin rights.

Here are some ideas to kick off discussion:

  1. Encourage all active Commons admins to consider applying for OTRS.
  2. Reach out to other Wikimedia projects to ask admins there who are active in licensing/copyright to consider (a) applying for OTRS and (b) becoming active on Commons and (c) applying for adminship here. Practically, this would probably begin with drafting a user message template here, and then translating it.
  3. Create a streamlined "Expedited RFA" process for (current!) admins on other Wikimedia projects who are OTRS volunteers. Make it clear in COM:ADMIN that such users don't need to have a deep involvement with Commons in order to gain adminship, since OTRS membership ought to confirm relevant competence (in exchange, they agree to only use admin powers in relation to OTRS tickets, unless they pass a normal RFA). Loss of adminship on their main project would result in immediate loss of Commons adminship. Possibly require candidates for this to have globally "clean" records (no active or recent bans or long-term blocks), and loss of a "clean" record whilst admin would result in immediate loss of Commons adminship.
  4. Alternatively, formalise idea 3. by creating a "limited admin" group specifically for such users (admins on other Wikimedia projects who are OTRS volunteers), with just viewdelete, browsehistory and undelete, and the understanding that these only be used in relation to OTRS tickets.
  5. Create a system to easily identify OTRS tickets which need admin rights to handle, so that admins can focus on these. [This might already exist, I don't know; but reading between the lines, I think not.]

Both 3. and 4. would have to be run past WMF legal, but I think have a fair chance of success. Comments? Other ideas? Rd232 (talk) 01:40, 10 November 2011 (UTC)

  • I'd strongly oppose granting indiscriminate, blanket privileges to wikipedia administrators. First, let the immortals stay on their mountain - no need to import their Olympian shoot-first mentality here. Second, many have quite lax views on copyright - and it shows in their uploads. Third, many are kids - why entrust copyright matters to twelve-year-olds? Finally, RFA process here is mostly a formality - no public humiliation, no flogging, drawing and quartering - that is, it's not broken. NVO (talk) 07:12, 14 November 2011 (UTC)
    • Thanks for your input. However I'm not sure from your comment whether you've taken into account the double filtering involved in that suggestion, admins on other Wikimedia projects who are OTRS volunteers. Also I would like comments on other suggestions, or suggestions of your own. Thanks! Rd232 (talk) 12:47, 14 November 2011 (UTC)
      • I'm not familiar with OTRS functioning outside of commons - but I suspect that fully certified OTRS reviewers there are very scarce - their job is primarily here, not on wikipedia. For example, there are 11 OTRS agents on Russian wikipedia: 4 are commons sysops already, 4 are sysops there but not here, 3 are not sysops there, neither here (I left out one OTRS agent with limited functionality). Not much of a choice. NVO (talk) 13:03, 14 November 2011 (UTC)
        • Well in that example, aren't there 4 candidates for limited Commons adminship? I'd be happy with that per project; indeed, considering the usefulness of language diversity, I'd be happy with a couple of dozen candidates from across Wikimedia projects. Rd232 (talk) 13:24, 14 November 2011 (UTC)
  • I oppose 3 and 4 - indeed, the RFA process does not seem to be broken, and I am not sure I want to see a Ru.wikiversity admin, who was banned in ru.wikipedia for disruptive behavior and stalking, to be an admin here without an RFA - whatever limited his authority would be. For 1, 2, and 5, I do not see any immediate problems.--Ymblanter (talk) 13:08, 14 November 2011 (UTC)
    • OK... I'm not sure if such a person would be given OTRS access(?) but I've clarified the suggestion that a currently "clean" global record could be a requirement. As to RFA not being broken - that may be true, but I'm sure there are competent OTRS-active admins on other projects who wouldn't consider full Commons adminship, for various reasons, but would go for a limited Commons adminship to facilitate their OTRS handling. Rd232 (talk) 13:19, 14 November 2011 (UTC)
  • As an OTRS agent, I have dealt with requests that relate to no project and several projects. I don't see myself as a Commons agent or Wikipedia agent. The agent needs enough good judgement to only lock tickets they have the skills to address competently, whether they are an admin in any particular project is not as important as language skills or understanding of policies and copyright. It's pretty easy to ask an independent project admin for assistance with a ticket when needed. Having more OTRS volunteers with good communication skills is far more important than having a mop of a certain colour. TBH, some admins of great experience would make for dreadful agents. -- (talk) 22:56, 16 November 2011 (UTC)
    Those are fair points, but Commons adminship is relevant because it enables OTRS agents to look at Commons deleted material, and to restore it if necessary. This was discussed more in the original section. Remember, these proposals do not at all affect who gets OTRS access, which is covered by OTRS admins' screening process, which explicitly says "Must not have a history of biting newcomers",, among other things (m:OTRS/info-en recruiting). Bottom line, we should encourage OTRS agents to get access to relevant tools, and that includes Commons adminship. In addition, we should try to encourage more people who are suitable for OTRS to volunteer, especially if they already have undergone the screening involved in getting sysop rights on a Wikimedia project (as m:OTRS/info-en recruiting mentions). Rd232 (talk) 23:09, 16 November 2011 (UTC)
    With regard to sysop rights, it is often overlooked that this is not a requirement for OTRS volunteers. I was not an admin anywhere when I started helping with OTRS. There may be an rationale that OTRS is a great proving ground for good admins. -- (talk) 23:00, 17 November 2011 (UTC)
    Fine, but I already said Bottom line, we should encourage OTRS agents to get access to relevant tools, and that includes Commons adminship. Granted, we shouldn't overlook the agents that don't yet have any sysop rights, but I was thinking of the lower-hanging fruit of agents who do (lower-hanging because there's more evidence of trust - not just OTRS, but OTRS+sysop). But there's no reason not to consider both cases. So where does that leave us in terms of practical action? Rd232 (talk) 23:39, 17 November 2011 (UTC)
  • I'll go ahead and contribute as someone who is a enwiki admin, but not here. There are a substantial number of tickets that I can't directly/conveniently help out with because of the lack of tools. (Disclaimer: I haven't done a whole lot with OTRS recently, I've been quite busy). The level of participation/etc requested/required in a commons admin seems very broad to me, and I'm not really sure what would need to be done to get it. Although the default inclusion of tools to OTRS agents is opening a huuuge can of worms, I do not see a problem with taking OTRS into account with an RfA. (admittedly, I would be affected) Just as administrators on other projects in enwiki can gain tools if they have a clear purpose, but do not meet the "requirements" NativeForeigner 토론 (talk) 09:18, 21 November 2011 (UTC)

Commons standard icon set

Irony: a multilingual image repository which doesn't use icons to support its user interface.

Proposal: develop a standard, high-quality icon set which can be used across Commons to support communication across our multilingual userbase (and also look more modern and friendlier).

Details: the MediaWiki interface is largely text-based, and that's probably difficult to change, both in technical terms and in terms of getting community consensus. I'm envisaging use of the standard icon set primarily in templates, and possibly by gadgets. It should be possible to use CSS to create a gadget which gives users the option to hide all icons. It's worth considering whether the set could fit into Commons:Project Nuvola 2.0+. Addendum: The development of this set should probably take place via a WikiProject, say Commons:WikiProject Standard Icon Set.

Some existing icon use:

Some examples of icon ideas:

  • Files under discussion: Disputed image.svg
  • Icons for the 3 types of deletion process: speedy (i.e. more or less immediate), ordinary by discussion, and "deletion tagging" (delete if tagged for 7 days)
  • File move: File move icon.svg
  • Help Desk icon
  • Gallery icon
  • Category icon
  • Video/Audio/Image icons

Rd232 (talk) 21:53, 16 November 2011 (UTC)

Discussion
  • I would like to banish the term "file move". Of course MW calls it move but changing the title is actually only renaming. Therefore I suggest an icon like Rename.svg or Textfield rename.png or Farm-Fresh textfield rename.png maybe combined with an image in the background. -- RE rillke questions? 12:57, 18 November 2011 (UTC)
    • "Renaming" makes a lot more sense for the average user, yes, so maybe we should try and phase "file move" out. On the other hand, the same is true of "moving" articles and galleries - that should just be "renaming", really, and we should be consistent with the terms. "Moving" is very well established in MediaWiki and Wikimedia websites and it won't be easy or quick to change. It should also be a separate thread, please! We can always change the icon later if/when the term is changed. Rd232 (talk) 14:40, 18 November 2011 (UTC)
  • Irony continued... Discussing icons without discussing the purpose and placement of these icons? Example: you propose a "Files under discussion" icon Disputed image.svg. What does it mean? Where should it appear: template on file description page, template on file talk page, on Special:ListFiles, or even Special:Contributions etc. - ?? NVO (talk) 08:38, 20 November 2011 (UTC)
    </irony> As you can see from the previous line, the proposed Nuvola-style symbols don't scale down well. So it makes sense to declare scope first: either it's about small icons, fitting standard text line (like Symbol support vote.svg Support), or larger icons to fit boilerplate boxes. NVO (talk) 08:45, 20 November 2011 (UTC)
    ? Inline templates like {{support}} use 15px voting symbols. Most other uses of icons are in the 36px to 50px range, with some of the SVG ones occasionally scaled up more as decorative images. So what? Either (a) there is no overlap between inline use and other use, and scaling is irrelevant (b) there is some overlap, and some icons that don't scale down well might have to be modified for smaller sizes, either to produce one simpler version or a simpler version for the small size. I think A is largely the case because we don't want an overproliferation of icons in textual discussion, but it doesn't need to be worked out until we get down to actual per-icon detailed discussion, which should not be here, because it'll take far too much space; it should probably be a WikiProject. Basically, I don't know where you see a real problem. Also, your phrase "the proposed Nuvola-style symbols" is technically wrong; I'm not proposing any specific icon style, only that a standard set be established, possibly being redesigned from the ground up. That might go with Nuvola style or it might not; though in the absence of any resistance to it, I'd lean to Nuvola. COM:ICON (work in progress) attempts to collect current use of icons. Rd232 (talk) 12:29, 20 November 2011 (UTC)
    I've added a reference above to Commons:WikiProject Standard Icon Set; I hope that makes things slightly clearer. Rd232 (talk) 12:56, 20 November 2011 (UTC)