Wiki article deletion policy

JKSH

Hi,

We're currently in the middle of a large cleanup of the wiki following migration, and have a number of articles marked for deletion: https://wiki.qt.io/Category:Delete

I think we should decide on a policy/procedure on how to handle these. Here's a starting proposal:

If the article is imported empty (except for a collection of categories, perhaps), an admin can delete it immediately.
If the article is not empty, nominate it for deletion with "Category:Delete".
If someone disagrees with the nomination, raise it in the Talk Page for discussion.
If an admin (who didn't nominate the deletion) agrees with the nomination, and there is no disagreement in the Talk Page, delete it.

Thoughts?

I'd also like to discuss specific categories of articles. Should we delete or archive/redirect them?:

Articles about Qt that are no longer relevant (e.g. Support-for-symbian).
- Arguments for archiving: They're a snapshot of Qt history.
- Arguments for deletion: They tend to be written in "present day" tone, which might confuse readers. Cleaning/updating them is also a big task.
Articles about the Qt Project website/wiki that are no longer relevant (e.g. Site moderators-Improvements-for-DocNote-module).
- Similar arguments as before.
Articles that are duplicates, where the only difference is in title case (e.g. How to USe QPushButton).
- These came because ExpressionEngine is case-insensitive, but MediaWiki is case-sensitive.
- Arguments for redirecting: Reduces the likelihood of link rot, when the redirection is enabled from the old wiki to the new wiki.
- Arguments for deletion: There are 2^(N-1) possible titles for each ExpressionEngine page, where N is the number of alphabetical characters in the title. We can't catch them all.

sierdzio

I like the proposal.

As for specific cases:

a bit against myself, but I would vote for keeping the Symbian stuff. Although it's old and mostly unused now, it is still kind of supported (Qt 4) and perhaps some people still need them. Maybe we coould get some viewing statistics and delete them if they are not being viewed often?
not relevant Qt Project/ wiki pages: I think they should be deleted
duplicate articles: I think they should be deleted

tekojo

@JKSH said:

Hi,

We're currently in the middle of a large cleanup of the wiki following migration, and have a number of articles marked for deletion: https://wiki.qt.io/Category:Delete

I think we should decide on a policy/procedure on how to handle these. Here's a starting proposal:

If the article is imported empty (except for a collection of categories, perhaps), an admin can delete it immediately.

There is a caveat here. The import didn't understand redirects. Before deletion, the admin in question needs to check that the same page does not exist with dashes instead of underscores (or the other way round). If the forwarding to page exists, then add the #REDIRECT [[Page_name]] line to the empty page.

If the article is not empty, nominate it for deletion with [[Category:Delete]].

If someone disagrees with the nomination, raise it in the Talk Page for discussion.

If an admin (who didn't nominate the deletion) agrees with the nomination, and there is no disagreement in the Talk Page, delete it.

Thoughts?

I'd also like to discuss specific categories of articles. Should we delete or archive/redirect them?:

Articles about Qt that are no longer relevant (e.g. Support-for-symbian).

Arguments for archiving: They're a snapshot of Qt history.

Arguments for deletion: They tend to be written in "present day" tone, which might confuse readers. Cleaning/updating them is also a big task.

I would archive them and add an archived banner to the topic. Thus users will know that the pages in question are not present day material. Deleting is pretty radical, as for example, I have received a question on Symbian development still this year.

Articles about the Qt Project website/wiki that are no longer relevant (e.g. Site moderators-Improvements-for-DocNote-module).

Similar arguments as before.

Again I'd archive. I don't read these articles as often as I should, but they contain sensible material.
(I'm starting to feel like a pack rat here)

Articles that are duplicates, where the only difference is in title case (e.g. How to USe QPushButton).

These came because ExpressionEngine is case-insensitive, but MediaWiki is case-sensitive.

Arguments for redirecting: Reduces the likelihood of link rot, when the redirection is enabled from the old wiki to the new wiki.

Arguments for deletion: There are 2^(N-1) possible titles for each ExpressionEngine page, where N is the number of alphabetical characters in the title. We can't catch them all.

It's not as bad as that. I have found a very limited number of these. However I vote for deletion of spelling mistakes. From the old site statistics these pages were rarely accessed and links to them from the outside are very rare.

SGaist

Hi,

Nice proposition, I was wondering if we should try to initiate an equivalent of Bugsy Tuesday or a Fix and Polish wiki week to help clean it up ?

tekojo

@SGaist said:

Hi,

Nice proposition, I was wondering if we should try to initiate an equivalent of Bugsy Tuesday or a Fix and Polish wiki week to help clean it up ?

Yes we should :)

I have that on my ideas list. I was thinking of a wiki cleanup week now that the migrations are done.

JKSH

Ok, the consensus is that we should minimize deletions, so I've written a cleanup guideline instead of a deletion policy: https://wiki.qt.io/Category:Articles_needing_cleanup

We now have a new {{ Outdated }} template to flag historical articles.

Wiki cleanup week sounds good!

tekojo

@JKSH said:

Ok, the consensus is that we should minimize deletions, so I've written a cleanup guideline instead of a deletion policy: https://wiki.qt.io/Category:Articles_needing_cleanup

We now have a new {{ Outdated }} template to flag historical articles.

Thank you!

Had to edit that a bit, as there is a known bug in the system, that eats the contents of curly brackets if the content isn't separated by spaces.

Wiki cleanup week sounds good!

I'll start thinking of the practicalities and open a thread here once I have a minimum viable idea in my head.