old-www/pub/Linux/docs/ldp-archived/mail_archives/ldp-discuss/msg00008.html

221 lines
9.9 KiB
HTML

<!-- MHonArc v2.5.0b2 -->
<!--X-Subject: QC draft -->
<!--X-From-R13: Uhlyurz Omane <thlyurzNbrvy.dp.pn> -->
<!--X-Date: Thu, 9 Sep 1999 18:13:25 &#45;0400 (EDT) -->
<!--X-Message-Id: 19990910001209.A20181@victis.oeil.qc.ca -->
<!--X-Content-Type: multipart/signed -->
<!--X-Derived: pgp00002.pgp -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML//EN">
<html>
<head>
<title>QC draft</title>
<link rev="made" href="mailto:guylhem@oeil.qc.ca">
</head>
<body>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
<hr>
[<a href="msg00007.html">Date Prev</a>][<a href="msg00009.html">Date Next</a>][<a href="msg00003.html">Thread Prev</a>][<a href="msg00010.html">Thread Next</a>][<a href="maillist.html#00008">Date Index</a>][<a href="threads.html#00008">Thread Index</a>]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<h1>QC draft</h1>
<hr>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<ul>
<li><em>To</em>: LDP discuss &lt;<A HREF="mailto:ldp-discuss@lists.linuxdoc.org">ldp-discuss@lists.linuxdoc.org</A>&gt;</li>
<li><em>Subject</em>: QC draft</li>
<li><em>From</em>: Guylhem Aznar &lt;<A HREF="mailto:guylhem@oeil.qc.ca">guylhem@oeil.qc.ca</A>&gt;</li>
<li><em>Date</em>: Fri, 10 Sep 1999 00:12:09 +0200</li>
<li><em>Resent-cc</em>: recipient list not shown: ;</li>
<li><em>Resent-date</em>: 9 Sep 1999 22:13:19 -0000</li>
<li><em>Resent-from</em>: <A HREF="mailto:ldp-discuss@lists.debian.org">ldp-discuss@lists.debian.org</A></li>
<li><em>Resent-message-id</em>: &lt;nijEF.A.ypC._DD23@murphy&gt;</li>
<li><em>Resent-sender</em>: <A HREF="mailto:ldp-discuss-request@lists.debian.org">ldp-discuss-request@lists.debian.org</A></li>
</ul>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<hr>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<pre>
Here's Alessandro work on QC.
I think we could use it as &quot;QC manifesto&quot;
******************************
There are two versions: the first includes the rationales behind any
paragraph and the second is just the rules (for people with little time
to read).
Proposal for a Quality Control Group
Teams of the group are volunteers and being part of the group doesn't
reequire devoting any predefined amount of work to the QC
needs. People interested in being part of the QC group must withstand
approval of the LDP leader, upon presentation of a resume or other
self-supporting evicence. (Rationale: the quality-control group must
be quality-controlled as well; we must prevent unfair people to enter
the QC group in order to damage the LDP. Also, we must prevent
incompetent people to judge LDP authors, even if in good faith, as
that would damage the LDP anyways).
The QC people is subscribed to a closed mailing list. Every new LDP
document is forwarded to the list in source form, maybe by having the
list itself as a subscriber of ldp-submit. When a QC member wants to
review a document, the member must express this intention by sending a
&quot;lock&quot; message to the list, to inform other reviwers that the document
is already taken. In case of multiple replies, the first one is
effective (according the ID of the message within the mailing list),
unless the reviewers agree differently via private email. (Rationale:
the list must be kept low-traffic: we don't need another place for
discussion; on the other hand all reviewers should have direct access
to reviewable material without human intervention).
Submitted documents appear immediately in a &quot;beta&quot; area in the LDP ftp
site, maybe only in source form (sgml or whatever is agreed upon).
The QC group should approve the new document within one week; if no QC
approval arrives within a week, the document is moved to the normal
ftp areas anyway, like any &quot;normal&quot; document. (Rationale: the
information must be made availabe as soon as possible to the general
public, and the QC group cannot be allowed to slow release of the
documentation. The &quot;beta&quot; area allows information-eager people to
access to the latest and greatest independent of the QC week and the
possible extra delay before the document is moved to its proper
place. Compiling and mirroring all the output formats for those few
people would be an unneedeed waste of network resources).
The reviewer should sort any problem directly with the author, who is
prepared to be be responsive during the QC week. If an agreement can
not be reached, the document is either reviewed by another QC member
(releasing the lock on the QC list and allowing anothere week of
&quot;beta&quot; status) or the whole question is brought to the LDP leader or
HOWTO maintainer. (Rationale: personal criticism should not be
performed in public and the issues can usually sorted out
friendly. Sometimes, however, the author and reviewer may not come to
an agreement for a variety of reasons, including character
differences; in this case a second chance must be allowed).
The LDP leader and HOWTO maintainer are allowed to refuse a document,
if it was considered unacceptable by at least two QC people. This does
not prevent the author for releasing the document through other means,
it just won't be distributed as part of the LDP and using the LDP
resources. (Rationale: a negative judgement doesn't deny anyone the
right to speak, and this must be stated clearly before we are called
fascists or anything similar).
Documents that passed QC review will carry the QC note just after the
title. A document that gets no QC review within the allowed time will
be part of the LDP without the QC mark. The QC approval will refer to
a specific version of the document, and an unreviewed release will
still carry its QC approval for the last version that was
approved. (Rationale: the readership must benefit from QC, thus being
warned whenever a document has been reviewed and when it didn't. On
the other hand, the QC group can feel less compelled to review a new
revision of a document that was already QC'd but the readership must
know about that and adapt their confidence in the document
accordingly).
----------------------------------------
Proposal for a Quality Control Group
Teams of the group are volunteers and being part of the group doesn't
reequire devoting any predefined amount of work to the QC
needs. People interested in being part of the QC group must withstand
approval of the LDP leader, upon presentation of a resume or other
self-supporting evicence.
The QC people is subscribed to a closed mailing list. Every new LDP
document is forwarded to the list in source form, maybe by having the
list itself as a subscriber of ldp-submit. When a QC member wants to
review a document, the member must express this intention by sending a
&quot;lock&quot; message to the list, to inform other reviwers that the document
is already taken. In case of multiple replies, the first one is
effective (according the ID of the message within the mailing list),
unless the reviewers agree differently via private email.
Submitted documents appear immediately in a &quot;beta&quot; area in the LDP ftp
site, maybe only in source form (sgml or whatever is agreed upon).
The QC group should approve the new document within one week; if no QC
approval arrives within a week, the document is moved to the normal
ftp areas anyway, like any &quot;normal&quot; document.
The reviewer should sort any problem directly with the author, who is
prepared to be be responsive during the QC week. If an agreement can
not be reached, the document is either reviewed by another QC member
(releasing the lock on the QC list and allowing anothere week of
&quot;beta&quot; status) or the whole question is brought to the LDP leader or
HOWTO maintainer.
The LDP leader and HOWTO maintainer are allowed to refuse a document,
if it was considered unacceptable by at least two QC people. This does
not prevent the author for releasing the document through other means,
it just won't be distributed as part of the LDP and using the LDP
resources.
Documents that passed QC review will carry the QC note just after the
title. A document that gets no QC review within the allowed time will
be part of the LDP without the QC mark. The QC approval will refer to
a specific version of the document, and an unreviewed release will
still carry its QC approval for the last version that was
approved.
--
Guylhem Aznar, Linux Documentation Project leader: <A HREF="http://www.linuxdoc.org">http://www.linuxdoc.org</A>
Clef PGP/PGP key: <A HREF="http://oeil.qc.ca/~guylhem">http://oeil.qc.ca/~guylhem</A>
Chez moi/At home: guylhem \@/ oeil.qc.ca
Anywhere/Partout: guylhem-pager \@/ oeil.qc.ca
</pre>
<p><a href="pgp00002.pgp" >PGP signature</a></p>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="00010" href="msg00010.html">Re: QC draft</a></strong>
<ul><li><em>From:</em> &quot;Mr. Poet&quot; &lt;poet@linuxports.com&gt;</li></ul></li>
<li><strong><a name="00011" href="msg00011.html">Re: QC draft</a></strong>
<ul><li><em>From:</em> P Jenner &lt;psj@mustec.eu.org&gt;</li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00007.html">Re: Local LDPs</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00009.html">Re: QC draft</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00003.html">Gathering new HOWTOs?</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00010.html">Re: QC draft</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#00008"><strong>Date</strong></a></li>
<li><a href="threads.html#00008"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>