On Sat, 2011-01-22 at 12:00 +0000, docs-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > Date: Sat, 22 Jan 2011 06:45:16 +0000 (UTC) > From: Jes?s Franco <tezcatl@xxxxxxxxxxxxxxxxx> > Subject: Re: Please tutor a crash course on Docs Project tools & > workflow. > To: docs@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <pan.2011.01.22.06.45.15@xxxxxxxxxxxxxxxxx> > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
