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

[Christopher Antila]

Hello Jesus and everybody:

I encourage the creation of this "crash course" document. Even though
I've written a Guide and continue to update it periodically, I forget
how to use the Docs tools, and I certainly remember how intimidating it
was when I first started.

I also think that we need more people, as you say, to contribute "for
real to Fedora top-projects." The Guides collectively have many
opportunities for improvement. It's not that the Guide owners don't know
about these possible improvements, but that we don't have enough time to
make all of the possible optimizations between releases. Additional "for
real" contributors would be a significant advantage.

I'm not sure what you're asking, Jesus, but if you propose writing the
document yourself, then go ahead and get started! If you would like help
with specific tasks, like to make sure that a particular chapter is
correct, you can ask for help on this mailing list.

As a more general observation, I wonder if a stronger QA ("Quality
Assurance") process would help with this problem. I know that some
Guides have QA contacts, but for others Bugzilla simply gives this
mailing list, and some (like the Musicians' Guide) have no QA contact
whatsoever. Lack of an active QA process means that, if a contributor
makes a mistake, it won't be noticed until after release - and that's
understandably intimidating.


Christopher.

On Thu, 2011-01-20 at 12:00 +0000, docs-request(a)lists.fedoraproject.org
wrote:
>  ...
>
>  Message: 3
>  Date: Thu, 20 Jan 2011 08:24:45 +0000 (UTC)
>  From: Jes?s Franco <tezcatl(a)fedoraproject.org&gt;
>  Subject: Please tutor a crash course on Docs Project tools & workflow.
>  To: docs(a)lists.fedoraproject.org
>  Message-ID: <pan.2011.01.20.08.24.43(a)fedoraproject.org&gt;
>  Content-Type: text/plain; charset=UTF-8
>  
>  Hi Docs team.
>  
>  I've read on last meeting-minutes the action item about getting someone 
>  to leader the RelNotes writing. There is a lot of talk lately too about 
>  getting more people into contributing for real to Fedora top-projects.
>  
>  But i think this is not an area than marketing can manage just by making 
>  Fedora look friendly and open to all. I've read since i joined to Docs 
>  project a lot of people (just like me), willing to join, and no matter 
>  how much is said "don't worry, if you broke something we can fix it"; 
>  it's simply overwhelming the idea of doing things bad since many times we 
>  don't know the way of doing things the right way.
>  
>  We need to learn how to make successfully what we'd like to. And no, there 
>  is no just matter of time or reading the bunch of pages under Docs 
>  category in the wiki. You know a lot of there is outdated and it becomes 
>  confusing when you read an updated page and kindly someone corrects and 
>  says: "It's outdated". A big WTF. (That's why i don't like
> mediawiki).
>  
>  This is happening because we are not the number of qualified people we 
>  would like to be. But we can.
>  
>  I'm working on a Draft for an introductory crash course to Docs Project, 
>  based on practical workshops to learn the basic of Publican, *git*, and 
>  the workflow preferred by the actual contributors.
>  
>  The goals of this course, would be:
>  
>  0) Acquiring practical dominion of that tools, letting more people feel 
>  confident to join to the Docs project.
>  1) Recruiting more people to work into real tasks of Docs Project.
>  
>  Forgive my references to gaming.
>  
>  World 1 
>  
>  ***Tutorial level. We need for first class...***
>  
>  * Make a schedule than effectively can let people to commit minor tasks 
>  with Publican/git, since first class.
>  * A main tutor able to run at least one-and-a-half hour class on IRC, 
>  showing folks how to produce their first Doc with the minimum hassle.
>  * People able to join to gobby writing of the first article of folks, to 
>  help tutor in fixing mistakes people will fail (something like paired 
>  programming driver-navigator).
>  
>  For folks unable to join to classroom session (and who can't finish the 
>  first world at first attempt).
>  
>  * More people helping the tutor in helping people (it can be via ML) to 
>  solve issues they (we) will face for sure at their first attempt.
>  * Also, people answering questions the students will confront sharing 
>  their patches, and troubleshooting whatever error they will found.
>  
>  We can encourage students too, to helping each other via the ML, and 
>  getting into the thread just for fix minor mistakes.
>  
>  Following the games analogy:
>  Level 1 would be actually writing with succes their first DocBook article.
>  Level 2 uploading to a git repo.
>  Level 3 taking another people article and suggesting changes via a patch.
>  Level 4 applying the patch and adding collaborators. (er, optional?)
>  Level 5 sharing their experience and figuring out what official guide 
>  they'd like to contribute.
>  
>  World 2.
>  
>  This time the challenge would be:
>  
>  * Choose a Docs top-document (Release Notes is my first candidate) to 
>  give people the chance to get into the real workflow of Docs project.
>  
>  We would combine again at least a synchronous session and the heavy load 
>  could be conducted through ML/bugzilla and work with repos/branches.
>  
>  I'm not so clear about that, so i'd like you really give feedback to:
>  
>  https://fedoraproject.org/wiki/Docs_Project/
>  Course_for_New_Contributors#Second_week.2C_explore_into_the_jungle
>  
>  ==== Too much changes? Naah ====
>  
>  If you read carefully, we could load a bunch of people into ML and maybe 
>  messing into bugs and patches (and always has been said that's fine, 
>  since we always can clean the house, right?); Apart from the classroom 
>  meetings via IRC/Gobby, we wouldn't take much more work than today. Just 
>  compare that to the steps to join L10N and Ambassadors teams*.
>  
>  The real difference is we could arrange by some weeks people learning 
>  together and working with Guide owners and experimented people, hopefully 
>  giving them (us) a more solid scale to jump into Docs boat than sending 
>  them to find the bit into the mess of Docs category in the wiki.
>  
>  Also, everything of this experience should be stored as an updated 
>  reference for people unable to join at the first invitation. I'm 
>  confident than this would be something similar to writing code from 
>  scratch in a cleaner and fresh way, than trying to fix overbloated code 
>  with too many patches acumulated over the time.
>  
>  And i'm pretty sure all that experience could be summarized and rearranged 
>  as an actual course in a way people could follow the manual and becoming 
>  more able to join Docs project and getting their hands dirty.
>  
>  You can fire to me now ;)
>  
>  
>  Best regards.
>  --
>  Jesus Franco
>  Fedora Ambassador and Translator
>  http://fedoraproject.org/wiki/User:Tezcatl
>  
>  P.S. I don't say translators and Ambassadors can't become better and rich 
>  higher levels in the quality of our contributions (I don't believe in 
>  number of strings translated just because Google seems easier than 
>  actually checking our translations). Just than those teams don't look so 
>  intimidating and it's lot of easier growing into them step by step.
>  
>

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

