[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Culling obsolete pages on wiki.debian.org



Hi Borden,

I think that updating or removing obsolete information is a great idea, I've noticed the same issue of badly outdated info on the wiki.

Personally, I don't believe you'll step on too many toes by updating information, but deleting is another matter. Maybe prominently flagging information as outdated is a good start? But I personally agree that just deleting it is the better move. The wiki is not the place for preserving old info for historical reasons.

Thank you in advance for any work you do! One thing, you will need your email whitelisted by someone on this list (I don't know who has that authority, but I've seen quick turnarounds on requests) before you can make an account.

See you around!

-Dan

On 8/19/22 02:12 PM, Borden wrote:
> This is a follow-up to https://lists.debian.org/debian-doc/2021/09/msg00018.html, in which Popescu referred a  question about obsolete wiki content to the -www mailing list (which I personally don't think is quite right because the wiki is supposed to be documentation).
>
> Agreeing with Kesper (https://lists.debian.org/debian-doc/2021/09/msg00009.html) much of the wiki is badly outdated and clashes with other documentation (such as that in /usr/share/doc , the handbooks, mailing lists, stackexchange, etc.). A lot of it should be removed since it will just frustrate new users and lead to more traffic on -users as people ask why a squeeze (or earlier) tutorial doesn't work on their system.
>
> Anticipating "So do it yourself, then," response,  before I open a wiki.debian.org account and start slashing and burning obsolete content, I'd be grateful for some guidance on the diplomatic way to remove or update obsolete information without offending people.
>
> I would also like the list's thoughts on whether this matter should be referred back to debian-doc to work on a coherent documentation strategy that makes it easier to maintain. No sense in fixing everything to 2022 standards if it will be obsolete again in 2025.
>


Reply to: