...making Linux just a little more fun!
Last updated Oct 14 2006
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. The Linux Gazette is a refereed journal (ISSN: 1934-371X, application for Ulrichs listing pending), and articles published here can be used for academic credit (please notify the editor if you need the acceptance reply to have some specific format.)
If you haven't written for LG before, the first thing you need to do is submit a short bio (for examples, see our authors list) and a 200x200 picture of yourself. This bio will be reused for all future articles until you submit an updated one.
Read the rest of this FAQ for topic suggestions and formatting requirements, and submit your completed article after formatting it accordingly (Exception: "2-cent Tips", i.e., short bits of technical advice, should be sent to The Answer Gang). If you're unsure about the suitability of the topic to LG, send us an abstract of your proposed article, and we'll happily give you feedback.
The main question to ask yourself 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.
The following types of articles are always welcome:
To quote Joseph Kimble, "Plain English is the style of Abraham Lincoln, and Mark Twain, and Justice Holmes, and George Orwell, and Winston Churchill, and E.B. White. Plain words are eternally fresh and fit. More than that, they are capable of great power and dignity [...]". Here at LG, clear communication with the Linux community is the goal - and clear, concise, plain language is the means.
LG is an English-language publication; however, we have readers from almost every country in the world. In order to make our content as accessible as possible, we ask that you avoid jargon, colloquial expressions, and complicated grammatic constructs in your writing. LG is also translated into a number of other languages, and an article that is difficult to read is likely to be ignored by a translator whose job is difficult enough in the first place.
Here are some resources if you need specific guidance:
Submissions should be written in simple HTML (see the LG author's crash course in HTML and the LG author's style guide), or even plain text; most other formats, including HTML created in FrontPage, MSWord, or OpenOffice, will be rejected unless they are easily convertable to the two acceptable formats.
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.
We have all levels of readers, from neophytes 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.
We're happy to accept articles previously published elsewhere, as long as the original copyright does not prevent that article from being re-released under the Open Publication License (OPL), LG's default publication license. Our official copyright statement (in short, the OPL without the optional clauses) is at http://linuxgazette.net/copying.html.
While we're on the subject of copyright: if you use a substantial part of someone else's work - a long quote from it, etc. - be sure to attribute the source. When in doubt about whether to credit someone's work that you quoted or paraphrased "just a little", wrote "in the spirit of", "used ideas from", etc., do it (feel free to run any borderline cases by the Editor - or just cite'em anyway.) In a very small number of cases, we've had to delete an article after publication and replace it with an "excessive uncited copying" note because in our view it crossed the line; humiliating to an author and unpleasant for us. You don't want this happening to your piece. We don't, either.
The article submission deadline is ten days before the end of the month, modified by the US holidays that occur during the publication period. For reference, here are the actual dates:
| January | 21st |
| February | 18th (19th on leap years) |
| March | 21st |
| April | 20th |
| May | 20th |
| June | 20th |
| July | 21st |
| August | 21st |
| September | 21st |
| October | 21st |
| November | 19th |
| December | 19th |
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.
Create the file using any plaintext editor. Put a blank line between
paragraphs and wrap each paragraph in <p></p> tags.
Name the article author.html (where "author" is your
last name in lowercase).
Delete (or don't create in the first place) the standard HTML headers (<html></head><title></title></head><body>) or footers (</body></html>) - they would just create problems in your article's layout. 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 your bio.
Keep the in-article formatting as simple as possible. The Linux Gazette is read on a wide variety of browsers and hardware, and we try to accomodate as many readers as possible.
Please bear in mind that our content is distributed as part of several CDROM/DVD collections, and that many people read it off-line; as a result, any off-site links become useless, and pointing to, e.g., sample code on your web site damages the article's readability and usefulness. There is, however, a limiting factor from the other perspective as well: many of our readers pay for their connections by the kilobyte, and large article attachments, particularly those that are not of broad interest, represent an unfair load on them. Therefore, the LG policy is an attempt at a compromise between the two: if your referenced content does not exceed 250kB total, please include it as part of your article submission; otherwise, please post it somewhere accessible and provide a link.
All supplementary article content (e.g., program listings, images, reference material) is stored under that issue's 'misc/' directory, in a subdirectory matching the author's last name. E.g., an image link in an article by N. Machiavelli would look like this:
<img src="misc/machiavelli/Il_Principe.jpg" alt="The Prince" width="100" height="200">
If any of your images are > 600 pixels in width, shrink them. Use PNGs or JPGs ( GIFs are questionable, and thus best avoided), and make the file size as small as possible.
Short program listings or scripts can be included right in the article itself; however, if the program is longer than 20 lines or so, save it as a text file and link it as above.
<p></p> tags.
<h3></h3> around the section headings.
alt=, width= and
height= attributes in the <img> tag, i.e.
<img src="misc/author/file1.jpg" alt="TCP/IP four-layer diagram" width="140" height="80">
<pre> around program output,
command lines, etc.; to highlight program listings, use <pre class="code"></pre>.
<a>, <em>,
<strong>, <code>,
<blockquote>, <ul>,
<ol>, <dl>, etc.) at will.
<p style="width: 200">);
these may conflict with the LG stylesheet.
<dt> and
<dd> are actually what you need.
<br> and tags
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; use <pre></pre> instead.
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.
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. And don't forget, lest you get into a stew about getting it all done by the deadline: there's always next month.
(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.)
Click on the "Talkback" link for that article, and email us your corrections, citing as much detail and context as possible (i.e., location of the error within the article, additional relevant information, etc.) We will do our best to bring it to our readers' attention by publishing it with the rest of that month's Mailbag.
Yes - but generally, there wouldn't be any point to doing so. Our mirror sites (http://linuxgazette.net/mirrors.html) pull down our new content (and only our new content) once a month, when we publish an issue. This means that the old content - including your article with the error in it - is now part of web history, essentially unchangeable. Note that this is not an effect of LG policy but simply an artifact of life on the Net: whatever you say publicly is usually archived - somewhere - forever. The best policy is to accept that as a fact of life and act accordingly.
There is one exception to the above - but it is mostly a goodwill gesture that we are only occasionally willing to make. If your error is going to result in ongoing repercussions - e.g., you have unwittingly insulted the Grand Poobah of Ungah-Bungah, and now every Ungah-Bunghese man, woman, child, and spectral tarsier wants to eat your toes for breakfast - we may change the content at our site just to "show willing", as the expression goes. If this is the case, feel free to write to our notoriously-cynical Editor-in-Chief - although a letter of apology to the Grand Poobah would probably be a more efficient use of your time.
