docs August 2006

docs@lists.stg.fedoraproject.org

30 participants
36 discussions

Proposed new document: Kexec/Kdump Usage Guide
by Jarod Wilson 25 Aug '06

25 Aug '06

I've got a basic kexec/kdump usage guide slapped together, just itching to see the light of day. Sounds like I need to propose it here and get approval before publishing it, as well as get added to the DocWritersGroup (or is that necessary for a draft?). First draft of kexec/kdump usage guide attached in text form. -- Jarod Wilson jwilson(a)redhat.com

4 8

Munch 'N' Learn: CVS
by Paul W. Frields 24 Aug '06

24 Aug '06

I've decided that's what I'm calling these sessions, since it's my hope that people show up at their keyboard with their favorite snack. Please observe the following Munch 'N' Learn Guidelines: 1. "Munch" means snack. Pick something that's not deadly, like veggies or rice cakes. Or alternatively, shake the bag before you eat any, so the calories fall down to the bottom. 2. As we discovered in the first session, having gobby 0.3.1 installed is helpful! (On Fedora Core, use yum or pirut, or if you're on another OS, visit http://darcs.0x539.de/trac/obby/cgi-bin/trac.cgi for downloads and more information.) 3. Bring questions, an open mind, and a willingness to learn! 4. Nope, there's no 4, I was just messin' witchoo. Having a Munch 'N' Learn with more than 3 steps would be stupid. Anyway, we're going to have another one of these sessions soon for CVS. It's our hope in FDP that contributors will get started drafting on the Wiki because it's easier for new folks. As you learn the ropes though, you'll find that most of our vital work goes on using DocBook XML files kept in CVS. The inaugural Munch 'N' Learn was all about DocBook XML, and next we're going to show you how to use CVS. We're even going to have a CVS repository up for everyone to actually run commands live! I'd like to try this next week some time, but I can't do any session before 2100 or 9:00pm UTC (currently 5:00pm EDT/2:00pm PDT). If I set this up for Thursday night at 9:00pm UTC, how would that work for everyone? If you plan to attend, drop a reply (ON-list) to this message, or let me know a better time. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

3 4

IRC & Gobby session: DocBook XML
by Paul W. Frields 24 Aug '06

24 Aug '06

