On Sat, 2011-01-22 at 12:00 +0000, docs-request(a)lists.fedoraproject.org
wrote:
Date: Sat, 22 Jan 2011 06:45:16 +0000 (UTC)
From: Jes?s Franco <tezcatl(a)fedoraproject.org>
Subject: Re: Please tutor a crash course on Docs Project tools &
workflow.
To: docs(a)lists.fedoraproject.org
Message-ID: <pan.2011.01.22.06.45.15(a)fedoraproject.org>
Content-Type: text/plain; charset=UTF-8
El Thu, 20 Jan 2011 17:56:23 -0500, Christopher Antila escribi?:
Thank you Christopher for your encouraging words. It's really
important
to me for continue this effort. But my proposal was not a document or
guide covering the topics for beginner contributors. It is for a
class
(or two) delivered on IRC as part of the Classroom initiative.
Sorry - I misunderstood what you meant. I do not know much about Fedora
Classroom, but this also sounds like a good idea.
...
I'd be glad to write the whole guide (as complement to Publican User
Guide), but maybe i'm the last person with the knowledge necessary to
commit that, on this list. I've commited just a few minor tasks, (i'm
most
a translator), and maybe my whole knowledge related to DocBook is the
most basic of HTML and XML.
However, you can count with when i get the knowledge needed, i'll
commit
the task for myself. I've even delivered a first class (in my
mother
language, castilian) for my fellow ambassadors on the basics of our
ticketing system at latam (Redmine). I'm not shy to share even a
little
amount of knowledge (should i be?). Just i like to get more knowledge
to
do a more valuable contribution.
You can start the project,
then learn how to finish it as you go. If you
make a good plan before you start, other contributors might want to help
you finish (I certainly will)! This is one of the benefits of
open-source development. If we had to wait for somebody who knows
*everything* about a project before it starts, we would be waiting for a
very long time.
At the first very time the QA process was proposed for guides, one
idea
was something like "peer review" by another Doc
contributor, able to
read
the whole guide and making proposal for improvement, in the form of
real
patches, apart from bugs filed against the guide.
My feeling is than QA shouldn't be a bureaucratic blocking for writers
to
commit the actual writing and maintenance of the guide for continuous
improvement. It should be a way for let less experienced contributors
to
help with the owners of the guides, but we need at least a minimum
training to do so.
I agree that the QA process should not block writers from
committing.
What would be nice is for a QA person to ensure that every Bugzilla bug
has been successfully solved. This can be done after the fix has already
been committed. Also, if a writer, whether new or experienced, wishes to
have their work approved by QA, they could make a bug request.
Christopher.