Wikipedia:Deletion review/Log/2015 August 15

15 August 2015

Passmap

Passmap (talk|edit|history|logs|links|watch) (XfD|restore)

From the closing admin's talk page:

Extended content

You closed Wikipedia:Articles for deletion/Passmap as "delete". I do not see a consensus for deletion. At most, there is a consensus for pruning the article by removing all but the first one or two sentences, which can be sourced to http://dl.acm.org/citation.cfm?id=2414513 and http://ijisme.org/attachments/File/v1i5/E0222041513.pdf. Please change your close to "no consensus" or "keep and prune". Cunard (talk) 17:43, 15 August 2015 (UTC) Hi, I had another look at the discussion. The "keep and prune" !votes are based on the sources mentioned by Sadads, but those were challenged effectively, in my eyes. You yourself said that only the first sentence might be worth salvaging and it is copied in full in the AfD, so it should be no problem to integrate it in Draft:Graphical password. Once that article has been created, a redirect can be put in place very easily. I therefore see no reason to change the close. If you disagree, you're of course welcome to take this to WP:DRV. --Randykitty (talk) 17:51, 15 August 2015 (UTC)

List of sources in the AfD:

1. International Journal of Science and Modern Engineering: http://ijisme.org/attachments/File/v1i5/E0222041513.pdf
2. "PassMap: a map based graphical-password authentication system" from the Association for Computing Machinery: http://dl.acm.org/citation.cfm?id=2414513
3. http://arxiv.org/abs/1001.1962
4. more

The closing admin said that Sadads (talk · contribs)' sources were rebutted by Finlay McWalter (talk · contribs), who noted that "None of these citations has anything to do with this company or their specific technology." However, as I noted in the AfD:

The lead of the article says:

Passmap /ˈpæsmæp/ is an image based method used for authentication, similar to passwords. The word passmap originates from the word password by substituting word with map. Passmap is a patented technology of Hydrabyte, Inc.

I agree that Hydrabyte's technology is not notable, but I think the concept itself is notable, so perhaps this can be saved by deleting everything except the first sentence of the article, which can be sourced to http://dl.acm.org/citation.cfm?id=2414513. Also, I would support a redirect of this topic to the article eventually created from Draft:Graphical password.

The discussion was relisted twice after my suggestion, and Prhartcom (talk · contribs) agreed, writing, "Article can coexist with a graphical password article." After re-reviewing the sources provided by Sadads again, I believe there is enough material for "Passmap" to be a standalone article. (Though it can certainly be mentioned in Rhododendrites (talk · contribs)'s draft at Draft:Graphical password about the broader topic.)

I would like passmap to be restored, so I can remove all but the first two sentences and source them to http://dl.acm.org/citation.cfm?id=2414513.

There was clearly no consensus in the AfD. Two editors supported "keep and prune" (Cunard and Prhartcom), one editor supported "keep" (Sadads), and three editors supported deletion (Finlay McWalter, Eclipsed, and Rhododendrites). The "delete" editors did not advance arguments far better than the "keep" editors, so a "delete" conclusion is untenable with a split vote count.

Overturn to no consensus.

Cunard (talk) 19:01, 15 August 2015 (UTC)

• Comment (from closing admin) As I explained on my talk page (copied above), I stand by the delete close. --Randykitty (talk) 19:19, 15 August 2015 (UTC)
• @Cunard: I'm confused by your argument for keeping the article: 'I agree that Hydrabyte's technology is not notable, but I think the concept itself is notable'. Passmap is Hydrabyte's technology. If the broader topic is notable, let's work on an article for the broader topic (I agree with you about that, hence starting Draft:Graphical password). To get more specific to this DRV, 'The "delete" editors did not advance arguments far better than the "keep" editors' - when the delete arguments in question are about there being insufficient sources, isn't that saying people who !voted delete should be proving a negative? The sources provided were exceptionally weak (again, unless we're talking about the broader topic and not actually about Passmap). — Rhododendrites ^talk \\ 20:45, 15 August 2015 (UTC)

