public inbox for gentoo-doc@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Jan Kundrát" <jkt@gentoo.org>
To: gentoo-doc@lists.gentoo.org
Subject: Re: [gentoo-doc] [RFC] Marking unmaintained documents
Date: Sat, 10 Sep 2005 14:35:09 +0200	[thread overview]
Message-ID: <4322D2FD.30601@gentoo.org> (raw)
In-Reply-To: <20050909165046.GA9727@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

Sven Vermeulen wrote:
>>a) Third party article
> 
> 
> We "can" fix those, but you don't see any news site "fix" their news items
> after a year... they are kept online as a reference. You might want to write
> a new article about the same subject but more accurate - having the old
> article at your disposal can be very interesting.

Well, I'm not talking about fixing, but marking *third-party* articles
as such.

> Although I can see why you want the chapters of the older handbooks "marked"
> as out-dated, some people still use the older handbooks, especially if they
> have older release media and want a networkless installation.
> 
> But then again, that's not the point :) Personally, I don't think we need
> anything red on those handbooks - I would refer to the people's common sense
> when they are reading the 2004.3 handbook :)

Okay, you've persuaded me :-).

>>c) Translation in language which is not officially supported
> 
> 
> We don't link that language; the documents are made available if you know
> the URI (which is of course not difficult to grasp). Perhaps we can disable
> viewing it entirely unless some variable is set (?override=1) but I don't
> think we should.

Neither do I. And yes, you (well, actually someone else, probably rane
or flammie) are right, additional warning might scare users so they
won't trust the translation which is very bad for the first stage of the
process.

> Yes, I know you want something to tell the users "Beware, this document
> might contain wrong information" but then again, how would you know the
> document gives wrong directives to the user? An old hardware-related guide
> might still be perfectly valid - just not updated. Or a very recent guide
> can contain erroneous commands while it is still actively maintained.

I haven't said old document is wrong document, of course not. I was
inspired by some bugreports touching articles.

> Imo, as long as there is no AI that can inform us about the malicious
> content of a document, we can't easily mark such documents as "outdated" or
> "erroneous". I have made a small attempt by allowing us to mark a specific
> bug as a showstopper in metadoc - as a result, the document will be unlinked
> from the index page. This can be extended by adding-in a <warn> on top of
> the document, but you'll have to fight Xavier with this as this results in
> another few queries of metadoc and such and makes the XSL again more
> obscure.

Yep, the question is if it is worth the effort. I'm inclining to say
"no", based on the arguments I've received (except for third-party
articles :-) ).

Cheers,
-jkt


-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2005-09-10 12:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-08 16:56 [gentoo-doc] [RFC] Marking unmaintained documents Jan Kundrát
2005-09-08 17:07 ` Xavier Neys
2005-09-08 17:36   ` Jan Kundrát
2005-09-08 17:54     ` Xavier Neys
2005-09-08 18:12       ` Jan Kundrát
2005-09-08 19:04         ` Shyam Mani
2005-09-09 17:00           ` Sven Vermeulen
2005-09-09 16:57         ` Sven Vermeulen
2005-09-10 13:10           ` Jan Kundrát
2005-09-10 18:22             ` Sven Vermeulen
2005-09-10 20:26               ` Jan Kundrát
2005-09-14 16:55                 ` Sven Vermeulen
2005-09-14 18:20                   ` Jan Kundrát
2005-09-08 21:00   ` Alexey Chumakov
2005-09-08 21:10     ` Jan Kundrát
2005-09-08 21:11     ` Łukasz Damentko
2005-09-09  1:13 ` Flammie Pirinen
2005-09-09  6:50   ` Alexey Chumakov
2005-09-09 13:10     ` Jan Kundrát
2005-09-09 13:08   ` Jan Kundrát
2005-09-09 15:49     ` Flammie Pirinen
2005-09-09 16:26       ` Łukasz Damentko
2005-09-10 13:11         ` Jan Kundrát
2005-09-09 16:50 ` Sven Vermeulen
2005-09-10 12:35   ` Jan Kundrát [this message]
2005-09-15 11:51 ` Xavier Neys
2005-09-15 11:55 ` [gentoo-doc] " Xavier Neys
2005-09-16 13:01   ` Jan Kundrát
2005-09-17 12:06     ` Sven Vermeulen
2005-09-19  7:51   ` Alexey Chumakov
2005-09-16  9:01 ` [gentoo-doc] " Xavier Neys
2005-09-16 13:07   ` Jan Kundrát
2005-09-16 15:24     ` Xavier Neys
2005-09-16 18:51       ` Jan Kundrát
2005-09-29 15:41   ` Xavier Neys
1980-01-03 20:09     ` Alexey Chumakov
2005-09-29 16:49     ` Jose Luis Rivero
2005-09-29 22:57     ` Łukasz Damentko
2005-09-30  7:20     ` Shyam Mani
2005-09-30  8:59     ` Flammie Pirinen
2005-09-30 16:29     ` Sven Vermeulen
2005-10-02 13:11       ` Jan Kundrát
2005-10-09 10:21       ` Xavier Neys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4322D2FD.30601@gentoo.org \
    --to=jkt@gentoo.org \
    --cc=gentoo-doc@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox