I was delighted to see my name in a previous email. It is an encouragement that I am important.
There are a couple of ideas that come to my mind regarding the topic.
.
Can the group move to a facebook/G+/forum/Linkedin approach, where we can "bid" on doing documentation, where the docs can be scrutinized by anyone with a cellphone/tablet. The writing tool is a partial issue, only chose a software that does not always require on-line access.
I am in Canada; I don't know if that makes any differences.
By the way, when I write user documentation, I target my audience and their skill levels.
I start of course with a plan. My usual plan is to have an introduction to the product, and a brief history.
Before beginning chapter 1, I point the reader to a table listing the error messages, explaining why the message occurred, and what action the user must take to resolve the problem.
An installation and setup guide is in an appendix and then the usage essence of the software is up front as chapters. I try to make the "readme file" memorable. If it is important,I tell the reader to keep it aside and as he/she will need to refer to it during the installation. I also encourage them to read it a few times before jumping in.
In this way,the manual becomes both a user document, a reference document and a keepsake. I also like to leave aside what I write for 24-48 hours and then proof read it again.
So, post the challenges on Linked-in (therein is a Fedora group), do the same on the Linux group. Ask the community how they would like to help. If the rejects say maybe because I have poor writing skills, just poo poo that and explain that we have some editors that will fix the grammar and spellings. Make the group warm and cozy.
Example. On Linked in post. We need some writers for abc, def, ghi, and mno. Can someone take on one topic individually or with a peer and provide a first draft by Dec,30,2014. Can they produce a table of contents?
Post what is open to deliver as a requirement . Offer a beer as the reward the next time you can get together, or just offer good friendships.
I would like someone to assign me a topic and a date, I will see if a) I have the knowledge to respond, b) if I can do the work in time, or c) I can do it with collaboration.
If the work is not fun to do, it won't get done.
Pete, when an employer allows his guy to take his productivity time for IRC,meeting, he is lucky. Most can respond to a Forum.
Leslie
PS. Any writing clubs or groups or senior golden-agers who don't know or heard about Linux can be targeted too. Many of those members were/are top notch software developers. They have brains that they do not want to become rusty. You would be surprised at the timelyness and quality of writing that many of these individuals can provide.
Our Spanish, Russian, French, Chinese Fedoracans should get the same messsage. I can translate French to English, and work with French writers. Who knows how friendships can develop. Why does it have to be English First, and the other languages second?
There are a couple of ideas that come to my mind regarding the topic.
.
Can the group move to a facebook/G+/forum/Linkedin approach, where we can "bid" on doing documentation, where the docs can be scrutinized by anyone with a cellphone/tablet. The writing tool is a partial issue, only chose a software that does not always require on-line access.
I am in Canada; I don't know if that makes any differences.
By the way, when I write user documentation, I target my audience and their skill levels.
I start of course with a plan. My usual plan is to have an introduction to the product, and a brief history.
Before beginning chapter 1, I point the reader to a table listing the error messages, explaining why the message occurred, and what action the user must take to resolve the problem.
An installation and setup guide is in an appendix and then the usage essence of the software is up front as chapters. I try to make the "readme file" memorable. If it is important,I tell the reader to keep it aside and as he/she will need to refer to it during the installation. I also encourage them to read it a few times before jumping in.
In this way,the manual becomes both a user document, a reference document and a keepsake. I also like to leave aside what I write for 24-48 hours and then proof read it again.
So, post the challenges on Linked-in (therein is a Fedora group), do the same on the Linux group. Ask the community how they would like to help. If the rejects say maybe because I have poor writing skills, just poo poo that and explain that we have some editors that will fix the grammar and spellings. Make the group warm and cozy.
Example. On Linked in post. We need some writers for abc, def, ghi, and mno. Can someone take on one topic individually or with a peer and provide a first draft by Dec,30,2014. Can they produce a table of contents?
Post what is open to deliver as a requirement . Offer a beer as the reward the next time you can get together, or just offer good friendships.
I would like someone to assign me a topic and a date, I will see if a) I have the knowledge to respond, b) if I can do the work in time, or c) I can do it with collaboration.
If the work is not fun to do, it won't get done.
Pete, when an employer allows his guy to take his productivity time for IRC,meeting, he is lucky. Most can respond to a Forum.
Leslie
PS. Any writing clubs or groups or senior golden-agers who don't know or heard about Linux can be targeted too. Many of those members were/are top notch software developers. They have brains that they do not want to become rusty. You would be surprised at the timelyness and quality of writing that many of these individuals can provide.
Our Spanish, Russian, French, Chinese Fedoracans should get the same messsage. I can translate French to English, and work with French writers. Who knows how friendships can develop. Why does it have to be English First, and the other languages second?
Subject: Re: Lowering the participation barrier for Fedora Docs
On Nov 18, 2013, at 5:37 PM, Pete Travis <me@xxxxxxxxxxxxxx> wrote:
> It would be *ideal* if they were eventually willing to learn DocBook.
What about Simplified DocBook as a starting point? Or is it sufficiently different to be pointless going down that road?
Chris Murphy
--
docs mailing list
docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/docs
-- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
