1. How do I become an author for LG?

New authors are always welcome; the Linux Gazette is dependent on Readers Like You for its articles. Although we cannot offer financial compensation (the LG is purely a volunteer effort), you will earn the gratitude of Linuxers all over the world, and possibly an enhanced reputation for yourself and your company as well.

If you haven't written for LG before, the first thing you need to do is send a short bio to(for examples, see our authors list) along with a 200x200 picture of yourself. This bio will be reused for future articles until you submit an updated one.

(Note that your email address will not be exposed to spambots by LG: just like the addresses on this page, it will not be presented in text form, and thus will not be harvestable.)

Read the rest of this FAQ for topic suggestions and formatting requirements and submit your completed article to. If you're unsure about the suitability of the topic to LG, e-mail an abstract of your proposed article to the above address, and we'll happily give you feedback.

2. Acceptance policy

If your piece is essentially a press release or an announcement of a new product or service, trim it down to a URL and a paragraph or two and submit it toas a News Bytes item rather than as an article.

The following types of articles are always welcome:

• Technical articles of a HOWTO nature; how to set up a program, how to maintain it, "my experience running a program even if I'm not an expert", etc. An article discussing how you arrived at a solution by trial and error, and what problems you encountered along the way, will be of interest to many readers. These real-life experiences are one of the unique things that LG can offer, because that's exactly what's missing in most standard documentation.
• For even more ideas regarding possible articles, look in the Mailbag for recurring questions. Explicit requests for articles appear at the top of the "Help Wanted -- Article Ideas" section.
• Articles demonstrating the use of Linux in an industry or environment where it might not be commonly expected.
• Software reviews, as long as it is a balanced review and not simply an advertisement. Comparing the pros and cons of this program with similar programs is a plus.
• Reports from conferences, etc.
• Anecdotes, lighthearted stuff, etc.
• New, creative, Linux-relevant topics - including those not mentioned above - may fit the bill, or may create a category of their own. As we move forward in parallel with the development of Linux itself, our ideas on presentation and content change as well - and your article may well be the agent of that change. Go wild... you never know till you try!

We have all levels of readers, from newbies to gurus. In order to appeal to both, the "howto"-type articles should be centered around an interesting topic or task - even a complex one is fine - but should also contain clear, explicit instructions sufficient to replicate your results. 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. Realize, as well, that articles age as time passes; the fact that we've had an article on, e.g., VMWare within the last couple of years should not discourage you from writing one yourself provided that you have new, updated, or different information to convey.

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. Note: We'll happily accept articles previously published elsewhere, as long as the original copyright essentially amounts to the above, and does not prevent the article being re-released under the Open Publication License (OPL). LG's official copyright statement (in short, the OPL without the optional clauses) is at http://linuxgazette.net/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 criterion is, "Does the article provide new and interesting information?" 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 to look for previous articles about the same topic and link to them if appropriate. This makes it easier for readers to find all the useful information LG has on a certain topic.

There is no specific word limit on article length. Most articles are 5-20 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 that it will be acceptable.

3. Deadlines

The article submission deadline is "seven days before the end of the month" unless US holidays interfere (these would move the date back by their own length.)

Since we're not a paper magazine, we don't have a certain amount of space to fill. If you miss a deadline, don't fret; just send your article in anyway and it will go into the following issue.

4. LG's "minimal HTML" guide

Create the file using any plaintext editor. Put a blank line between paragraphs and begin each paragraph with <p>.

An actual HTML document contains headers and footers - i.e.

<html><head><title>...</title></head><body>

at the top and

</body></html>

at the bottom. In a Linux Gazette article, however, these are neither used nor at all useful, and will be removed if sent; instead, the first two lines of the file should be

author: your_last_name
title: Article Title

Note that there's no markup used around these lines: they are simply text, just as you see above. These will be used to generate the article and page title, as well as a link to you bio.

Place <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 title.

Place <pre>...</pre> around program listings, output, configuration file text, and anything else which must line up vertically. <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 displayed verbatim.

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 closely at program listings since these symbols are frequently used in shell commands or mathematical expressions.

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.

5. Style Guide

Keep the HTML as simple as possible. Linux Gazette is read on a wide variety of browsers and hardware, and we try to accomodate as many readers as possible. CSS markup, for example, will always get removed - so don't bother adding it in the first place. Also note that Word- or FrontPage-generated "HTML" is not acceptable; the hundreds or even thousands of markup tags created in the process are nearly impossible to parse into any semblance of useability. StarOffice/OpenOffice is a bit less virulent in its markup, but still painful; even plain text without any markup is preferable to any of the above HTML-mangling methods.

Good

• <p> before paragraphs (</p> after paragraphs optional).
• Standard markup tags (<a>, <em>, <strong>, <code>, <blockquote>, <ul>, <ol>, <dl>, etc).
• <h2> or <h3> around section headers.
• <pre> around program listings and output. (Please also make a text file of any program listings that are longer than 20 lines or so; see below.)
• Images. Include the alt=, width= and height= attributes in the <img> tag, i.e.

  <img src="misc/author/file1.jpg" alt="Description of picture" width="140" height="80">
  

  If the image is > 600 pixels in width, either shrink it or link it. Use PNGs or JPGs, make the file size as small as possible - and definitely no GIFs!

OK, but don't overuse

• Local style declarations (e.g., <p style="width='80%'">). These will mostly be deleted, or overridden by the LG stylesheet.
• Tables. Use mainly for columns of data; avoid for layout unless it's absolutely necessary. Often, <dt> and <dd> are actually what you need.
• Fonts and colors.

Bad

• Stylesheets.
• Underlining (<u></u>). This makes the text look like a link. Replace with <em>, and all will be fine with the world.
• Decorations and doodads on section headers. Sometimes these are tolerated for variety; other times, they go "poof".
• Extra <br>'s and  's to achieve precise indentation or vertical space. Much of that stuff will be lost anyway when people use a browser that is different from yours.
• Platform-specific fonts. The only words you need are "helvetica" (sans serif) and "courier" (fixed-width). The default is roman (serif).
• Javascript.

Name the article author.html (where "author" is the author's last name in lowercase). If you have images, program listings, or other companion files, place them in a subdirectory misc/[author]/ and have your hyperlinks point there.

If you have long program listings (e.g., longer than 20 lines or so) that do not require a line-by-line description, abstract them into a file called misc/[author]/[program].[language].txt and link to them in your article, thus:

The code for this example may be found <a href="misc/jones/trip.sh.txt">here</a>.

The ".txt" extension ensures the browser will not try to interpret the contents. Since it's a text file rather than HTML, you should not escape the "<", ">" and "&" characters.

6. After Submission

So, you've submitted your article. At the time that you wrote it, it was the most wonderful bit of prose ever released into the wild, flights of fact and fancy unparallelled in history - but now that the end of the month (and actual publication) approaches, you can see... umm, certain improvements that could be made. Not that there's anything wrong with the original, of course, but - a bit of clarification never hurts, right? So, you set out to revise your brilliant treatise and resubmit it...

If this is what you were about to do, STOP! What you'd be doing is creating a fork: a second, divergent version of the material. You see, at this point, the article has probably been proof-read, possibly heavily corrected with regard to the HTML, maybe even had some of the material moved around a bit - and all of this work would have to be re-done if you were to resubmit your original version with corrections. As a result, your "new" submission may well be rejected.

So, what, is correction after submission not possible?

It is - in fact, it's very easy if you follow procedure. That is, simply contact the editor () and say that you want to add/change/correct something. If it's a minor change, just submit a diff (i.e., show what you want changed) and we'll apply it. If the changes are more comprehensive than that, and it's not too close to the publication date ("too close" being a constantly-changing variable; you'll just have to ask and find out), we'll 'freeze' your article and send you the working copy, which you can then correct and send back to us.

A good idea whose time has come

(thanks to Barry O'Donovan for setting a good example)
If you've written an article that mostly concerns or describes a specific piece of software, you may find it of benefit to notify the author of that software. Not only is it a pleasant and courteous thing to do, but they may have a salient comment - and you will have the security of having had your article vetted by the number-one expert. We will usually be happy to post the resulting exchange in the Mailbag section (assuming that you've asked your correspondent for permission to do so and had it granted.)