Commons:Village pump/Proposals/Archive/2014/08

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

Renaming chess symbols

I find that the naming convention adopted in Category:SVG chess pieces/Standard and subcategories isn't fully consistent: e.g. for dots and crosses, the first letter represents the foreground color ("o" for white, "x" for black), while the second one represents the type of symbol ("o" for dot, "x" for cross). Almost the same for numbers. Instead, for "standard" chess pieces, the first letter is for the type, and the second one is for the foreground color ("l" for white, "d" for black, "r" for red, etc). I propose to rename those files, e.g. File:Chess olt45.svg should be a white dot on a transparent background, File:Chess xdl45.svg a black cross on a light background, File:Chess 7dt45.svg a black "7" on transparent background, etc. --Ricordisamoa 09:41, 10 August 2014 (UTC)

New group: Deleter

Reasoning: Admins are constantly overbooked on Commons. For the deletion-requests and speedydeletions we need some users with experience and time. See also Commons:Village_pump/Archive/2014/07#More_admins

  1. The sysop-usergroup allows far more dangerous changes than deleting a file.
  2. WMF will not allow displaying deleted content to a wider user-group for legal reasons.
  3. Viewing deleted text is not so useful on Commons and may raise privacy-concerns.

Rights to include:

  • autopatrol: Have one's own edits automatically marked as patrolled
  • delete: Delete pages
  • deletedhistory: View deleted history entries, without their associated text
  • rollback: Quickly rollback the edits of the last user who edited a particular page

This user group should be assigned after a community election like it is currently done for image-reviewers (asking a few questions, ...) and should be removed after inactivity (6 months no deletion) or doubtful behavior.

  Voting: Support

  • Editors don't participate because the deletion process tends to be a hostile battleground for all parties involved (from uploaders, to nominators, to commentators, to closing admins); contentious/controversial topics, grudge matches, and witch hunts run rampant and unchecked at DR. In light of this, un-bundling the tools isn't a solution, in fact, it doesn't even come close to addressing the heart of the problem. -FASTILY 22:27, 24 July 2014 (UTC)
  • One issue is possibly that several contributors believe all DRs should be closed within the same time span and call it backlog if they are open after a certain date. This is just a guess and the topic deserves analysis: Why is it a hostile battleground? If we do not know it for each of the involved parties we can't improve. -- Rillke(q?) 07:39, 25 July 2014 (UTC)
  • Causing DoS or whatever by doing nifty script changes, instructing users to provide their passwords on their user page, …, blocking users, messing with upload campaigns overwriting highly visible file with inappropriate content (heh, that actually works without even getting any right at Commons). Sure, these deleters need as much trust as admins now need but they won't have that complexity of administration.
  • I recommend IRC; did you ever delete an important file accidentally? Never seen that. -- Rillke(q?) 19:43, 27 July 2014 (UTC)
  • Is there additional complexity by the sole existence of further buttons which are going to be never used (nor seen)?
  • Mostly in DRs, the buttons are quite close and I observed a couple of false deletions. (Less than ten, if I remember correctly but it happens). --McZusatz (talk) 22:07, 27 July 2014 (UTC)
  • Fair enough. Not so sure, perhaps it's just the expectation of contributors that an admin should be able to help out with all of them. Just prefer the principle having only those rights that one is going to use. -- Rillke(q?) 22:18, 27 July 2014 (UTC)
  • Providing limited stepping-stones to become a full admin seems like a good idea. It might also be a good idea to make this a time-limited right, e.g. it could be granted for one year at a time. That would make it less risky than granting someone full admin rights. Thoughts? Kaldari (talk) 19:13, 31 July 2014 (UTC)

  Voting: Oppose

  • We just need more admins in general. Not more usergroups. Plus deleting stuff is most of the adminwork anyway. Natuur12 (talk) 17:37, 23 July 2014 (UTC)
  • The initial post that spawned this was not particularly well thought out. Category:Media uploaded without a license as of 2014-07 has 700+ files, with 90%+ likely copyvios? So people need to go through and either add a license or a {{Copyvio}} template (Category:Copyright_violations is very well tended). That does not require admin rights. This, like most other backlogs, is a result of lack of participation in general, not lack of admins. Besides that, if someone can be trusted to delete files and to view previously deleted files, they can be trusted to block. There is no need for this decoupling. Эlcobbola talk 18:11, 23 July 2014 (UTC)
  • --Krd 18:16, 23 July 2014 (UTC)
  • Anyone I'd trust with deletions I'd trust as a full administrator. My thoughts are largely the same as Natuur12's on the matter, but would add that I feel deletion (and the ability to view deleted files) should be considered significantly more sensitive of a right to give out than blocking. Blocks are comparatively rare, and blocks of active users are much more heavily scrutinized than deletions of actively used files. Sven Manguard Wha? 20:49, 23 July 2014 (UTC)
  • Per Sven Manguard and Эlcobbola. More useful would be recruiting more admins, especially with certain language skills Com:ABL. --Hedwig in Washington (mail?) 03:42, 24 July 2014 (UTC)
  • Per Natuur12, Эlcobbola, and Sven Manguard. --AFBorchert (talk) 06:49, 24 July 2014 (UTC)
  • Per above. Lack of participation is obviously the problem here, and frankly I can hardly blame people for that. -FASTILY 10:53, 24 July 2014 (UTC)
  • Per Natuur12, Эlcobbola, and Sven Manguard. if someone is trusted enough to handle the deletions, they can be nominated for adminship.  ■ MMXX talk 23:28, 24 July 2014 (UTC)
  • I agree with others above. If someone is trusted enough to delete files, I see no reason not to give her/him the full admin rights. Regards, Yann (talk) 05:33, 25 July 2014 (UTC)
  • Originally I was going to support this, but the arguments on the oppose side swayed me. I think that the real problem here is that we don't have enough administrators. I agree that anyone trusted enough to be given deletion rights ought to just be made an admin. (Also agree that admins with language skills other than the common European languages ought to be recruited more!) Zellfaze (talk) 23:34, 28 July 2014 (UTC)
  • Files are the most valuable content we have on Commons (not users or system messages). I would support giving OTRS members the ability to restore files and view deleted content for practical reasons.    FDMS  4    10:02, 29 July 2014 (UTC)
      • The WMF has said (I have no idea where, though) that access to deleted content requires a community vote in an RfA or RfA like process. That being said, I'd be happy to support just about any current OTRS member with photosubmission or permissions-commons queue access at an RfA, so long as they're at least moderately active on both OTRS and Commons. Sven Manguard Wha? 05:41, 30 July 2014 (UTC)
  • Ditto anyone I'd trust with file deletion, I'd trust with full adminship.--KTo288 (talk) 20:44, 14 August 2014 (UTC)

  Discussion

  • Though the proposal really makes sense due to the stated points (privacy and legal reasons), I highly doubt that the burden on the current Administrators is lowered. In fact, we need more people searching for license-violations than the ones clicking a single button of some hacky semi-automated tool. I'd rather appreciate it if mass deletions of files in Category:Copyright_violations kept the precise reason for deletion/nomination. E.g. File:Louis Koo.jpg (reason is not transparent/public and only visible to admins) and File:Clara Alonso 2014-07-23 23-28.jpg (reason is given via the source and publicly available in the deletion log) --McZusatz (talk) 19:57, 23 July 2014 (UTC)
