Template talk:Deletion requests/Archive 2

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.

Watermarks

What is our position on watermarks and copyright notices superimposed or imbedded in images? (e.g. Image:Oleifera Antanimieva.jpg).

I don't like them. But should we tolerate them? — Erin (talk) 02:23, 31 July 2006 (UTC)

Hmm that's a mild example compared with Image:Crayfish-Astacus astacusP1002890.JPG, where it's in the middle of the picture. I'd say we at least discourage them, author information could easily be embedded within EXIF tags or something like that, there's no need to deface the image itself. Furthermore, I'd say Commons isn't responsible for the way images are used later on, almost all licenses used here require attribution of some sort so watermarking shouldn't be encouraged. I however, as you, couldn't find any policy on this, so for the moment we'd have to (grudgingly) accept this. NielsF 02:35, 31 July 2006 (UTC)
From Commons:Manipulating meta data:
Visible tags or watermarks inside images are strongly discouraged at Wikimedia Commons. So information like "Mr. Foobar, May 2005, CC-BY-SA" shall not be written directly in the image but in EXIF fields, which is technically even superior. The reasons are:
  • We don't tag our Wikipedia articles with our names in a prominent way inside the article text in order to step behind the work and let it speak for itself, the same applies to the images (stepping behind own work and thus reducing personal vanity is crucial for neutrality).
  • Reusage of images with these signatures for example for printing purpose gets limited by personal tags like at collage posters and in books (as in books you always have the copyright information in the image caption or at the end of the book and thus it would produce unprofessional duplications in page layout and would also be unfair compared to the article authors credit).
--Matt314 07:20, 31 July 2006 (UTC)
Yes we should tolerate, but discourage, them. Again, it's not our job to mandate which version of an image a project should use. But once someone creates an unwatermarked version, I think that project is going to have a pretty easy choice to make. pfctdayelise (translate?) 10:44, 1 August 2006 (UTC)
So, looking at Image:Oleifera Antanimieva.jpg, should I crop off the copyright notice and reupload? — Erin (talk) 12:19, 1 August 2006 (UTC)
Well actually where is the permissions info for that image? Is it on OTRS? It should be linked on OTRS or through a talk page or something. Kinda wonder if that author really understand what they've agreed to. If it's legit, and you can really be bothered, I could just crop it. I guess the golden rule is: if anyone disagrees, revert and upload separately. pfctdayelise (translate?) 14:11, 1 August 2006 (UTC)
Oh, I really have to disagree with the "upload separately" part. Commons has enough duplicate junk already! I believe that for each image we should reach a consensus as to what the optimum version is, and go with that version. I have now cropped off the copyright notice. If anyone disagrees, please simply revert and do not create a duplicate. — Erin (talk) 01:23, 2 August 2006 (UTC)
Well, in case you hadn't noticed, there is totally zero consensus that that is the right approach. The approach you describe is not policy at all. "Duplicate junk" doesn't hurt anyone (it doesn't ruin categories, and we're not running out of disk space) and at least keeps the peace. Commons has no mandate to decide which version of an image should be used. Therefore making both (or all) versions available and letting the projects battle it out is appropriate, which is what should happen with alternate uploading. I wish you'd rethink this "alternatives are evil" approach.
If you'd go to the trouble to crop or otherwise modify an image, it seems reasonable that that's because you want it available or you want to use it. So most people are not going to happy with your suggested course of action and instead we get angry upload-revert wars. --pfctdayelise (translate?) 02:45, 2 August 2006 (UTC)
That's a sort of lowest-common-denominator, unprofessional, lack-of-direction sort of approach to organisation. — Erin (talk) 11:28, 2 August 2006 (UTC)
Exactly. Are we professional? No. We don't even have the volunteer force to pretend to be. What is our main goal here? Organisation? Serving the projects? Organisation that helps us serve the projects, or organisation for its own sake? Like organising the sock drawer by alphabetical colour...
The abrasive, my-way-or-the-highway sort of approach actively causes us (Commons) grief and enemies and bad reputations among the local projects. The whole concept of Commons kinda doesn't work unless we have everyone on-side. It only takes a couple of people to have a bad encounter with this "stiff shit, deal with it" authoritarian attitude, and the next thing you know people are boycotting Commons and asking to go back to local uploads. It doesn't matter if we think they're crybabies because they're so attached to GIFs, or watermarks, or anything else. It's not the point. The point is: the only thing we have a mandate on is enforcing copyright. When a dispute exists, creative choices, however minor, are not for us to enforce the final word. --pfctdayelise (translate?) 12:37, 2 August 2006 (UTC)

(reset indent) en-wiki has Template:Imagewatermark. I suggest we create something similar here. howcheng {chat} 22:12, 3 August 2006 (UTC)

Well, we simply don't have that policy. If another project (of the dozens of others!) find that a particular image with a watermark is absolutely vital and they insist on using it, as long as it's freely licensed, who are we to stop them? That is up to their individual projects' image use policies. If there's no copyright problem, and a Wikimedian wants to use it, we should host it. I don't find watermarks to be cause for exception to that. pfctdayelise (translate?) 02:39, 4 August 2006 (UTC)
Yep, I agree with that. / Fred Chess 09:13, 4 August 2006 (UTC)
I think that this would be a good thing to try to come up with a consensus policy on. A discrete watermark may not be a problem, but what about Image:L1000666.JPG (and other image uploads by the same user), where the address of a website (apparently unrelated to the image) is emblazoned across the photo. Commons:Project scope says that "Media files that are not useful for any Wikimedia project are beyond the scope of Wikimedia Commons", surely plastering the address of a website across an image has the effect of making that image not useful for any Wikimedia project. --JeremyA 23:47, 4 August 2006 (UTC)
Something like "watermarking of images is discouraged, however watermarking that renders images unusable when the watermark has been removed is prohibited"? No project would ever use that image (the 1000666 one)... 00:12, 5 August 2006 (UTC)
If two images are identical, except that one has a watermark and the other does not, isn't the non-watermarked version always preferable? Image watermarks are only against policy in the English Wikipedia if they are user-created images; for images found elsewhere that contain watermarks, the Template:Imagewatermark tag is simply a request for a non-watermarked alternative. It seems that such a request is reasonable on the Commons too, even though we don't have a specific "no watermarks" policy. —Bkell (talk) 22:23, 5 August 2006 (UTC)
IMHO a good picture with a d*mn ugly watermark is better than no picture, but it surely should inspire somebody with a camera to make a better photo without. Eventually the marked pic could get some subst'ed template saying like "This picture might be deleted once Commons get another good one without watermarks" or some other "soft warning". G®iffen 22:27, 5 August 2006 (UTC)
Something like {{Convert to SVG}} and subsequently {{SupersededSVG}}? Anyhow, I've created a sample template at User:NielsF/Watermark:
Watermark Crown CA.jpg This image contains digital watermarking or credits in the image itself.. This image (or all images in this article or category) should be adapted by removing the watermark. The usage of watermarks is strongly discouraged according to policy. If a non-watermarked version of the image is available, please upload it. After uploading the non-watermarked version, replace this template with template {{superseded|Image:''new image name.xxx|image without watermarks}}

العربية | català | čeština | Deutsch | Ελληνικά | English | español | eesti | فارسی | suomi | français | galego | עברית | hrvatski | magyar | italiano | 日本語 | македонски | മലയാളം | Plattdüütsch | Nederlands | polski | português | română | русский | slovenščina | svenska | ไทย | українська | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

