discuss: Re: Beginning of outline for policies
Subject:
Re: Beginning of outline for policies
From:
David Lawyer ####@####.####
Date:
15 May 2002 23:16:09 -0000
Message-Id: <20020515150404.H368@lafn.org>
On Tue, May 14, 2002 at 04:09:01PM -0400, Tabatha Persad wrote:
> Hi there everyone,
>
> I've started a rough sketch. Of course, there could be more issues that we
> need addressed and added, but I wanted to throw something out there and see
> what comes back!
Since we already have the Manifesto, we might work on revising it. I'll
shortly make a post regarding this.
The situation with the LDP is that we've always been short of people to
do the work and thus we must have flexible policies which permit the
highest priority jobs to be done first. Giving definite answers to many
to the questions poised below for certain policies, would interfere with
the required flexibility. So I think that it would in some cases be
counterproductive to establish many of the policies listed below.
One item that needs doing is to have a webpage for docs that need
maintainers. We really have no such page now because the "unmaintained"
page includes obsolete docs that need no maintainer. Also, some
maintained docs need a new maintainer. So I would say that it's high
priority to discuss this and do something about it.
Another comment is that I'm not sure if LDP should have any "editors".
Most of them could be called "reviewers". The word "editor" sounds too
dictatorial. What about saying that Joy is the "quality control" person.
Her title would just be "quality control". What else could we call
her besides editor?
>
> Here's a start:
>
> 1. Overview of Editing Processes * Introduction - This could contain
> some information about the fact that the LDP has a team of editors to
What team? If we had such a team, why would Joy need to try to recruit
someone for the PHP-HOWTO.
> assist, and an overall picture of what service editors are trying to
> provide to authors. It might take the scare out of the process to
> know that editors are working to help improve quality and readability,
> not hack apart the author's work. A good area to establish the
> mission of the LDP and why this is beneficial to the community.
Just have no editors. Problem solved.
> * Language Review - This will be a broad description of the sentence
> level editing performed by editors, and examples of other things that
> may be recommended or changed by editors. This should outline what
> types of changes the editor would make, as well as when author
> consultation would and would not be necessary.
This can often be combined with Technical Review. We could just call
it review for short. There's also a brief review by sampling parts of the
doc. Since we are lucky if we can get any kind of review on all the
docs, we should not worry too much about classifying reviews by type.
There's a whole gamut of types of reviews.
> * Technical Review - This would be the same type of review but for the
> technical content. It is doubtful that the LDP could do this alone,
> but we've been discussing the idea of bug tracking, and creating ways
> to enable the community to participate with the right system in place.
> We need to develop some info for this section as soon as it's
> definitive.
>
> * License Review - Many existing and new documents come into the LDP
> without a license, sometimes without even a copyright. Although
> publication of the author's work can probably constitute as copyright,
> without the license, either LDP or GFDL in place, this results in a
> document that no one effectively has permission to change. The
> license protects the author and this should be stressed. It should be
> included in their work - being implied because it simply resides in
> the LDP repository is not sufficient.
It doesn't have to be a separate License Review.
> 2. Procedure for New Submissions
> * How long does the review take once I submit my document?
This will vary, but if it's too long, then the doc is published with
only a cursory review. No need to specify this.
> * How are editors assigned?
reviewers
> * What type of content should be submitted?
Again, we don't need any definite rules on this. It's obvious from our
Manifesto that the docs need to relate to Linux. The details of just
how closely they must relate to Linux is decided on a case by case
basis.
> * What type of text formats should be submitted?
Specified in the Manifesto.
> * Where can authors obtain help to format their text?
They can look at my mini-HOWTO on LinuxDoc :-)
> * Discussing recommendations with your editor.
Presently, we have no editor for each doc.
> * What you can do if you object to recommendations.
If we only have a reviewer, then it's understood that you don't really
have to follow the recommendations. But if the resulting doc is poor,
then the staff can reject the doc. It's kind of negative to even
mention what happens in extreme cases where the author is unreasonable.
But it might be mentioned somewhere that in extreme cases the LDP has
been known to reject documents.
> * What if you have not responded to the review?
I think that since almost all authors will respond to a review, this
needs to be handled on a case by case basis. Before any review is even
started, it must be ascertained that the author can be reached and
responds to emails.
> 3. Procedure for Existing Documentation
> * When do documents come up for review?
> * How does the review differ from a new submission?
> * How are editors assigned, and how long will it take?
> * Discussing recommendations with your editor.
> * What you can do if you object to recommendations.
> * What if you have not responded to the review?
My comments here are similar as in 2. above.
>
> 4. Procedure for Unmaintained Documentation
> * How does the LDP determine a document is unmaintained?
> * What steps are taken to contact an author who has not responded?
> * Where can a list of unmaintained documentation be found?
You mean docs that need a maintainer
> * How do I volunteer to take responsibility for an unmaintained
document?
This should be on the same webpage with the list to docs that need a
maintainer
> * Will the LDP review or maintain the document in any way until there is a volunteer?
The LDP is itself volunteers, so nothing gets done unless someone
volunteers.
> _______________
>
> I realize that a couple of sections are the same in 2 and 3, but I took into
> consideration the process might be different with two different types of
> documentation, new vs existing.
>
> Feedback, propose your changes, tell me if it's in the wrong order, you name
> it! (ducking)
>
> Tab
>
>
>
> --
> Tabatha Persad
> Web: http://www.merlinmonroe.com
> The Linux Counter Project Area Manager US:wa (http://counter.li.org)
> Linux Documentation Project Editor (http://www.tldp.org)
> Gnu Writing Movement Project Developer (http://savannah.gnu.org/projects/gwm)
>
> ______________________
> http://lists.tldp.org/
>
>
>
David Lawyer