A few people came by IRC and we started up a gobby[1] session to talk about how DocBook XML works. Below you'll find the IRC log and the subsequent gobby log. I've edited them slightly for readability. I'm also attaching copies of the documents we used, inline where they make sense. Hopefully people can read this from beginning to end and the flow generally makes sense, even when we hopped from IRC onto gobby. There's a bit of Emacs-specific stuff in there[2], but the bulk is devoted to DocBook XML and how to start writing it using Your Favorite Editor. [1] gobby: Interactive, collaborative document editor (available in Fedora Extras) [2] And yes, I was very fair to users of vi (several of whom were in attendance). Arguments and flames to /dev/null please. ;-) ### ### IRC LOG FOLLOWS ### ### <stickster> OK, this might be weird with no one asking questions, but here goes... <stickster> Hands down, the best possible way to write documentation for Linux or Fedora is DocBook XML. <cdehaan> Hm, haven't learned that. <stickster> XML is a markup language that looks on its face a lot like HTML. And in fact, it really isn't that different at all. <cdehaan> I never understood how the Wiki was entangled with XML and the final output of documentation. <stickster> Aha! <stickster> So I've found someone who wants to ask questions. <stickster> Well, skip my stupid intro then, and let's get down to brass tacks. <stickster> The "entanglement" is that we wanted a place where people could write documents easily without having to learn anything *at first.* So quaid has been working with a Summer of Code intern to have a way to take documents written on the wiki and convert them (more or less) to DocBook XML. <cdehaan> Hm <stickster> The sticky, unavoidable problem is that DocBook allows you to mark a document -- if you want -- with fairly detailed and exact information. The Wiki simply can't do it -- not without so many hacks that no one would want to run the resulting code <stickster> But what we can do is have the Wiki -> DocBook converter make some educated guesses based on how the writer formats the document. That's why we require specific tagging like `this` for a file or program, '''this''' for the name of a GUI application, and so on <stickster> The converter reads that and turns it into a "best-guess" DocBook document. An editor can then go through the document and tag it correctly. <cdehaan> Aah. <stickster> Like HTML, XML uses tags to mark elements. So a filename in DocBook XML looks like this: <filename>/etc/services</filename> <stickster> However, on the Wiki, a filename is marked like `/etc/services`, a program is marked like `yum`, and a package name is marked like `yum-utils`. So the converter will often tag wrong, and someone has to correct it in the XML version. <stickster> The converter can't tell whether `yum` is a file name, program name, or package name. But in DocBook you can! <stickster> In DocBook these would be <filename>yum</filename>, <command>yum</command>, or <systemitem>yum</systemitem>. <stickster> (The last one is actually an approximation since the DocBook version we use doesn't yet have an exact markup for "package.") <cdehaan> Hm <stickster> Once we have it marked up correctly, though -- how do you get it back onto the wiki? According to some people, the answer is "You don't." Because every time you had corrections, the version coming *back* from the Wiki would be wrong. Again. <cdehaan> So then, does it cause problems to edit in the Wiki? <cdehaan> Is the eventual goal to have everyone using XML? <stickster> Problems? No. At least not at first. In other words, the drafting can and should be done on the Wiki. It's a great place for people to collaborate when they don't know how to use DocBook or CVS yet. <stickster> As for the second question -- it depends on whom you ask. <stickster> My personal feeling is that yes, we do want people to work using XML and CVS, because those can be just as collaborative as a Wiki. <stickster> What we *don't* want is to scare people off before they get their feet wet. <cdehaan> Ok. So what if someone wanted to work on something, say DUG, but wanted to use XML? that would be a perfect mess, since someone using the Wiki and someone using CVS with XML would be using different versions. <stickster> In other words, if you like writing and working on docs, after working on the Wiki for a little while, you will probably get eager to try your hand at DocBook and CVS. <stickster> cdehaan: *Exactly.* <cdehaan> I like the idea of having one system better, but that's tough, since the stuff I'm working on now (albeit very, very minute), are on the Wiki. <stickster> The solution to this problem is that drafting should be done in the wiki -- as long as the participants are all happy to do so -- and once a draft is done, it can be converted to DocBook. <stickster> By that point the contributors should be ready to try the Better Way of doing business. ;-) <stickster> Now, keep in mind this isn't coming from someone who is a hard-core programmer, or a kernel hacker. <cdehaan> I prefer HTML-style markup, though I'm not familiar with XML. <cdehaan> HTML is what I do. <stickster> I knew *NOTHING* about DocBook, or XML, or CVS, before I started with this project. <stickster> DocBook XML is as easy as HTML. <stickster> The idea is exactly the same. <stickster> You're probably already familiar with XHTML then. <stickster> cdehaan: What may trouble you at first is the number of elements you can use in DocBook. <Eitch> I see <stickster> After all, most people can handle the easy <html>, <head>, <body>, <h1>, <p> and so forth in simple HTML <stickster> cdehaan: So the idea with DocBook is that you typically are writing an <article> <stickster> Inside the <article> you can have other elements. You don't have to use all of them; most are optional. <cdehaan> i see. <stickster> cdehaan: I was thinking, maybe a gobby instance would help... are you on a FC5 box? <cdehaan> Now that I know this, I really think it's detrimental to the progress of things to have some things Wiki, some CVS. <cdehaan> I'm on OS X at the moment. <stickster> Oh, OK. <stickster> Well, no then. <cdehaan> My MacBook (With FC5) is in for repair (surprise) <stickster> Heh. <cdehaan> gobby runs on OS X <cdehaan> Apparently <stickster> Oh, well if you want to set it up real quick, I am going to try and get a server working here. <stickster> I have no idea how to do it, but I bet it's a simple process. <cdehaan> I will do that. <cdehaan> It looks to be easy on Windows. I'll go to my Windows box. <cdehaan> BRB ### ### ### ### ### a few minutes later, and after a couple false starts... ### GOBBY LOG STARTS ### ### ### ### <cdehaan> hey hey. <stickster> I'm going to clear out this document for a fresh start. <cdehaan> OK <cdehaan> Aah. <stickster> So here's how we start a document. ### ### ### ### ### <?xml version="1.0" encoding="UTF-8"?> ### ### ### ### <cdehaan> Indeed. <stickster> That's pretty much verbatim. Never changes. <Eitch> o> <stickster> It's just a signifier that the rest of the document will be an XML 1.0 document of some type, yet unknown. <stickster> Next, we put in a "document type declaration" or DTD that explains EXACTLY what type of XML document this is. ### ### ### ### ### <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" ### "http://docbook.org/xml/4.4/docbookx.dtd"> ### ### ### ### <stickster> Note the DTD has five pieces inside a <! > entity: <stickster> 1. DOCTYPE -- in other words, this is a DTD entitiy <stickster> 2. article -- the top level element of this document is a DocBook "article". You can actually make smaller pieces than that, and they're perfectly legal. That in fact is how we combine "chapter" pieces into a "book". <stickster> 3. PUBLIC -- that means that the next piece of the DTD is a public identifier (well-known) that describes this document's allowed elements, attributes, etc. <stickster> If it wasn't PUBLIC it would be SYSTEM, which would mean some URI on your local box, so you can write XML without a well-known public DTD, like some private DTD you've made up for your own use. <stickster> anyhoo... <stickster> 4. "-//OASIS//DTD DocBook XML V4.4//EN" -- that's called the FPI string, which is the public identifier for DocBook XML, version 4.4 <stickster> It always looks just like that. If you don't type it right, some tools will act strangely. So copy it from somewhere that works, or just learn from your mistakes like I did. :-D <stickster> 5. "http://docbook.org/xml/4.4/docbookx.dtd" -- that is also a well-known URL for the actual DTD that describes DocBook XML V4.4. There's another one at a different URL located at OASIS web site: http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd is the right one, I think. <stickster> OK... <cdehaan> So basically what we've done is declared what type of language/document is to follow? <stickster> Exactly! <stickster> If you still don't know what a DTD is, here's the scoop: For things like DocBook, it's a huge bunch of stuff that's not fun to read, but which describes how the DocBook schema works. <stickster> What we've done with this "entity" is to declare that for any tool that understands how to parse or validate XML, it will find all the rules it needs to understand this particular schema at the noted URL. Then the tool can do all the work for you, like checking that your document is valid. <stickster> Generally, if you know you're writing an <article>, you can just copy this from some other article with absolutely zero work on your part. <stickster> Since #2 element was an article, that means that our top-level element is (must be) an <article>. <cdehaan> What if "#2 element" is NOT article... <stickster> Well, your computer won't start smoking or anything, but validation tools will tell you that your document is invalid. <cdehaan> Ok <stickster> And all the fun little helpful stuff in Emacs or vi will start giving you warnings <cdehaan> But our opening tag should always correspond to the element? <stickster> Yes <cdehaan> Alrighty <stickster> That is always true in DocBook XML and may be true for other DTDs as well <stickster> OK, so now that we have an article, what can we put in it? <cdehaan> More tags <stickster> Right. <stickster> In fact, in many cases you can't just start typing text, because it would be "invalid" according to the DTD. <stickster> This, for example, is invalid: ### ### ### ### ### <?xml version="1.0" encoding="UTF-8"?> ### <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" ### "http://docbook.org/xml/4.4/docbookx.dtd"> ### ### <article> ### This is my article. Isn't it great? ### </article> ### ### ### ### <stickster> Now, that *IS* what we call "well-formed" XML, because all the tags open and close without overlapping each other. <stickster> Just like HTML, right? <stickster> It may be "well-formed," but it isn't "valid." Because the DocBook DTD tells us that you're not allowed to just type text in your article like that. <stickster> (short footnote: From time to time, I might get particular DTD details wrong. It's not like I've memorized the whole thing. I'm used to doing things a certain way, and there's a chance -- a pretty good one in fact -- that I could be wrong about where you can and can't do things.) <stickster> Aha, I can demonstrate this! <stickster> I'm going to start another document which you guys should join. I'll post my command lines there along with the output. <cdehaan> ok <stickster> I'm using an FC5 box, so I'll describe that environment. <stickster> If you do a "yum groupinstall 'Authoring and Publishing'" you will get all the tools I am using. <stickster> Including the one above. If I save the XML document we just wrote, and run that xmllint command, here's what the output looks like: ### ### ### ### ### $ xmllint --postvalid docbook-test.xml ### <?xml version="1.0" encoding="UTF-8"?> ### <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" ### "http://docbook.org/xml/4.4/docbookx.dtd"> ### <article> ### This is my article. Isn't it great? ### </article> ### docbook-test.xml:5: element article: validity error : Element article content does not follow the DTD, expecting ((title , subtitle? , titleabbrev?)? , articleinfo? , tocchap? , lot* , (((calloutlist | glosslist | bibliolist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | task | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+ , (sect1* | refentry* | simplesect* | section*)) | sect1+ | refentry+ | simplesect+ | section+) , ((toc | lot | index | glossary | bibliography) | appendix | ackno)*), got (CDATA) ### Document docbook-test.xml does not validate ### ### ### ### <stickster> Aha! Check it out. The validator tells me that I goofed up. <stickster> It doesn't follow the DTD -- xmllint just told me so. (Read error message closely for details.) <stickster> Starting on line 5, where I typed some text inside the <article> element, I goofed. The validator was expecting -- well... something else. <stickster> All those names and markings reflect the real DTD expectations. (a, b, c) means any one of <a>, <b>, or <c>, for example. <stickster> Question marks mean "optional," + means "one or more," and * means "zero or more" <stickster> Now -- DON'T PANIC. You don't have to remember ANY of this stuff. <cdehaan> Heh <cdehaan> as eyes glaze over <stickster> This is only a nice little reminder that you did something wrong. If you want to find out how to write a document, you don't read xmllint output. :-) <stickster> The best idea is to look at a document that's already written, and follow its lead. But an idea that is second only to that in goodness is to download or bookmark "DocBook: The Definitive Guide," which is available for download free on the web. <stickster> http://www.docbook.org/ <stickster> You don't have to do it now, just hold on to that for later. <stickster> I will try and find a link to directions to getting the exact V4.4 version out of their CVS, since the one on the web is for beta-5.0 <stickster> OK <stickster> . <stickster> . <stickster> . <stickster> Now, let's see what happens when I put my document in the correct form. <stickster> Heh <cdehaan> Oops. ### ### ### ### ### <?xml version="1.0" encoding="UTF-8"?> ### <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" ### "http://docbook.org/xml/4.4/docbookx.dtd"> ### ### <article> ### <title>My Article</title> ### <para> ### This is my article. Isn't it great? ### </para> ### </article> ### ### ### ### <stickster> OK, I just corrected the article if you'd like to look at it <cdehaan> Ok, simple tags. <stickster> Yup, I kept it REALLY simple for this demonstration. Our articles for FDP have quite a bit more information, but even what we use is not that complicated. <stickster> Now, I'm going to show you the new validation in the shell-output.txt doc. <stickster> There's the command. ### ### ### ### ### $ xmllint --noout --postvalid docbook-test.xml ### $ ### ### ### ### <stickster> And the output is: <stickster> NOTHING. <cdehaan> Sweet. <cdehaan> WB Bob! <stickster> The "--noout" means I don't want xmllint to output the parsed document (which usually looks very much like the input), but rather just tell me if there's a problem. <stickster> In this case -- like most Linux commands -- if you don't see output, everything worked fine. <stickster> Valid document! <cdehaan> Cool. You type the command, if you see no output whatsoever, it's good? <stickster> Yup. <stickster> Now, I did that at a command line, but normally I don't even do that. <stickster> I write all my DocBook in Emacs along with the "psgml" package installed. <stickster> Along with a short configuration file, it means I can do all of this work right in the editor. <stickster> MOREOVER -- <stickster> Emacs WILL NOT LET ME MAKE A MISTAKE unless I force it to do so. <cdehaan> Oh? <cdehaan> At what point does it intervene? saving? <stickster> There's about -- hmm -- maybe TEN special keystrokes I learned to edit DocBook documents. <stickster> To open an element, I use either Ctrl+< or Ctrl+C, Ctrl+E <stickster> If I then use the [Tab] key, Emacs will do autocompletion -- and it ONLY provides the valid tags. <stickster> If I really want to, it will let me type something wrong, but that would be kind of silly. <cdehaan> I see. <stickster> If I hit [Tab][Tab], like bash, it will open up a frame with the available elements (tags) in it <cdehaan> Cool <stickster> To close an open element, I use the Ctrl+/ key combo. <stickster> If I want to validate a document I'm done drafting, I use Ctrl+C, Ctrl+V key sequence. <stickster> Sorry, that last one should have been Ctrl+C, Ctrl+/ to close an element <stickster> Most key sequences like this in Emacs are Ctrl+C, <something> <stickster> There's lots of other functions, too -- I can block a whole region and then put it in an element <stickster> I can sit somewhere in a tagged region and change the element it's in <stickster> Many others. <stickster> But there's only around 7 - 10 functions that I needed to learn to get started. <cdehaan> Cool <stickster> It's not GUI, and it's not WYSIWYG, but what you give up in mouse-ability you more than make up for in PHENOMENAL COSMIC POWER <stickster> Many UNIX gurus I know do everything in Emacs. <cdehaan> I've never used it, so I'll have to check it out. <stickster> I'm not at that level... but it's the dog's bollocks for DocBook. <cdehaan> I presently use vi for text editing <stickster> vi also has many adherents. Tommy Reynolds, one of our resident gurus, is a big vi fan. I don't bother arguing with him about it, and I won't bother arguing with you about it either. <stickster> USE WHAT WORKS. <stickster> But there's no denying that DocBook XML is the absolute best way to do markup for technical documentation. <Eitch> /me uses vim <cdehaan> Eh, if emacs makes it that easy, no reason not to use it. <stickster> Once you have a document in DocBook, you can turn it into (X)HTML, TeX, PDF... <stickster> I think vim probably has some kind of similar support. I have no idea how it works. I used to be a big-time vi lover but after I tried Emacs for DocBook, I never went back. Now I only use Emacs. <stickster> You can probably find people who are the exact opposite. The key is, use an editor that (1) supports XML, and (2) supports DTD parsing and validation. <stickster> If it does that, DocBook writing becomes SUPER-easy. <stickster> The editor keeps you from making DTD-related mistakes like incorrect element names or placement, and you can just concentrate on your document instead. <stickster> It is worth reading DocBook: The Definitive Guide to get a handle on what DocBook's all about, and here's what I use that book most for -- <stickster> I downloaded it to my local disk, and it has a big list of every element in alphabetical order. If I'm looking for a tag that does X, I look up "X" in the Table of Contents and it's usually there, or something like it. <stickster> If I am talking about a keyboard key, I look up "key" and voila! There's "keycap". <stickster> After you use a tag a few times, it sticks with you. So now, just like I know that <table><tr><td>something</td></tr></table> does stuff in HTML, I know that <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> does stuff in DocBook <stickster> It keeps you from having to decide, "Hmm, should I write Applications -> Internet, or Applications => Internet?" Nope, instead you just do <guimenuchoice><guimenu>Applications</guimenu><guisubmenu>Internet</guisubmenu></guimenuchoice> <stickster> When you render it to HTML it comes out with the neat little arrows inserted because they're part of the stylesheets for turning DocBook into HTML. <stickster> So.. <stickster> . <stickster> . <stickster> Does this make it a little less terrifying? <stickster> This was all *completely* new to me just a few years ago. quaid, Tammy Fox, and a couple other nice folks taught me what I needed to know, and the rest you just kind of pick up as you go along. <cdehaan> It makes perfect sense <cdehaan> Basically just learning tags and using a good editor. <stickster> If only I'd had Gobby when I started!!! :-) <cdehaan> Heh <cdehaan> :) <stickster> Now, next week we'll tackle CVS. <stickster> :-) <stickster> Is this a good time for doing this? <stickster> I know some of you are in different TZ <cdehaan> it works. *I* probably won't be on next week, as next Tuesday I'll be moving into my dorm. <stickster> No problem <cdehaan> But in the fairly near future, yes. <stickster> Maybe we'll shoot for a different time. I'll start a thread in fedora-docs-list and people can get back to me with a time <cdehaan> that works. <stickster> OK then, thanks for coming by, everybody! <cdehaan> Thanks for the intro! <stickster> You're welcome, thanks for helping with FDP <stickster> OK Eitch, I'm going to close up shop here ### ### ### ### END TRANSCRIPT ### -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