• The sources provided were exceptionally weak (again, unless we're talking about the broader topic and not actually about Passmap). – yes, I'm talking about the broader topic. I think none of the "keep" editors think that Hydrabyte's Passmap technology is notable. We instead argued that "passmap" as a general concept is notable and that the article could be reframed to discuss that general concept using only the first one or two sentences in the now-deleted article. Cunard (talk) 00:57, 16 August 2015 (UTC)

• Shrug I can kind of see it as a no consensus, but when you are arguing to cut it to a one liner then redirect to a draft when it's more complete, then I get a bit lost. If a one liner is good enough then preparing the draft to be good for main space should be trivial. I would suspect more time has been spent on discussing this than it would have been to move things forward there. --86.2.216.5 (talk) 21:55, 15 August 2015 (UTC)

• I withdraw my suggestion to redirect this article to a draft. I had thought that this would be better covered in an article about the larger subject. But there is sufficient material in the sources Sadads (talk · contribs) found (and in the sources I listed here) to satisfy Wikipedia:Notability#General notability guideline for passmaps as a general concept. The deleted article had a good definition of what a "passmap" is:

  Passmap /ˈpæsmæp/ is an image based method used for authentication, similar to passwords.

  Cunard (talk) 00:49, 16 August 2015 (UTC)

• Well I get to a similar response. I can't see the original article but it sounds from what's been written here so far that you are proposing a different set of content to that which was there. In which case the AFD is irrelevant and whoever is interested in that new article should just write it. The quotes below (I wish you wouldn't do that, the way these get rendered in mobile as large quotes makes it very difficult to read properly) are all basically the same thing, I'm not seeing much more than a paragraph to be written, which from a usability point of view would probably be better as a section in a bigger article than a standalone article with nav boxes to the other "similar" concepts. --86.2.216.5 (talk) 09:34, 16 August 2015 (UTC)

• The article said that "Passmap /ˈpæsmæp/ is an image based method used for authentication, similar to passwords". Hydrabyte's passmap product is not notable but the general concept is. The article can be reframed to discuss the general concept of how passmaps do authentication through images.

  From the abstract of this article in the Association for Computing Machinery:

  Based on the idea of using an extremely large image as the password space, we propose a novel world map based graphical-password authentication system called PassMap in which a password consists of a sequence of 2 click-points that a user selects on an large world map. We also conducted a user study for evaluation. The result shows that the passwords of PassMap are easy to memorize for humans and PassMap is friendly to use in practice. Furthermore, PassMap provides higher entropy than PassPoints and also increases the cost of attacks.

  Here are other sources:

PassMap sources and quotes provided by Cunard

Thorpe, Julie; MacRae, Brent; Salehi-Abari, Amirali (2013). "Usability and Security Evaluation of GeoPass: a Geographic Location-Password Scheme". Symposium on Usable Privacy and Security. Archived from the original (PDF) on 2015-08-16. Retrieved 2015-08-16. The article notes: PassMap [35] asks users to choose two map locations as their location-password, whereas GeoPass only requires users remember one location. There are also many subtle differences relating to usability/security trade-offs between the GeoPass and PassMap designs, including: (1) GeoPass does not allow users to choose points at a zoom level lower than 16 for security reasons, whereas PassMap does not implement zoom level restrictions and thus users can choose points at lower (less secure) zoom levels (e.g., level 8). (2) GeoPass calculates the error tolerance at zoom level 16, whereas Pass- Map does not normalize error tolerance to a particular zoom level. We implemented this feature as we found that very few users remember their zoom level in our pilot testing. (3) GeoPass's initial screen is of the entire world to avoid in u- encing users to choose points in a certain geographic area (which would reduce security); PassMap's initial screen is centered on Taiwan at zoom level 8. (4) Upon a search, GeoPass zooms into the viewport assigned by the Google Maps API, whereas PassMap zooms into zoom level 18.</blockqote> Al-Ameen, Mahdi Nasrullah; Wright, Matthew (2015-02-07). "Multiple-Password Interference in the GeoPass User Authentication Scheme". Internet Society. doi:10.14722/usec.2015.23004. Archived from the original (PDF) on 2015-08-16. Retrieved 2015-08-16. {{cite journal}}: Cite journal requires |journal= (help) The article notes: There are two other schemes that use map locations as an authentication secret: one proposed by Spitzer [11] and another one is called PassMap [10]. PassMap requires the user to choose two locations and the scheme by Spitzer [11] requires five or seven locations at different zoom levels to be selected as the location-password. Thorpe et al. [8] have shown that GeoPass is more usable than other digital- map-based schemes [10, 11] because of its requirement to click on a single location and normalized error tolerance to a given zoom level. The login success rate in GeoPass (97%) was found to be higher than that in PassMap (92.59%). Sachdev, Ritika (2014). "User Authentication: A Case History". International Journal of Pure and Applied Research in Engineering and Technology. 3 (1): 77–84. ISSN 2319-507X. Archived from the original (PDF) on 2015-08-16. Retrieved 2015-08-16. The article notes: PassMAP: From psychological studies of human memory, it is well known that human beings find it very easy to remember the landmarks on the journeys they have made. In the PassMAP technique, user can tag sequence of locations or places defining their own route. In a way this is highly subjective or customized based password to ensure security. Lashkari, Arash Habibi; Farmand, Samaneh; Saleh, Rosli; Zakaria, Omar Bin (2009). "A wide-range survey on Recall-Based Graphical User Authentications algorithms based on ISO and Attack Patterns" (PDF). International Journal of Computer Science and Information Security. 6 (3): 17–25. Retrieved 2015-08-16. The article notes: PASSMAP (cute recall) One of the main problems with passwords is that very good passwords are hard to remember and the one which are easy to remember are too short of simple to be secured. From the studies of human memory, we know that it is relatively easy to remember landmarks on a well-known journey[19]. Figure 9 will be shows a sample of PassMap password. Weaknesses: Additionally the PassMap technology is not very susceptible to "shoulder surfing" as can be clearly seen from Figure8. Noticing a single new edge in a large graph or even an absence of some edge in the map is not a trivial task,for someone just passing by. But it is respect to Brute Force attacks while at the same time considering how good those mechanisms are in terms how memorable they are [19] Rajarajan, S.; Prabhu, M.; Palanivel, S.; Karthikeyan, M.P. (2014-03-20). "Gramap: Three Stage Graphical Password Authentication Scheme". Journal of Theoretical and Applied Information Technology. 61 (2): 262–269. Archived from the original (PDF) on 2015-08-16. Retrieved 2015-08-16. From this 2014 article in the Journal of Theoretical and Applied Information Technology: Perhaps the only world map based authentication scheme that seem to have been proposed is the one called PassMap [17]. In this scheme users are shown the google map on their screen. Then they need to use the zoom facility to select two points in any geographical locations of their choice. This becomes their password. Because this scheme uses google maps in its implementation, it is not usable in systems without Internet facility or google map support. Since google maps is a third part tool, it can not be fully integrated into the system by adjusting it according to our requirements. This scheme is not resistant to shoulder surfing attack which is the major problem to graphical passwords. Nevertheless, this scheme have got good memorability due to the usage of map for the password mechanism. Yampolskiy, Roman V. (2008). "Action-based user authentication". International Journal of Electronic Security and Digital Forensics. 1 (3). Inderscience Publishers: 281–300. Archived from the original (PDF) on 2015-08-16. Retrieved 2015-08-16. On pages 293–296, the article has an entire section about PassMap. Here is a short excerpt from the article: PassMap is very easy and can even be done for authentication on multiple systems with multiple base maps without any additional memorisation being required. For example,your PassMap might be to connect the most upper-left city with the lowest city and with most upper-right city regardless of the actual map presented to you. In addition, the PassMap technology is not very susceptible to ‘shoulder-surfing’ as can be clearly seen from Figure 4. Noticing a single new edge in a large graph or even an absence of some edge in the map is not a trivial task (Yampolskiy, 2007f) Cunard (talk) 00:49, 16 August 2015 (UTC)

• .... notice how those sources say "PassMap" or "Passmap" and not "passmap"? That's because Passmap is proprietary. You're saying the proprietary "Passmap" is not notable but the "general concept" of "passmap" is notable, but I see no evidence such a thing even exists (and it would be weird if it did, since it's apparently trademarked). Perhaps what you're looking for is "map-based password system", which is (again) a perfectly reasonable addition to an article about graphical passwords, but is not the same as the topic of this article. Also, this wall of text belongs at AfD, not DRV. — Rhododendrites ^talk \\ 03:34, 16 August 2015 (UTC)

• Also, this wall of text belongs at AfD, not DRV. – I added these sources here after I did further research on the topic to see how widely discussed it was. I thought Sadads' sources were sufficient, so during the AfD I did look for more.

  notice how those sources say "PassMap" or "Passmap" and not "passmap"? ... You're saying the proprietary "Passmap" is not notable but the "general concept" of "passmap" is notable, but I see no evidence such a thing even exists – you are correct that the "m" should be capitalized. My correction: The general concept of "PassMap" as "an image based method used for authentication, similar to passwords" is notable. The "keep" editors believed the article should have been reframed to discuss that instead of the non-notable proprietary concept.

  The "delete" editors did not explicitly dispute this reframing that was proposed by me and endorsed by Prhartcom at the AfD. Therefore, I cannot see a consensus to delete. Cunard (talk) 05:25, 16 August 2015 (UTC)

• The general concept of "PassMap" as "an image based method used for authentication, similar to passwords" is notable - The point of my previous message wasn't to correct your capitalization, but to point out that the fact that it's always capitalized as one indication of what is elsewhere explicitly stated: the "general concept" of "passmap" doesn't exist. If you're searching for a general concept, it's something like "map-based graphical passwords/authentication" of which Passmap is one example -- and that doesn't make the keep arguments any stronger than they were (which, of course, is all that's relevant here -- whether the strength of the arguments presented effect a consensus to delete). — Rhododendrites ^talk \\ 19:09, 16 August 2015 (UTC)

• Yes, "map-based" is more precise than "image-based". I'll revise it once the article is restored. Cunard (talk) 20:32, 16 August 2015 (UTC)

• Why are we here? It sounds like this is a request to do one of two things. Either 1) create a new article under this title with completely different content, or 2) wait for some other article which is currently in draft to be created, then make this a redirect to that. Neither of those actions require DRV to be involved. Thus, I suggest this DRV be speedy closed to save a week of pointless arguing. -- RoySmith (talk) 12:45, 16 August 2015 (UTC)

• 1) create a new article under this title with completely different content – it would not be completely different content. I would like the article to be restored so as suggested at the AfD, I can prune it to the first one or two sentences, citing it to http://dl.acm.org/citation.cfm?id=2414513, a source Sadads mentioned at AfD.

  wait for some other article which is currently in draft to be created, then make this a redirect to that – as I have written repeatedly above, I do not think this should be a redirect. I agree with Prhartcom, who wrote in the AfD that Article can coexist with a graphical password article.

  Why are we here? – we are here because there was no consensus in the AfD for deletion, and some of the material in the original article can be salvaged.

  If you'd restore the article so I can do my proposed pruning, then yes, this DRV can be speedy closed. Cunard (talk) 17:46, 16 August 2015 (UTC)

• Endorse I'm not sure why this DRV was open. There is consensus the 'article does not belong here, but on the other hand there's nothing wrong with either incorporating some of the material into a wider topic and/or creating a redirect. But the close was appropriate. §FreeRangeFrog^croak 19:50, 16 August 2015 (UTC)
• Thank you, RoySmith (talk · contribs), for temporarily undeleting the article. I have pruned and rewritten the article. I have re-blanked the article per my comment at Wikipedia talk:Criteria for speedy deletion/Archive 55#Improving articles temporarily undeleted for WP:DRV:

  I will do the following if I rewrite an article with a {{TempUndelete}} template on it in the future. I will either save the rewrite in mainspace and then immediately blank it myself, or I will recreate it in the draft namespace.

  To RoySmith, FreeRangeFrog, or the DRV closing admin: Please unblank the article and move this page to PassMap. I think there is enough material here to warrant a standalone article with a brief mention in Draft:Graphical password. Once this page is restored to mainspace, this DRV can be closed as resolved.

  Cunard (talk) 20:32, 16 August 2015 (UTC)

My take on this is editing a tempundeleted article in mainspace is inappropriate. If you want to propose a new draft before the DRV is over, that's what userspace is for. -- RoySmith (talk) 17:53, 17 August 2015 (UTC)

• Endorse. The general concept of a map-based authentication method is (probably) notable. The general concept of a "passmap" does not exist. The main source presented for passmap is for a specific piece of software. The ACM publishes papers describing software written by the paper's authors all the time. Cunard's rewrite is still spam for a non-notable product. Much more well-meaning spam than the original spam, yes, but still spam. —Cryptic 00:30, 17 August 2015 (UTC)

• My rewritten article has five sources, four of which are independent reliable sources while one is a primary source from the ACM. Because of the significant coverage from four independent reliable sources, the subject is notable.

  From Wikipedia:Spam: "There are three main types of spam on Wikipedia. These are: advertisements masquerading as articles; external link spamming; and adding references with the aim of promoting the author or the work being referenced."

  The latter two types are clearly inapplicable, so are you saying that I wrote an "advertisemen[t] masquerading as [an] articl[e]"? That is a serious accusation to make. Please explain how I wrote an advertisement that is masquerading as an article. I did not use promotional language. I have no affiliation with the subject. I only included facts that were supported by reliable sources.

  Cunard (talk) 00:41, 17 August 2015 (UTC)

  • Because you've taken an article about a specific product and are proposing to use it as the general case. It's like (first ridiculous example to spring to mind) replacing the content of Web search engine with that of Google Search. —Cryptic 00:58, 17 August 2015 (UTC)

• Both Web search engine and Google Search are notable. That's why there are articles for both topics.

  Both map-based authentication method and PassMap are notable. The rewritten article PassMap is titled "PassMap", not "map-based authentication method", so it's unclear why you believe I've "taken an article about a specific product and [am] proposing to use it as the general case". Cunard (talk) 01:07, 17 August 2015 (UTC)

• • • Probably because it's what you've said multiple times such as "..to satisfy Wikipedia:Notability#General notability guideline for passmaps as a general concept." etc. --86.2.216.5 (talk) 06:29, 17 August 2015 (UTC)

• Overturn (to no consensus). I though Cunard was a little forward with his request, until I read the AfD. There was not a consensus to delete. There was a stronger case for "keep and prune", with deleted arguments being rebutted. However, I don't feel that there was a readable consensus for the "keep" part of "keep and prune", and so a closing of "keep and prune" is probably less justifiable than "no consensus, let's see what happens if pruned and improved, no prejudice to a renomination in a month or two". The close reads to me as maybe a little but WP:Supervoteish, that is, if the closer had !voted, the discussion might have been clearer. That was a might. But, a closers' !vote is not allowable. --SmokeyJoe (talk) 05:32, 17 August 2015 (UTC)

• Comment SmokeyJoe, I have no problem with you reading the AfD discussion differently than me. However, I do protest your characterization of my close as a "supervote". I gave my reasons why I gave the "keep" !votes less weight than the "delete" ones. You can agree with that or not, but characterizing it as an improper supervote is something I vehemently disagree with. Indeed "a closers' !vote is not allowable" and that is not what I did. --Randykitty (talk) 13:46, 17 August 2015 (UTC)
• @SmokeyJoe: There was a stronger case for "keep and prune", with deleted arguments being rebutted. - Rebutted? One "Keep and Prune" argument rested on "the article can coexist with a graphical password article" and the other was Cunard's, as presented here, which says verbatim "I agree that Hydrabyte's technology is not notable", arguing for a "general concept" that doesn't exist. (As stated here multiple times already, PassMap is Hydrabyte's technology). The only other keep argument was Sadads, linking to 3 sources also referenced by Cunard. So the "rebuttal" in the AfD relies on a primary source and brief mentions in two other papers. — Rhododendrites ^talk \\ 14:42, 17 August 2015 (UTC)

• Rhododendrites, though !voting delete, indicates that tons of sources exist. Despite what he actually, wrote, he is effectively providing a case for "merge to Graphitical password", this new article in the process of creation. Prhartcom slammed that home. There was no consensus at this point to delete. The closer appears to have not bought this. The closes' "there seems" flags that the closer was on the edge. It was just better read as a "no consensus". The "Supervotish" thing I attempted to put very gently was motivated by the observation that had've Randkitty !voted "delete" with clarity, it may have helped the discussion reach a clear consensus, whether through making the case for deletion, or provoking more input in response to the unexected perception that "delete" was where others could see it heading. Also, Cunard's serious contribution is not reflected in the close. --SmokeyJoe (talk) 00:06, 18 August 2015 (UTC)

• No. I indicate nothing of the sort.

I started Draft:Graphical password because while the sources provided by Sadads/Cunard in no way showed PassMap to be notable, they indicated that the concept of a graphical password is likely notable. Maybe PassMap could be mentioned in that graphical password article and thus a redirect would be appropriate, but that article doesn't yet exist in the article namespace. So the only appropriate course of action (since a merge/redirect to a non-existent article or another namespace is inappropriate, and because it's quite clear that PassMap is not notable) is to delete. That's why I !voted delete. When the article is created, we could mention it there and create a redirect. — Rhododendrites ^talk \\ 04:02, 18 August 2015 (UTC)

OK, PassMap sources were weak, and the Graphical password sources were related but not PassMap sources. Still, I read the XfD as no consensus with the possibility of a merge or a rescope remaining on the table. I am a huge skeptic of the value of DraftSpace and think Draft:Graphical password should be moved to Graphical password. I recommend undeleting and redirecting Passmap to Graphical password. --SmokeyJoe (talk) 04:22, 18 August 2015 (UTC)

• Overturn. With even numbers and reasonable arguments on each side, the accurate outcome of the discussion was no consensus. Stifle (talk) 08:11, 17 August 2015 (UTC)
• Overturn to No Consensus - decent sources, balanced headcount; there's some evidence the usual adage "AfD ain't Cleanup" was ignored here. I'm also troubled by the closing admin coming here to endorse/stand by their decision; it ruins the appearance of impartiality on their part (whether they are or not, I can't say, but admins need to be able to at least look superficially impartial in closes). WilyD 11:47, 17 August 2015 (UTC)

  Comment WilyD, As far as I know, it is absolutely normal and even desirable for the closing admin to comment here. For a DRV to be started, the normal procedure is to contact the closing admin first and ask them to reconsider. If they don't, you go to DRV. I didn't !vote here, I only posted a comment that confirms that Cunard contacted me and that I didn't see reason to change my close. There's many a DRV that I have seen where the closing admin participates and !votes "endorse". How I didn't "look impartial" in the close and in this debate is beyond me. --Randykitty (talk) 13:46, 17 August 2015 (UTC)

  I would draw a distinction between commenting and endorsing, of which the phrase "stand by" strikes me far more like the latter than the former. If there was some relevant information that (for whatever reason) wasn't in the close, that we should know about, or if there was a remark that a phrase in the close that was ambiguous and needs clarification, then of course the closing admin should provide that information, but that's different from stating or implying that DRV should endorse the close. I mean, obviously when one closes a discussion, they think their close is right. But that's different than being invested in that close "sticking". I realise my standards are higher than mosts' in this regard. WilyD 15:16, 17 August 2015 (UTC)

  I for one would disagree with WilyD's characterization. As DRV is not determining if the result is the "correct" result as such but weather the process was followed correctly and if the closer read the debate correctly, I don't think the is any question about impartiality regarding the topic. If we wanted to make a rule that admin's can't comment here we could and that would seem a more constructive way forward rather than trying to shame individual admins to conform to a view point which seems to be only expressed by one person. I'd fully expect the closing admin to endorse their own close, and in fact I'd go so far as the opposite view and admin not wishing to come here to endorse their own actions tends to suggest they didn't take their responsibility in closing seriously. --86.2.216.5 (talk) 17:56, 17 August 2015 (UTC)

  An admin who strongly prefers a particular outcome, and feels it necessary to endorse that outcome, is suspect with respect to their ability to read the debate fairly and impartially. It's poisonous to the community if we can't trust that admins are closing discussions based on the discussion, rather than because they have some strong opinion. I wouldn't say closers shouldn't comment at DRV - often times they should. But they shouldn't close discussions they're so invested in the outcome that they can't abide by other people examining and possibly overturning their close. WilyD 09:38, 18 August 2015 (UTC)