Slight adaptation of Template:Convert to SVG and en:Template:Imagewatermark. Feel free to edit and or improve as I'm not the best template editor ever (understatement). NielsF 23:34, 5 August 2006 (UTC) (edit: have substed the template and outcommented category as using it here put it into the non-existing category:Images with watermarks. NielsF 00:16, 6 August 2006 (UTC))
I don't have a problem with NielsF's template, it looks like a good solution. pfctdayelise (translate?) 00:12, 6 August 2006 (UTC)
I don't think it makes sense to say we have a "policy" to "discourage" anything. "Policy" is by definition yes/no enforceable, not a preference. (Clever use of image though :-) ). Stan Shebs 05:31, 6 August 2006 (UTC)

It is a terrible solution. It creates potentially huge amounts of work for admins. New versions should be uploaded over old versions. Creating a new file name forces admins to check usage on all projects to transfer usage to the new name before deleting. Unless of course the intention is to leave the new image as unused clutter... oh my god I bet that's it. I give up. — Erin (talk) 03:17, 6 August 2006 (UTC)

Agree. Reword the proposed template to recommend that the non-watermarked version be uploaded with the same name as the old watermarked version. —Bkell (talk) 20:29, 6 August 2006 (UTC)
I am not against that either, as a recommendation and not an iron rule. I wrote: if anyone disagrees [with uploading over the top], revert [to the watermark version] and upload separately. Is that not a simple process to keep everyone happy? pfctdayelise (translate?) 08:25, 7 August 2006 (UTC)
Yes, it will keep everyone happy who is possessive about their version. It will make everyone despair who wants a coherent, junk-free body of useful and properly-labelled material. Let's adopt your proposal on Wikipedia too, with a boiler plate like the following:
Split-arrows.svg This article contains a typo or factual error. Please rectify the error and paste the corrected text into a new article with a slightly different title. For example, paste a corrected version of w:George W. Bush at w:George Walker Bush or w:George W. Bush2.

Whatever you do, please don't just edit the article under the original title. Someone might not like their article being messed with. Try to keep everyone happy, even if it means that multiple versions of virtually identical articles or images coexist in a chaotic fashion.

Remember, we are not professionals; ergo we ought to be disorganised and amateurish in our approach.


Erin (talk) 02:03, 8 August 2006 (UTC)
Ideally of course people would be as non-possessive of their graphic contributions as they are of their text contributions. But in reality most people are not. Most people are very posessive and get a lot more upset about seemingly trivial changes such as crops, colour balances and other attempted enhancements. That is just the reality that causes countless frictions and upsets here.
So, good luck trying to change that attitude en masse... what will happen is: most people will remain posessive, and in the end just be upset and angry at Commons as well. Good solution! As long as we're right, that's all that counts! pfctdayelise (translate?) 04:12, 8 August 2006 (UTC)
I do not believe that there is any evidence to support your belief that there is something about media contributions that causes more possessiveness than text contributions. Take a look at Wikipedia. It is text based. It is riddled with battles over content. Hundreds of articles are tagged as being the subject of a conflict. When people's edits are reverted for whatever reason, they re-revert and re-re-revert. Possessiveness is so ingrained in users that policies (see w:WP:OWN) have been drawn up specifically to combat this mindset and mandate non-possessiveness. POV-forks are specifically banned, and all users are mandated to keep articles together and abandon ownership. Other policies (w:WP:3RR) are designed specifically to punish people for reverting to their version, and several blocks have to be set every day to enforce this.
In contrast, Commons is fairly harmonious. I say that all this is more than enough to counter the idea that people feel possessive about images and not text. The reality is that people feel possessive about everything. It is human nature. And like other negative aspects of human nature (e.g. violence), laws and regulations must exist to prevent a descent into chaos. Wikipedia is older than Commons, and so it has had more time to encounter and subsequently counter problems. For example, I remember the halcyon days of innocence when there was no Three-Revert Rule. This youngster we call Commons still has a few areas in need of regulation. One such area is possessiveness. Like Wikipedia, we need a policy that specifically recognises that we all get possessive at times, but that this is a tendency to be combatted, rather than ceded and pandered to.
If I edit a Wikipedia article, and someone comes along and condenses my paragraph, I tend to get annoyed. But do I start demanding the right to keep everyone happy by creating multiple version of the page? No, I look at the edit and decide whether it was an improvement or not. If it is a clear improvement, I simply leave it. If it is a clearly destroying what I had written, I simply revert it (especially if it looks like vandalism). If it doesn't make much difference, I simply leave it. If it is unclear whether it is an improvement or not and dialogue is needed in order to reach a consensus about the best version, then I go to the talk page to discuss it.
It is almost exactly the same on Commons. If someone crops one of my images, I look at the edit and decide whether it was an improvement or not. If it is a clear improvement, I simply leave it. If it is a clearly destroying what I had created, I simply revert it (especially if it looks like vandalism). If it doesn't make much difference, I simply leave it. If it is unclear whether it is an improvement or not and dialogue is needed in order to reach a consensus about the best version, then I go to the talk page to discuss it.
On Commons there is a further option: If the edit turns the image into something quite different (e.g. it turns a panorama into a close-up) and both the new and old images have quite different and useful purposes, then I will take one of the versions and upload it under a different name. It would be insane, however, to do such a thing with images like Image:Oleifera Antanimieva.jpg.
In conclusion, pacifying possessive people who don't understand how to work co-operatively is no way to "keep everyone happy". That sort of pandering to people's worst instincts may well please people with the worst instincts, but it drives away people with the best instincts. Your comments at the top almost convinced me that there was no consensus for not creating junk on Commons. If you had managed to persuade me that Commons participants were that muddle-headed, I would have had to abandon the project, just as I have half-abandoned Wikipedia due to all the nonsense there. — Erin (talk) 05:26, 8 August 2006 (UTC)
You want Commons to be a "coherent, junk-free body of useful and properly-labelled material". Hmmm... I find this to be utopian, and it has also not been main a priority as far as I know.
Fred Chess 13:21, 8 August 2006 (UTC)
To Erin: you make some good points and I think that probably developing a strong Commons:Ownership policy would be a good start, and actions regarding watermarks would simply fall out from there. I still feel that there is a fundamental difference between authoring text and authoring media/art. Media generally cannot and is not authored in the piece-meal way that articles are. There's a good reason we have no template saying, "This image is a stub. Feel free to expand it". "Versions" are much more clearly defined for media than for text, to the extent that for media, the versions (ie. the history) all appear on the image page itself, not hidden in an "uploads" tab. Furthermore authorship is much more clearly defined and identified for media. Almost all media contributions have something that say: this one person is the author, the creator. (Well, ideally they do.)
All our licenses must allow the creation of derivative works. That doesn't mean: you can create a derivative work and treat it as if it was the work itself, ie. upload over the top.
Of course in many situations we would want that to occur. The point I want to make is that according to the licenses, the original authors always have the right to veto the treatment of the derivative work as the original, i.e. insist on a separate upload. (Call it the author's "right to revert".) If we want to make it so that according to our site policy they don't have this right (ie "be aware that your work may be mercilessly edited"), well, that's a separate thing. Personally I wouldn't support that. For example on COM:FPC I have seen lots of cases where original authors have vetoed seeming colour "improvements" because they feel the "improved" version doesn't reflect the reality that they captured. And it's good that editors have in those cases been working constructively together and accepted their reasons.
So, I think we're almost on the same page now... if we can write a page Commons:Ownership, promote it as policy, and then whoever wants to can start aggressively hunting down watermarks... go ahead. pfctdayelise (translate?) 06:43, 9 August 2006 (UTC)

I wonder... If it's not okay to delete a duplicate image with a watermark, is it ok to add duplicate images with a watermark? Say, if I added a watermark to a random file just because I can? -Samulili 14:56, 8 August 2006 (UTC)

Yep, according to their logic that image would stay in order to keep you happy. Deleting the junk you had created would be "utopian". People on vandalism patrol should probably also be told they are "utopian". — Erin (talk) 22:18, 8 August 2006 (UTC)
Very constructive... Anyhow, even though I invited everyone to change the template I had in mind, nobody did, so I guess I'll move it to mainspace soon ;-). Just kidding. IMHO (and I'm repeating myself) watermarking should be extremely discouraged, so overwriting the file is ok with me. Can't be bothered to change the proposed template myself... Samulili, of course it shouldn't be allowed to change existing images and add a watermark, we're discussinghow to treat existing and future images with one. NielsF 03:43, 9 August 2006 (UTC)
Just to let you know there's another option possible: I tagged most of my maps (one of them is featured, BTW) with a copyright notice in the far top right corner and released them under GFDL. At the same time I also included information that other licenses are possible and... uploaded a multi-layer source file so that anyone could remove the tag if they don't like it. And the source file is of course linked from all derivative images. Halibutt 09:53, 9 August 2006 (UTC)
Your copyright notices are unobtrusive and so I would probably not bother removing them, even though they may be technically against policy. You have also made them easy to remove. What I really hate are watermarks that ruin the image. — Erin (talk) 00:51, 10 August 2006 (UTC)

