|
List of Who Framed Roger Rabbit characters (edit | talk | history | protect | delete | links | watch | logs | views) (restore | cache | AfD))
After the AFD was restarted a second time, User:RMHED performed a non-admin closure about 2 hours later, stating it closed as keep as there was no obvious consensus to delete and that any merge discussion should take place on the article's talk page. I agree there was no "delete" consensus, but if a merge were to occur, there is a likely need for this page to be deleted. Both the speedy close after the second restart and the reasoning make this closure (particularly by a non-admin and in the timeframe given after a restart) a highly questionable use of a NAC. MASEM 00:34, 12 November 2008 (UTC)[reply]
- Endorse closure (keep pagehistory intact). This was not a second AfD, this was a relisting. Once a discussion has run it's five days, it is subject to closure at any time - a relisting does not automatically mean that it will suddenly run for 10 days. In this case, the consensus is remarkable clear with only two people arguing to delete the page and 16 people arguing for some flavor of "keep". The discussion was civil and well based in policy and precedent. I am not normally a fan of non-admin closures (because the discussions are frequently more complicated than they appear) but I can see no way that this discussion could have been closed differently.
The decision now of whether to "keep as is" or "merge" should be sorted out on the respective article Talk pages. Note: Even if the AfD discussion did finally reach a clear "merge" decision, it would be no more binding than an equally-well attended discussion on the Talk page. As has been said frequently before, AfD has no mandate to decide on ordinary-editor actions like mergers, removal of content, decisions to redirect, etc.
One last point. If the final decision is to merge the page, deletion is the very last thing that we would want to do. Mergers conclude with redirects and deliberately keep the pagehistory intact so that we can be sure that we are fully complying with the attribution requirements of GFDL. To delete the page would be to delete the contribution history of the merged content. Rossami (talk) 02:39, 12 November 2008 (UTC)[reply]
- Endorse closure And I'm also endorsing the first closure by Alexnia. (which he self-reverted) AFD is a discussion on whether or not an admin should push a delete button and at the time of the first closure, nobody but the nominator was arguing for that button to be pushed. At the time of the second closing, only one other editor was arguing for deletion. All and all the discussion ran for 7 days and there was no consensus to delete. --Ron Ritzman (talk) 04:01, 12 November 2008 (UTC)[reply]
- Endorse preferably speedily. mergers should never result in the deletion of the merged page. See Help:Merging and moving pages. We keep the old page history intact even if the redirect is unlikely in order to preserve the page history for GFDL reasons. Eluchil404 (talk) 05:42, 12 November 2008 (UTC)[reply]
- Endorse closure. Ran full time, and there was clearly nowhere near a consensus for outright deletion. Sjakkalle (Check!) 07:55, 12 November 2008 (UTC)[reply]
- Endorse closure. The only procedural error alleged was an early closure, and WP:RELIST clearly states that a relisted debate may be closed at any stage and need not run for a further five days. To be frank, Alexnia should have left the keep closure intact rather than relisting it. Stifle (talk) 13:30, 12 November 2008 (UTC)[reply]
- IMHO Alexnia's close was proper but he reopened it because of the nominator's objection to his close on his talk page where he could have done a better job of defending the close. Instead of saying I counted more keeps then merges he should have said nobody but you was arguing for deletion. Even though the nom couldn't have gone any other way he was giving the nominator the benefit of the doubt. --Ron Ritzman (talk) 14:10, 12 November 2008 (UTC)[reply]
- Incidentally, discussion on a merge (which can never result in the page being deleted anyway) is still possible on the article talk page. Stifle (talk) 13:31, 12 November 2008 (UTC)[reply]
- Really It's no use to make a fuss about my declaration I made on my talkpage the nom objected my NAC closure and seeing that I was not a admin i thought it would have been better to let an admin decide. Regarding my poor defence the afd rahther ended up in a merging discussion. I think in a situation like this my state ment "I counted more keeps then merges" was right. I'm deciding not to do any Nac closures anymore because it only leads to users objecting my Nac closure because I'm not an admin, not even rergarding how obvious the Afd is. Alexnia (talk) 15:11, 12 November 2008 (UTC)[reply]
- endorse close Nominator claims "but if a merge were to occur, there is a likely need for this page to be deleted". This makes GFDL a sad panda. JoshuaZ (talk) 21:53, 12 November 2008 (UTC)[reply]
- A page merge could use a history merge which would keep the GFDL compliance but still result in the deletion of said page. --MASEM 22:40, 12 November 2008 (UTC)[reply]
- Yes, but there's rarely a very good reason to bother doing that, and it still doesn't require an AfD. JoshuaZ (talk) 23:04, 12 November 2008 (UTC)[reply]
- … and there are good reasons for not doing history merges unless they are absolutely necessary. They make a complete mess of an article's history, for example. In all of my time as an administrator, I have only ever needed to do history merges for repairing bogus copy-and-paste "moves" (including botched transwikifications, which are a subset of that). I have never had another use for them. An ordinary merger, done the ordinary way, is the the way to merge articles, and requires no administrator tools, nor even an account on the wiki. Uncle G (talk) 17:31, 13 November 2008 (UTC)[reply]
- Endorse - The close statement "any merge proposal is best discussed on the article talk page" is flat out wrong because AfD brings a wider range of people with less personal interest in the topic. I probably would have close as no consensus or merge. The keep close seems within the closer's discretion of interpteting the discussion. Once an article has been listed at AfD for more than 120 hours (five days), it can be closed by anyone who can reasonably derive a consensus (or lack of consensus) out of the discussion. The close should not have been a NAC close, but the remedy for that is that any admin may change the close. -- Suntag ☼ 02:19, 13 November 2008 (UTC)[reply]
- I would not oppose a change in deletion policy so that merge proposals that were not clearly consented to or rejected on the talk page, were in fact discussed at afd. It would only regularize the present situation. I would suggest accompanying this with another change, that there be explicitly 4 outcomes for afd, keep/merge/redirect/delete -- with merge meaning merge all the content. Again, this would only regularize the current situation. All this would still of course leave the qy of how much to merge with no real way to enforce decisions--there have already been too many cases where a merge close is followed by an almost total deletion of content, but at least it should deal with the problem of a keep followed by a merge followed by a deletion of content. As for NAC closes, too many of them come here, which would not be challenged if they were from an admin. I suggest we simply prohibit non-unanimous NACs. DGG (talk) 03:21, 13 November 2008 (UTC)[reply]
- The vast majority of DRV's are from admin deletions usually incorrect CSD's, NAC's seldom feature on DRV. If you wish to change the NAC guideline or indeed implement a new policy prohibiting NAC's then you'd need to start a discussion and attempt to get a consensus for it. RMHED (talk) 04:24, 13 November 2008 (UTC)[reply]
- Further on RMHED's point, if there is a solid rejection of a NAC at DRV, than the non admin should get the hint to not close AfDs for a while until they get more skill. In this case, it seems that RMHED will live on for another day to do more NACs. -- Suntag ☼ 11:28, 13 November 2008 (UTC)[reply]
- I'm quite aware I'm making only a preliminary suggestion about a change in the stated policy, that would need much further discussion elsewhere. DGG (talk) 15:59, 15 November 2008 (UTC)[reply]
- As I understand it, merge at AfD means merge useful content, not move content not meeting Wikipedia's standards from one location to another. It is another way of saying get rid of the crap, keep whatever the closer feels meets Wikipedia content standards, and redirect this article to the merge targe so we don't continue to fill up this space with more content not meeting Wikipedia's content standards. Where the content is not sourced to independent, secondary sources, there wouldn't seem to be anything to merge. -- Suntag ☼ 11:25, 13 November 2008 (UTC)[reply]
- content of some types within an article does not need to be sourced to secondary sources. It's material indicating independent notability that needs to be so sourced, not article content DGG (talk) 15:59, 15 November 2008 (UTC)[reply]
- I do agree that a merge consensus at AfD can leave the actual outcome of the content somewhat uncertain and the results could vary from one AfD to the next. -- Suntag ☼ 02:33, 16 November 2008 (UTC)[reply]
Responding to some comments above: a merge can never result in the page history being deleted, but it can result in the page being deleted, as follows:
- Merge articles A and B
- Move B to Talk:A/OldHistory
- Make a note at Talk:A about the old history.
- Delete the new redirect at location B, which has only one entry in its page history
This procedure was, when I gained adminship, discussed in one of the admin guides for deletion discussions. It's the correct procedure to follow if there is consensus that not only does B not deserve an independent article, it does not deserve even a redirect, probably because the redirect is an unlikely search target. I have already explained in detail in this post why I feel merge is a valid AFD outcome. Regarding this particular case, there's no need to revisit the AFD now, but in general an AFD should only be closed by a non-admin if there is a clear consensus for maintain the status quo. — Carl (CBM · talk) 03:40, 13 November 2008 (UTC)[reply]
- Please see Uncle G's comments a few lines up about why this is such a bad idea in most cases. It's theoretically possible but it is definitely not the preferred or routine practice. Rossami (talk) 02:54, 14 November 2008 (UTC)[reply]
- He was talking about history merges. The procedure I discussed has nothing to do with history merges. — Carl (CBM · talk) 03:02, 14 November 2008 (UTC)[reply]
- Editors may be interested in the recent discussion WT:AFD#Mergers at AfD, where CBM made his detailed post. Flatscan (talk) 04:21, 13 November 2008 (UTC)[reply]
- The procedure outlined above seems unneccessarily complex and bureaucratic in almost all cases. There is no need to tidy up the main space in this way—"redirects are cheep". After all, the effect would be to turn any remaining (or later created) links to the merged article red, thus encouraging its recreating, precisely what the merger decison sought to avoid. With regards to the WT:AfD discussion I would say that I have no objection to merge as an AfD outcome (though I view it as a clear subspecies of keep), but see it as an inadequate reason for an AfD nomination since if that were to become standard practice mergers preformed without an AfD would be seen as "lacking consensus" and AfD's scope and power would increase greatly. A prospect I deem unhelpful to the project. But, of course, WT:AfD is the proper place for that discussion. Eluchil404 (talk) 11:17, 13 November 2008 (UTC)[reply]
- Agree Nothing wrong with discussing mergers or redirects at AFD or even close as Merge or Redirect but IMHO an article should not be nominated unless the nominator wants an admin to push a delete button. (though he could say that a merge or redirect is an acceptable alternative) Also, merge !votes are a variant of "Keep" and the closer, admin or not, should not be bound to close as "Merge" even if there are a significant number of them. In practice, I personally wouldn't close Keep if the "merges" far outnumber the "keeps" and/or the "keeps" aren't soundly based on policy or precedent. A lesson I learned the hard way.
- Redirects are a little trickier as I have seen "delete and redirect" !votes. When I review for close. I view these as "deletes" when deciding if the AFD is "nacable". Also, perhaps Redirect closes should be somewhat enforceable and at the least those who defend these could be exempt from 3RR. Ron Ritzman (talk)
- Re Eluchil404: you're right that in most cases the procedure I outlined isn't needed. However, from time to time I see comments to the effect of "it's impossible to merge and delete", and so I wanted to point out that it is perfectly possible. In rare cases where that procedure are needed, article is orphaned, or almost orphaned, and the title of the article is a completely implausible search target. A vote to "merge and delete" basically says "Merge the articles. Then, since the old title is such an unlikely search term, skip the RfD and delete the redirect too." Of course this is only reasonable is the old title is unlikely to be recreated. — Carl (CBM · talk) 14:30, 13 November 2008 (UTC)[reply]
|