IDEA: Has been suggested this could become an official How To make a Doc with Publican
Objectives
- Getting people interested in Docs project, to feel confident with the tools used, getting an useful product finished to share.
- Get them to work together into learning and meet each other, sharing more ideas to work in Fedora.
- Engage that people into solve a real need for an actually maintained guide.
- Getting more and more qualified people into the real for Docs Team.
Schedule proposed
These could be the tasks for a first introductory crash course
Based on my readings of POSSE, and the advice provided for Kevin Fenzi to my blog post on Escuela Fedora - Fedora School.
First week, first article wrote with Publican
Everyone should be able to produce a first article using Publican in a maximum time of a week. We have plenty of tools to write synchronously a first draft authored by every student, in a live session of one-and-a-half-hour.
Prerrequisite: Setting up a fedorapeople space
Introduction to Publican and first repo git
0) Meet-up at Classroom (#fedora-classroom on freenode). Describe essential tags and creation of first article, *inside a git repo* (local at least).
Hands on writing our first article with Publican
Jump to Gobby (prefered, alternative could be etherpad or git push/pull).
1) Everyone upload the skeleton of a first article and start to write.
2) Our teacher(s) could oversight errors and fix/suggest corrections.
3) Everybody could see what is doing his/her fellows and give feedback too.
4) Download their document writen in gobby and put in place of their local repo.
Followup asynchronously (if anyone gets in trouble, ask in the ML).
5) Commit the draft at his current state.
6) Push to fedorapeople remote git repo
7) Follow writing the article until a good shape for it, and proofread it.
8) Push to git; publish to fedorapeople; announce in ML.
9) Choose another guide (not yours), cloning the repo for yourself.
10) Review and try to make improvements (if any). Create a patch and share in your fedorapeople space; announce to ML.
11) Test the patches and (optionally) merge/give write access to your repo to your contributors.
12) Share your work with the world and your feelings about the experience
Second week, explore into the jungle
Second talk on IRC and guidance for next steps
Lucky 13) Talk in #fedora-classroom about how the docs writers do their job for real: reading Beats; checking Bugs; reading more...
14) Choose a real guide you want to contribute and clone it for yourself.
(We could take two steps to workaround network lags:
* Take release notes and everyone choose one chapter/beat. We could
give just the copy of the chapter to work in;
* Asking every "student" to choose a guide and clone *previous* to
the second session, to work in real bugs of it).
Would be better if the synchronous session could count on with more
than one teacher, maybe some guide owners? This would be the best way
to learn new tags, and a richer experience by more writers.
"Final" steps would finish the job, and can be done asynchronously
15) Of course, create the "git patch" with the job done and sent to owner of the guide.
16) Optionally: apply for membership into that project or start a new project, discussing it on the list for potential contributors.
Another aproaches
Another approach could be through pages need love in the wiki, but if something is easier to solve through git even involving lots of files, it's anything but easy into wiki if too much pages being touched.
After joined to the Docs Project.
Once you have joined the Docs Project you are free to work on any project or task we might have. If you aren't sure where you'd best fit please feel free to talk with us and we'll help point you in the correct direction.
Meetings
- Using/editing agenda howto. User:Tezcatl/COMOs/Reuniones (in Spanish, but based mainly in Zodbot howto.
Tasks by levels
Docs Project content tasks for new contributors
Docs_Project_content_tasks_for_experienced_contributors