RE: Fedora survey results
by David-Paul Niner
I looked back through my Gmail archives (thank you, Google!) and see
that Paul Nasrat was the person who had communicated with you. I am
CC'ing him on this email so he can get back into the loop for the RPM
Guide massage with which you kindly offered help.
I also see that Karsten was helping you with some problems you
experienced getting your official Fedora account working. Sorry you
were having problems; normally the process seems to work fine, but every
once in a while a contributor's specific configuration, or an ambiguity
in the procedure, makes it more difficult than it needs to be. What's
your status with regard to that account at this point?
<snip />
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
I've actually had to move away from using that particular account due to
the massive amount of spam it's attracted, so I'll have to update my
account with the new email address and public key information.
I'm leaving town for the next few days but will be back for the start of
classes next Monday, so I should be able to jump on the wagon then.
BTW--Karsten was a big help in getting the pub key situation resolved.
David-Paul Niner, RHCE
18 years, 3 months
RE: Fedora survey results
by David-Paul Niner
-----Original Message-----
From: fedora-docs-list-bounces(a)redhat.com
[mailto:fedora-docs-list-bounces@redhat.com] On Behalf Of Karsten Wade
Sent: Tuesday, January 03, 2006 3:52 PM
To: For participants of the Documentation Project
Subject: Re: Fedora survey results
On Tue, 2006-01-03 at 14:41 -0500, Paul W. Frields wrote:
> On Tue, 2006-01-03 at 12:39 -0500, Tim Burke wrote:
> > I hope you all had a great holiday. Sorry for the delay, and a
sincere
> > thanks to all who participated in the survey. The results of this
> > survey are hung off the fedoraproject.org marketing page under a
> > feedback section.
> >
> > http://fedoraproject.org/wiki/Marketing/Fedora
>
> I would highly recommend all DocMonkeys check out the results -- at
> least the summary -- listed on the URL above. Of special concern for
> us:
>
> A. "Improve documentation and release notes" was priority #3 on the
> list of 12, right behind "Improve overall stability" and "Implement
new
> features."
>
> B. Documentation appeared on the performance list in position #11 of
> 11. Yikes. 161 responses considered documentation performance as
> "strong good to excellent," while 277 called it "poor."
>
> Certainly we all know that we're hampered somewhat by a lower level of
> involvement from the community than, say, Fedora Extras. But surely
we
> have made and can continue to make improvements. Let the discussion
> commence!
I'm both pleased and upset by the results.
Upset because it confirms what I've known, which is that we're falling
short of the need and it shows.
Pleased because ... well, the same reason. What we're doing matters to
people, and they want more of it done right.
I would like to consider this as a marketing opportunity:
"X% of you think that Fedora documentation could use serious
improvement. Want to help?"
"Think Fedora documentation sucks? You can make it suck less."
> I think this should be on our agenda for today's FDSCo meeting if
> possible, so some initial responses can make it to the minutes posted
> here later tonight/tomorrow.
It's on the agenda, we'll maybe move it up the list?
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
--
I realize I'm an outsider here, so I'll keep my response short.
I volunteered a number of weeks back to work on some documentation (The
RPM manual, IIRC), and was told that someone would be divvying up the
sections and getting in touch with me soon.
So I waited. Not being incredibly familiar with those involved with
the docs projects I didn't feel comfortable just barging in and taking
over editing responsibilities.
No one got in touch.
I suppose one could fault me for not being more assertive, but with a
project of this size it's difficult to know precisely where "the new
guy" should position him- or herself.
I'm just wondering if there is anyone else out there on the fringes
offering to help but just doesn't know where to start.
The marketing idea is keen, and could produce returns, but once you get
the fish on the hook how, precisely, do you reel him to shore?
DP
18 years, 3 months
Minutes of FDSCo Meeting 03 January 2006
by Stuart Ellis
Attending:
---------
Karsten Wade (quaid)
Tommy Reynolds (megacoder)
Paul Frields (stickster)
Gavin Henry (G2)
Stuart Ellis (elliss)
Schedule of Tasks:
------------------
http://www.fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule
Highlights:
-----------
* Paul and Tommy: Packaging infrastructure work is close to completion.
Tommy will be reviewing the Makefile, and Paul will be updating the
Documentation Guide once the process is finalised.
By default, the HTML files within the RPM are marked with the "draft"
watermark - a build option will be documented that overrides this.
* Paul: Scott Glaser has volunteered to revise the opening chapters of
the Installation Guide, to make them more approachable for inexperienced
users.
* Stuart: Material for FC5 Installation Guide is mostly complete.
Section on package selection will be updated with test2.
* Karsten: Call for volunteers to go out, to build screencasts for
Fedora.
Full IRC Log:
-------------
https://www.redhat.com/archives/fedora-dsco-list/2006-January/msg00001.html
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
18 years, 3 months
Fedora survey results
by Paul W. Frields
On Tue, 2006-01-03 at 12:39 -0500, Tim Burke wrote:
> I hope you all had a great holiday. Sorry for the delay, and a sincere
> thanks to all who participated in the survey. The results of this
> survey are hung off the fedoraproject.org marketing page under a
> feedback section.
>
> http://fedoraproject.org/wiki/Marketing/Fedora
I would highly recommend all DocMonkeys check out the results -- at
least the summary -- listed on the URL above. Of special concern for
us:
A. "Improve documentation and release notes" was priority #3 on the
list of 12, right behind "Improve overall stability" and "Implement new
features."
B. Documentation appeared on the performance list in position #11 of
11. Yikes. 161 responses considered documentation performance as
"strong good to excellent," while 277 called it "poor."
Certainly we all know that we're hampered somewhat by a lower level of
involvement from the community than, say, Fedora Extras. But surely we
have made and can continue to make improvements. Let the discussion
commence!
I think this should be on our agenda for today's FDSCo meeting if
possible, so some initial responses can make it to the minutes posted
here later tonight/tomorrow.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 3 months
XSLT Tip
by Tommy Reynolds
Paul,
+ <xsl:for-each select="/rpm-info/copyright">
+ <xsl:element name="copyright">
+ <xsl:for-each select="/rpm-info/copyright/year"><xsl:element name="year">
+ <xsl:value-of select="node()"/>
+ </xsl:element></xsl:for-each>
+ <xsl:for-each select="/rpm-info/copyright/holder">
+ <xsl:element name="holder">
+ <xsl:value-of select="node()"/>
+ </xsl:element>
+ </xsl:for-each>
+ </xsl:element>
+ </xsl:for-each>
This is a bit verbose. Embedding so much of each element's path here
can be detrimental to maintainability. The <xsl:for-each> cycles
through the available /rpm-info/copyright/ elements, setting the
symbol "." or node() to the element currently getting the "focus", so
you could write this as:
<xsl:for-each select="/rpm-info/copyright">
<xsl:element name="copyright">
<xsl:for-each select="year">
<xsl:value-of select="."/>
</xsl:for-each>
</xsl:element>
</xsl:for-each>
HTH.
18 years, 3 months
Packaging progress
by Paul W. Frields
Hi Docs gangstas,
I am steadily making progress toward a packaging solution. Thanks to
Tommy jumping in with XSLT-based solutions, I learned a lot (although
not nearly enough, of course) about how to solve other problems using
the same building blocks. I also -- finally! -- figured out how to
package documentation for KDE's khelpcenter, and believe me, it's not
self-evident. Or rather, the end-state is comprehensible, but the
procedure for getting there cleanly is not. In any case, that's solved
too.
Also, the "fedora-doc-common" RPM is just about ready for rollout and
will contain (hopefully) everything required for people not operating
out of CVS to build docs. Mostly this just involves including our XSL
snippets, entities, custom scripts, and so forth. This is not to say
that by installing this RPM people will be able to just happily build
away, but it puts that goal within reach.
Since the fedora-doc-* stuff will probably live in Fedora Extras, and
because that is a rolling repository, it is much easier for us to work
on this in phases. Phase One goals are for our currently available
documents to be installable by an end user using yum, and that those
documents should show up prominently in each of the locations a user
might expect:
1. Launching "Desktop -> Help" for GNOME or KDE
2. Launching "Documentation -> [title]"
I don't know yet what Phase Two entails, but some goals might include:
1. Nice Python scripts for creating new XML document templates
2. " " " for building DRAFT-marked documents?
Some items I am still in the process of solving, by which I mean I
should be able to finish them for Phase One:
- The rpm-info.dtd needs some lovin':
- Packages should not get separate versions, too confusing
- Docs should not get releases, also confusing
- Figure out a way to condense generic person entries for use as
authors, editors, translators, and/or packagers? Alternately, remove
those not needed -- e.g. packagers only need full name and email,
authors, editors and translators need "component" names, and people
performing revisions only need initials. Some reference to dbpoolx.mod
shows this shouldn't be too hard to do.
- Provide functionality to automatically sort "doc" or "rpm" revisions.
Because RPM is particular about things like date formats in %changelog
entries, we may need to "encourage" proper formatting using the DTD. We
already have a *strong* hint there in the attributes Tommy provided, but
I don't think there's anything built in to a DTD to check for ordering;
I believe, however, that XSLT can sort. Anything we can do to
bulletproof the process is probably good. If it proves too cumbersome
to complete RSN, I'll push this off until Phase Two.
That's it from my neck of the woods. Hope everyone is enjoying the
holidays. The holiday break and the patience of my ever-lovin' wife are
the main reason I've been able to work on this stuff for the last few
days. Best to all, and here's to a Happy New Year!
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 3 months
