public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Documentation linkage or location
Date: Thu, 23 Oct 2003 10:51:01 +0200	[thread overview]
Message-ID: <200310231051.01383.pauldv@gentoo.org> (raw)
In-Reply-To: <20031023073039.GA1697@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think we might consider a split on documentation target

On Thursday 23 October 2003 09:30, Sven Vermeulen wrote:
> (1) Link all documentation on the documentation index, but keep the
> documentation where it is. This however has one big disadvantage,
> which is that only a very very very small part of the documentation
> team can do editing on those documents (one person most of the time).
> The result is that installation-related documents are quickly outdated
> (our installation guide changes a lot, and with the upcoming handbook
> this won't change :) because the documentation team can't update the
> related documents.

Developer related documentation can go here, however we need to get some 
good procedure for publishing links to these documents in an index.

>
> (2) Move all documentation in the documentation repository and link
> those on the index page. This however has one big disadvantage, which
> is that only a small part of the respective project (clusters,
> hardened, metastructure) have access to the documentation for updates.
>

User documentation should go here. It is more critical on correctness and 
readability. It probably also creates more confusion if it not 
maintained by documentation.

> In the eyes of the documentation development, this latter is
> preferred: at least one person of each project has (or should have)
> access to the documentation cvs (see the "Project Doc Editor" at
> http://www.gentoo.org/proj/en/gdp). Further more, updates to
> documentation shouldn't be a one-man change -- a second "opinion" must
> be established (we just call it reviewing) so that no major mistakes
> are made (we are all human).

> Are there objections if I would suggest to implement the second
> proposal (i.e. migrate documentation to the documentation directory)?

For user related docs not at all. I think that developer related 
documentation (esp. that which is still in state of development) can 
stay in the project directories. However I agree with robbat2 on 
exploring ACL's

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/l5Z1bKx5DBjWFdsRArSFAJ4qapZKiLAxHSp8XmbgpsopaHH2hACfYTPW
JlOYnwo2infMW7tijv3/5mY=
=vrCM
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2003-10-23  8:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-23  7:30 [gentoo-dev] Documentation linkage or location Sven Vermeulen
2003-10-23  7:38 ` Robin H. Johnson
2003-10-23  9:49   ` Sven Vermeulen
2003-10-23  8:51 ` Paul de Vrieze [this message]
2003-10-23  9:52 ` Donnie Berkholz
2003-10-23 13:33   ` Sven Vermeulen
2003-10-23 17:09     ` donnie berkholz
2003-10-24  8:45       ` Sven Vermeulen

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=200310231051.01383.pauldv@gentoo.org \
    --to=pauldv@gentoo.org \
    --cc=gentoo-dev@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