2 2

CVS access
by Serhat Güngör 23 Aug '06

23 Aug '06

Hi, I still can't access the Documents CVS Repo. My membership in the cvsdocs group isn't approved. Do I have to do something else? Serhat ---------- Forwarded message ---------- From: Serhat Güngör <cepxat(a)gmail.com> Date: Jul 14, 2006 10:32 PM Subject: Re: Self Introduction : Serhat GUNGOR To: For participants of the Documentation Project < fedora-docs-list(a)redhat.com> I already singed up for access to the cvsdocs group in the Fedora Account System but my membership isn't approved. I think it must be approved by an admin. When I look my membership from the accounts home i see as the following. Group NameUsernameRole DomainRole TypeRole StatusSponsor ambassadors<https://admin.fedora.redhat.com/accounts/groupbox.cgi?_editme=Edit&name=amb…> cepxat<https://admin.fedora.redhat.com/accounts/userbox.cgi?_editme=Edit&username=…> user approved *Unneeded* cla_done<https://admin.fedora.redhat.com/accounts/groupbox.cgi?_editme=Edit&name=cla…> cepxat<https://admin.fedora.redhat.com/accounts/userbox.cgi?_editme=Edit&username=…> None user approved *Unneeded* cvsdocs<https://admin.fedora.redhat.com/accounts/groupbox.cgi?_editme=Edit&name=cvs…> cepxat<https://admin.fedora.redhat.com/accounts/userbox.cgi?_editme=Edit&username=…> user unapproved *Unneeded* What should i do for to be approved? Thanks, Serhat On 7/14/06, Paul W. Frields < stickster(a)gmail.com> wrote: > > On Wed, 2006-07-12 at 23:11 +0300, Serhat Güngör wrote: > > Hi, > > I'm Serhat GUNGOR from Istanbul, Turkey. I'm a Computer Engineer and > > using linux nearly 4 years. Before Fedora i was using Red Hat. Till > > last week i was working as system administrator in Istanbul Technical > > University(ITU) which is the one of the big universities of Turkey. > > Mostly Red Hat Enterprise Lİnux is used there in the server side. In > > the client side more than 1000 computers are Fedora. We started a a > > Linux Education program in ITU which is called ITU Linux Academy > > ( http://ila.itu.edu.tr -- page is in Turkish) and had lots of > > students from university or out of the university. Now i'm working at > > Turkey's biggest GSM operator. > > > > I am working on Fedora Translation Project and i will be leading the > > Turkish team. And to make people join the translation project, firstly > > i want to translate quick-start-guide to Turkish. > > Welcome Serhat. If you haven't already signed up for access to the > cvsdocs group in the Fedora Account System, please do so. We're proud > to have you and all our hard-working translators aboard. They've been > doing a splendid job recently and we're hoping to have lots of > translations for documents out for the FC6 cycle. > > We are very close to having release notes in the i18n.redhat.com system, > so keep a lookout there. We'll of course post to this list and > fedora-trans-list when it's ready. > > If you need any help getting started here, please let us know. > > -- > Paul W. Frields, RHCE http://paul.frields.org/ > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > Fedora Project Board: http://fedoraproject.org/wiki/Board > Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject > > -- > fedora-docs-list mailing list > fedora-docs-list(a)redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list >