Those examples and your critique is spot on, but that should be addressed by rules stating the contents of deletion entry longs, not by limiting who has the delete right. -- Tuválkin ✉ 20:20, 23 July 2014 (UTC)
  •  Question I would appreciate a more detailed explanation of why deletedhistory would include looking at deleted files, but not the deleted text. If this were intended to be used for image pages, I doubt there would be many non-oversighted privacy issues that someone trusted with a deletion right would be unable to handle. Note that I have had deleted text pages dumped off-wiki to avoid them being restored on-wiki when there were reasons for me to examine them for potential copyright issues, which seemed a bizarrely clunky solution compared to me being able to look at the same deleted material on-wiki without restoring it. --Fæ (talk) 11:39, 24 July 2014 (UTC)
    • deletedhistory does not include looking at deleted files nor does it allow viewing deleted text. All it allows is viewing the list of deleted history items including author and summary of each item unless they are hidden or suppressed. -- Rillke(q?) 12:21, 24 July 2014 (UTC)
      • This does not seem very different from the current set up if we intend to help people investigate copyright issues, as opposed to just closing DRs, which non-admins can already do in theory, but hardly anyone can see the point.
      I find some of this discussion a bit disheartening, some of the previous comments are starting to make me wonder why non-admins would make much effort to add opinions to DRs, apart from the most controversial ones. I used to do much more DR work than I do now, and not being an admin is a significant part of that, as it would be hard work arguing the case for seeing deleted material or having it explained second hand through another's eyes. If the answer is that really DRs are a domain of administrators, then we ought to be honest about it and be looking to double the number of active admins so that DRs can be handled by a much wider team than the current situation, where most deletions (both DRs and speedies) (80%?) are done by about three people in any month. It's a situation prone to natural systemic bias as there is such low diversity of viewpoint. --Fæ (talk) 12:34, 24 July 2014 (UTC)
  •  Info Now it becomes another relevance by the new group "Superprotectors" meta:Requests for comment/Superprotect rights (implemented and used in 24h). So we can also for sure create as natural balance a new Deleters group. → User: Perhelion (Commons: = crap?) 00:26, 11 August 2014 (UTC)
  •  Comment Just as with uploads and categorisation we now have bots to aid us, I think its now time to consider a deletion bot, we can experiment first with those files tagged for procedural deletions i.e. Category:Media without a license, Category:Media missing permission, and Category:Media without a source. If this first stage works out, and the bot doesn't go all Terminator on us, we can consider creating a {{Procedural deletion}} template for files which are not in use, the template would add a file to the list of files that will be bot deleted say every 7 days, with the community being encouraged to scrutinise that list for those which do not belong and convert these into DRs. I don't know if its possible to code for this, but I envisage granting the ability to tag a file with this template as an automatic user right, that is granted to every User who has achieved a minimum of say a 1200 edits and 3 months with no blocks or warnings. The right would be forfeit and removed for example, if a user repeatedly tags files which are kept after a DR. I don't know if our community can sustain it now, but this relies on going back to the wiki ideal of believing in the crowd, that we as a community of users, rather than as individual deleters, can identify files that need to be deleted, and we as a community can identify those files that have been wrongly marked for deletion--KTo288 (talk) 22:27, 14 August 2014 (UTC)

