Please tutor a crash course on Docs Project tools & workflow.

[Christopher Antila]

On Sat, 2011-01-22 at 12:00 +0000, docs-request at lists.fedoraproject.org
wrote:

> Date: Sat, 22 Jan 2011 06:45:16 +0000 (UTC)
> From: Jes?s Franco <tezcatl at fedoraproject.org>
> Subject: Re: Please tutor a crash course on Docs Project tools &
>       workflow.
> To: docs at lists.fedoraproject.org
> Message-ID: <pan.2011.01.22.06.45.15 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20110123/9a436ed0/attachment.bin