• Pray tell me where you get the idea that I was not "closing discussions based on the discussion, rather than because [I] have some strong opinion"? When I closed this AfD, that was the first time I ever heard about anything called PassTime and I couldn't care less personally whether we have an article there or not. I take this as a rather serious accusation, so back it up or strike your comment. I have no problem with somebody reading the AfD discussion differently from me. If the community here decides that I erred in my closure, that's fine with me too. We are all human and mistakes are made and nobody is perfect. But while you are welcome to disagree with my closure and read the debate differently, you are not welcome to accuse me of improper conduct, which is what you are doing here. --Randykitty (talk) 09:45, 18 August 2015 (UTC)

• Of course, I haven't accused you of any improper conduct, so I can hardly strike it. By coming by DRV to endorse/stand by close, you've presented yourself as too invested in the outcome to be able to stand as an impartial closer for the discussion. And hell, letting your biases slip into how you read & close a discussion isn't misconduct, it's just a mistake. But by doubling down on that mistake, there's too much encouraging sides/battleground mentality/however you want to put it. People coming to talk to you about your mistakes shouldn't have to fear you're going to fight them on trying to get them rectified. WilyD 10:07, 18 August 2015 (UTC)

• Then please tell me where it is stated/recommended that a closing admin should not comment in a DRV? All I thought I was doing was confirming that I was aware of Cunard's intention to open a DRV and confirming that his representation of my position was correct. I empathically did not !vote, but only posted a comment. You are reading way too much into a short comment. And I don't take accusations of bias lightly, not the same thing as a "mistake". --Randykitty (talk) 10:17, 18 August 2015 (UTC)

• Endorse - Well within admin discretion, which has been explained more than adequately. There was one actual keep vote and 2 "keep per X", but since X's vote was refuted, ll of the keeps are thus weakened. The consensus of those who made the better policy-based arguments to delete carried the discussion. Also, it is quite routine for the closing admin of a discussion to come to DRV and endorse their own close. There are some pretty strange lines of attack coming from some DRV regulars, ones who should know better. Tarc (talk) 19:32, 18 August 2015 (UTC)
• Endorse- delete !votes were correctly judged to be stronger. Reyk _YO! 10:54, 19 August 2015 (UTC)

• A very difficult one. I'm with Stifle and DGG to an extent: when I look at the discussion I don't see a "delete". I definitely see a "no consensus". But was the close within discretion? I'm not seeing the kind of socking, gaming or other disruptive behaviour that would lead to increased sysop discretion ---- and without that I think the range of discretion should be relatively small. If we allow wide discretion then AfD will be a lottery that depends on who closes it. So I'll go with overturn to no consensus.—S Marshall T/C 18:10, 19 August 2015 (UTC)

Template:Non-free_GFDL-invariants

Template:Non-free_GFDL-invariants (talk|edit|history|logs|links|watch) (restore)

Not only did the deletion discussion of this template have no resulting consensus, this license is, from what I've seen, relatively uncommon - if it's (rarely) used on an image with no free alternative it may be useable alongside the {{Non-free with ND}} template. 201.53.49.33 (talk) 05:26, 15 August 2015 (UTC)

• The template was deleted 3 years and 8 months ago, so I think saying it's "relatively uncommon" would be something of an understatement. What are you asking for here? --86.2.216.5 (talk) 10:08, 15 August 2015 (UTC)
• TFD discussions default to delete if there are no contributions, due to the generally small number of participants. In light of this and the long time since the deletion without anyone needing the template, that is strong evidence that it wasn't used and the deletion should be endorsed. Stifle (talk) 08:17, 17 August 2015 (UTC)
• For this sort of unsupported delete proposal, it is a softdelete, so you can ask at WP:REFUND for a restore. But it could also get a speedy delete for being unused. In anycase what is 201.53.49.33 asking for? Graeme Bartlett (talk) 12:32, 17 August 2015 (UTC)