[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Slashdot reply (draft 0.1)
> -----Original Message-----
> From: Guylhem Aznar [mailto:email@example.com]
> Sent: Friday, February 11, 2000 1:26 AM
> To: Gregory Leblanc
> Cc: firstname.lastname@example.org
> Subject: Re: Slashdot reply (draft 0.1)
> The author seems to mix Hugo van der Kooij and Norman Walsh. So this
> bucket of water will cool the heat of this flame.
Oh, darn, sorry about that. I know who both of you are, and I didn't get
the two of you mixed up, but "van der Walhs" is stuck in my brain from a
chemistry course. My sincerest appologizies.
> On Fri, Feb 11, 2000 at 12:23:24AM -0800, Gregory Leblanc wrote:
> > <flame>This is really stupid. I'm sure there's a logic
> behind this, but I
> > can't grasp what it is. I understand why these were put in
> place, but not
> > why they're still in use. We should abolish silly
> distinctions to allow
> For simplicity.
> > LDP/
> > LDP/FAQ/
> > LDP/HOWTO/ (put the actual plain text HOWTO documents here)
> > LDP/HOWTO/DocBook/ (put the DocBook source here)
> > LDP/HOWTO/LinuxDoc/ (put the LinuxDoc source here)
> > LDP/HOWTO/pdf/ (put pdf output here)
> > LDP/HOWTO/ps/ (put PS output here)
> > LDP/HOWTO/tex/ (put tex output here)
> > LDP/HOWTO/html/ (put html output here)
> > LDP/HOWTO/stuff I missed/ (put the stuff I missed here)
> > LDP/GUIDE/
> Too complicated.
> Even if we know the difference between a FAQ and an HOWTO,
> most ppl take
> this as "documentation".
I don't know if I'd agree with this, but I have no supporting evidence. The
names seem fairly obvious to me, and if we have a blurb above each section
explaining what that type of document is, then it should be clear enough on
how to find things. Greg F had a good suggestion with the README. in
LDP/README it should tell how the directory structure is layed out, and have
an explanation of what a FAQ, HOWTO, GUIDE, etc are. Here's a rough sketch
of one for FAQ"
FAQ stands for Frequently Asked Questions. Look here if you've got
a question that you want answered, or are looking to find out what the most
common problems and glitches are pertaining to a specific topic.
OK, so that's pretty bad, I can't think of anything better right off. Then
within LDP/FAQ/ the README file should contain something similar to the
section above, followed by a list of the FAQs that are available. And so-on
and so-forth with the other things, and perhaps for the formats.
> > HTML, then either plain text or LaTeX or Tex. We should
> not accept source
> > in pdf, or ps, or any of the ones that I've not mentioned
> here. This
> It can be accepted as a guide, as long as the license is
> compatible with
> our requirements.
> The format is not a problem, if the document is *very* interesting we
> can convert it or retype it.
> > This should have a pointer to the manifesto so that they
> know what our
> > requirements are.
> Will add links to each question
> > This doesn't sound too good, it implies that we don't want this many
> > documents submitted. We want MORE documents submitted, not
> less, right?
> Right, I will rephrase that :
> However, there are far too many docs submitted to ldp-submit
> for our 2«
> peer readers.
> They can not proof read each document ; if you feel like helping them«
> please subscribe to ldp-submit (mail
> > the LDPemail@example.com, as a place to submit
> documents for
> > grammar/style/markup editing, and the LDP-submit list
> should become an
> > automated submission mechanism.
> Good idea ; I will mail the listmaster to create that list ASAP.
> Documents will first go to ldp-editors for grammar and spelling (and
> maybe peer review?), then move to ldp-submit for final submission.
> > I'm not sure that we should be singling (sp?) out any
> particular HOWTOs, but
> > perhaps pointing them to the page ordered by date that Greg
> F has created.
> What's the url?
> > writing "sexier" (I really don't believe that it's going to
> get me any
> > dates, but what the heck) by helping out with the LDP,
> either by sending
> Don't laugh, it got me one in october.
> Her brother felt like working for a linux company so she asked me to
> introduce him (it's chocking ! I never saw that before !!!)
> > nicest, most efficient code you've ever seen. I'd have to
> say that /.er's
> > quote isn't appropraite for this follow-up, nor is this statement.
> Ok will remove it, but it's exactly my opinion (you can't
> code want you
> can't think)
> > > criticize your
> > > HOWTO they didn't even read.
> > I like the re-write that somebody proposed much better than
> this paragraph,
> > it makes it sound like you shouldn't care if somebody
> bashes your HOWTO.
> I care if there's a good reason, unfortunately most of the
> time there's
> no reason at all.
> Pure flaming for the pleasure (goes to /dev/null BTW)
Ah, now if MS had created a /dev/null so that it could be directed there
before it even left the originating machine, wouldn't life be a lot better?
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com