Open Source im professionellen Einsatz
Hinweise für unsere Autoren

Von der Idee zum Artikel

Sie möchten einen Artikel für das Linux-Magazin schreiben? Prinzipiell kann das jeder, der einige wenige Voraussetzungen erfüllt:

  • Er oder sie verfügt bei dem gewählten Thema über umfassende fachliche Kenntnisse und
  • kann diese strukturiert in Worte fassen,
  • beherrscht die deutsche Sprache und
  • beachtet die Autorenhinweise.

Nun können Sie sich gerne bei uns melden:

Wir brauchen vor allem folgende Angaben :

  • Was beschreibt der Artikel?
  • Welche Zielgruppe hat er (beispielsweise Entwickler, Entscheider, Cracks und solche, die sich dafür halten, "Normalnutzer")?
  • Welchen Umfang hat der Beitrag vorausichtlich? Auf eine Seite passen etwa 5000 Anschläge (Buchstaben und Leerzeichen), von denen in der Praxis Screenshots (pro Stück im Durchschnitt 1/6 Seite) und andere grafische Elemente abgehen.
  • Wenn Sie zum ersten Mal für uns schreiben, benötigen wir zusätzlich Ihre Bankverbindung, Adresse (bitte immer angeben) und Telefon/Fax. Diese Daten geben Sie in folgende Seite ein: https://www.linux-magazin.de/heft_abo/kontakt/autor_werden/autorendaten/ (die Daten werden per SSL verschlüsselt übertragen). Außerdem bitten wir Sie, unseren Autorenvertrag zu unterzeichnen: Download Autorenvertrag

Darüber hinaus freuen wir uns natürlich, wenn Sie uns Referenzen angeben können oder schon mehr über den geplanten Artikel wissen. Ärger bekommen Sie mit uns dagegen, wenn Sie das gleiche Manuskript schon an einer anderen Stelle veröffentlicht oder wesentliche Teile Ihres Textes irgendwo in einem Howto o.Ä. "gefunden" haben...

Wenn Sie von einem unserer Redakteure ein OK haben, legen Sie einfach los. Hinweis: Jedes Linux-Magazin lebt von seinem Themenmix und hat einen begrenzten Umfang. Die Redaktion lehnt darum etwa die Hälfte der angebotenen Beiträge ab. Zudem behält sie sich vor kurzfristig Artikel auf spätere Ausgaben zu verschieben.

Kleine Stilfibel

Achten Sie beim Schreiben bitte darauf, den Artikel lesbar zu gestalten. Treten Sie gelegentlich einen Schritt zurück und versuchen Sie sich einen Leser vorzustellen, der über Ihr spezielles Thema wahrscheinlich weniger weiß als Sie. Er soll den Artikel gern lesen und daraus etwas mitnehmen. Halten Sie aus demselben Grund die Menge der Fachbegriffe und Kürzel in einem normalen Rahmen, das verringert den Lesewiderstand - schließlich will jeder Autor, dass seine Leser den Text bis zum Ende lesen. Kompetenz demonstriert man mit Sachkenntnis, nicht indem der Leser künstlich auf Abstand gehalten wird. Anglizismen gehören bei Technikblättern für Profis zum Alltag. Übertreiben Sie es bitte aber nicht: Eine "Festplatte" wird nicht anspruchsvoller, wenn Sie sie mit "Harddisk" titulieren. Im Internet finden sich Beiträge zu Übersetzungsfallen und Anglizismen .

Wie die erdrückende Mehrheit aller deutschsprachigen Periodika benutzt auch das Linux-Magazin die neue Deutsche Rechtschreibung . Die Korrekturhilfe von Star Office ab Version 5.2 beherrscht diese zum Beispiel. Ein aktueller Duden oder wenigstens das Studium von Hinweisen der Duden-Redaktion sind Ihrer Orthografie zuträglich. Weitere Hinweise gibt zum Beispiel eine FAQ der Newsgroup de.etc.sprache.deutsch.

Die meisten Artikel im Linux-Magazin folgen dem journalistischem Genre "Bericht". Die Zeitform der Verben ist zumeist das Präsens. Beispiel: "Star Office 6.0 besitzt anders als sein Vorgänger keinen E-Mail-Client." Bei selbst durchgeführten Produkttests wechselt die Verbform gelegentlich ins Präteritum oder Plusquamperfekt: "Beim Auspacken des Gerätes fiel den Testern ein Abdeckblech entgegen." Werden im Zuge des Tests jedoch allgemein gültige Eigenschaften ermittelt, sind diese wieder im Präsens darzustellen: "Die Quantum-Platte im Gerät rotiert mit 7200 Umdrehungen pro Sekunde."