Does anybody read the GNU FDL? Copyright notices may not be deleted! --Historiograf 00:35, 16 August 2006 (UTC)

Are you sure? In that case, if someone accidentally tags an image with {{GFDL}} {{GFDL}}, and someone else comes along and corrects it to just {{GFDL}}, then the second person is in violation of the GFDL.
I don't believe that this is the case. I believe that superfluous copyright notices can be removed. — Erin (talk) 04:59, 16 August 2006 (UTC)

A different approach, red cross

By request from English Wikinews, I tried a different approach for deletion of images, when I deleted the images from Vigeland Sculpture Park. Instead of orphaning them from articles, I uploaded a red cross, deleted the original image, and rewrote the img descr page to reflect the deletion. For example see Image:Vigeland monolith terrace couples.jpg.

For admins, it is a lot easier to do it this way, because orphaning an image takes 1-2 minutes / page (if everything is optimal, the toolserver isn't lagging,etc ); most images were used on around 10 pages , there were 18 images , so the total time would have been 270 minutes or 4,5 hours. Now it took less than 30 minutes.

Fred Chess 11:08, 11 August 2006 (UTC)

Do you use a template to insert the multilingual text? --ALE! ¿…? 08:22, 15 August 2006 (UTC)
I am copy-pasting User:Fred chessplayer/Translations, which is in turn a modified version of user:Pfctdayelise/Translations. But putting it as a temple would be good idea! / Fred Chess 08:35, 15 August 2006 (UTC)

Model releases

Now, when we ask for a model release, exactly what permission needs to be given?


I can think of seven different levels of permission:

  1. unacceptable No permission?
  2. unacceptable Permission to take the photograph?
  3. maybe Permission to take the photograph and show it to people?
  4. maybe Permission to take the photograph and display it fairly publicly?
  5. maybe Permission to take the photograph and display it on the Internet?
  6. acceptable Permission to take the photograph and display under a free licence that will allow it to be legally disseminated across the web and elsewhere?
  7. acceptable Picture of oneself?

Here are some examples of situations were varying levels of permission are tacitly or explicitly given. In each case except the first, the person deliberately poses for the photograph and understands why it is being taken.

  1. unacceptable Person takes picture of someone without their knowledge.
  2. unacceptable Person takes picture of lover in bed for them both to look at later.
  3. maybe Person takes picture of sibling whilst sightseeing, and adds it to the family album in order to show it to people.
  4. maybe Person takes picture of friend for the school magazine.
  5. maybe Person takes picture of friend to post on a blog.
  6. acceptable Person takes picture of friend for a Wikipedia article.
  7. acceptable Person takes picture of self for a Wikipedia article.

Levels 5 and 6 are clearly OK, and levels 1 and 2 clearly aren't. I'm OK with the others, but as far as I can tell, there is no policy on this. We ought to have one. — Erin (talk) 04:57, 16 August 2006 (UTC)

National laws are also a matter to consider here; they vary a bit with regards to this. In most countries, #1 in the second list would be OK if it's a public figure (some countries have tightened the reins a bit there because of problems with paparazzi, but most would be OK) and in some countries it would also be fine if the photo was taken in certain circumstances. For instance, in Norway the law states that you do not need permission to publish photos of identifiable people in a public parade in open air. There might be difficult cases, but there are times when #1 is not unacceptable. Cnyborg 14:47, 16 August 2006 (UTC)
Your last couple of examples aren't clear at all.. "pictures of a friend for a wikipedia article" .. are they giving permission for their image to be used in all the ways our mandatory free licenses would allow? If not, we still should get a release.--Gmaxwell 15:12, 16 August 2006 (UTC)
I think that Cnyborg is correct that the level of model release required might depend on the situation of the photograph. For example, I think that it's fair to say that many of the people in Image:Waiting for a train.jpg did not know that this photograph was being taken, but I don't think that that precludes publication without releases. However, if a similarly posed photograph featured a line of girls in bikinis on a beach, we might want to at least be sure that the subjects were aware that they were being photographed. --JeremyA 22:31, 16 August 2006 (UTC)
[After edit conflict] Oh, I think they are clear. A person takes a picture of a friend, who poses for it and knows that it is for a GFDL encyclopaedia. The last example is totally clear: the picture is of the uploader, and the act of uploading is permission. It couldn't be clearer unless we added level 8: "Person takes picture of self whilst reciting all Wikimedia polcies, with one hand on the Bible and the other on a print-out of the GFDL, in front of ten witness, and signing confirmation in his own blood." :-) — Erin (talk) 22:40, 16 August 2006 (UTC)
Yes, that's right. All my examples were referring to close-ups of clearly-identifable non-famous people. — Erin (talk) 22:40, 16 August 2006 (UTC)


We are discussing personality rights here, and this respect taking a picture is not problematic, only showing the image. Effectively, we are only dealing with three scenarios:

  1. unacceptable No permission to publish the image on Wikipedia.
  2. unacceptable Permission to publish the image on Wikipedia, further use requires individual permission.
  3. acceptable Permission to freely publish the image in any context.

We are running into a free content issue here. As long as the person on the image does not allow free use of his or her image in any context, the image cannot be freely used. Users would need to get individual permissions from the person depicted each and any time they want to use such an image, which is against Wikipedia's and the Commons policy.

Unfortunately, free use in any context may include all sorts of uses that one does not really whish to see one's image in, I'm afraid, which will make getting a model release rather thorny. --Wikipeder 07:23, 17 August 2006 (UTC)

Refactoring

So, after some discussions..

It seems reasonable to refactor in the same way they have en:Wikipedia:Images and media for deletion on English Wikipedia.

To translate for Commons, it would look like this:

first older entries, that are only links:

then, inclusion of templates:
Template:Deletion requests/2006 August 14
Template:Deletion requests/2006 August 15
Template:Deletion requests/2006 August 16
Template:Deletion requests/2006 August 17
Template:Deletion requests/2006 August 18
Template:Deletion requests/2006 August 19
Template:Deletion requests/2006 August 20


Templates are removed from the main deletion page, and put into pending-deletion, after seven days. This will result in swifter deletions, which should be a good thing as deletions should follow Commons:Licensing, and not be subjected to case-by-case sophism of certain German smooth-talkers, who like to have the last say on all deletions based on their own personal interpretations.

I could refactor the page in this way, but it would need some time, during which it will be closed. The template {{delete}} should also be updated to point to {{Commons:Deletion requests/<CURRENTYEAR><CURRENTMONTH><CURRENTDATE>#image name}}

Fred Chess 15:55, 20 August 2006 (UTC)

Please let a bit more discussion go by before implementing this (to Fred, or anyone else). I want to check out a couple of different systems first. It's worth taking the time to find the right one. :) pfctdayelise (translate?) 16:02, 20 August 2006 (UTC)
No problem, pfctdayelise, although if one waits for perfection, one will wait for ever, as you know. Anyways, thanks for commenting!
I hope you also read my post on Commons:Village pump#Rethinking_COM:DEL.
Fred Chess 16:15, 20 August 2006 (UTC)
I do not like english in archive titles. I'd prefer numbers representing months. I have already refractored archives (including really old ones) to be on a month by month basis. it would take 32 edits to achieve what is proposed for august. --Cool CatTalk|@ 21:50, 21 August 2006 (UTC)
I've reverted Cool Cat's edits to the page just now, because I thought they weren't very useful. By archiving everything, even outstanding requests, at once, I think it's made even less likely that such requests will be closed. NielsF 23:31, 21 August 2006 (UTC)
Good point. Moving unclosed issues to the archive does not make sense. They will never be closed. --ALE! ¿…? 23:32, 21 August 2006 (UTC)
Another thing: The unclosed archived issues should be removed from the archives. --ALE! ¿…? 23:34, 21 August 2006 (UTC)
How about letting people edit the sub pages so we dont have to archive. Copy paste archives are bad taste. And since my edits are so underapriciated, I wont make any more of them. --Cool CatTalk|@ 23:38, 21 August 2006 (UTC)
See also User talk:Cool Cat where I've tried to explain my action a bit more. NielsF 23:58, 21 August 2006 (UTC)
In the light of that I think its best to leave the duplicate entries on archives. They are easy enough to overwrite once discussion concludes. I will do so myself if no one else does. --Cool CatTalk|@ 02:14, 22 August 2006 (UTC)
OK, I feel something needs to be done and fast. Lets do this in a gradual shift though.
Firstly, I propose we get rid of the copy-paste style archiving (really bad taste) and allow people to edit the "archives" to discuss the issues. Is there any reason to oppse this?
--Cool CatTalk|@ 02:14, 22 August 2006 (UTC)
It doesn't need to be done fast like today. It needs to be done fast like within a couple of weeks. I agree copy-paste style archiving sucks. At the moment I'm leaning towards a template-per-nomination method. Please see also the mailing list discussions. Magnus Manske's "Tasks" extension may be worth a try.
People should not be able to edit the "archives" unless they are also able to watch specific discussions only (ie, template per nomination). Having to put every archive on my watchlist to follow up discussions is a crazy idea.
Please keep in mind the need to have a working multilingual system as well. pfctdayelise (translate?) 06:57, 22 August 2006 (UTC)
I used fast in an abigious manner... I do not think there is a way to sort this mess aside from using more sub templates (either one template per day (rather than month) or one template ber case). It isn't like you watch every discussion.
The discussion will be in a multi lingual manner like it is now. Templates will have dates presented as numbers in ISO format. Or at least thats what I have in mind.
--Cool CatTalk|@ 11:43, 22 August 2006 (UTC)
Symbol oppose vote.svg Oppose No, I do not think that copying and pasting done entries is bad taste. I think it would be a very bad practice to to edit archives. Archives are for archiving which means to store the results of the discussion for later reference not for the discussion process itself. --ALE! ¿…? 06:59, 22 August 2006 (UTC)
You cant oppose like that this isnt a poll. Do not treat it like one. Few nice questions:
  • How do you know, I don't change entries while copy pasting? Why trust the archiver that much? Histories are lost on copy/paste archiving.
  • Do you have any idea how many people it takes to continiously archive finished requests? As it is a person has to repetively load two +400k pages to archive just a single entry. What about the situation in ten years?
If people were able to edit a sub template all it takes to archive is to remove the recursion. The history is kept with the archive. This is how it is done on english wikipedia.
I do not have access to the mailing list and I find mailing lists hard to follow. I reccomend keeping the entier discussion here.
--Cool CatTalk|@ 11:35, 22 August 2006 (UTC)
Cool Cat is correct in that this page has become impossible to read, and errors are multiplying as people make attempts at cleaning it up. I would like to also point out pfctdayelise's remark about the mailing list. Some discussion has been going on already about this. Cary "Bastique" Bass parler voir 11:46, 22 August 2006 (UTC)
Oh, and one more thing. Although it was in contrast to consensus (note that, Cool Cat), he did make a great effort in attempting to reduce this page to more manageable details. It becomes irrelevant what's left on this page if nobody can manage to update it because it's so big. Cary "Bastique" Bass parler voir 11:49, 22 August 2006 (UTC)
Actualy my browser had crashed (kinda) several times while I was archiving that stuff. Editing this page or even loading it may crash browsers. And I am talking about most recent firefox and not some ancient browser. --Cool CatTalk|@ 12:09, 22 August 2006 (UTC)
Cool Cat, yes you and anyone else can read the mailing list discussions. I'm sure you understand it's kind of annoying when someone jumps into the middle of a discussion without seeing what was said before. Please do so. pfctdayelise (translate?) 12:29, 22 August 2006 (UTC)
Oh I wasnt trying to be annoying... --Cool CatTalk|@ 13:05, 22 August 2006 (UTC)

Moving along

Ok, lets discuss ideas in a more organised manner. I'll break the proposals into sub sections and we can discuss pros cons. --Cool CatTalk|@ 11:56, 22 August 2006 (UTC)

Keeping current system

I think it is obvious the current system is unworkable with.
  • It requires one to load 400k at any given time to even glance at a recent entry.
  • It can easly break browsers.
  • Copy/paste archiving is very difficult as it requires loading two 400k pages to archive a single entry. Histories are not preserved.
--Cool CatTalk|@ 11:56, 22 August 2006 (UTC)

One template per day method

Currently this can work
  • Debates will eventualy grow too large to fit a single template per day.
  • People would edit the sub template and not Template:Deletion requests
    • This will preserve histories.
    • Archiving will be less of a hassle. One would be juggling templates rather than two 400kb blocks of text.
--Cool CatTalk|@ 11:56, 22 August 2006 (UTC)

One template per case method

Best solution in my oppinon
  • People would edit the sub template and not Template:Deletion requests
    • This will preserve histories.
    • Archiving will be less of a hassle. One would be juggling templates rather than two 400kb blocks of text.
--Cool CatTalk|@ 11:56, 22 August 2006 (UTC)

How article deletions are done on en.wiki

Just as a heads up
  • Each case has its own template.
  • People edit sub-templates rather than the listing page. Infact only bots edit the listing page juggling the templates.
  • Cases are only listed for 7 days. While the debate can go on further, they dont cluter the listing page. You can cycle through entries older than seven days reading unfinished business. See en:Wikipedia:Articles for deletion/Log/2006 August 22 as an example. See the en.wikipedia archive page Wikipedia:Articles for deletion/Log
--Cool CatTalk|@ 12:04, 22 August 2006 (UTC)

Opinions:

  • I think I am prefering the "One template per day method" system. However I would like to add, that the templates should not be shown all at once. Maybe something like in the German Wikipedia is preferable: de:Wikipedia:Löschkandidaten/Bilder. Otherwise this system would results again in the repeated loading of 400k+ pages. --ALE! ¿…? 12:08, 22 August 2006 (UTC)

There are other approaches, such as dividing by type, which I am strongly in favour of, as well as moving to a one-template-per-debate approach, to allow people to watch single discussions only, and thus follow them more closely. Also keep in mind many debates will take much longer than 7 days here, and there's simply no way of speeding that up. I am working out some ideas on my user page. To Cool Cat, I suggest to create a mock system in your user subspace so other people can see how it will work. pfctdayelise (translate?) 12:29, 22 August 2006 (UTC)

I'd really rather keep all deletion as a single process. On en.wiki for instance there is an adequate number of articles and categories to warrant their own deletion process but on commons we mostly (completely) deal with media.
The one-template-per-debate (one template per case) is already suggested above. The 7 day time period was an ambiguous one. We can wait 10 or 15 days or whatever. The point is after a reasonable amount of time, listing every unfinished case seems problematic. The one template per case method would allow us to list cases that are not complete in 7 days on a seperate list. Concluded cases would be easy enough to remove. One template per case gives us the greatest mobility.
I am not certain what you mean by mock system. I'd suggest the en.wiki afd structure.
--Cool CatTalk|@ 13:01, 22 August 2006 (UTC)
At w:Wikipedia:Articles for deletion, they only have links to 7 'day' subpages. How do they ensure that all AfDs before those dates have already been closed? What stops them accidentally living on forever? pfctdayelise (translate?) 13:17, 22 August 2006 (UTC)
Thats called a backlog. In the current system we are listing everything on one page. I think hat discourages admins from closing cases (since they have difficulty even looking at it).
One posibile way to keep the backlog at check would be to keep a list of days with unclosed entries. Once a day is cleared from all backlog its entry can then be removed from the list.
I guess this is what you mean by mock system: User:Cool Cat/Deletion. I have taken the en.wiki system and improved it a bit.
--Cool CatTalk|@ 13:34, 22 August 2006 (UTC)
OK, well Commons lives in perpetual backlog, and this is a reality we have to process. We currently have 34 days listed... that means a backlog of 34-7=27 days, so many more items than that. (One reason Commons has a bigger backlog than AfD is because even when a debate is clearcut, an admin may be hesitant to delete an item if it is heavily linked.) This is what I'm talking about...we can't just adopt another process wholesale. We have to adapt it to suit our needs. At the moment I'm looking at DPLs, which are used on Wikinews. I will try to set up a mock system on my test wiki. pfctdayelise (translate?) 13:47, 22 August 2006 (UTC)
Also, of note... we might use voting icons during deletion debates, however, it should not be assumed that we're actually "voting" here at deletion requests. With regard to the "backlog". One of the images I delisted, rather than deleting--I put a speedy template on it, as the image is linked on a Wikinews page; and there are issues with deleting images hosted for wikinews. In that respect I was able to archive the deletion debate. Cary "Bastique" Bass parler voir 13:52, 22 August 2006 (UTC)
pfctdayelise, like I said the 7 day thing is an ambigious time frame I threw out. Dont be corny about it, ok? :) We can do a 15 day listing and 15 day backlog + old old backlog (4 days with your calculation). Still each 15 day listing should be around 200k then hence why I'd recomend several 7 day listings instead.
One way to fix it is to have a few backlog pages, each holding a few days (maybe seven). Its very easy to manuplate how data is presented when it is used in templates. Is there any reason not to use the "One template per case method"?
How the data is to be presented can be a later debate. Lets first establish how it will be preserved.
--Cool CatTalk|@ 15:53, 22 August 2006 (UTC)
I'm in favour of "One template per case method", too. -Samulili 16:13, 22 August 2006 (UTC)
IMHO, I agree with ALE (top post) because it will work. I've already stated that I believe in this system. We actually have no obligation to keep debates for longer than, say, 14 days. Furthermore, it is my deepest wish that debates of license validity will not be conducted at this page anymore, but at commons_talk:Licensing. If this becomes a reality, it should ease the process significantly. / Fred Chess 21:43, 22 August 2006 (UTC)
Hi there, I'm also in favour of "One template per case" method, as this has the following advantages:
  • it is not incompatible with a division by case types (although I think that dividing by case types may puzzle people who are new to Commons and don't know yet the various kinds of deletion reasons)
  • it is very simple to handle for archiving closed cases (just remove the link from the list page, the discussion is archived and can be found by a search in the sub-namespace of the list page)
  • it is quite simple to handle for sorting cases (a section by date or a section by type of case or any combination of both)
  • it is possible to get either a view of case list only or a view of case list with their contents: you can make simple links with square brackets or include the case templates with double "{" and "}".
A simple test is visible on my local user page: User:Alno/Refactoring_deletion_request_page.
Best regards to all,
-- AlNo (talk) 08:57, 23 August 2006 (UTC)

Prototype!

Please have a look here and let me know what you think. pfctdayelise (translate?) 16:30, 24 August 2006 (UTC)

Wow. It's... different. Cary "Bastique" Bass parler voir 17:06, 24 August 2006 (UTC)
Not very straight forward to use. --ALE! ¿…? 19:01, 24 August 2006 (UTC)
Why not? What do you expect to be able to do that you can't? pfctdayelise (translate?) 00:33, 25 August 2006 (UTC)
I am not a beginner what concerns using a computer. But if a system makes me to click and read to many pages until I get what I want it is not user friendly to me. This thing is to complicated. We have a Wiki here for everyone not only for computer freaks. An example: The nomination: Many users who want to delete an image do not want to bother about the category to put it in. --ALE! ¿…? 07:03, 25 August 2006 (UTC)
It's not supposed to be for computer freaks, it's supposed to be for everyone. :( If we want to divide by type of request then we have to branch at some point - unless admins are supposed to do all the categorising?? I hope not. I mean we do this at the moment, but it doesn't work very well (still lots of 'duplicate' requests on COM:DEL). pfctdayelise (translate?) 11:21, 25 August 2006 (UTC)

The section I want to /nominate something for deletion is a good thing for new users. Experienced users i think make the nomination and editing directly.

In connection with Commons:Deletion guidelines it should be a section like quick guide. --GeorgHH 07:19, 25 August 2006 (UTC)

Symbol oppose vote.svg Oppose Not something the regular user is used to. Prefer to keep it simple. / Fred Chess 10:27, 25 August 2006 (UTC)
  • Do you think the current system is simple? pfctdayelise (translate?) 11:21, 25 August 2006 (UTC)
    • Well, maybe not simple, but people are accustomed to it... / Fred Chess 22:14, 26 August 2006 (UTC)
      • Which people, us? We will quickly get accustomed to whatever system we adopt. The thing is to adopt something that is easy for first-timers to navigate and use. pfctdayelise (translate?) 01:10, 27 August 2006 (UTC)
        • This is right. It´s mainly a good method to take new users easy trough the deletion procedure. Experienced users do it on their own way, i think.--GeorgHH 08:24, 27 August 2006 (UTC)

I would certainly like to see more discussion on this. It's apparent to me that the current system is not working very well. Cary "Bastique" Bass parler voir 16:53, 27 August 2006 (UTC)

I think the compromise on this would be to display this with the deletion guidelines, it certainly has benefits for all users. However, as it is so very different it should be included in a section like "Browse current nominations". Beneath that then have all the currently open nominations (through days if needed), making it feel more like the traditional layout.--Nilfanion 20:24, 28 August 2006 (UTC)

I don't support the user interface as such - it has too many options and too many clicks - although the idea is worth developing, imho. But I very much support the technology used with the prototype. -Samulili 19:40, 29 August 2006 (UTC)

From the prototype front page to view a discussion (while browsing) takes 3 clicks (selecting browse, selecting filter, selecting discussion). That could easily be reduced to one. Instead of having to click to /browse, if it that page was incorporated onto the front page that would save one click. The other thing to simplify matters would be to display the discussions on the browse page instead of just giving links. That second point is really useful; being able to view multiple debates at once is exceptionally useful imo. It may also be sensible to decide which is the most useful one (probably /o). That could then be directly transcluded onto the main page, producing an identical end result in appearence to the current system, but with the much more powerful underlying tech would solve many of the problems.--Nilfanion 20:02, 29 August 2006 (UTC)

Also, it might be an idea to pipe the /links. /ss&o looks quite intimidating, it might deter someone from using it. "Open Superseded" wouldn't have that effect.--Nilfanion 20:10, 29 August 2006 (UTC)
Of course, the actual interface and front page can be changed as to what the community wants. My idea with the prototype was to showcase the strength of using dynamic generated pages. The most important thing, IMO, is that the interface (whatever it is) is user centred. That means it's based around what the user might want to do, not focused on the technicalities of how the things are actually achieved. See for example w:Help:Contents. It guides the user from a general enquiry to a more specific one. I think this is important because it will make the system more accessible to non-Commons regulars -- ie, the vast majority of the users we serve. pfctdayelise (translate?) 08:00, 30 August 2006 (UTC)

Alternate nomination process

Perhaps we could copy the en.wp AFD route for nomination. The steps as applied to this would be:

  1. Add {{delete}} (or its successor) to the page.
  2. Follow the redlink on the deletion tag to the COM:DR subpage, subst in a standard template like w:Template:Afd2, which adds it to the Open requests cat and perhaps to a "Manually created deletion request" category.
    1. If the user is familiar with Commons deletion process they can add the other relevant deletion cats, either manually or through extra fields in the nomination template.
  3. Add the link to the main page.
  4. If the nominator did not provide any categorisation, COM:DEL regulars (or a bot?) could then add the relevant categories (by patrolling the manual creation cat).

This is a simple enough procedure imo. The prototype works very well for allowing people to view the open requests, according to their interests. If we implement this "traditional" route concurrently to the automagic of Pfctdayelise's prototype. This would give us a tried and tested system, and will also allow for-real testing of the prototype. How does this sound?--Nilfanion 17:21, 31 August 2006 (UTC)

Although familiar with Wiki-editing here and on nl.wikipedia I tried to nominate a page for deletion on en.wikipedia somethime ago, but it still was just a bit too hard for me to agree to this. Not a problem for Commons/en.wikipedia regulars probably, but for newbies it might just be too much to handle, because it requests too many separate actions, imho. NielsF 01:23, 1 September 2006 (UTC)
How does nl.wiki do it? Obviously commons isn't the best example really, the needed reform is indicative that it is overly simple.--Nilfanion 07:07, 1 September 2006 (UTC)

Poll to establish consensus

Lets first establish where data is to be kept. Add a new section for new suggestions. --Cat out 19:50, 28 August 2006 (UTC)

(05/01/03) One template per case

Symbol support vote.svg Support The most workable system if you ask me. --Cat out 19:50, 28 August 2006 (UTC)
Symbol neutral vote.svg Neutral (leaning towards this option). To me, COM:DEL feels much more like AFD than IFD on the English Wikipedia. The nomination on Image:Rouge-Admin.png looks like a contentious AFD, as opposed to a typical dull IFD. I would really like to see Template nominations get their own template, as these are about more fundamental things than individual images. That suggests to me perhaps we should split image deletions from everything else. Also it makes adding a speedy criterion "recreation of deleted content" more workable.--Nilfanion 20:32, 28 August 2006 (UTC)
Symbol support vote.svg Support Yes. Obviously this is the most favoured option. The question is then how to meta-present it. Getting this right, to simplify nominations and thus reduce mistakes and confusion for new users, is the hard bit. pfctdayelise (translate?) 05:11, 29 August 2006 (UTC)
Symbol support vote.svg Support Swayed by Pfctdayelise's argument. Cary "Bastique" Bass parler voir 13:11, 29 August 2006 (UTC)
Symbol support vote.svg Support -Samulili 17:00, 29 August 2006 (UTC)
Symbol oppose vote.svg Oppose In most cases, pages or images are proposed for deletion in clusters. These are not independent cases : you'll find similar reasons, similar arguments for each case of the same cluster. One template per case leads to an efficiency loss. --Juiced lemon 08:42, 30 August 2006 (UTC)
Just noting that "case" doesn't necessarily imply "image". This can handle multiple requests as a single page easily enough.--Nilfanion 09:00, 30 August 2006 (UTC)
Multiple requests must be forbidden in every system. --Juiced lemon 09:08, 30 August 2006 (UTC)
So you would rather see 40 requests for a set of obsoleted shields rather than a single request encompassing all 40 shields? --TwinsMetsFan 17:48, 30 August 2006 (UTC)
Or do you mean that the 40 requests must be grouped as one? --TwinsMetsFan 17:51, 30 August 2006 (UTC)
A set of obsolete shields ? Who decrees that there are obsolete ? Please, allow me to take an separate decision for each request. If not, delete them and do not ask for my opinion.
They are obsolete when they are incorrectly named and the image contains errors. --TwinsMetsFan 01:04, 2 September 2006 (UTC)
A case is one page or one image : that's the way it has to be. --Juiced lemon 08:55, 31 August 2006 (UTC)
Not in the case above. In the case above, "vector superseded" doesn't work because they are both SVGs. So a multi-image request is necessary. The case I'm referring to can be found under August 15 on the accompanying page. --TwinsMetsFan 01:04, 2 September 2006 (UTC)
Vector superseded graphics will always end up going to COM:DEL (under current rules). With requests such as Template:Deletion requests#A bunch of orphaned superseded images one request for the lot is logical. If you think "keep" for all but foo.png, you can say that after all.--Nilfanion 09:20, 31 August 2006 (UTC)
Symbol support vote.svg Support with the understanding that extremely similar image requests (such as my above example) can be grouped as a single case. --TwinsMetsFan 18:02, 30 August 2006 (UTC)
Symbol neutral vote.svg Neutral i will not support until you show me how you think this whole system will work. Pfctdayelise claim that this system is simple to use. But in general, a template-based system is a bitch for those who aren't used to it. I AM ALL TOO WELL FAMILIAR with the English Wikipedia Articles for Deletion the Sw Wiki equivalent Sidor som bör raderas, the En Wiki Peer Review, and the feature picture process here. The whole "click here, write here, open separate page, paste this template, change header, insert the following text, write arguments, save, go back, purge". What computer nerd finds this simple?! / Fred Chess 09:46, 31 August 2006 (UTC)
Having the simplest possible process has led to the current situation: everything dumped on one page. There is a trade-off between minimum nominator actions and ease of use for admins and regular voters. pfctdayelise (translate?) 05:41, 1 September 2006 (UTC)
The entier process can be achieved with 3 steps, #1 you tag the image, #2 you click a link on the template and create your template, step #3 add the template to the list. --Cat out 05:16, 2 September 2006 (UTC)
  • In the current system you would have to do step #1 and #2 anyways (you'd create a new section rather than a tmeplate but its the same deal). The extra work is the transclusion of the template to the main list. I dont believe its all that difficult. --Cat out 19:31, 3 September 2006 (UTC)
Symbol neutral vote.svg Neutral I agree with Fred here, although pfctdayelise's system makes this a lot more workable than the standard way used in en.wp for example. NielsF 01:25, 1 September 2006 (UTC)
Symbol support vote.svg Support, since this would allow the best system for archiving. --tomf688 (talk - email) 13:49, 4 September 2006 (UTC)

(04/03/00) One template per day

Symbol oppose vote.svg Oppose A day contains too many entries. Half of them will likely be easily closed while others last forever. --Cat out 19:50, 28 August 2006 (UTC)
Symbol support vote.svg Support -- it works for English and German Wikipedia. / Fred Chess 20:13, 28 August 2006 (UTC)
{{support}} Swayed...see above -- Probably would work better for this project. Cary "Bastique" Bass parler voir 20:22, 28 August 2006 (UTC)
  • So what do we do with a day full of entries but only one open case? The page will have a larger lenghth than the current system (which removes closed cases). --Cat out 20:40, 28 August 2006 (UTC)
  • I won't give any vote, but a comment: Pages by date have proven to be the best solution between granularity (small pages for quick reading), easy acess and easy archiving (single pages, priorization for admins after duration) in quite some wikiprojects I know. A case by case subdivision is far to modular (very bad access of archives, important for image "ghosts" returning). We should just try date subdivison. We still can modify it later. Arnomane 18:28, 29 August 2006 (UTC)
  • Sorry if I comment at the wrong place but I don't think we're using the same language here. I think that we should have one template per issue (usually one template per image). These templates can be arrenged so that one page includes several templates from the same day. This is the way I have understood the question. -Samulili 19:36, 29 August 2006 (UTC)
  • Well my concern is: Creating a template for each issue is hard. How do you get a random user that wants to report a posible copyvio creating a template and embed it on his own? A page where he just can write it down is far better. And it needs only one edit instead of two. And cleaning up all these templates after users is no fun and work we also shouldn't need to do. Arnomane 23:57, 29 August 2006 (UTC)
  • Using the Inputbox method is the best way to ensure consistent naming of cases. It also means that when you go to create a case that already exists (ie, has been nominated previously), it will pop right up on the screen. It does need two edits, one to create it and one to insert it in the page (if we don't use a dynamic method like my prototype), but the method currently used on COM:FPC is working well I think. As for "cleaning up": using a template-per-case means less cleaning up, not more. Archiving is far simpler - delete one line, not copy and paste ten lines to some other page. It also preserves edit history accurately, unlike manual archives. pfctdayelise (translate?) 07:55, 30 August 2006 (UTC)
  • The template can hold a mini-how to just like how it is on en.wiki. Its just 3 edits (including the inclusion of the deletion tag). --Cat out 05:20, 2 September 2006 (UTC)
Symbol oppose vote.svg Oppose for two main reasons: one, manual archiving is a pain and destroys the edit history; two, inability to watch a specific debate only. I really believe this is vital! Who wants to be scanning a 30-day old page to see if they can close a debate yet? pfctdayelise (translate?) 08:13, 30 August 2006 (UTC)
Symbol oppose vote.svg Oppose per Cool Cat and Pfctdayelise. --TwinsMetsFan 18:06, 30 August 2006 (UTC)
Symbol support vote.svg Support --Juiced lemon 13:49, 31 August 2006 (UTC)
Symbol support vote.svg Support although a way should be found to keep the templates lean, or readable if you prefer (maybe outcommenting them (<!--) for example?) NielsF 01:28, 1 September 2006 (UTC)
Symbol support vote.svg Support Hbdragon88 21:44, 1 September 2006 (UTC)

(01/01/00) One template per week

The current system with a smaller page.

Symbol support vote.svg Support --Juiced lemon 08:55, 30 August 2006 (UTC)
Symbol oppose vote.svg Oppose Too broad of a time frame. --TwinsMetsFan 17:53, 30 August 2006 (UTC)
Pictogram voting comment.svg Comment: We can present it weeky with template trasclusions (thats something I am suggesting below) but each image would have their own template in that system I am proposing. --Cat out 19:28, 3 September 2006 (UTC)

(00/03/00) Current system

Symbol oppose vote.svg Oppose The system is KAPUT, unworkable. --Cat out 19:50, 28 August 2006 (UTC)
Symbol oppose vote.svg Oppose Too heavy page, impracticable. --Juiced lemon 08:58, 30 August 2006 (UTC)
Symbol oppose vote.svg Oppose I can't put it any better than Cool Cat and Juiced Lemon already have. --TwinsMetsFan 17:49, 30 August 2006 (UTC)

Another quick poll...

How should we break up/divide the page of deletion requests? This is a separate (although related) issue to whether keep nominations on a mass page or use individual templates. pfctdayelise (translate?) 08:11, 30 August 2006 (UTC)

Divide by day only

e.g. One page for each day's nominations.

I think this is enough for now. The new system, which is easier to use and browse, may add the number of deletion requests and it may change what kind of issues arise. I don't think we are capable of judging which other division are reasonable at this point. -Samulili 11:49, 30 August 2006 (UTC)

Divide by type of request only

e.g. "Superseded", "mass requests", "suspected copyvio", etc. Actual details can be worked out later. Has the additional problem of, how do we communicate this to the new user? Currently many users still put their "duplicate" and "mistake" requests on COM:DEL even though they explicitly should not, so instructions need to be very clear and straightforward.

Divide by day and by type

Realistically, users won't follow too many instructions, so this would require a dynamic solution (a la my prototype above).

Divide by some other method

Would love to hear your suggestions!!

Improve speed of speedy - will help here

I notice that some of the COM:DEL discussions raised are actually reasonably experienced editors getting frustrated with speedy deletion. If we can get a handle on the speedys we may cut the workload on here.--Nilfanion 00:55, 31 August 2006 (UTC)

So, moving to a one-template-per-day approach...

What does that mean? We can either also move to a one-template-per-case approach or stick with the current "just write directly on the page" approach. When you close/archive a debate in this approach, do you move it to a separate archive or does it stay forever on that day template?

Who takes care of removing days listed on COM:DEL when all of their debates have been closed? Last admin to close a debate, I guess.

Given that we can't please everyone and any improvement is better than none, when should we set the date for a changeover? pfctdayelise (translate?) 01:42, 2 September 2006 (UTC)

If we're going to go with one template a day, it'd probably be best to do a direct approach and write right on the page (template) like w:WP:IFD. As for the changeover date, I'd say by September 9 (one week). This problematic system has been in place far too long. --TwinsMetsFan 02:05, 2 September 2006 (UTC)
A one template per day style is used here tr:Vikipedi:Telif sorunları. Debates on tr wiki about copyrights are relatively short and on occasions an entier day may have no new copyright issues posted. The entier archive of Tr.wiki probably is less than what we have in a day.
Hence why I feel one template per case methid is better as we deal with collosal discussions (some are over a page long).
The one-template-per-case method I would use if I had my ways:
  • All content is kept on the individual templates. Template talk:Deletion requests is only used to link to templates. (much like en.wiki AfD listing)
  • Archiving would be done through delisting an entry from Template talk:Deletion requests and relisting on the archive page... History is preserved. (example archiving from tr wiki)
  • Anyone closing the debate can archive or volunteers can work on it to.
--Cat out 05:10, 2 September 2006 (UTC)
OK, so you are basically saying...same approach as now, except each case has its own template, and each case is linked to from COM:DEL (but not transcluded)? I didn't think of that... Hm I could live with that. pfctdayelise (translate?) 08:09, 2 September 2006 (UTC)
No, the templates will be transcluded (I apologise for my poor choice of words, linkage is an intersting idea just not my suggestion :) ).
In my vision...
  • It will look just like how it is now in the broadest sense.
  • As my original sugeestion, I propose several 7 day listings.
    • Template:Deletion requests only display the past 7 days.
    • A linked (not translcuded) page for the past 8 - 14 day old listings
    • another linked (not translcuded) page for the 15 - 21 day old listing
    • another linked (not transcluded) page for everything else (there shouldnt be too many listings over 22 days old).
    • Commons is a growing project. If the backlog seems to get overflowing again we can simply shorten time frames and etc. Dealing with it should not be all that hard.
  • When a case is closed, it can be removed form any one of the listings (making the listing shorter). All that needs to be done to archive is to comment out the transclusion. A bot or person can move it to the archive listing later on... The method of archiving and etc can be discussed later.
--Cat out 15:39, 2 September 2006 (UTC)
Can we go ahead with the system change? If so I will be moving every current issue to its own template. --Cat out 19:44, 3 September 2006 (UTC)
I realise there is no clear cut concensus but when I joined the refractrong debate page was 400kb, it is now 450kb. I went ahead with the one template per case method with the help of Rory096. I can assure anyone reading that juggling 450kb was demanding task not just for me but for my computers cpu. Some of the debates are rather large, The template:soviet-pd debate alone is like some 40k+.
I have transcluded all of the templates to Template:Deletion requests so nothing has actualy changed as far as appearance is concerned. The entier thing is still 450kb. However it is very easy to break it to 7-day groups (or whatever grouping we will proceed with).
--Cat out 03:14, 4 September 2006 (UTC)
If you "reform" now which you seem to have at least partially done, I don't think anyone should revert you. But for the love of God DO NOT DO A PARTIAL JOB. It appears that you changed the templates to months? I thought we agreed on weeks? And be sure to update template:delete and the instructions on COM:DEL. This is half the problem - something changes and all the instructions never get updated. :/ pfctdayelise (translate?) 06:45, 4 September 2006 (UTC)
I merely moved cases to individual templates as I felt no one would object to that. Thats three quarters of the deletion process. Juggling the templates is the easy part.
As for the month thing, thats my temporary mesure. As is, the page pushes my latest firefox browser to its limits as it was not designed to work with this kind of a colossal page. If things get out of control, we have a way of dealing with it now. In no way do I support monthly listings.
Furthermore it should take like 5 edits to make this thing a weekly listing. I didnt want to go that far as this wasnt discussed throughly. I'd support weekly listings anyday though and can proceed with that right away. How should we do weeks? Fixed times (monday - sunday) or the dynamic times (past seven days)? Either way would require a bot to juggle the templates (like on en).
We also need the other languages updated once the en version is solidified.
--Cat out 07:35, 4 September 2006 (UTC)
Your move was a good initiative, Cool Cat. / Fred Chess 09:45, 4 September 2006 (UTC)
Thank you for your efforts. Looks good. But I still have some remarks and questions. (Please interrupt me, if it was already discussed. I was out of office for some days.):
  1. Could you explain, how archiving works now?
  2. Could we name the individual deletion requests with the date added? Example: {{Commons:Deletion requests/2006/July/08/Image:The name of the image.extension}} (The reason for this is: better structure and it could be that a different image with the same name was already discussed here.)
Thanks! --ALE! ¿…? 09:59, 4 September 2006 (UTC)
Okay, I'll try to explain. My reasoning and ideas... Feel free to agree/disagree...
  1. Archiving can be done many ways. We have a great room for flexibility. I'll list some of the possible ways. All involves linking or transcluding the sub deletion template.
    • We can archive in advance. We dont have to wait for the debate to conclude to "archive". At the end of every day, new entries can be dumped to archive (a bot can do this). With this method once debates "close" all that needs to be done is to de-translude them. My belief is that this is the best and most efficient way.
    • We can keep the current system (in a sense) and move transcluded templates to their approporate archive location in a copy/paste manner as they close. The copy/paste only includes the copy paste of the template transclution and not the template content.
    • We might simply not archive since the sub pages will be there for referance. This is a bit more chaotic then other options but certainly easier to maintance.
    • I am open to other suggestions. If you have a better idea, feel free to suggest
  2. Thats a nice and easy to impliment idea. (I would recomend a number date (2006/07/08) though). However an unintended result of the current system is the detection of recreation of deleted content. I do not believe keeping this feature is critical but something to think about. I do not particularly mind going either way.
Hope this clears things up. Feel free to ask any kind of questions.
--Cat out 15:10, 4 September 2006 (UTC)
@1.a: I do not like that idea because there are a number of admins and even bureaucrats that "forget" to close deletion discussions.
@1.b: I prefer that.
@1.c: I do not like that at all.
@2.: The side effect might be useful to detect re-uploads of previously deleted files but it hinders the easyness for unexperienced users to nominate files for deletion that have the same name but different content. --ALE! ¿…? 20:55, 4 September 2006 (UTC)
@1.a Eventualy all discussion should be "closed", how else would it be archived? The archives would display all discussion (closed or open). All should be closed eventualy anyways and closed discussions are clearly marked as not to be edited... As for the current listing, only continuing discussions are displayed. I am using a similar system in tr:Vikipedi:Telif sorunları, feel free to take a look (I just want you to see it in action).
@1.c I do not either. :)
@2. We can do that, sure. However I really do not want to move existing templates. :) Someone can do that or we can move them to the date format while archiving. We can employ that system for newer discussions.
--Cat out 19:56, 5 September 2006 (UTC)
Um... so what are we deciding? pfctdayelise (translate?) 09:29, 6 September 2006 (UTC)
Listing type. I made my propositions below. We need bot support for this... --Cat out 09:32, 6 September 2006 (UTC)

Moving really along with final phase of transition

Ok lets vote on how we want to present the data. This is to establish a reasonable and easy to navigate system. Add if you have a better idea. --Cat out 17:08, 4 September 2006 (UTC)

(01/01/00) Weekly (dynamic) listing

In this method, past seven days are listed on Template:Deletion requests, anything older is been displayed on another sub page as a backlog. Some info

  • The past 7 days are roughly 200kbs, roughly 50% of the entier listing.
  • Everything else is another 200kbs, the remainder 50%ish. (this can be broken apart further)
Symbol support vote.svg Support Easier to manage and only two pages to deal with --Cat out 17:08, 4 September 2006 (UTC)
Symbol oppose vote.svg Oppose. Would this not make linking between pages more difficult and more cumbersome to find that thing one was just reading two, or was it three, days ago? I also don't like to labeling some discussions as backlog. -Samulili
Please sign your comments
Sure we can call it whatever you like. How about older discussions or dicussions older than seven days?
Any discussion older than seven days would be avalible a link away. An discussion newer than seven days would be here on the same page.
--Cat out 19:44, 5 September 2006 (UTC)

(00/00/01) Weekly (static) listing

In this method an ambigious time frame (ex Monday - Sunday) is used for listings. I have no idea on how to get this working in an automated method.

Symbol neutral vote.svg Neutral Might work but not really happy with the idea. --Cat out 17:08, 4 September 2006 (UTC)

(00/01/00) Monthly listing

Too long of a time frame. System would still be KAPUT and little different from current system.

Symbol oppose vote.svg Oppose --Cat out 17:08, 4 September 2006 (UTC)