These are the legal and organizational issues you should be aware of before submitting your article to us:

• All articles should be submitted via email to cscene@cscene.org.
• Once submitted, you retain the original copyright but we reserve the right to publish, re-publish, and edit all articles in perpetuity. We will not make major edits without your consent. Do not submit articles to C Scene that you have submitted to other "forums" unless you retain the copyright on such material.
• We are a small non-profit organisation trying to provide interesting information to the programming community. As such, we are not able to verify that anything submitted to us violates another persons copyright. If you run across previously copyrighted material on this site, please inform us as soon as possible so that we may pull it immediately. We will gladly cooperate with any authorities in any prosecution of copyright laws.
• We assume that articles submitted to us are ready for publication, and reserve the right to publish them in any issue or to discard them after one year.
• No money or any other kind of reward should be expected from C-Scene.

C-Scene uses leading-edge technology of the new millenium, so you can write your article in XML now (using the Stylebook DTD). XML submissions are preferred, the article Stylebook - An Introduction shows you how to use the Stylebook DTD.

If you ask yourself why you should go to the trouble of learning Stylebook, think about advantages like the fact that your text will also be available as PDF, for easier printing. Also, if C-Scene changes its layout, your article will instantly follow these changes, unlike a document that is written in HTML.

Though we clearly prefer XML submissions, we accept plain old boring HTML, too. In that case, please follow these rules:

• Please include your real name, IRC nickname (if applicable), and email address with your submission. If this is your first submission, please include a short bio that lists your interests and experience, along with relevant contact data (that is real name, IRC nickname, your email address(es) and your homepage URL).
• Please make up a title for your article.
• While we try to correct spelling and grammar, you should spell-check and proofread your writing before submitting it.
• Articles should be either in plaintext ASCII format or fully-formatted HTML (i.e., your code is <PRE> formatted and all special characters like & are replaced with the proper HTML codes). If you are not confident in your ability to format your article so that everyone (including users of text-based browsers like Lynx) can read it, please send it in formatted ASCII and let us do the work. If your article is not properly formatted, we will have to send it back to you with suggestions on how to format it, because we don't have the time to do it for you. We suggest you run your article through a validation tool such as weblint.
• If your article is in HTML format, please make sure that you use as few special HTML tags as you can. Since we will convert it it XML eventually, any fancy stuff you use in your submissions has to be removed anyway. Do not use Netscape or Internet Explorer extensions: This means no JavaScript, no frames, no ActiveX controls, etc.
  In essence, please use only the following tags: h1, h2, h3, h4, em, strong, small, img, p, br, pre, ul, ol, li, table, tr, th, td. Use lower-case for your tags, and try to write well-formed HTML.
• If you do your own complete HTML formatting, then images are acceptable. Graphics are often necessary to get your point across. Unfortunately, Lynx does not display graphics (does someone want to write a JPEG to ASCII-art translator?), so keep in mind that users of Lynx will not be able to see your pictures. Try to include ALT text in your IMG tags so they will at least know what they're missing.
• Multiple-file submissions are accepted, but we would prefer one article per email to simplify copyright issues.

Articles about C/C++ tend to talk about source code, please consider these guidelines:

• We try to check the source code for obvious errors, but you should make sure all your code compiles cleanly and does not rely on any undefined behavior (unless you state it specifically).
• Unless specifically stated, all source code should be fully ISO/ANSI compliant. We welcome API and platform specific code, but don't assume that the readers are able to guess your platform if you don't tell them.
• Format your source code consistently and cleanly, unless you are purposely writing obfuscated code.
• If your source code has compiler specific code, you must explicitly state so.
• Try to keep your code well commented, so others can understand. Of course that depends on the level of the article. So don't over-do it.