Tony Sidaway wrote:
I wonder if we could agree to change policy to permit an administrator to "speedy redirect" a merge candidate and close an AfD where notability is the sole or principal reason given for deletion, or no reason is given. This would be a good way of ensuring that the possibility of merging articles was not unreasonably neglected. An article could always be renominated if good faith attempts to merge had failed.
I endorse that, although I don't see why the authority to merge-and-redirect should be limited to administrators. I've always found the resistance to merges puzzling. It's almost as bad as the polarizing notion that deletion debates orbit the twin suns of Keep and Delete, which are the only possible outcomes, and a "vote" to merge is in reality to be reinterpreted as a vote for one of these binary stars (which one depends on who's arguing). An argument for a merge is just that, and in these cases it's often by far the best solution.
--Michael Snow
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Michael Snow wrote:
Tony Sidaway wrote:
I wonder if we could agree to change policy to permit an administrator to "speedy redirect" a merge candidate and close an AfD where notability is the sole or principal reason given for deletion, or no reason is given. This would be a good way of ensuring that the possibility of merging articles was not unreasonably neglected. An article could always be renominated if good faith attempts to merge had failed.
I endorse that, although I don't see why the authority to merge-and-redirect should be limited to administrators. I've always found the resistance to merges puzzling. It's almost as bad as the polarizing notion that deletion debates orbit the twin suns of Keep and Delete, which are the only possible outcomes, and a "vote" to merge is in reality to be reinterpreted as a vote for one of these binary stars (which one depends on who's arguing). An argument for a merge is just that, and in these cases it's often by far the best solution.
Merge-and-redirect often *does* require admin attention, because the "proper procedure" is to perform a history merge, isn't it?
- -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Michael Snow wrote:
Tony Sidaway wrote:
I wonder if we could agree to change policy to permit an administrator to "speedy redirect" a merge candidate and close an AfD where notability is the sole or principal reason given for deletion, or no reason is given. This would be a good way of ensuring that the possibility of merging articles was not unreasonably neglected. An article could always be renominated if good faith attempts to merge had failed.
I endorse that, although I don't see why the authority to merge-and-redirect should be limited to administrators. I've always found the resistance to merges puzzling. It's almost as bad as the polarizing notion that deletion debates orbit the twin suns of Keep and Delete, which are the only possible outcomes, and a "vote" to merge is in reality to be reinterpreted as a vote for one of these binary stars (which one depends on who's arguing). An argument for a merge is just that, and in these cases it's often by far the best solution.
Merge-and-redirect often *does* require admin attention, because the "proper procedure" is to perform a history merge, isn't it?
Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQ0dAL7MAAH8MeUlWAQhQPQf+JUqu3Qc3jfeggXPZRpgwEeqL2DNy4KcJ y02ec0wcwwWE641GWdIzv4uBVZHufJAj3pqyTZyaccYxbUp9VinKzttZL9Y8ssno jDUrPUZtTIRpN9i9y4Yv+z/CPV4C3TQ9tuZb9CAQs4k7njIgWylKN+VSDtMTfybW wlu+0OItFOPRScOBX5IqRHtaE6zZAegwYYagzYj9G+tGhsgF+UQRTm9+7yi+uhvQ wihn9Cv81ExPF8LvX85a10htDF3OZKYQiBaR3IW3hwmx9fnyHBPIWBB0ybyTrTfF p7SJ+Lk6krR9VFqNREyqpFleZqPkwhX5RnFFRxKNa7Z74NzUzT9jog== =Zn+p -----END PGP SIGNATURE----- _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
Wouldn't that kill the usefulness of diffs over a period when both articles were edited? If article A was edited on December 1 and December 3 and you merge in an article edited on December 2. You get two diffs with massive changes without any explanation how that happened. You could mention the merge in an edit summary, but you'd have to list which edits have been merged in. Redirecting keeps the histories clean.
--Mgm
On Sat, 2005-10-08 at 11:09 +0200, MacGyverMagic/Mgm wrote:
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
Michael Snow wrote:
Tony Sidaway wrote:
[...] I don't see why the authority to merge-and-redirect should be limited to administrators. I've always found the resistance to merges puzzling.
The reason is that an admin is required to end the AfD, not that an admin is required to click on the "edit" button.
Merge-and-redirect often *does* require admin attention, because the "proper procedure" is to perform a history merge, isn't it?
Not often, no. The vast majority of the time, the edit history consists of one or two original edits and the addition of the AfD tag. Simply noting "merging in joesixpax's [[Mushi mushi]] article" when doing the merge should be sufficient, and the edit history is still on the redirect page.
Wouldn't that kill the usefulness of diffs over a period when both articles were edited?
Over that period? No. During that period? Sure, but that's as minor as a page-blank. In the long-run it does not affect the usefulness of the page's history.
On 10/8/05, Aaron Sherman ajs@ajs.com wrote:
On Sat, 2005-10-08 at 11:09 +0200, MacGyverMagic/Mgm wrote:
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
Michael Snow wrote:
Tony Sidaway wrote:
[...] I don't see why the authority to merge-and-redirect should be limited to administrators. I've always found the resistance to merges puzzling.
The reason is that an admin is required to end the AfD, not that an admin is required to click on the "edit" button.
Why is an admin required to end an AfD? Doesn't this contradict the statement on [[Wikipedia:Administrators]] that "Administrators are not imbued with any special *authority"?
*It used to be the case that non-admins could close any VFD with a keep result. This has been changed, though, and now we're only supposed to close "unambiguous" keep decisions. See [[Wikpedia:Deletion process]]. An admin *isn't* required to end an AfD.
Time to remove the statement about admins not having any special authority, I suppose.
- *It used to be the case that non-admins could close any VFD with a keep
result.
Ah, here's what I was looking for: [[Wikipedia:Maintenance]] "Non-admins can help keep deletion pages clean by resolving discussions. Administratorshttp://en.wikipedia.org/wiki/Wikipedia:Administratorsare needed to actually delete pages. Anyone can nominate pages for deletion."
And here's where the explicit statement was removed: http://en.wikipedia.org/w/index.php?title=Wikipedia:Maintenance&diff=199...
"There is a common misconception that only [[Wikipedia:administrators|administrators]] can deal with [[Wikipedia:Votes for deletion]]. This is not the case. Over half of the pages listed are never deleted, so at least half the work can be done by non-sysops." 04:19, 31 July 2005http://en.wikipedia.org/w/index.php?title=Wikipedia:Maintenance&oldid=19962502
Time to remove the statement about admins not having any special authority,
I suppose.
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
Merge-and-redirect often *does* require admin attention, because the "proper procedure" is to perform a history merge, isn't it?
Absolutely not. A history merge should be limited to situations such as those where a fork has been created. A proper merge is one that would permit the merge to be reversed at some time in the future, and this would require the use of a redirect, not a history merge.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tony Sidaway wrote:
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
Merge-and-redirect often *does* require admin attention, because the "proper procedure" is to perform a history merge, isn't it?
Absolutely not. A history merge should be limited to situations such as those where a fork has been created. A proper merge is one that would permit the merge to be reversed at some time in the future, and this would require the use of a redirect, not a history merge.
Ah, my mistake. Whoops.
So history merges are useful only for cut-and-paste moves?
- -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
So history merges are useful only for cut-and-paste moves?
Yes, pretty much. The problem with history merges is that the software provides no means of unmerging elements from the history. One they're there, there's no way to get them out again.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tony Sidaway wrote:
On 10/8/05, Alphax alphasigmax@gmail.com wrote:
So history merges are useful only for cut-and-paste moves?
Yes, pretty much. The problem with history merges is that the software provides no means of unmerging elements from the history. One they're there, there's no way to get them out again.
Not easily, anyway. I'm willing to try it out though :)
- -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \
On 10/8/05, Michael Snow wikipedia@earthlink.net wrote:
Tony Sidaway wrote:
I wonder if we could agree to change policy to permit an administrator to "speedy redirect" a merge candidate and close an AfD where notability is
the
sole or principal reason given for deletion, or no reason is given.
I endorse that, although I don't see why the authority to merge-and-redirect should be limited to administrators.
I agree. I don't know why I thought it should be limited to administrators. A non-administrator can close a clear non-delete debate (indeed I believe some adventurous non-administrators may have closed delete debates by putting a delete-because tag on the article).
I can see that a speedy redirect of this kind could encounter severe resistance where there is already an emerging consensus to delete. I wouldn't like to be there when something like that happened; it could be very unpleasant. There is a strand of thinking that regards any alternative to deletion in such case as illegitimately thwarting the decision-making process--perhaps this stems from a belief that the purpose of AfD is to delete rather than to debate deletion.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tony Sidaway wrote:
On 10/8/05, Michael Snow wikipedia@earthlink.net wrote:
Tony Sidaway wrote:
I wonder if we could agree to change policy to permit an administrator to "speedy redirect" a merge candidate and close an AfD where notability is
the
sole or principal reason given for deletion, or no reason is given.
I endorse that, although I don't see why the authority to merge-and-redirect should be limited to administrators.
I agree. I don't know why I thought it should be limited to administrators. A non-administrator can close a clear non-delete debate (indeed I believe some adventurous non-administrators may have closed delete debates by putting a delete-because tag on the article).
Yes, I'm one of them :) I did it for a few more-than-week-old debates where there was near-unanimous support to delete the article; of course, I would hope that any admin coming across an article tagged with {{db|per [[Wikipedia:Articles for Deletion/{{PAGENAME}}]]}} would actually check the outcome of the AfD...
- -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \