- [Logged in] users should be able to view the deleted article, if it
was not deleted due to copyright or legal issues. I believe there are many articles that are being deleted that are still very educational to the public, and I don't think it is in the educational best interest of our public to ban someone's right to view a deleted article.
That brings up the question of what exactly the point of deletion is, then. Users can already get the text articles deleted for innocuous reasons from any number of friendly administrators, and if they don't know where to ask, that's something that the English Wikipedia should solve itself by editing the appropriate message.
Casual users don't even know who administrators are to ask them for the article. The point of deletion is to delete the article, but if people want to see the archive, then they can still see it, but they realize it's not an "approved" Wikipedia article. As a compromise, we could allow only those users who have previously edited the article to be able to see its review process and former article easily. At the very least, all users should be able to see that an article was formerly deleted, so they don't waste their time starting to write a new one.
- There should be direct links on the deleted page to the discussion
(and previous discussion if it was put up for AfD before), so people can more easily understand why an article was deleted.
Posting deletion logs was tried just now and changed, because it's ugly and because it partly defeats the point of deletion when it quotes the content right on the very page it was supposed to have been deleted from.
Possibly it would be interesting to allow a custom message to be added to a deleted article by admins, without actually recreating the article.
So, a user returns from their two week vacation and finds their article deleted. Even though a long process occurred where people debated it, to their eyes it looks like the article just up and disappeared for no reason. They have no way to go and even see why. So then they'll see that the time they spent on Wikipedia was wasted and reach the conclusion that "Wikipedia sucks." ... and in this case, I would have to agree with them. If something was deleted, then interested individuals should at least be given the decency to be able to see the reasons why and a link to the deletion review process.
- Email auto-notification of articles on someone's watchlist of being
proposed for AfD.
Hard to see how this would be implemented without a fair amount of special-case code being written specifically for the English Wikipedia or whatever.
This is really simple. IF article is up for deletion for more than 12 hours THEN email all users who have this article on their watch list. I say more than 12 hours so that people can't use this to just spam lots of users with inappropriate AfD status. This should work in all Wikipedias, not just English.
I hope this clarifies my points.
Best wishes, Chuck
On 6/23/07, Chuck Smith chuckssmith@gmail.com wrote:
This is really simple. IF article is up for deletion for more than 12 hours THEN email all users who have this article on their watch list. I say more than 12 hours so that people can't use this to just spam lots of users with inappropriate AfD status. This should work in all Wikipedias, not just English.
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Bryan
On 23/06/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Yet.
*cough* Deletion work queue? *cough*
Rob Church
Slightly off topic, but was the deletion log in Noarticletext merely something en.wp tried and didn't like, by transclusion of the log or something, or a MediaWiki feature?
On 23/06/07, Rob Church robchur@gmail.com wrote:
On 23/06/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Yet.
*cough* Deletion work queue? *cough*
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 23/06/07, Gary Kirk gary.kirk@gmail.com wrote:
Slightly off topic, but was the deletion log in Noarticletext merely something en.wp tried and didn't like, by transclusion of the log or something, or a MediaWiki feature?
Reverted feature.
Rob Church
On 6/23/07, Rob Church robchur@gmail.com wrote:
On 23/06/07, Gary Kirk gary.kirk@gmail.com wrote:
Slightly off topic, but was the deletion log in Noarticletext merely something en.wp tried and didn't like, by transclusion of the log or something, or a MediaWiki feature?
Reverted feature.
Of course, the link to the deletion log remains.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rob Church wrote:
On 23/06/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Yet.
*cough* Deletion work queue? *cough*
*ding ding ding* We have a winner!
Since marking things for deletion, discussing them, and then either letting them disappear or cancelling it is
a) A very common operation
b) Relatively easily codified in a queue system
it's a prime candidate for adding more software support. This is particularly so given that that software support would make it a lot easier to give people the feedback they need to:
a) not feel like they're being personally attacked or betrayed by other people
b) find out about what happens to their pages
c) get closure
- -- brion vibber (brion @ wikimedia.org)
On 6/25/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rob Church wrote:
On 23/06/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Yet.
*cough* Deletion work queue? *cough*
*ding ding ding* We have a winner!
Since marking things for deletion, discussing them, and then either letting them disappear or cancelling it is
a) A very common operation
b) Relatively easily codified in a queue system
it's a prime candidate for adding more software support. This is particularly so given that that software support would make it a lot easier to give people the feedback they need to:
a) not feel like they're being personally attacked or betrayed by other people
b) find out about what happens to their pages
c) get closure
Once upon a time, a busy programmer hacked a little extension called "Tasks". It was supposed to help semi-automate recurring tasks, from deletion requests to anon page creation petitions. It can automatically generate a page for each task in a special namespace where said task can be discussed. Tasks can be listed by type (and by page category, if enabled), and are shown in the page header or sidebar, depending on the type.
But, while some people use (used?) it on other MediaWiki installations, it got not much attention on Wiki(m|p)edia and is now all dusty and rusty, and probably doesn't work anymore after the many changes in MediaWiki that were done in the meantime. However, yours truly is confident that it could be adapted to the current system, if someone who knows the current Wikimedia setup (caching etc) intimately, like, say, someone who works there :-) would make a brave attempt to revive it.
Will it run happily ever after? We shall see in the next episode of "all my extensions"...
Magnus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Manske wrote:
Once upon a time, a busy programmer hacked a little extension called "Tasks". It was supposed to help semi-automate recurring tasks, from deletion requests to anon page creation petitions. It can automatically generate a page for each task in a special namespace where said task can be discussed. Tasks can be listed by type (and by page category, if enabled), and are shown in the page header or sidebar, depending on the type.
I'll be honest -- it didn't look like it would help with this stuff at all. For instance, it didn't handle with any of the above things that were mentioned.
All it was was yet another set of manually-maintained pages that would be hard to deal with.
- -- brion vibber (brion @ wikimedia.org)
On 6/25/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Manske wrote:
Once upon a time, a busy programmer hacked a little extension called "Tasks". It was supposed to help semi-automate recurring tasks, from deletion requests to anon page creation petitions. It can automatically generate a page for each task in a special namespace where said task can be discussed. Tasks can be listed by type (and by page category, if enabled), and are shown in the page header or sidebar, depending on the type.
I'll be honest -- it didn't look like it would help with this stuff at all. For instance, it didn't handle with any of the above things that were mentioned.
Not as it is now. But it would be the aforementioned "internal mechanism" to keep track of these things, e.g., "time since deletion request is up".
All it was was yet another set of manually-maintained pages that would be hard to deal with.
It would replace the current template-based deletion process with a tracking system (e.g., "status") and its own, seperate namespace for task-related discussion. One could view lists, e.g., "Last pages that got a deletion request", "Oldest deletion requests that are still open", etc. The comment made when closing the deletion request could be served on deleted pages, instead of the deletion log (or whatever we have there now).
We are using bugzilla instead of MediaWiki pages for a reason. The same reason would apply here, IMHO, and not only for deletion requests. One could ask "which pages in [[Category:Biology]] need cleanup", or wikification, creation, or (partial) rewrite.
Magnus
On 25/06/07, Brion Vibber brion@wikimedia.org wrote:
I'll be honest -- it didn't look like it would help with this stuff at all. For instance, it didn't handle with any of the above things that were mentioned.
All it was was yet another set of manually-maintained pages that would be hard to deal with.
I can't find the page I thought I'd seen before, so I've started making some notes at http://www.mediawiki.org/wiki/User:Robchurch/Deletion_work_queue - feedback and suggestions welcome.
Rob Church
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rob Church wrote:
On 25/06/07, Brion Vibber brion@wikimedia.org wrote:
I'll be honest -- it didn't look like it would help with this stuff at all. For instance, it didn't handle with any of the above things that were mentioned.
All it was was yet another set of manually-maintained pages that would be hard to deal with.
I can't find the page I thought I'd seen before, so I've started making some notes at http://www.mediawiki.org/wiki/User:Robchurch/Deletion_work_queue - feedback and suggestions welcome.
Looking good.
- -- brion vibber (brion @ wikimedia.org)
Since marking things for deletion, discussing them, and then either letting them disappear or cancelling it is
a) A very common operation
b) Relatively easily codified in a queue system
it's a prime candidate for adding more software support.
The major issue that has to be taken into account is different deletion policies and processes on different MediaWiki wikis. The software shouldn't be designed to endorse one particular policy. It is probably possible to design it in a general way so individual projects can use it in their own way, but it's a much more complicated feature than just hardcoding the English Wikipedia's AFD system (for example).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
Since marking things for deletion, discussing them, and then either letting them disappear or cancelling it is
a) A very common operation
b) Relatively easily codified in a queue system
it's a prime candidate for adding more software support.
The major issue that has to be taken into account is different deletion policies and processes on different MediaWiki wikis. The software shouldn't be designed to endorse one particular policy. It is probably possible to design it in a general way so individual projects can use it in their own way, but it's a much more complicated feature than just hardcoding the English Wikipedia's AFD system (for example).
How people choose to approve/disapprove/cancel things is up to the humans who use the queue, just as how (or if) to arrange voting is up to humans in the current system where any sysop _can_ delete anything at any time.
What needs to be hardcoded is not complex:
1) A way to mark things _to be_ deleted.
2) An automated list that's easy to find and review.
3) ***Automated notifications to relevant people***
4) An easy way to **get from there** to the discussion, **and not lose it**.
(For instance I find it very hard right now to find the relevant discussion when one of my old files goes up for deletion. A bot posts something on my talk page with a vague reference, and I've got no idea who to talk to or where. It's kind of annoying. :) Having a single discussion point per event, and multiple easy ways to get to it, would make it a lot easier for everyone involved -- the deleter, the creator of the resource, other interested parties.)
- -- brion vibber (brion @ wikimedia.org)
How people choose to approve/disapprove/cancel things is up to the humans who use the queue, just as how (or if) to arrange voting is up to humans in the current system where any sysop _can_ delete anything at any time.
What needs to be hardcoded is not complex:
A way to mark things _to be_ deleted.
An automated list that's easy to find and review.
***Automated notifications to relevant people***
An easy way to **get from there** to the discussion, **and not lose it**.
(For instance I find it very hard right now to find the relevant discussion when one of my old files goes up for deletion. A bot posts something on my talk page with a vague reference, and I've got no idea who to talk to or where. It's kind of annoying. :) Having a single discussion point per event, and multiple easy ways to get to it, would make it a lot easier for everyone involved -- the deleter, the creator of the resource, other interested parties.)
Already, you're making assumptions about process - you've assumed there will be some kind of discussion. Not all deletions involve discussion. Even for just the English Wikipedia, there is AFD, PROD and CSD, all of which need to be supported despite having very different processes behind them.
On 25/06/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Already, you're making assumptions about process - you've assumed there will be some kind of discussion. Not all deletions involve discussion. Even for just the English Wikipedia, there is AFD, PROD and CSD, all of which need to be supported despite having very different processes behind them.
There doesn't *have* to be a discussion, it's optional. The current plans associate a page, termed the "discussion page", with the queue item, but it could just as well be used for something else, or ignored.
I find it interesting that the English Wikipedia would reject outside opinions and offers to help make such discussions more accessible to users with little or no insider experience of them, given that the project itself has accepted there is a severe need for reform.
Rob Church
I find it interesting that the English Wikipedia would reject outside opinions and offers to help make such discussions more accessible to users with little or no insider experience of them, given that the project itself has accepted there is a severe need for reform.
Where has the English Wikipedia rejected anything? The only discussion I've seen on this subject has been this thread. Official English Wikipedia decisions are certainly not made on wikitech-l...
On 6/25/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Already, you're making assumptions about process - you've assumed there will be some kind of discussion. Not all deletions involve discussion. Even for just the English Wikipedia, there is AFD, PROD and CSD, all of which need to be supported despite having very different processes behind them.
Multiple queues might be useful. Perhaps a more general queue system would be good. For each queue, we could store
1) Who can add stuff to the queue 2) Who can remove stuff from the queue with no further effect 3) Who can remove stuff from the queue with effects, and what effects those would be 4) Who gets notified on addition to the queue and various removals from the queue 5) How long the items would stay in the queue, and what if anything would happen when their time expired 6) Whether there was a discussion page, and if so where
as well as, obviously, the actual items in the queue and their status.
Maybe I'll write up a counterproposal. Of course, something this broad would be best as an extension, I'm thinking, but it could be used for all sorts of things: deletion, protection, blocking, oversight, even sysopping, replacing the confusing mishmash of alphabet soup and special categories that currently handle all this on larger wikis. Needless to say, it would have to be suitably general to handle all this, but I think it could be done. It seems silly to pick out one particular type of queue (deletion) when all the others are so extremely similar in terms of how they work.
Multiple queues might be useful. Perhaps a more general queue system would be good. For each queue, we could store
- Who can add stuff to the queue
- Who can remove stuff from the queue with no further effect
- Who can remove stuff from the queue with effects, and what effects
those would be 4) Who gets notified on addition to the queue and various removals from the queue 5) How long the items would stay in the queue, and what if anything would happen when their time expired 6) Whether there was a discussion page, and if so where
as well as, obviously, the actual items in the queue and their status.
Maybe I'll write up a counterproposal. Of course, something this broad would be best as an extension, I'm thinking, but it could be used for all sorts of things: deletion, protection, blocking, oversight, even sysopping, replacing the confusing mishmash of alphabet soup and special categories that currently handle all this on larger wikis. Needless to say, it would have to be suitably general to handle all this, but I think it could be done. It seems silly to pick out one particular type of queue (deletion) when all the others are so extremely similar in terms of how they work.
I like it. It would be great to merge all the various policies into one automated system (using the English Wikipedia as an example [and apologising for the use of acronyms], this would be great for AFD, PROD, CSD, AIV, RFA, RFAr, CSN, DRV, RFP, CHU, etc, etc,etc).
On 25/06/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I like it. It would be great to merge all the various policies into one automated system (using the English Wikipedia as an example [and apologising for the use of acronyms], this would be great for AFD, PROD, CSD, AIV, RFA, RFAr, CSN, DRV, RFP, CHU, etc, etc,etc).
I've generalised the proposed schema to cope with multiple classes of task. It makes sense to generalise this, of course.
Rob Church
I'd like to chime in here with a request for an "incoming check sanity work queue", for newly created pages and newly uploaded files.
Checking Special:Newpages and Special:Newimages is haphazard at best - a lot of stuff slips through the cracks, and other stuff gets double checked.
Commons would find the image queue spectacularly useful, but I suspect most other wikis would find the page queue very useful.
thanks Brianna user:pfctdayelise
Brianna Laugher wrote:
I'd like to chime in here with a request for an "incoming check sanity work queue", for newly created pages and newly uploaded files.
Checking Special:Newpages and Special:Newimages is haphazard at best - a lot of stuff slips through the cracks, and other stuff gets double checked.
And then there is also Special:Recentchanges ...
To build an "incoming check sanity work queue" is the idea behind the "stable version" feature (or at least half of it).
Kurt
On 6/25/07, Brianna Laugher brianna.laugher@gmail.com wrote:
I'd like to chime in here with a request for an "incoming check sanity work queue", for newly created pages and newly uploaded files.
Checking Special:Newpages and Special:Newimages is haphazard at best - a lot of stuff slips through the cracks, and other stuff gets double checked.
Commons would find the image queue spectacularly useful, but I suspect most other wikis would find the page queue very useful.
Isn't using this in lieu of Newpages and Newimages the same as enabling patrolling? Incoming check-sanity work queues don't need discussion pages, expiration dates, automatic actions on removal from queue, notification, or any of the other fancy things we're going to implement here.
On 26/06/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 6/25/07, Brianna Laugher brianna.laugher@gmail.com wrote:
I'd like to chime in here with a request for an "incoming check sanity work queue", for newly created pages and newly uploaded files.
Checking Special:Newpages and Special:Newimages is haphazard at best - a lot of stuff slips through the cracks, and other stuff gets double checked.
Commons would find the image queue spectacularly useful, but I suspect most other wikis would find the page queue very useful.
Isn't using this in lieu of Newpages and Newimages the same as enabling patrolling? Incoming check-sanity work queues don't need discussion pages, expiration dates, automatic actions on removal from queue, notification, or any of the other fancy things we're going to implement here.
They do need some way to remove them from the queue.
AFAIK patrolling applies to all edits (not just new-page-creation edits) in all namespaces, does it not? Is there a way to locate the oldest yet-to-be-patrolled edits? Because if there isn't, it's a lot less useful.
I'm also not aware of any feature in patrolling that is particularly useful for images, i.e. you'd want to be able to see the image in one step rather than having to click through to the image page.
regards Brianna
On 6/26/07, Brianna Laugher brianna.laugher@gmail.com wrote:
They do need some way to remove them from the queue.
Yes, by marking them patrolled. :)
AFAIK patrolling applies to all edits (not just new-page-creation edits) in all namespaces, does it not? Is there a way to locate the oldest yet-to-be-patrolled edits? Because if there isn't, it's a lot less useful.
Yes, it does. And yes, there is: just select "hide patrolled" on recent changes (that will order them backwards, I suppose).
I'm also not aware of any feature in patrolling that is particularly useful for images, i.e. you'd want to be able to see the image in one step rather than having to click through to the image page.
True, but that's not addressed by this proposal either.
On 6/25/07, Thomas Dalton thomas.dalton@gmail.com wrote:
How people choose to approve/disapprove/cancel things is up to the humans who use the queue, just as how (or if) to arrange voting is up to humans in the current system where any sysop _can_ delete anything at any time.
What needs to be hardcoded is not complex:
- A way to mark things _to be_ deleted.
Tasks extension can do that already.
- An automated list that's easy to find and review.
Tasks extension can do that already.
- ***Automated notifications to relevant people***
Would have to be written; could be largely outsourced to Brion's notification mechanism :-)
- An easy way to **get from there** to the discussion, **and not lose it**.
Tasks extension can do that already.
(For instance I find it very hard right now to find the relevant discussion when one of my old files goes up for deletion. A bot posts something on my talk page with a vague reference, and I've got no idea who to talk to or where. It's kind of annoying. :) Having a single discussion point per event, and multiple easy ways to get to it, would make it a lot easier for everyone involved -- the deleter, the creator of the resource, other interested parties.)
Already, you're making assumptions about process - you've assumed there will be some kind of discussion. Not all deletions involve discussion. Even for just the English Wikipedia, there is AFD, PROD and CSD, all of which need to be supported despite having very different processes behind them.
Tasks extension supports as many task types as you want. That can include different types of deletion.
Magnus (yes, I keep on annoying you:-)
(For instance I find it very hard right now to find the relevant discussion when one of my old files goes up for deletion. A bot posts something on my talk page with a vague reference, and I've got no idea who to talk to or where. It's kind of annoying. :)
It more than just annoying - it's actually mildly sadistic.
When I get those bot notifications, the message I interpret is basically this:
"Something that you care about may be deleted soon, following a convoluted discussion held at some obscure location (and of course, I'm certainly not going to tell you that location - because where would be the fun in that?), involving a group of unnamed people (I _could_ tell you their names, but it's just more fun to make you think ill of everyone), for reasons which may or may not have been disclosed (I _could_ tell you the reason, but it's more fun to think of the Wikipedia as one big game of totally random Russian-roulette for deleting data, don't you think?) ... and no matter what happens, you will not be notified of the outcome (I _could_ give you closure, but perpetuating fear, doubt, and uncertainty is _so_ much more entertaining). Any failure to act on your behalf will be taken as full acceptance of this deletion. Thank you for your cooperation in this matter! -- signed, the Sadistic Deletion Notification Bot."
-- All the best, Nick.
On 26/06/07, Nick Jenkins nickpj@gmail.com wrote:
It more than just annoying - it's actually mildly sadistic. When I get those bot notifications, the message I interpret is basically this: "Something that you care about may be deleted soon, following a convoluted discussion held at some obscure location (and of course, I'm certainly not going to tell you that location - because where would be the fun in that?), involving a group of unnamed people (I _could_ tell you their names, but it's just more fun to make you think ill of everyone), for reasons which may or may not have been disclosed (I _could_ tell you the reason, but it's more fun to think of the Wikipedia as one big game of totally random Russian-roulette for deleting data, don't you think?) ... and no matter what happens, you will not be notified of the outcome (I _could_ give you closure, but perpetuating fear, doubt, and uncertainty is _so_ much more entertaining). Any failure to act on your behalf will be taken as full acceptance of this deletion. Thank you for your cooperation in this matter! -- signed, the Sadistic Deletion Notification Bot."
Betacommand runs most of these. He's not actually a dick :-) But he's not a great writer. Try to work out a more useful wording with him.
- d.
Bryan Tong Minh wrote:
On 6/23/07, Chuck Smith chuckssmith@gmail.com wrote:
This is really simple. IF article is up for deletion for more than 12 hours THEN email all users who have this article on their watch list. I say more than 12 hours so that people can't use this to just spam lots of users with inappropriate AfD status. This should work in all Wikipedias, not just English.
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Bryan
Could be done with a bot.
-Gurch
Hoi, If it can be done by a bot, it is done by software.. Being able to do things with a bot is essentially something that you do rarely. When it is done continually, you want to make it part of the software proper.
The question then is; does it make sense. to do it. and this may get you to implement it with a bot.. because does it ? Thanks, GerardM
On 6/24/07, Matthew Britton matthew.britton@btinternet.com wrote:
Bryan Tong Minh wrote:
On 6/23/07, Chuck Smith chuckssmith@gmail.com wrote:
This is really simple. IF article is up for deletion for more than 12 hours THEN email all users who have this article on their watch list. I say more than 12 hours so that people can't use this to just spam lots of users with inappropriate AfD status. This should work in all Wikipedias, not just English.
So how does the software know that a page is up for deletion? Pending deletions are done using templates, not by some internal mechanism by the software.
Bryan
Could be done with a bot.
-Gurch
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chuck Smith wrote:
- [Logged in] users should be able to view the deleted article, if it
was not deleted due to copyright or legal issues. I believe there are many articles that are being deleted that are still very educational to the public, and I don't think it is in the educational best interest of our public to ban someone's right to view a deleted article.
That brings up the question of what exactly the point of deletion is, then. Users can already get the text articles deleted for innocuous reasons from any number of friendly administrators, and if they don't know where to ask, that's something that the English Wikipedia should solve itself by editing the appropriate message.
Casual users don't even know who administrators are to ask them for the article. The point of deletion is to delete the article, but if people want to see the archive, then they can still see it, but they realize it's not an "approved" Wikipedia article. As a compromise, we could allow only those users who have previously edited the article to be able to see its review process and former article easily. At the very least, all users should be able to see that an article was formerly deleted, so they don't waste their time starting to write a new one.
Next, people will start asking to view oversighted pages :P
Currently if you go to create a previously-deleted page you see a message with the deletion log.
- There should be direct links on the deleted page to the discussion
(and previous discussion if it was put up for AfD before), so people can more easily understand why an article was deleted.
Posting deletion logs was tried just now and changed, because it's ugly and because it partly defeats the point of deletion when it quotes the content right on the very page it was supposed to have been deleted from.
Possibly it would be interesting to allow a custom message to be added to a deleted article by admins, without actually recreating the article.
So, a user returns from their two week vacation and finds their article deleted. Even though a long process occurred where people debated it, to their eyes it looks like the article just up and disappeared for no reason. They have no way to go and even see why. So then they'll see that the time they spent on Wikipedia was wasted and reach the conclusion that "Wikipedia sucks." ... and in this case, I would have to agree with them. If something was deleted, then interested individuals should at least be given the decency to be able to see the reasons why and a link to the deletion review process.
Get the reason with Special:Log/delete?page={{PAGENAME}} Add to [[MediaWiki:Noarticletext]] {{#ifexist:Wikipedia:Articles_for_deletion/{{PAGENAME}}| Check the [[Wikipedia:Articles_for_deletion/{{PAGENAME}}|deletion vote]].}}
- Email auto-notification of articles on someone's watchlist of being
proposed for AfD.
Hard to see how this would be implemented without a fair amount of special-case code being written specifically for the English Wikipedia or whatever.
This is really simple. IF article is up for deletion for more than 12 hours THEN email all users who have this article on their watch list. I say more than 12 hours so that people can't use this to just spam lots of users with inappropriate AfD status. This should work in all Wikipedias, not just English.
Not so simple, but there could be some background process running at midday & midnight and sending batches of emails. It would need to be on the main server though, as the toolserver doesn't have personal data like watchlists.
wikitech-l@lists.wikimedia.org