[Zach Oglesby]

On Thu, Jan 20, 2011 at 11:56 PM, Christopher Antila
<crantila(a)fedoraproject.org&gt; wrote:
>  As a more general observation, I wonder if a stronger QA
> ("Quality
>  Assurance") process would help with this problem. I know that some
>  Guides have QA contacts, but for others Bugzilla simply gives this
>  mailing list, and some (like the Musicians' Guide) have no QA contact
>  whatsoever. Lack of an active QA process means that, if a contributor
>  makes a mistake, it won't be noticed until after release - and that's
>  understandably intimidating. 
This is something that I need to reengage, we need to have a process
in place for QA and we have yet to hammer that out. I hope to have
something done in the next few weeks, so that for F15 all docs will
have a good scrub before release.

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

[Jesús Franco]

El Thu, 20 Jan 2011 17:56:23 -0500, Christopher Antila escribió:

>  Hello Jesus and everybody:
>  
>  I encourage the creation of this "crash course" document. Even though
>  I've written a Guide and continue to update it periodically, I forget
>  how to use the Docs tools, and I certainly remember how intimidating it
>  was when I first started. 
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.

>  I also think that we need more people, as you say, to contribute
> "for
>  real to Fedora top-projects." The Guides collectively have many
>  opportunities for improvement. It's not that the Guide owners don't know
>  about these possible improvements, but that we don't have enough time to
>  make all of the possible optimizations between releases. Additional "for
>  real" contributors would be a significant advantage. 
Yes, the actual number of people able to maintain the guides is certainly 
small (and for sure without the full time they'd like to have to do it), 
so, this course could be a way to attract more people to contribute, and 
making them *able to do that*, not just "willing to do".

>  I'm not sure what you're asking, Jesus, but if you propose
> writing the
>  document yourself, then go ahead and get started! If you would like help
>  with specific tasks, like to make sure that a particular chapter is
>  correct, you can ask for help on this mailing list. 
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.

>  As a more general observation, I wonder if a stronger QA
> ("Quality
>  Assurance") process would help with this problem. I know that some
>  Guides have QA contacts, but for others Bugzilla simply gives this
>  mailing list, and some (like the Musicians' Guide) have no QA contact
>  whatsoever. Lack of an active QA process means that, if a contributor
>  makes a mistake, it won't be noticed until after release - and that's
>  understandably intimidating. 
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.

>  Christopher. 
Thanks again for your comments on this issue.

-- 
Salud, tierra y libertad
Jesús Franco http://identi.ca/tzk
http://fedoraproject.org/wiki/User:Tezcatl