On Thu, 2005-04-07 at 17:51 +0100, Philip Johnson wrote: > On 7 Apr 2005, at 00:30, Paul W. Frields wrote: > <snippety> > > Send your public key to one of the well-known public keyservers if you > > haven't done so, and sign your messages to the list for maximum effect. > > If all is well, this message should now be signed :). Sorry, I didn't > look (was too lazy to look? :D) at the Self Introduction wiki page > before sending so I wasn't aware it was mandatory ;). Also, by looking > at the page I noticed a few other things I should have probably filled > in. > > Heres what I aim to do as one of the documentation guys and gals: > 1. First of all, docbookalize documents which haven't been already in > order to get familiar with docbook itself. DocBookalizing (dig that crazy verb!) is definitely appreciated, since this seems to be perceived as a major barrier to entry for some would-be participants. I say perceived because, as someone who knew NO DocBook, and didn't even really use Emacs before I started here, I can tell you it's definitely more perception than reality. > 2. Second of all, help out with editing - not full blown writing just > yet - I think being an editor would help me see how things work before > jumping right in, getting things wrong and annoying those > sometimes-irritable ;) programmers :D. We are in desperate need of writers right now, with quite a few editors having signed up already, but *any* help is good help. Even finding extra people to take existing documents and rewrite them with better attention to grammar, usage, and style would be a major help. As you read the actual files, you'll get very familiar with the DocBook basics quickly. You don't have to let learning the editing process block the writing process. Here's what I did: I found a subject which interested me and would be useful for novice to intermediate administrators (setting up a local Fedora mirror for use by LAN users). I started by writing an outline, then wrote a first draft from that. I made a first attempt at DocBook tagging by reading someone else's XML code, trying to imitate as best I could. Karsten agreed to edit it for me, so I sent the somewhat spotty results to him. Instead of rewriting my whole document, which was a waste of his time, and which wouldn't teach me anything in the long run, Karsten rewrote a section of it and tagged it correctly. He then sent me the results, with instructions to make the rest of it consistent with what he'd done. (He was a lot nicer about it than that, of course, which was pretty commendable, given how much work he put into the process.) The next draft was, I thought, quite a bit better, and the editorial process after that point went faster since there wasn't as much to correct. > Along the line of 'soft skills', I would say I have good people skills > and a great deal of patience. Very commendable and helpful for any collaborative project! [...snip...] The most helpful advice I think that *I* could give you (as opposed to other more experienced writers/editors) would be to pick something small and chewable to learn with. That's not to say you shouldn't work on an HCL. I'm only saying that from the standpoint of learning the tools and process, a small tutorial will serve you better. You can continue working on the substantial part of the HCL at the same time if you like without the learning process unduly hindering those efforts. Once you're comfortable with the writing style and DocBook tagging, converting the HCL material will only get easier. After I did the mirror tutorial, I actually took a bunch of content, a book in the public domain, albeit a slim one, and converted it into DocBook with great results. If I had started with the book, I think I would have lost steam very quickly because it was such a big project. Just my $0.02. Looking forward to your contributions! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Attachment:
signature.asc
Description: This is a digitally signed message part