Category moves

Commons allow to move category pages through "move" bookmark at the top bar of the page. This way have some advantages (the history of the category page is kept, the text shouldn't be copied, the interwiki connection is corrected automatically). However some issues should be thought-out still.

  • The old category should be soft redirect {{Category redirect}} by standard rules. However, this way makes hard redirect from the old category. (P.S.: seems to be treated by RussBot --ŠJů (talk) 15:46, 14 August 2014 (UTC))
  • As I know, no bot corrects "commonscat" (P373), "commonsgallery" (P935) and "image" (P18) etc. properties in Wikidata when the Commons page is moved.
  • Would be possible to integrate Cat-a-lot script into the page-move process to allow to move the category page with all contended pages (files, subcategories and galleries) together by one click? --ŠJů (talk) 15:17, 14 August 2014 (UTC)
I was already working on something like that on MediaWiki:Gadget-catMoveLink.js but found that one of the libraries I wrote was trash and didn't work. -- Rillke(q?) 16:43, 14 August 2014 (UTC)
#1 would be fixed by this change. --Ricordisamoa 11:11, 16 August 2014 (UTC)

3D printing files and 3D rendering files

A next logical step for Wikimedia Commons is to host files containing public domain 3D printing instructions, which would allow a user to "print" an object serving both educational and utilitarian purposes (a working model Geneva mechanism, for example, or a scale model of the Nefertiti Bust). This technology is nascent, but rapidly increasing in both quality and availability (much like computers themselves in the past few decades). This is an opportunity for us to lead the curve on making educational models available, so let us begin discussing how such media will be presented and made available to our users. Cheers! BD2412 T 14:11, 8 August 2014 (UTC)

This isn’t going to happen until there is the code necessary for rendering those files to check them for copyright violations quickly. That code then needs security review and so on. So if you are excited to write an extension, have a look at MediaWiki.org -- look for existing stuff and if nothing exists you'll have to write it on your own or find someone doing this for you. We do not only need files for 3D printing: See COM:UNSUPPORTED. -- Rillke(q?) 15:06, 8 August 2014 (UTC)
I'm not a coder, but I know some people who are. We'll talk further when I get home from Wikimania. ;-) BD2412 T 22:05, 8 August 2014 (UTC)
@BD2412: We can also just talk at Wikimania. Most of the time I'll be in the garden room, you can meet me there for sure from 18:00 to 21:30. -- Rillke(q?) 09:42, 9 August 2014 (UTC)
Good. As long as you're here, talk to Paul Sohi at the Makeversity table. He does 3D printer files, and tells me that there's a website called Thingiverse where people upload files under various licenses (apparently some PD and the vast majority some kind of CC). That's exactly what I think we should be aiming for. We should also, by the way, be making/hosting 3D object rendering files which allow the user to look at an object from different angles. There are many open source programs for such renderings. Cheers! BD2412 T 12:29, 9 August 2014 (UTC)

So now I am led to understand that Wikimedia already has 3D rendering display capability, and just needs files? Or does it need something else in between the model and the display? BD2412 T 12:25, 10 August 2014 (UTC)

Huh, how did you come to this understanding? -- Rillke(q?) 12:51, 10 August 2014 (UTC)
I went looking for you in the Garden Room and ran into another group of Wikimania attendees. I ran into a subset of them again later in the hotel bar, and one of them (I wish I know who) told me that. It should not be too hard to confirm. BD2412 T 21:57, 10 August 2014 (UTC)

What do we need in order to have something like this in an article? BD2412 T 16:32, 12 August 2014 (UTC)

Erm … Commons is repository for media files – content –, not for printing instruction files – software –, and it has a specific scope …    FDMS  4    13:30, 18 August 2014 (UTC)

Putting aside the software issue for a moment, I presume that the 3D image renderings count as content. I'm told by the experts that the difference between a 3D graphic rendering file and a 3D printing file is largely where you send it (i.e. if you send it to your computer screen, it is a 3D viewable file, and if you send it to your 3D printer, it is made into a physical object). So, why not lead in providing access to the files, for instructive purposes? BD2412 T 13:59, 18 August 2014 (UTC)
Ah, right, 3D image renderings sounds far better than printing instructions :) .    FDMS  4    17:11, 18 August 2014 (UTC)
With the right software (which Wikimedia might already have), we can have a 3D rendering suitable for inclusion in an article, so that the reader can look at many-sided shape or object from any angle they choose. If this happens to be translatable to printing the shape, so much the better. BD2412 T 18:15, 18 August 2014 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2014/08&oldid=296807272"