IRC Log FDSCo Meeting 9th May 2006

Tue May 9 21:32:52 UTC 2006

(21:06:32) quaid: <meeting>
(21:06:54) quaid: first order of business, before the regular stuff
(21:07:45) quaid: Stuart (elliss) is moving to inactive status for
FDSCo, although he's likely to come hang out with us during meetings and
such.
(21:07:57) quaid: sad for us, but hopefully this gives him more
breathing room in his life.
(21:08:16) quaid: elliss: and we're always here when/if you feel like
getting active again :)
(21:08:24) elliss: Thanks.
(21:08:28) ghenry: I should probably do that, since it's overdue. As
that's all I have been doing, hanging ou here.
(21:08:37) quaid: :)
(21:08:44) quaid: now the inactive outnumber the active
(21:08:59) quaid: tcf_home and mjohnson became inactive by default
(21:08:59) ***BobJensen looks around and shrugs
(21:09:07) quaid: yeah, huh
(21:09:21) quaid: well, this project needs fewer committee members and
more just members, but...
(21:09:59) quaid: does anyone feel we need to recruit more FDSCo people?
or focus on just recruiting in general?
(21:10:08) megacoder [n=chatzill at host-216-76-237-169.hsv.bellsouth.net]
entered the room.
(21:10:19) megacoder: I made it ;-)
(21:10:20) ***BobJensen waves to Tommy
(21:10:28) stickster: Documentation is pretty low-hanging fruit, if you
ask me, yet people don't seem to want to stick with even this project
(21:10:34) stickster: Hi megacoder
(21:10:48) megacoder: stickster: tutti frutti!
(21:10:49) elliss: stickster: I'd disagree slightly
(21:11:21) stickster: *note: by low-hanging fruit, I mean, easy to get
involved -- cf. software development
(21:11:24) BobJensen: quaid: we are starting to recruit for FedoraUnity
hope it will result in some cross membership
(21:11:44) Sonar_Guy: BobJensen: I surely hope so.
(21:12:04) elliss: stickster: I think that time to outcome is important
here
(21:12:08) quaid: docs have a stigma, though, right?
(21:12:24) quaid: actually, here's an overall question ...
(21:12:26) BobJensen: quaid: what one?
(21:12:30) BobJensen: LOL
(21:12:34) elliss: You can be live on a Wiki in minutes, but formal docs
take weeks to build
(21:12:38) quaid: do we have anything more important to talk about today
other than growing FDP?
(21:12:42) elliss: and months to complete
(21:13:01) BobJensen: elliss: I agree
(21:13:04) quaid: yet we've proven that at last a good, long article can
be written by many hands in a Wiki
(21:13:09) stickster: My opinion is that if FedoraUnity gets more
members involved in Docs, it means we've failed miserably for several
years -- and I mean that in the best possible way, esp. toward Bob,
Scott and the other Unity guys
(21:13:17) quaid: +1
(21:13:27) quaid: not several years, though, just the last 14 months
(21:13:37) elliss: I would say we had a specific focus
(21:13:38) stickster: == We can pick up lessons from them as we move to
Plone
(21:13:39) quaid: I don't count the time before FDSCo formed against
FDSCo
(21:13:43) Sonar_Guy: stickster: I disagree, we just us a different
approach.
(21:13:55) stickster: quaid: good point, 40% retract
(21:13:57) stickster: :-)
(21:14:15) stickster: Sonar_Guy: don't back down, that's exactly my
point
(21:14:24) stickster: Sonar_Guy: own the awesomeness
(21:14:50) Sonar_Guy: stickster: we are starting to hit some limitations
as we were discussing last night.
(21:15:11) megacoder: We've been looking for authors, but most folks
just want to dash off a postcard 
(21:15:16) BobJensen: How can what we learned in Fedora Unity be applied
to FDP? I don't know yet we are only 4 or 5 onths old
(21:15:17) Sonar_Guy: Hopefully we can come up with some changes to make
this easier.
(21:15:25) elliss: megacoder: Right on the nail
(21:16:05) megacoder: How about we start the "Fedora Sticky-Notes
Project"?
(21:16:07) BobJensen: megacoder: true but any of these postcards can be
merged in to larger works by good editors
(21:16:18) stickster: megacoder: There is a point there
(21:16:28) stickster: The FDP work needs to be in stitching the
postcards together
(21:16:38) quaid: maybe we focus on enabling content editors, people who
gather stuff like mether, and others who massage it into a whole.
(21:16:45) stickster: Or at least a goodly portion thereof
(21:16:56) elliss: knowledgebase?
(21:16:57) stickster: quaid: Yes, relnotes as an example
(21:17:09) BobJensen: stickster: I agree
(21:17:18) BobJensen: stickster: perfect example
(21:17:27) quaid: but can we take e.g. the Yum Guide and parse that out
or make it from scraps and pieces?
(21:17:29) megacoder: Classical documentation doesn't appear to be
working here
(21:17:48) stickster: At least not with only four or five people doing
all the writing
(21:17:50) quaid: we need to think more like open source
documentation :)
(21:18:06) quaid: that thinking got us the Beats -> relnotes
(21:18:09) BobJensen: megacoder: I think one reason for that is the
community as a whole, they want quick and easy
(21:18:15) quaid: but that model doesn't work IMHO with larger works.
(21:18:20) quaid: recipes
(21:18:26) quaid: maybe ... we can focus
(21:18:31) quaid: on getting a kbase-like thingie together
(21:18:42) quaid: and we can troll fforum.o, fu.o etc.
(21:18:58) quaid: and get ppl's permissions to publish their recipes,
like the way FEdoranews.org was but with more fact checking
(21:19:03) quaid: and best practice checking.
(21:19:18) quaid: if the recipes could be rated
(21:19:20) stickster: Does anyone see the input from RH docs as being a
positive move? I.e., massaging a big base of already-written stuff as
opposed to starting from scratch?
(21:19:25) quaid: a developer and a social rating ...
(21:19:35) quaid: stickster: yes, conceptually
(21:19:44) megacoder: Nope. "Drive-by documentation" ie. wiki / plone(?)
IMHO should be focussed on a topic basis. 
(21:19:47) quaid: stickster: but it requires an editorial hand, do we
have that? is RH supplying that?
(21:19:51) elliss: I'd say possibly not from experience
(21:20:10) elliss: Sun dropped a load of docs on GNOME
(21:20:19) BobJensen: stickster: I am looking forward to the chance to
take on those large items and make them Fedora Focused
(21:20:20) elliss: More than the community could carry
(21:20:24) quaid: was it a smelly load?
(21:20:24) megacoder: Editors will then need to construct the "doc" from
all the post-its
(21:20:46) quaid: updating a guide for a release is HUGE work
(21:20:54) quaid: and we have three-times the releases that RHEL does
now
(21:20:59) BobJensen: true
(21:21:17) quaid: I've warned for a while that the "drop a smelly load
of docs on Fedora" approach wouldn't work
(21:21:40) quaid: do we want docs from RH that don't have an owner who
at least shepherds?
(21:21:52) quaid: similar to ... if we tried to do a man page update
(21:21:55) quaid: or modify docs from LDP
(21:22:03) quaid: tons of work, have to be checked for each release,
etc.
(21:22:12) megacoder: Are these just docs qua docs or Fedora-specific
docs? Isn't that our remit?
(21:22:18) Eitch left the room (quit: Remote closed the connection).
(21:22:24) stickster: quaid: w/r/t recipes, as long as the vast majority
of the "community" still thinks "disable SELinux" and "install [Nvidia|
ATi] proprietary drivers" is a solution, I'd say ratings are for crap.
(21:22:43) quaid: megacoder: RHEL docs based on RHEL 4, meaning FC 3
needing updating to FC 5 facts.
(21:22:57) quaid: stickster: which is why we have a developer.technical
rating as well
(21:23:13) quaid: and show at the top the recipes with the highest
_developer_ level approval
(21:23:29) megacoder: How do we get out of the relnotes churn long
enough to care?
(21:23:39) BobJensen: anyone who suggests to disable selinux for more
than testing is foolish
(21:23:42) stickster: What does the social rating provide then?
Readability check?
(21:23:51) quaid: hmmm ...
(21:24:07) megacoder: BobJensen: disagree on that. maybe later, though.
(21:24:09) quaid: well, social rating may not have value, if we can't
trust the social group to do smart things sometimes.
(21:24:24) stickster: Heh
(21:24:30) quaid: megacoder: to answer you ...
(21:24:36) quaid: megacoder: we need to segment ourselves a bit
(21:24:41) quaid: and not have all-hands on relnotes
(21:24:47) stickster: quaid: +1`
(21:24:48) BobJensen: megacoder: using the tools to make things work
with SElinux is a much better option in my opinion
(21:24:48) quaid: even if relnotes get smaller as a result
(21:25:07) BobJensen: quaid: +1
(21:25:35) quaid: yeah, see, having me be the EiC meant I could delegate
to the whole group, so I did :D
(21:25:47) stickster: BobJensen's fully on board with the "let's not
play Norman Mailer" idea :-D
(21:26:01) quaid: what if we had general topic areas
(21:26:02) megacoder: And now EvilBob has the ball; I like it
(21:26:07) quaid: and editors for each, who can assemble teams
(21:26:15) quaid: similar to the way the beats are ...
(21:26:32) quaid: even a relation there, so that all content goes into a
recipe index, and only some comes back out into the relnotes.
(21:26:35) Sonar_Guy: And now with the work change for me I should have
some more time to work on Docs.
(21:26:52) quaid: Sonar_Guy: getting your land legs back, eh?
(21:26:54) stickster: quaid: Whence, pray tell, do we assemble these
hordes of workers?
(21:27:00) quaid: :D
(21:27:18) quaid: if we absorb the Beats
(21:27:24) ***stickster swings dead cat around and hits... er, nothing
(21:27:24) quaid: and make the relnotes only _one_ of the work outputs
(21:27:26) Sonar_Guy: quaid: Yup
(21:27:56) quaid: I mean, each of the little bits on many topics in the
relnotes could == a full article
(21:27:57) quaid: so ...
(21:28:11) nman64_away is now known as nman64
(21:28:12) quaid: we have the beat group ... decide next what the groups
are ... picjk
(21:28:23) quaid: pick three or five topics from all the pile of Beat
notes
(21:28:30) quaid: and make them into longer works.
(21:28:34) quaid: as a group.
(21:28:53) quaid: we can consolidate the beat groups a bit, so it's more
like 2 to 5 people per beat
(21:29:10) quaid: like the earliest model, where all daemons (services)
were in one group.
(21:29:37) quaid: we can choose to regroup the final output of the
relnotes, but have wider focuses.
(21:29:44) quaid: 'course ... what if they all say no?
(21:29:59) BobJensen: we hunt new minions
(21:30:04) quaid: this is more of a concept and a way to continue the
wave, than a shangai'd army
(21:30:25) quaid: BobJensen: right, and use the success and model of the
other as a selling point
(21:30:35) ghenry: yes, sounds good
(21:30:52) quaid: "Now you can not only contribute to the release notes
with the same work ... but your group will output several articles or a
guide."
(21:30:56) ghenry: my net connection is flaky tonight, so my comments
are a bit wavy
(21:31:18) quaid: this gives us somewhere to parse the RH docs into,
conceptually, so we're not handling big guides, but still do something
to provide value to that content.
(21:31:19) BobJensen: I think all of us have time to do small parts of a
bigger picture as long as we can project track and keep things moving if
someone "falls down"
(21:31:33) quaid: right, project tracking is the key
(21:31:43) quaid: and double coverage where we can, buddy system
(21:31:48) BobJensen: Yup
(21:31:53) Sonar_Guy: +1
(21:31:56) BobJensen: +1
(21:32:15) BobJensen: we do that in Unity quite a bit, team of people
getitng things done
(21:32:49) Sonar_Guy: The whole issue with my working on the install
guide came to a screeching halt due to work. A buddy system would help
out there.
(21:32:56) quaid: yes
(21:33:00) quaid: we have that with trans
(21:33:06) quaid: one person gets busy and the whole language falls down
(21:33:16) quaid: that's improving with time, but it is what it is
(21:34:13) quaid: ok, and how can we use Plone to make this work even
better?
(21:34:30) quaid: give people ... a workbench .. with a queue of small
items to work on?
(21:34:41) quaid: the work itself could be out in the wiki with just a
paragraph that points at the URL
(21:35:03) quaid: just so it is being tracked somehow, and we can
automate the Wiki -> XML in CVS managed by Plone part
(21:35:03) BobJensen: the way we have plone set up is simple many can
contribute, some can edit and few publish
(21:35:12) quaid: exactly
(21:35:40) quaid: I think if the first thing we gave a new writer was an
empty queue, a way to fill it, and some suggested bits to work on based
on interest that we can push into their queue ...
(21:35:46) quaid: that would help a lot of the bench warmers
(21:36:15) BobJensen: yup
(21:36:34) Sonar_Guy: +1
(21:37:22) Sonar_Guy: If it is easy for the writer to submit the content
it is more likely for them to generate the document.
(21:37:33) quaid: I'm woefully ign'nt about our Plone setup
(21:37:35) quaid: need to fix that ASAP
(21:37:41) quaid: but this seems feasible, yes?
(21:38:02) Sonar_Guy: +1
(21:38:06) quaid: ok, I'm going to reiterate where I think we are:
(21:38:09) quaid: <summary>
(21:38:22) quaid: 1. Consolidate Beats into functional groups to work on
topic areas
(21:38:29) quaid: 2. Relnotes are only one of the Beats outputs
(21:38:32) stickster: quaid: I am seeing the CVS/XML solution dissolving
in favor of Plone/XHTML
(21:38:44) quaid: 3. Enable Beat groups to contribute little bits by
using a queue within the CMS
(21:38:55) quaid: 3.1 This means each Beat needs a strong leader/editor
type
(21:39:47) quaid: 4. Beat groups work on outputting one guide or several
tutorials based around their area
(21:40:13) quaid: 5. Incoming docs e.g. RHEL docs, usable LDP or other
OPL content, etc. are parsed into the Beats in chunks
(21:40:31) quaid: chunk == all of the content about a topic area
(21:41:13) quaid: 6. We ask all writers to choose one or more Beats to
join, now and when new; then we can populate their queue with relevant
bits to work on.
(21:41:34) quaid: 7. Every content area gets double+ coverage to give
relief/back-up
(21:41:57) quaid: that it?
(21:42:21) BobJensen: good start
(21:42:31) quaid: </summary>
(21:42:44) quaid: how soon can we have the infrastructure in place?
(21:42:55) quaid: it would be good to announce when we are actually
ready for people to do something.
(21:43:00) Sonar_Guy: quaid: one last thing KISS Keep It Stupidly
Simple!!
(21:43:14) quaid: ok
(21:43:18) quaid: how can we make this simpler?
(21:44:56) Sonar_Guy: Another member of unity and I were talking last
night about how hard it is to work on a structured document. If there
was a form that took the information and fomated it without the user
doing the formatting it would make it easier for a poster to generate
documentation.
(21:45:40) stickster: Sonar_Guy: Just to make sure I'm understanding,
what do you mean by "structured" and what is hard about it?
(21:46:05) Sonar_Guy: The form would put it into a rough draft fomat for
the editor to tweak and help keep moving it forward throught
publication.
(21:46:40) Sonar_Guy: CVS and the format for DOC is overwhelming to a
new poster. As is our template on FU.o.
(21:46:54) quaid: thought templates were supposed to make it easier
(21:47:12) quaid: Sonar_Gal: how about structured text?
(21:47:13) Sonar_Guy: They are, but templates are only so good.
(21:47:19) quaid: i.e., email. .. which some people find way hard, too
(21:47:31) quaid: here's my thing ...
(21:48:04) quaid: with few, very rare exceptions *cough* mether *cough*,
if someone isn't interested in the minimal editing and structure for
their work, they are too much effort for us out of the gate
(21:48:28) quaid: I'd rather miss out on one or two of those rarities,
and I know we do!, but am I wrong about that?
(21:48:39) stickster: Sonar_Guy: +1 on the CVS call, +1 on DocBook even
(21:49:04) stickster: But at *SOME* point, people have to be willing to
do some structuring in their doc -- otherwise how is the editor supposed
to read the organization to know if it makes sense?
(21:49:20) quaid: I think plain text structuring is enough
(21:49:21) stickster: I mean, you don't write a high school term paper
without writing an outline, right?
(21:49:27) quaid: for a draft, anyway
(21:49:27) stickster: quaid: Yup
(21:49:31) BobJensen: stickster: that is what makes our template hard
for some for FU.o
(21:49:40) stickster: quaid: People should also be looking at the Plone
editor to see how it works
(21:49:47) quaid: maybe we need a plain text template for people to
follow
(21:49:53) Sonar_Guy: Agreed, however if the outline was a form to fill
in, that makes it easy.
(21:49:59) BobJensen: stickster: they are required to think about the
structure of the post first
(21:50:05) stickster: as I mentioned before, I think CVS/XML are going
to fall into disuse in favor of Plone's XHTML
(21:50:09) ghenry: bens up, have to dash. by efor now
(21:50:12) ghenry left the room (quit: "oops").
(21:50:31) stickster: Sonar_Guy: How do you fill in an outline for an
unknown topic, other than just the introduction (purpose, audience,
etc.)?
(21:50:50) stickster: If that's all you're looking for... I can have one
ready for you in an hour
(21:50:55) stickster: :-)
(21:51:15) megacoder: It's called "ooffice", isn't it ;-)
(21:51:55) stickster: Heh
(21:51:57) Sonar_Guy: Most people do not understand document flow,
having a form that walks them through filling out the outline and then
Fleshing out the outline into a rough document will make it easier for a
poster to generate the type of documentation needed.
(21:52:07) quaid:
http://people.redhat.com/kwade/fedora-docs/text-template.txt
(21:52:15) BobJensen: lol
(21:52:32) megacoder: If folks can't even manage to generate an outline,
should be believe their technical info?
(21:52:32) quaid: hmm .. a form
(21:52:46) quaid: 1. What topics do you want to cover? List them
separated by commas
(21:52:48) megacoder: s/be/we/g
(21:52:56) quaid: then those become the top levelsl, etc.
(21:53:19) quaid: megacoder: yeah, see, that's where I keep stopping at
(21:53:21) quaid: how low do we go?
(21:53:30) quaid: we have google for that already
(21:53:31) stickster: So now we're going to teach people how to write?
(21:53:49) stickster: Umm... isn't that a little like the developers
spending their time teaching people how to program?
(21:54:01) stickster: megacoder: +1, btw
(21:54:09) megacoder: I know: I'll invent a documentation language that
uses, get this, INDENTATION to suggest chapters, paragraphs and
sentences and words...
(21:54:22) megacoder: I'll call it MYTHON!
(21:54:24) stickster: Heh
(21:54:41) quaid: lol
(21:54:56) Sonar_Guy: No so much teaching them how to write, but how to
get thier information into the format needed for the docs project.
(21:55:08) megacoder: The folks will need to know about the TAB key and
spelling. Oops, spelling is hard. Gotta work on that one.
(21:55:48) quaid: I don't mind if there is polishing needed
(21:55:59) quaid: that is acceptable in coding projects, too
(21:56:03) quaid: practices, etc.
(21:56:11) mether: so, someone called me here?
(21:56:14) megacoder: Sonar_Guy: we'll take ANYTHING. We have resources
that are just waiting to do format surgery.
(21:56:29) stickster: mether: quaid just tossed your name out, is
all :-)
(21:56:36) BobJensen: mether: no we were just using you as an exmaple
(21:56:50) ***quaid is about to jump on a phone call
(21:57:05) mether: ok. anyone here to format
http://fedoraproject.org/wiki/ThomasChung/pup into docbook and publish
it?
(21:57:08) megacoder: XHTML is OK because I can morph that into DocBook
XML easily enough. You give me the content, we can package it.
(21:57:32) Sonar_Guy: Ok, then that solves that issue.
(21:57:38) BobJensen: megacoder: Tommy that sounds like a challenge....
(21:57:47) BobJensen: hehehe
(21:57:51) quaid: please continue without me, anyone can call meeting
closed when it's obvious :)
(21:58:07) BobJensen: Our thanks quaid 
(21:58:21) megacoder: Not a challenge, just a restatement of our current
position which has gotten LITTLE or NO content submittals
(21:58:24) quaid: moi aussi
(21:58:59) BobJensen: megacoder: I know I was only joking
(21:59:23) megacoder: Smiley when you say that, Stranger ;-P
(21:59:27) stickster: megacoder: Meaning, formatting is not the problem,
the lack of content continues to be the problem?
(21:59:29) megacoder: I know
(21:59:40) megacoder: stickster: got it in one
(21:59:52) stickster: megacoder: Just wanted to make sure the world
hadn't passed me by... again
(22:00:15) Sonar_Guy: lol
(22:00:21) megacoder: Every think old is new again. (sic)
(22:00:32) mether: so again, we have content here -
http://fedoraproject.org/wiki/ThomasChung/pup. anyone wants to look at
formatting it?
(22:00:58) megacoder: Heck, I will
(22:01:37) stickster: nman64: Does the Fedora Plone include Kupu?
(22:01:40) mether: ok anyone updates on relicensing of RHEL docs quaid 
(22:01:46) BobJensen: mether: I will see what I can do, I have another
guy who wants to get started on something new
(22:01:55) nman64: stickster: Yes.
(22:02:01) stickster: nman64: thanks :-)
(22:02:08) mether: BobJensen, ya. needs a editorial review and
formatting
(22:02:18) tcf_home left the room (quit: Client Quit).
(22:02:24) mether: BobJensen, get people to post on the list so not
everyone ends up doing it 
(22:02:38) megacoder: BobJensen: I'm withdrawing my offer then.
(22:03:23) BobJensen: mether: will try to have it done with in the week,
trying to hook up with the other writer has been a little hard at times,
if that plan fails I will take it on single handedly
(22:03:37) mether: ok. whatever works
(22:04:15) stickster: nman64: Can I make a short list of Kupu
"styles" (or whatever the term is) that would be useful, and send them
to you? Is there anywhere I can find the current list of attached CSS so
I can give you more useful input?
(22:04:41) mether: stickster, the workflow for the ideal system that you
posted on fedora-websites list will probably take time. is that a
requirement to redirect f.r.c to fp.org?
(22:05:04) stickster: mether: I don't see why it should hold up
anything, no
(22:05:20) stickster: It's a goal to shoot for, nothing more or less
(22:05:38) megacoder: so long until next time. Cheers
(22:05:46) nman64: stickster: What browser do you use?
(22:05:49) stickster: FDP: btw, Kupu is the (optional?) on-screen editor
in Plone... it produces XHTML.
(22:05:53) stickster: nman64: Firefox
(22:06:10) megacoder left the room (quit: "Chatzilla 0.9.73 [Firefox
1.5.0.3/2006042618]").
(22:06:16) stickster: ...at least I *think* it produces XHTML
(22:06:32) nman64: stickster: Grab the Web Developer extension for
Firefox and use it's CSS features. That's probably the best way to get a
quick look. (And it's a great extension, anyway.)
(22:06:39) stickster: nman64: I have it
(22:06:47) stickster: nman64: Will do
(22:08:01) Sonar_Guy: There are also other editing modules that can be
plugged in besides kupu.
(22:08:16) stickster: Sure
(22:08:46) stickster: The point is, if we have an editor that supports
character styles as well as paragraph styles, that would be ideal for
drafting documents
(22:08:56) stickster: nman64: can Kupu do that?
(22:08:57) Sonar_Guy: +1
(22:09:21) Sonar_Guy: But I believe that tinyMCE is beter suited for
that task.
(22:09:35) BobJensen: tinyMCE has security issues on the past
(22:09:45) nman64: stickster: I'm honestly not sure how extensible Kupu
is, but it's worth looking into. I personally switch off Kupu and use
plain text.
(22:09:59) stickster: nman64: No good for our contributors, unfortch.
(22:10:18) stickster: Sonar_Guy: tinyMCE == Java == no-go for some
people
(22:11:09) stickster: Sonar_Guy: Oh wait, Javascript, I can't read
today.
(22:11:10) stickster: :-(
(22:11:17) nman64: stickster: I've upgraded your Plone account to
Manager. You should be able to poke around the ZMI at
http://fpserv.fedoraproject.org/manage
(22:11:36) stickster: Lesson to all: this is what happens when you bug
the admin enough :-D
(22:11:57) Sonar_Guy: lol
(22:12:05) nman64: From there, the portal_skins item is particularly
valuable. ;-)
(22:13:31) stickster: nman64: Ah, I see, thanks
(22:15:09) stickster: *: All right, anything else at this point then?
(22:16:03) elliss: Yes, minor.
(22:16:11) elliss: RPM Guide
(22:16:33) elliss: I converted this to DocBook a while ago in CVS.
(22:17:02) elliss: With the changes to the build process it probably no
longer builds
(22:17:29) elliss: That won't take long to fix
(22:18:02) elliss: But it also needs someone to go through the
autogenerated DocBook and reformat
(22:18:29) elliss: I did about three or four chapters before the IG took
precedence.
(22:19:10) elliss: I can look about getting it to build again
(22:19:53) elliss: But it needs another contributor to carry it forward.
(22:20:42) stickster: elliss: What sort of reformatting did you find
necessary?
(22:21:00) stickster: (other than fixing file names, sectN -> section,
etc.)
(22:22:18) elliss: I've just looked at my notes...
(22:22:48) ***Sonar_Guy has to run Kids have a concert tonight at school
(22:22:50) elliss: Fixing up the markup for URLs and <command>s like
rpm 
(22:22:57) stickster: ah
(22:23:04) elliss: A lot of find and replace
(22:23:15) elliss: About an hour per chapter
(22:23:21) stickster: OK, I will put this on the schedule so we can find
someone to help
(22:23:23) elliss: 30 chapters :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-dsco-list/attachments/20060509/0deb09c7/attachment.sig>