Subject:
Re: Beginning of outline for policies
From:
Tabatha Persad ####@####.####
Date:
16 May 2002 04:15:59 -0000
Message-Id: <20020516041532.UTON12519.rwcrmhc53.attbi.com@there>
On Wednesday 15 May 2002 18:04, David Lawyer wrote:
>
> 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?
As I address some of your comments, please don't consider me
adversarial. I'd like to understand your point of view...
I didn't know the term "editor" was an issue. That's really what we
do, or at least what I signed up to do when I spoke with Joy. It's
my understanding that I AM editing these documents I pick up for
grammar and spelling. Anything beyond those two items would require
review with the author. Just a review implies, "This is what I found
wrong, what are YOU going to do about it?" Correcting a typo isn't a
review process, it's an editing process.
Also, my goal is not to remove the author's voice, but make it
clearer, and I take that responsibility seriously, since I want to
help the quality of the documentation I also use from the LDP.
> > 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.
When I last checked there were approximately 30 volunteer
editors/reviewers listed at the LDP. I can't speak for the rest of
them, but I am readily available, have a high bandwidth, and joined
the project to get involved for a very long time to come.
I can only surmise that in the case of the PHP-HOWTO, a simple
language review would not be sufficient for this document. It will
probably require the help of someone or a group who are familiar with
the technical aspects of PHP to address this doc, or re-create it
altogether.
> > 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.
Do you propose then that the editing group (of volunteers) be
disbanded? Given the current state of much of the documentation, is
it so bad that there is a team willing to take on this
responsibility? In my case, getting rid of editors means that
unless I am an author, I don't have anything to contribute to the
LDP.
> > * 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.
I'd have to agree to disagree with you on this point. There are many
documents that I am not technically adept to edit/review. I am
certainly not going to follow the instructions on every HOWTO to
determine whether the syntax and procedure of each and every one is
valid. I do feel that I am skilled enough to perform the language
reviews for English documents.
> > * 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.
No, but when we have your Licensing HOWTO that would help immensely!
> > 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.
Actually this point is covered in the Reviewer HOWTO but may not be
obvious to authors, who might not automatically think to read that
document, being that they are authors, not reviewers. On the other
hand, if they are waiting longer than the specified one week, then
they might actually go dig up that HOWTO!
> > * How are editors assigned?
>
> reviewers
If that was all I did I'd agree on that one... and while
editors/reviewers are not necessarily assigned, new documents are
forwarded to someone immediately for review, while we are free to
pick up existing documents as our bandwidth permits. Once we are
at a point where everything in the collection has been reviewed and
quality improved, this responsibility might level off somewhat.
> They can look at my mini-HOWTO on LinuxDoc :-)
It's a great doc too! Linuxdoc was the first dtd I learned. I
realize we have a reference page for resources on this subject too,
so having resources in this proposed doc could be duplication of
effort.
> > * Discussing recommendations with your editor.
>
> Presently, we have no editor for each doc.
No, but once one of us volunteers to pick it up and assign ourselves
the work, there is an editor for THAT doc, and a starting point for
the author, who could definitely seek help from another
editor/reviewer or the list if seeking another opinion.
> > * 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.
Objections are something best dealt with amongst a group of one's
peers, so I think the mailing list is a great medium for these
issues. As an author I would be thrilled to have someone proofread
my work and make the grammar and spelling changes for me. In some
cases where the language issues bleed into the technical parts of a
document, it's time to talk to the author, since I may not understand
the technical message he/she is trying to convey.
Another point: not every HOWTO writer's first language is English, so
making the author proofread in a language that is a struggle to begin
with is not fair. I'd just as well edit the typos and grammar errors
and then get on with the actual review, which may contain suggestions
to carry some type of FDL, move several in-line thank yous to a
"Credits" section, use another format other than the TXT file they
submitted originally (I'm mainly talking about new docs here btw, but
much of the same can apply to existing work).
On a final note, it may be that some of the questions I asked
inspired the proposal of this document. I tend to ask MANY
questions, and do get these writing urges to document things. If
David Merrill and Joy had not suggested I put something together, I
doubt if I would have of my own volition. I re-read the Manifesto
yesterday evening to make sure I hadn't missed anything, and then I
noticed that you are the author of the document. So please know that
I didn't start this to step on your toes!
Tabatha