7 12

[Fwd: FW: stcetsig-l digest: August 15, 2006]
by Michael Hideo Smith 22 Aug '06

22 Aug '06

FYI. STC will have open source educational tracks at next year's conference and they are looking for presenters. making good progress on this front. -----Original Message----- From: Ed Marshall [mailto:ed.marshall@verizon.net] Sent: Wednesday, August 16, 2006 5:45 PM To: Jacob, Lizy Saji (STSD); bhaskara(a)amazon.com Subject: FW: stcetsig-l digest: August 15, 2006 -----Original Message----- From: bounce-stcetsig-l-285798(a)lists.stc.org [mailto:bounce-stcetsig-l-285798@lists.stc.org] On Behalf Of STC Emerging Technologies SIG discussions digest Sent: Wednesday, August 16, 2006 2:03 AM To: stcetsig-l digest recipients Subject: stcetsig-l digest: August 15, 2006 STCETSIG-L Digest for Tuesday, August 15, 2006. 1. Call for Open Source Progression presenters at annual STC Conference in Minneapolis ---------------------------------------------------------------------- Subject: Call for Open Source Progression presenters at annual STC Conference in Minneapolis From: "Dan Charles" <dan(a)dan-charles.com> Date: Tue, 15 Aug 2006 08:35:48 -0600 X-Message-Number: 1 Believe it or not, it's time to submit proposals for next year's conference. If you are interested in presenting at the ET SIG Open Source progression, please let me know by August 28. The progression topics are targeted to people unfamiliar with open source technology. We do three sessions of about 30 minutes each. You only need about 10 - 15 minutes of content to leave time for questions. Handouts are always appreciated. We are looking for 8-10 people. Potential topics include: - What the heck is open source? - When does open source make sense? - Open source resources - Open Office - Anything else you can think of that is related to open source, and may be of interest to other technical communicators If you would like to participate, please send the following information by August 23: - Topic title (no more than 8 words), which clearly identifies your proposal content - Detailed description (no more than 150 words), which clarifies the content of your proposal. - Key learning objectives (3 to 5 bullet points) ****New item***** - Your name - Company - Snail mail address - Phone and fax numbers - E-mail address - Two references *****New item - more details to come - Sources cited *****New item - more details to come I hope to see all of you in Minneapolis next May! --- END OF DIGEST --- You are currently subscribed to stcetsig-l as: ed.marshall(a)verizon.net To unsubscribe send a blank email to leave-stcetsig-l-285798M(a)lists.stc.org -- Michael H. Smith Associate Red Hat Asia-Pacific Ph: +61 7 3514 8103 Level 2/5 Gardner Close Mb: +61 418 182 451 Milton, QLD 4064 Fx: +61 7 3514 8199 Australia

