|
By XavierP at 2005-12-11 16:22
|
At the right hand side of the screen, there is a box which reads
Quote:
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
|
We do honestly want original content from you, the members of LQ. (We also like the Linux news links so keep them coming too).
So what does this have to do with you? Well, at the bottom of this post there is a link to email me. If you have an idea for an original article, put together a very brief summary of it and email me. I will then make contact with you and we can work together on making your idea into an article. I will be acting editorially, by the way, and won't be looking for a credit ;)
Articles can be on almost anything - read through the ones we have already and see if there is something you have been thinking of that would fit here.
Get writing!
|
|
|
It will hopefully help you when you come to put your own articles together.
~~~ 0;-Dan
I agree! But the only way things will be renewed or updated is by LQ member participation. Choose something and contribute a updated/revised article.
Most active LQ members are aware of the situation but to correct things someone needs to take the first step(s).
I would but too much on my platter/TODO list at this point in time.
Go for it!
I agree! But the only way things will be renewed or updated is by LQ member participation. Choose something and contribute a updated/revised article.
...
I've made inquiries at several projects and linux docs project and get a similar story every time I ask.
If someone on LQ has clues how to proceed, please let me know what those are.
~~~ 0;-Dan
I've made inquiries at several projects and linux docs project and get a similar story every time I ask.
If someone on LQ has clues how to proceed, please let me know what those are.
~~~ 0;-Dan
To put it plainly, tech speak is one thing while general technical writing is a composition to interpret for the reader to understand the underlining information presented by the application author. Sometimes you must pull the information from the developer while at other times you will need to perform interpretations of their intent or even a single description of the operation as you see it. And hopefully you and the developer end up agreeing on your presentation. Interaction is important! But not always necessary if you have the skills to perform the desired task(s).
If you happen to be wrong then your interaction with other skilled writers will facilitate so as to provide a good/useful document. You could get lucky and have a developer who will share all documentation/notes for the application thus making things easier. I would not count on that since most programmers will not share their toolbox/notes unless $$ are involved.
To put it plainly, tech speak is one thing while general technical writing is a composition to interpret for the reader to understand the underlining information presented by the application author.
I've spent enough time in new-customer presentations and training to translate from tech to human pretty well.
Interaction IS important!! Where skills are concerned, code reading seems to be the only one that works because other details may exists, but are similarly hard to find.
Cheers,
~~~ 0;-Dan
I would but too much on my platter/TODO list at this point in time.
As a very simple example, a someone develops a word processing app. A very basic feature might be on how to underline selected characters, words or even whole paragraphs. The dev is the only one who can say, "To underline a word, select the word, and press Ctrl-U or go the formatting toolbar and press the button with the underlined characters on it." For someone new to word processors, this may not be as simple a task as it sounds.
When it comes to even more complex tasks such as writing macros, the devs are the only ones who can help the documenter with this.
For this I really needed to dig deep into the gfxmenu code, because so much had changed within that year. Not being too conversant with C, it was no easy task. I put every spare moment for almost four months into that, and of course the devs were of no help.
I can only imagine the horror of having to dig deep into the source code of a much larger program to document it. It really is next to impossible without the help of the devs. If only someone can get them to understand this.
It's in Swedish on one of my sites:
http://www.linuxdist.se/wp-content/u.../12/ubuntu.pdf
I've spent the better part of 4 weeks helping a member trouble shoot his printer.
One other Senior member joined the thread and an additional member joined as well.
Long story short; after much laboring and trouble shooting (on my behalf and others) I think it would be an asset to our group if I write a specific article addressing this Brother Printer issue and the steps advised that lead to a solved resolution.
I propose all of the ample information, links, commands and arguments to libraries that resulted in success to a printer that finally lead to complete functionality.
I'll gladly e-mail Xavier our Moderator the article but I figured it would be good to post of this first before investing time to compose the article; this would be the first paper I have written.
I thoroughly read the instructional page for "Writing An Article" the Heading, Lead and Conclusion is clear.
Where would I check to see that this subject has not been published already?