Passiv -Konstruktionen sind nicht immer zu vermeiden, Sie sollten es aber zumindest versuchen: Stilistisch viel gelungener ist zu sagen, wer oder was in einem Satz die aktive Rolle spielt. Beispiel: "Beim IP-Spoofing wird eine falsche Absenderadresse vorgetäuscht ..." Besser ist: "Bei IP-Spoofing täuscht der Absender eine falsche Adresse vor ..."

Vermeiden Sie viele aufeinander folgende Sätze mit "man" und unnötige Substantivierungen ("Die Durchführung der Befragung" oder "Die Zurverfügungstellung"). Außer bei Workshop-ähnlichen Texten fühlt sich mancher Leser gegängelt, wenn der Autor ihn sehr häufig direkt mit "Sie" anspricht, und bei exzessivem Gebrauch von "wir" vielleicht sogar an Kindergarten oder Krankenhaus erinnert. Taucht ein "wir" auf, muss zudem klar sein, welche Personengruppe gerade agiert. Durch ständige Verwendung der Ichform wiederum erhält der Autor schnell den Ruf eines Egozentrikers. Diese Form sollte sich also auf Meinungsäußerungen und Erfahrungsberichte beschränken.

Ersparen Sie uns und unseren Lesern bitte Allgemeinplätze und "Füllsel". Ein Beispiel der eher harmloseren Art: "Seit Version 1.0 ist über ein Jahr vergangen. Dennoch ist die Entwicklung nicht stehen geblieben und es wird aktiv weiterentwickelt." Auch halten Sie keine öffentliche Rede, bei der Sie die Zuhörer über rhetorische Wendungen führen müssten, der Art: "Wie schon zu Beginn des Artikels angekündigt kommen wir nun zur Installation des Pakets."

Versuchen Sie im Vorspanntext die Kernaussagen des Artikels zusammenzufassen. Wenn das überhaupt nicht geht, zum Beispiel bei reinen Know-how-Beiträgen, sollte der Vorspann beschreiben, worum es im Artikel geht. Schreiben Sie den Vorspann erst, wenn Sie das Manuskript ansonsten fertig haben - dann gelingt er oft am besten!

In Fach- und Publikumszeitschriften sind Abkürzungen wie z.B. verpönt (im Gegensatz zu wissenschaftlichen Zeitschriften, bei denen Unverständlichkeit Teil des Konzepts ist :-) Eine Ausnahme bilden Maßeinheiten wie MByte .

Textformat

Die eigentlichen Texte brauchen wir in normalem Ascii (ISO-8859-1/Latin-1 beziehungsweise mit Euro: ISO-8859-15/Latin-9). Da moderne Linux-Distributionen standardmäßig UTF-8-Kodierung verwenden, ist es meist notwendig, den verwendeten Texteditor auf ISO-8859-1/Latin-1 einzustellen.

Wir verwenden keine Office-Formate. Um in diesem Text die einzelnen Abschnitte hervorzuheben (Überschriften, Listings, Bilder usw.) verwenden wir einfache Marken (Tags). Diese sind möglichst kurz gehalten, um die Tipparbeit nicht unnötig zu vergrößern. Im Folgenden sind diese Formate kurz beschrieben; die Details stehen auf einer eigenen Seite.

Absätze

Einzelne Textelemente wie Überschriften, normaler Lauftext et cetera sind durch spezielle Marken (Tags) voneinander getrennt. Diese haben immer den Aufbau @XX:. Unsere Texte haben folgende Hauptkomponenten:

  • Eine Dachzeile, die das Thema beschreibt (@D:)
  • Eine phantasievolle Hauptüberschrift/Titel (@T:)
  • Den Vorspann (@V:)
  • Den eigentlichen Text (@L:)
  • Zwischenüberschriften (@ZT:)
  • Eine Autorenbox mit einer kurzen Vita

Eine Marke muss nur gesetzt werden, wenn sich das Format ändert. Bei mehreren Text-Absätzen, die direkt hintereinander folgen, genügt ein einzelnes @L: am Anfang. Die Absätze können durchaus auch über mehrere Rohtext-Zeilen laufen, ein wirklicher Absatzwechsel (Zeilenumbruch) kommt erst, wenn der Rohtext eine Leerzeile enthält (oder wenn die nächste Absatzformat-Marke folgt).

Ein Artikel besteht nie nur aus Text. Abbildungen und auch andere Gestaltungselemente (Kästen, Diagramme) lockern den Textfluss auf und verhindern die gefürchteten "Bleiwüsten". Wer liest schon gerne einen Artikel, der nur aus trockenem Text besteht und nicht durch anschauliche Grafiken, hübsche Scrennshots oder informative Listings aufgelockert wird. Denken Sie dabei aber daran, dass Bilder, Tabellen und Kästen frei positionierte Elemente sind, auf die Sie sich im Text nicht mit "wie dieses Bild zeigt" oder "wie unten dargestellt ist" beziehen können, sie müssen stattdessen auf die Abbildung anhand ihrer Nummer verweisen. Dazu sind diese mit der Kennzeichnung "Abbildung X:" zu versehen, es sei denn, der Artikel enthält nur ein einziges Bild.

Bilder

Der Mensch nimmt Informationen visuell leichter auf als verbal. Abbildungen vergeuden darum nicht etwa wertvollen Platz im Heft, sondern erleichtern das Verständnis der meist komplexen technischen Sachverhalte. Machen Sie sich darum beim Schreiben Gedanken, wie Sie Ihren Lesern durch Grafiken und Screenshots das Verstehen erleichtern können!

Eine manchmal etwas kniffelige Frage ist die nach dem passenden Dateiformat für Abbildungen. Handelt es sich um Grafiken (also Schaubilder, Ablaufdiagramme oder Übersichtsbilder), dann ist XFig eine gute Wahl. Es lässt sich sehr einfach weiterbearbeiten (die Redakteure nutzen natürlich auch Linux-Rechner) und in sehr gutes Postscript übersetzen. Wenn Sie ein anderes Format nutzen, senden Sie möglichst das Quellformat und eine PS-, EPS- oder PDF-Fassung. Oft ersetzen unsere Layouter nämlich Schriftarten oder Farben, um sie dem Erscheinungsbild des Linux-Magazins anzupassen. Bei Fotos eignen sich JPEG und TIFF. Bei Unklarheiten fragen Sie einfach die Redaktion.

Für Screenshots eignen sich PNG und GIF, auf gar keinen Fall aber JPEG. Achten Sie beim Erstellen des Screenshots darauf, dass er vor allem die wichtigen Teile zeigt und keine großen Leerflächen. Das Fenster dazu so klein wie sinnvoll ziehen. Bei Webbrowsern bitte unnötige Linkleisten etc. ausblenden. Ein Screenshot sollte immer nur ein Fenster (inklusive Rahmen) zeigen und nicht den ganzen Desktop. Einzige Ausnahme: Der Artikel behandelt den Desktop als solchen.

Schriften - insbesondere Menüs - müssen im gedruckten Magazin noch lesbar sein. Das gegrabbte Applikationsfenster sollte darum nicht größer als 800x600 Pixel sein. Auf keinen Fall aber den Screenshot nachträglich "kleinrechnen" - wir brauchen ihn immer in Originalgröße. Ein Farbschema nach europäischen Geschmack verhindert bonbonfarbene Farbtupfer im Linux-Magazin.

Bilder werden wie folgt ausgezeichnet:

@Bi:bild1.png
@B:Abbildung 1: Max kompiliert hier gerade seinen ersten Kernel. Er beobachtet
gespannt, wie die einzelnen Make-Kommandos ablaufen.

Die Bildunterschrift sollte beschreiben, was auf dem Bild zu sehen ist, und damit verdeutlichen, welcher Teil wichtig ist. Im Text sollten Sie auf die Abbildung verweisen:

@L:In Abbildung 1 können Sie Max beim Kompilieren des Kernels bewundern.

Oder:

@L:.....Max beim Kompilieren des Kernels (Abbildung 1)

Kennzeichnungen im Fließtext

Fließtext beginnt immer mit dem Tag @L:. Tags beziehen sich immer auf den kompletten folgenden Absatz. Zwei Sternchen statt eines Leerzeichens (wie in Red**Hat) stehen für ein geschütztes Leerzeichen, das nicht umbrochen wird. Es erfüllt die gleiche Funktion wie in HTML.

Textauszeichnungen wie fett, kursiv et cetera nehmen wir mit so genannten Spitzmarken vor. Bitte beachten Sie, dass es keine Ende-Marken wie in HTML gibt! Kurze Kommandos wie "rm -rf *" oder Datei- und Verzeichnisnamen setzen Sie einfach als <C>Code<C> in den Fließtext. Das erscheint dann nachher so: >>rm -rf *<<. Andere Auszeichnungen sind <I>kursiv<I>, "in Anführungszeichen" oder in ganz seltenen Fällen auch mal <B>bold<B> (Fettdruck). URLs können Sie auch im Fließtext unterbringen, dazu einfach mit dem Tag <U> kennzeichnen, also:

<U>http://www.welt.weites.warten.net/index.html<U>

Ein oder zwei Zeilen Listing können Sie mit dem Tag @LI: beginnen und auf separaten Zeilen im Fließtext unterbringen. Diese erscheinen dann in einer Courier-Schrift. In eine Zeile passen etwa 40 Zeichen; wenn eine Zeile länger ist, bitte sinnvoll umbrechen. Als Umbruch-Zeichen verwenden Sie §§ (diese Zeichen kommen in einem normalen Listing nicht vor). Beispiel:

@LI:
./configure --with-idea --prefix=/usr --with-rsa

ist etwas zu lang. Besser:

@LI:
./configure --with-idea --prefix=/usr §§
--with-rsa

Größere Listings stehen besser in einem eigenen Listing-Kasten. Listings können Sie auch als separate Dateien anliefern. Bitte immer auch vollständige (also ablauffähige) Skripte und Quelldateien mitliefern, die wir dann auf den FTP-Server stellen können.

Kästen und Tabellen

Zu viele einzelne Codezeilen im Fließtext erschweren den Lesefluss erheblich. Sie sollten sich deshalb überlegen Code möglichst in einem Kasten unterzubringen und im Text auf den Kasten zu verweisen. Natürlich ist das nicht immer möglich, aber versuchen Sie es zumindest.

Kästen haben immer einen Titel (@KT:). Normaler Text in Kästen ist Kastentext (@KL:). Listings werden auch im Kasten mit @LI: formatiert:

@KT:Listing 1: xy.c
@LI:
#include <stdio.h>
...

Kästen können außer Code auch zusätzliche Informationen enthalten, zum Beispiel Glossare, ein Interview oder einen anderen Aspekt des Hauptthemas, der im Fließtext nicht unterzubringen ist. Das alles ist zulässig und erwünscht. Aber bitte übertreiben Sie das "Kastenwesen" nicht, sonst sehen wir bald aus wie der Focus.

Tabellen sehen ähnlich aus wie Kästen, sie beginnen mit @TT:. Die einzelnen Tabellen-Zeilen müssen auch im Quelltext in einer Zeile stehen, die Spalten sind durch Tabulatoren voneinander getrennt:

@TT:Tabelle 1: Zeichen
@TL:Spalte1 Spalte2

Es erleichtert den Setzern und uns das Leben erheblich, wenn Sie Tabellen als Spreadsheets (Star Office, Applix ...) oder in einem Spreadsheet-fähigen Format (.csv oder so) anliefern. Andernfalls besteht gerade bei größeren Tabellen immer die Gefahr verrutschter Spaltenangaben.

Infos sind Referenzen auf URLs oder Literatur. Diese kommen ebenfalls in einen Kasten, der mit @IT:Infos beginnt und die Referenzen im @IL:-Bereich hat:

@IT:Infos
@IL:
[1] Online-Handbuch zur Pinguin-Zucht:
<U>http://www.growpenguinsathome.org/handbook<U>

[2] Karl Korner: Der Kernel; Compilieren leicht
gemacht; Linux-Magazin 22/2007, S. 458

Den Verweis im Text geben Sie bitte in eckigen Klammern an [1]. Die Autorenbox ist ein weiterer Info-Kasten. Er beginnt mit:

@IT:Die Autorin
@IL:Maria Mustermann schreibt gerne....

Im Kastentext stehen dann einige Sätze Ihrer Wahl. Die weiteren Details entnehmen Sie bitte der Seite " Formate ". Ein Beispiel zeigt, wie das in der Praxis aussieht.

Häufige Fehler

  • Abkürzungen nicht ausgeschrieben (z. B., usw., bzw., USD, US-$)
  • Falsche Zusammen- und Getrenntschreibungen von Komposita (richtig: E-Mail-Client, Linux-Programm, Standard-PC, Know-how, Referenzkunde)
  • Zu häufiger Einsatz der Passiv-Form (falsch: "Nun wird die PS-Datei erzeugt.", richtig: "Nun erzeugt <C>out.sh<C> die PS-Datei.")
  • Häufiger Wechsel der Perspektive (man, Sie, ich, wir)
  • Zu wenig Abbildungen, keine oder zu knappe Bildunterschriften
  • Keine oder zu kurze Zwischenüberschriften
  • Dateiformate HTML, Latex, Star Office oder Word statt Ascii-Text
  • Screenshot als JPEG (statt GIF oder PNG)
  • Screenshot nachträglich auf kleinere Maße skaliert (wir brauchen die Originalgröße)