LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General > LQ Articles Discussion
User Name
Password
LQ Articles Discussion This forum is for the discussion of content posted to the Articles and Editorials section.

Notices


Reply
  Search this Thread
Old 12-12-2005, 08:43 AM   #1
XavierP
Moderator
 
Registered: Nov 2002
Location: Kent, England
Distribution: Debian Testing
Posts: 19,192
Blog Entries: 4

Rep: Reputation: 475Reputation: 475Reputation: 475Reputation: 475Reputation: 475
DISCUSSION: LQ Would Like Original Articles and Editorials


This thread is to discuss the article titled: LQ Would Like Original Articles and Editorials


Quote:
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
 
Old 02-18-2006, 03:10 PM   #2
XavierP
Moderator
 
Registered: Nov 2002
Location: Kent, England
Distribution: Debian Testing
Posts: 19,192

Original Poster
Blog Entries: 4

Rep: Reputation: 475Reputation: 475Reputation: 475Reputation: 475Reputation: 475
For anyone who is interested in writing an article, please read this LXer page: http://lxer.com/module/newswire/view/54348/index.html

It will hopefully help you when you come to put your own articles together.
 
Old 02-22-2011, 07:23 PM   #3
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: "North Shore" Louisiana USA
Distribution: Mint-20.1 with Cinnamon
Posts: 1,767
Blog Entries: 3

Rep: Reputation: 108Reputation: 108
As I read the site, many of the Articles and Tutorials are quite olde -- not only in calendar time, but also in terms of the content vs. the distro edition and components. The "topic" itself probably remains germaine, but the details are often written for kernels versions and package versions that may as well be ancient.

~~~ 0;-Dan
 
Old 02-23-2011, 10:26 AM   #4
onebuck
Moderator
 
Registered: Jan 2005
Location: Central Florida 20 minutes from Disney World
Distribution: Slackware®
Posts: 13,922
Blog Entries: 44

Rep: Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158
Hi,

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!
 
Old 02-23-2011, 01:16 PM   #5
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: "North Shore" Louisiana USA
Distribution: Mint-20.1 with Cinnamon
Posts: 1,767
Blog Entries: 3

Rep: Reputation: 108Reputation: 108
Quote:
Originally Posted by onebuck View Post
Hi,
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 do a pretty decent job of technical and end-user document writing, but I must have the information to work from. I can read code [grading C/C++ and scripting assignments] when I must but that becomes tedious work very quickly.

I've made inquiries at several projects and linux docs project and get a similar story every time I ask.
  • The developers know the details.
  • The details evolve at internet speed and get captured as code instead of documents.
  • Developers focus on code -- whether creating or maintaining -- instead of documents.
  • Developer time cannot then be used to provide raw details to writers.

If someone on LQ has clues how to proceed, please let me know what those are.
~~~ 0;-Dan
 
Old 02-23-2011, 02:00 PM   #6
onebuck
Moderator
 
Registered: Jan 2005
Location: Central Florida 20 minutes from Disney World
Distribution: Slackware®
Posts: 13,922
Blog Entries: 44

Rep: Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158
Hi,

Quote:
Originally Posted by SaintDanBert View Post
I do a pretty decent job of technical and end-user document writing, but I must have the information to work from. I can read code [grading C/C++ and scripting assignments] when I must but that becomes tedious work very quickly.

I've made inquiries at several projects and linux docs project and get a similar story every time I ask.
  • The developers know the details.
  • The details evolve at internet speed and get captured as code instead of documents.
  • Developers focus on code -- whether creating or maintaining -- instead of documents.
  • Developer time cannot then be used to provide raw details to writers.

If someone on LQ has clues how to proceed, please let me know what those are.
~~~ 0;-Dan
If you have done any third party technical documentation then you would understand that developers/maintainers are not proficient in communication outside their expertise.

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.
 
Old 02-23-2011, 02:57 PM   #7
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: "North Shore" Louisiana USA
Distribution: Mint-20.1 with Cinnamon
Posts: 1,767
Blog Entries: 3

Rep: Reputation: 108Reputation: 108
Quote:
Originally Posted by onebuck View Post
If you have done any third party technical documentation then you would understand that developers/maintainers are not proficient in communication outside their expertise.

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 the developer trench to understand tech speak.
I've spent enough time in new-customer presentations and training to translate from tech to human pretty well.
Quote:
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).
My original point is that access to developers, for linux topics, borders on not possible for the reasons I cited.

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
 
