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.