1 0

After-meeting IRC "social"
by Paul W. Frields 22 Aug '06

22 Aug '06

I'll be hanging around on Freenode IRC #fedora-docs after today's steering committee meeting to answer questions and help people get started with DocBook XML. That meeting goes from 4pm until 5pm, at which point I'll just probably start yapping. Even if you can't hang around at your keyboard, leave your IRC client logged in and you can capture the buffer. Mmm, buffer. Anyone who wants to ask crazy, off-the-wall DocBook or toolchain questions related to FDP, please come on by! (Sorry about the late notice. If there are a lot of "Aww, I missed it!" emails, we may repeat the offer next week.) :-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

1 0

Focus on two guides for FC6 and a schedule
by Karsten Wade 22 Aug '06

22 Aug '06

We have just enough time to complete two important guides for FC6: * Desktop User Guide (new) * Installation Guide (update) This would give us an additional guide over the FC5 release. We need to do this with the resources we have now, while doing our magic for the release notes. A bonus would be getting both guides available for translation prior to the release. I've updated the schedule to reflect this. Our content is due into alpha/draft on 28 August (Wiki) or 30 August (XML in CVS): http://fedoraproject.org/wiki/DocsProject/Schedule To succeed, we need to focus FDP on getting this done. I ask each of you to put your name on *one* of these contributor pages, or two if you are not doing a primary role on the second guide. We need to be realistic about how much personal time we have to finish these on time. http://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide/Contributors http://fedoraproject.org/wiki/Docs/Drafts/InstallationGuide/Contributors Each team needs a designated leader who is accountable for making sure all other contributors know what they are responsible for, when it is due, and where it has to go. This is not a hard role, but someone needs to do it. How does this approach sound? Any suggestions to improve it? Is my schedule too crazy/aggressive to you? Do you think we should be focused on a different set of guides? Do you want to work on something else and not these guides or the release notes? Let's get any issues resolved and proceed to writing. I personally have just a bit of time to put into these guides, and want to know what I am doing is contributing to the release. ;-) I'm sure you all feel the same. cheers - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