Old 09-08-2011, 11:22 PM   #8
towheedm
Member
 
Registered: Sep 2011
Location: Trinidad & Tobago
Distribution: Debian Stretch
Posts: 612

Rep: Reputation: 125Reputation: 125
Quote:
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.
This is the problem most times with people who write articles and documentations. They move on to other projects while the previous projects get some major changes but no one goes back to the original article to update it. I am guilty of this in one instance.

Quote:
I've made inquiries at several projects and linux docs project and get a similar story every time I ask.
  • The developers know the details.
  • The details evolve at internet speed and get captured as code instead of documents.
  • Developers focus on code -- whether creating or maintaining -- instead of documents.
  • Developer time cannot then be used to provide raw details to writers.
This is one of the thing badly lacking in linux apps. Proper documentaion, even a simple help file. In most instances, either the devs do not care to, or simple do not have the time to produce proper documentation even when someone else is willing to do the bulk of the work for them. They are the ones who develop the apps, and they are the only ones who know how to get things done.

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.

Quote:
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.
I switched to Linux in Dec 2009. In April 2010, I produced my first tutorial on 'Customizng the Graphics in GRUB, XSplash GDM and Usplash'. This is what I'm not guilty of updating. Later on I produced my second tutorial on 'Theming GRUB2'. The second edition was released in May this year (the link is in my sig for those interested).

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.
 
Old 02-15-2012, 04:01 AM   #9
johntaw
LQ Newbie
 
Registered: Mar 2011
Location: Stockholm/Sweden
Distribution: Centos 5.5, Debian, Fedora, Mandriva
Posts: 6
Blog Entries: 1

Rep: Reputation: 1
Cool Ubuntu install on VM Virtual Box

I have created a presentation with very easy step by step follow through pictures on how to install Ubuntu on Oracles VM Virtual box. The presentation requires no preinstalled software, all is included in the presentation. The goal is to make a 'real installation' rather then the Live mode.
It's in Swedish on one of my sites:

http://www.linuxdist.se/wp-content/u.../12/ubuntu.pdf
 
Old 01-28-2013, 02:21 PM   #10
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware, MX 18
Posts: 9,484
Blog Entries: 15

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Printer Troubleshooting with Ubuntu and Debian

Hi:

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?

Last edited by Ztcoracat; 01-28-2013 at 02:36 PM. Reason: Phrase correction
 
Old 10-29-2013, 04:39 AM   #11
jeuxdemoto12
LQ Newbie
 
Registered: Oct 2013
Posts: 1

Rep: Reputation: 0
Sometimes you must pull the information from the developer while at other times you will need to perform interpretations of their intent or even.........................
 
Old 10-29-2013, 12:22 PM   #12
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware, MX 18
Posts: 9,484
Blog Entries: 15

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
I agree with you jeuxdemoto12-
On getting the information from the developer.

However it is not always easy to get answers from a developer they are really busy people. Also; in some cases it is hard to find articles that they have composed online-

For example I had the pleasure of communicating with a developer that built drivers for a specific type of hardware that was designed for working with Linux.
Had I not found the developer and e-mailed him back and fourth I would not have been able to get that device working.
The developer did not have time to make a manual but I was fortunate to be able to communicate with him.

Sometimes one can not "perform interpretations" (even with some facts) for things to work or come together with certainty-- (least in this case I couldn't)
 
Old 12-20-2020, 11:53 PM   #13
Logimite
Member
 
Registered: Jun 2020
Location: California
Distribution: Linux Mint, ElementaryOS, ZorinOS, Manjaro
Posts: 64

Rep: Reputation: Disabled
Post Hello.

Might be a little late, but can I write for LQ?
 
Old 12-20-2020, 11:57 PM   #14
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.9.2009
Posts: 5,701

Rep: Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208Reputation: 2208
Quote:
Originally Posted by Logimite View Post
Might be a little late, but can I write for LQ?
My English teacher would have said, “I don’t know, can you?”

Click on the link and fill out the form.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Welcome to the Linux - News, Articles and Editorials Forum jeremy Linux - News 6 10-28-2004 06:45 PM
New Forum: Linux - News, Articles and Editorials jeremy LQ Suggestions & Feedback 2 09-21-2004 12:37 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General > LQ Articles Discussion

All times are GMT -5. The time now is 09:44 PM.

Main Menu
Advertisement
My LQ
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.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration