This page is for those who wish to write articles for Linux Gazette.
If you have any other questions, see the Linux Gazette FAQ.
Linux Gazette is dependent on Readers Like You for its articles. Although we cannot offer financial compensation (this is a volunteer effort, after all), you will earn the gratitude of Linuxers all over the world, and possibly an enhanced reputation for yourself and your company as well.
New authors are always welcome. Read the rest of this FAQ for topic and format suggestions and submit your completed work to firstname.lastname@example.org. If you're unsure whether the topic is appropriate, email a short description of your proposed topic, an abstract, to the same address and you will be informed of its suitability. The goal of Linux Gazette is to be an open community of contributors. There is no editor as such and we're relying on authors to be self-editing. You know as well as anybody what topics are interesting to the community. Additionaly, assume that your article is publishable, at most we'll take a cursory glance at it, spell-checking and grammar are the author's responsibility.
The following types of articles are always welcome:
We have all levels of readers, from newbies to gurus, so articles aiming at any level are fine. If you see an article that is too technical or not detailed enough for your taste, feel free to submit another article that fills the gaps.
Articles not acceptable include one-sided product reviews that are basically advertisements. Mentioning your company is fine, but please write your article from the viewpoint of a Linux user rather than as a company spokesperson.
If your piece is essentially a press release or an announcement of a new product or service, submit it as a News Bytes item rather than as an article. Better yet, submit a URL and a 1-2 paragraph summary (free of unnecessary marketoid verbiage, please) rather than a press release, because you can write a better summary about your product than the NewsBytes Editor can. The submission address for News Bytes is: email@example.com.
Articles not specifically about Linux are generally not acceptable, although an article about free/open-source software in general may occasionally be published on a case-by-case basis.
Authors retain the copyright to their articles, but readers are free to copy and distribute the articles as much as they please. LG's official copyright statement is at http://www.linuxgazette.com/copying.html.
Articles should be written in simple HTML. Please read the LG author's crash course in HTML and the LG author's style guide below.
The following was written in response to an author inquiry:
The article must be about Linux, about programming normally done on a Linux platform, etc. (Occasionally we may accept an article about a non-Linux open-source topic.) LG has a wide variety of readers, so technical articles, tutorial articles, human-interest stories and humor are all accepted. Rejected are mindless Linux advocacy and Microsoft-bashing that you can find plentifully in the advocacy newsgroups, and articles that appear to badmouth or slander a company unfairly.
The biggest criteria is, "Does the article provide new information, something that hasn't been published in LG in the past year?" An article may overlap a previous article in content, but is it a 100% overlap or is there any new information or a different perspective? We do ask that authors use the LG search engine and Index of All Issues to search for previous articles about the same topic and link to them. This makes it easier for readers to find all the useful information LG has on a certain topic.
There is no word limit. Most articles are 2-12 screenfulls of text, but they can be of whatever length necessary.
For their first article or two, new authors are encouraged to send a short summary or outline before writing it, to verify it will be accepted.
|Issue||Deadline for Articles||Comments|
|#89 April 2003||Monday, March 10, 2003||Early due to Editor's schedule|
|#90 May 2003||Wednesday, April 23, 2003|
|#91 June 2003||Monday, May 19, 2003||Early due to Editor's schedule|
|#92 July 2003||Monday, June 23, 2003|
|#93 August 2003||Monday, July 28, 2003|
|#94 September 2003||Monday, August 25, 2003|
|#95 October 2003||Monday, September 22, 2003|
Since we're not a paper magazine, we don't have a certain amount of space to fill. So if you miss a deadline, don't fret; just send it in anyway and it will go into the following issue.
Create the file using any text editor. Put a blank line between paragraphs
and begin each paragraph with
<H2>...</H2> around section titles, with a
blank line above and below. You may use H3 for subsections, H4 for
sub-subsections, etc, on up to H6. H1 is used by LG for the article
<PRE>...</PRE> around program listings,
output, configuration file text, and anything else which must line up
<PRE> goes on its own line above the block, and
</PRE> on its own line below. Everything inside this block
will appear in a monospaced font, and indentations and line breaks will be
To display a literal "<" in your article, type
instead. For ">", type
>. For "&", type
&. Otherwise, the browser will try to interpret them as
parts of HTML tags rather than displaying them. Look especially in program
listings since these symbols are frequently used in shell commands or
There are other HTML tags (BR, EM, STRONG, UL, OL, DL, IMG) you may optionally use to jazz up the document; see any HTML tutorial for their syntax and meaning.
A complete HTML document requires
<HTML><HEAD><TITLE>...</TITLE></HEAD><BODY>at the top and
</BODY></HTML>at the bottom. You don't need to do this for a Linux Gazette article because the Editor throws away your headers and footers and inserts the standard Gazette header and footer (with navigation bars).
Keep the HTML as simple as possible. Linux Gazette is read on a wide variety of graphical and text browsers, on new and old hardware.
Word processors (StarOffice, Microsoft Office) and HTML editors are notorious for doing the "bad" things below, in an attempt to make the HTML document look exactly like the word-processing document. Readers care about your text, not about your fancy formatting. If your word processor has an option to produce
simpleHTML without styles, please use it. Or save the document as text and add the simple HTML tags by hand. (The
<P>before paragraphs and
<PRE>...</PRE>around program listings are the only tags that are vital.)
<P>before paragraphs (
</P>after paragraphs optional).
<H1>around section headers. Use this instead of a bold paragraph--that's what it's for!
<PRE>around program listings and output. (Please also make a text file of the program listing; see below.)
HEIGHT=attributes in the
<IMG>tag. If the image is > 600 pixels wide, link to it rather than using an
<IMG>tag. PNG or JPG only, no GIFs.
's to achieve precise indentation or vertical space. The reader cares about your text, not about your fancy formatting.
"helvetica"(sans serif) and
"courier"(fixed-width). The default is roman (serif).
Articles may be of whatever length necessary. 2-15 screenfuls is typical.
At the top of the article or in the accompanying e-mail, clearly state: title, author's name, author's email (as it should be published) and bio. The bio is a few sentances about you for readers who are curious. It may be professional or personal, funny or serious, whatever you wish. See the bios at the bottom of most articles for examples.) The same bio will be reused for future articles until you submit an updated one.
Name the article author.html (where "author" is the author's last name in lowercase ASCII letters). If you have images, program listings or companion files, place them in a subdirectory misc/author/ and have your hyperlinks point there.
If you have images, please include the ALT text, WIDTH and HEIGHT in your IMG tags. Proper form is:
<IMG ALT="Alterate text" SRC="misc/author/file1.jpg" WIDTH="140" HEIGHT="80">The ALT text is for text browsers, blind users and those with images turned off. WIDTH and HEIGHT allow the browser to display the article around the image even before the image finishes downloading.
If you have inline program listings a user might want to run without having to type them all in by hand, please place a second copy of each listing in a text file called called misc/author/program.language.txt and put a hyperlink before the PRE block, thus:
bla bla bla this listing: (<A HREF="misc/author/trip.sh.txt">text version of this listing>)The ".txt" extension ensures the browser will not try to do something funny to it. Since it's a text file rather than HTML, you should not escape your "<", ">" and "&" characters.