7 17

Installation .png files
by Edward Haddock 20 Aug '06

20 Aug '06

Aloha, Installed FC6 RC2 via VMPlayer and took .png files with KSnapshot. Saved the cropped with The Gimp. Got a total of 29 of them zipped up nice and neat. Who wants? Where to send? I am not able to do much these days to help you guys out with writing Docs and stuff but I can at least take some screen shots. If needed I suppose I could also take shots of the Desktop for a Desktop users guide. Just let me know what you need. Many Mahalo's Edward

4 5

Meeting minutes FDSCO 15-Aug-2006
by Karsten Wade 17 Aug '06

17 Aug '06

We're using the task list as the minutes as well; use the status column to see what happened on each task. http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/TaskSchedule Let us know if you feel more information is needed on a regular basis. Trying balance convenience, timing, and quality. :) - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

1 0

Translation QSG
by Paul W. Frields 17 Aug '06

17 Aug '06

Translators no longer need to translate the special "rpm-info.xml" file separately in Docs CVS. We've made it part of our normal POT/PO inclusion, so there's one less "extra" step in doing Docs translation directly in our CVS. I've updated the Translation Quick Start Guide to remove that procedural step. We currently have the following locales available for that document which translators might want to update: el es fr_FR it ja_JP nl pa pl pt pt_BR ru As I get updated versions, I'll publish them. Translators who use our special wiki publication queue page will get top priority: http://fedoraproject.org/wiki/DocsProject/PublishQueue Remember to get a fellow translator to check your work so we can publish your translation right away! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs August 2006