One of the main purposes of the Power Architecture content area is to serve as a forum where professionals can share knowledge with one another, and one of the best ways to share your knowledge (as well as add to your resume, boost your company's profile, and earn some extra cash) is to submit an article idea to our editors.
This FAQ is for everyone who has never submitted a story to us before. If you have any further questions, feel free to send us an e-mail.
1. What kind of stories are you interested in?
We're looking for stories that would cover everything connected with the Power Architecture processors and environments (including POWER™ and PowerPC®, PowerPC cores and IP, and Cell) -- but also microelectronics and embedded design and development in general, from the hardware itself, to the firmware, to the tips and tricks of programming for Power Architecture processors. However, if you were hoping to write an end-user piece for us, don't be discouraged -- we want to serve the whole of the Power Architecture Community, and have a place for such subjects in our editorial mix as well, so long as they are meant for readers at an advanced level. (See also question 10 below for more detail.)
2. How do I submit an article idea?
E-mail us, or use the submissions form, and give us a headline, abstract, or synopsis of the story you would like to write (along with your full name and contact information). Please also include samples of your previous written work (or URLs to the same) if you have any. (If you don't have writing samples, see question 4).
3. Can I submit an article that I've already written?
Sorry, the editors don't have the bandwidth to read complete unsolicited manuscripts. If you've already written an article and would like to submit it to us, complete the steps in question 2 and submit it as an article idea first. After all, we'll never know that you've already written it, and if we accept your idea, then most of your work is done! However, as a general rule, we can't accept papers that have already been published elsewhere unless they have been substantially updated or revised. (See question 9 for more copyright details.)
4. Can I write for you if I've never been published before?
Sure! We don't mind working with new authors. You will, however, probably want to make your article idea submission as outlined in question 2 indicative of what we can expect the final product to look like; if you won't be submitting a writing sample, you may, in addition to the abstract, include one or two introductory paragraphs (but not more!) to give us a sense of your writing style.
5. Can I write for you if I already work at IBM?
Yes! One of developerWorks' reasons for being is to showcase IBM talent and know-how and to share it with the community.
6. Can I write for you if I work at another company?
Yes! We want to showcase the knowledge of not only IBMers, but the whole Power Architecture community! Many companies encourage their employees to write for technical journals, since the company name gets positive exposure when it appears in the author's byline and biography. Ask your manager about this if you're not sure about your company policy.
7. Can I write for you if I live outside the U.S. or am not a U.S. citizen?
The Power Architecture community is worldwide, so naturally we accept articles from virtually anywhere in the world and from citizens of almost every country! Unfortunately, you can't write for us if you are a non-U.S. citizen living inside the U.S. on a work visa, but just about any other residency situation is fine. Ask an editor if you're not sure, or if you have any questions.
8. How much do you pay?
Our fees are in keeping with industry standards, but are determined on a piece-by-piece basis. Basically, it depends on the length and rigor of the article. We can't say more until we see your article idea. If you're an IBM employee, payment terms depend on your position and duties within IBM. We'll need to know the details before we can tell you more.
9. What is your copyright policy?
When you write for IBM developerWorks, you retain copyright over your work, but you grant us 30 days' exclusivity, as well as a perpetual license to publish the work. To quote from our contract:
You will retain full ownership of the article. You hereby grant IBM a perpetual, irrevocable, worldwide, paid up, license to use, perform, publish, reproduce and prepare derivative works of the article in any form, including but not limited to print, CDs and distribution on the Internet, and to allow others to do so. This license is exclusive for the first 30 days from our initial publication, and non exclusive thereafter, provided that any publication of the work by the author or any other licensee of the author must include the notice "First published by IBM developerWorks at http://www.ibm.com/developerWorks/."
10. So what types of content are you looking for, exactly?
Here follows a partial wishlist. We hope it will give you an idea of the range of articles we are looking for, but feel free to submit your own ideas, even if they don't seem to match up.
In essence, the Power Architecture content area is looking for articles that touch on all aspects of work with POWER and PowerPC processors, from the fabs that make chips to the code that runs on them. We're also interested in vendor-agnostic microprocessor how-to and tech articles and would particularly like to hear about open hardware solutions. Some more specific examples of potential topics include:
- All aspects of microprocessor design, testing, and integration (either generic topics which pertain to all architectures, or topics which pertain to POWER, PowerPC, PowerPC cores and IP, and Cell), including but not limited to:
- SoC/ASIC design, testing, debugging, and verification
- Tools for designing, testing, and building microprocessors
- Free software/open source tools for hardware design and testing
- CoreConnect and compatible bus architectures
- Heat and power management
- Embedded systems design, prototyping, testing, and programming
- Software programming for Power Architecture, including:
- Free software/open source software development tools for POWER, PowerPC, and Cell platforms
- Porting code to the Power Architecture platform, or cross-compiling
- Native software development for POWER, PowerPC, and Cell
- 64-bit computing
- Linux on Power Architecture
- AIX Power programming
- Best practices (or tips) for any of the above
The best way to get a sense of what we're looking for is to read what's already on the Power Architecture content area. Obviously we don't want every article to be the same, but by familiarizing yourself with our content, you can see if your idea fits in with our program.
11. Will you cover Freescale (Motorola), Apple, and other companies that make products based on the Power Architecture platform?
Yes! We do, however, have to focus on the technology, not on the products. Hence we publish how-tos rather than product reviews. For instance, if you think our content area should have an article about your company's unique board, don't submit a press release or marketing white paper; instead, have the design team members write about how they overcame obstacles or resolved a tricky situation.
If you also have a technical white paper to go with it -- or if you have press releases or product announcements that you would like to share with our readers, we would like to include them in the Power Architecture Community Newsletter. You can contact us in the same way as you would for a zone article (by e-mail or through the submissions form), but please put "newsletter" or "Power Architecture Community Newsletter" in the subject line. For more information on contributing to the Newsletter, see the article "How to contribute", and visit the Newsletter subscription page.
12. How about small or niche companies like the new Amiga boards, or free software/open software projects?
Yes and yes! That's what the Power Architecture community is all about! We want to hear from you, and so do our readers.
13. Do you publish product or book reviews?
No. developerWorks tries to be as neutral as possible, and so opinion pieces and product reviews simply aren't our style. The articles published in the Power Architecture Community Newsletter have a slightly different style than content published on the zone, and highly technical product write-ups (note: not reviews) would be considered for publication in the newsletter. Again, see "How to contribute" to the newsletter for more details.
14. Do you have a style guide?
Not an official one, no -- but there are a few basics that you should follow. All of our articles will ultimately go into developerWorks' XML template, so if you are comfortable editing markup documents, please download the latest version of our template and author your article in that. (See the Resources section below for a link to "Authoring with the developerWorks XML article template;" please note that it's recently been updated, so even if you've used developerWorks' template before, you should make sure that you have the latest version.) If XML intimidates you, please send your article in plain text format (See Question 15 for more information on plain text formatting).
Please do not submit documents in Microsoft Word or other office formats (if you're using Word to write the article, please use the Save As option to save the file as plain text). We also can't use HTML documents or PDFs. If you are a dab hand with hand-coding HTML and want to put a simple HTML table in your article, feel free to do so; however, please do not use Microsoft Word or another word processor to autogenerate HTML table code. If need be, our production team can build the table for you.
Style guidelines to consider:
- Use a headline for each figure, table, and code listing (if the code is longer than two lines).
- Use sentence-style headings (for example, "A new microchip development" and NOT "A New Microchip Development"). This also applies to headings used in tables, charts, or graphic images.
- Spell out acronyms the first time you use them and then, use the acronym in the remainder of the text (for example, "local area network (LAN)").
- Try to avoid Latin in text (for example, instead of i.e. use "that is," instead of e.g. use "for example," instead of via use "through" or "using").
- Because we're writing for an international audience with varying English skills, avoid U.S.-English idioms or slang. For example, do not use "ballpark figure," or an American holiday as a time reference (as in "This chip is scheduled for general availability after Thanksgiving."). Use Merriam-Webster's (www.m-w.com) for spelling, and for grammar questions, use the Chicago Manual of Style.
- Use the active voice. Prefer second person to first person. For example, use "Look at the output," rather than, "Let's look at the output."
If this is your first article for developerWorks, don't worry. Your editor will work with you on all of this.
15. How should I format my article?
developerWorks articles usually range from 2000-3000 words (not counting code). However, we are more interested in the article being accurate and complete than in how many words it has, so articles of greater or shorter length are fine, and exceptions are always possible. Your editor will work with you if you have any questions, so don't worry about it too much. But if you are very used to dealing with word counts, then the 2-3K number is a good guide.
Whether you plan to submit in XML or as plain text, the basic format of all articles is:
- Title; subtitle
- Author information (as you would like it to appear in the byline; author bio goes here also even though the XML will make it appear at the bottom of the page when it renders)
- Three to seven line abstract
- The body of the article (with headings, code listings, figures, and sidebars, as appropriate)
- Resources, including relevant IBM and off-site links. Each item should be described by at least one complete sentence.
You will find a link with a few articles that provide good examples of these elements in the Resources section.
If you're comfortable using XML, please see Resources for a link to "Authoring with the developerWorks XML article template." And if you're using a Mac, see Resources for a program that previous authors have found helpful when working with XML.
If you plan to submit in plain text, there are some markup tags you can use to make our lives easier: to emphasize material in the text, use <i> to italicize and <b> to boldface. (Please do not use <em> and <strong> tags.) Set code (or monospaced) font off by surrounding it with one of two types of tags: use <code type="inline"> </code> for code that appears in running text, and use <code type="section"> </code> for multi-line code listings.
Each subsection should have a major headline, and each sub-subsection a minor one. In addition, each code listing that is longer than two lines, each figure, and each table should have its own headline (you may indicate these in some way, for instance by flagging them as MAJOR: or MINOR: (headlines), or as headlines for CODE:, FIGURE:, or TABLE:, but it is usually pretty self-evident). "Authoring with the developerWorks XML article template" offers more highlighting conventions.
In some cases, your idea might be more suited for the developerWorks tutorial template instead of the article template. Such is the case if your material includes step-by-step instructions on how to perform a certain task. Tutorials often include multiple screen shots. See Resources for more information on developerWorks tutorials and to download the tutorial template.
16. Can I include graphics with my article?
Yes! In fact, it is recommended!
Please do submit any figures, diagrams, and photos that you think would support your article (and to which you have copyrights). developerWorks employs a professional graphics staff, so if you're drawing a figure or diagram from scratch, you don't need to be fancy. Our production team will almost certainly be redrawing it to match our style anyway, so just make sure that it's legible and in a standard graphic format (for example, JPEG, GIF, PNG, PDF). Please don't send any files that we would need a proprietary application to read.
The developerWorks graphics team has written an article to show authors how to create and submit appropriate technical graphics (such as figures, diagrams, screen shots, and photographs) for their articles or tutorials (see Resources).
17. What happens after I submit an article idea? How soon will I hear back?
You should hear back within a week, after we discuss it at our editors' meeting. We might tell you that you can get started on writing immediately, we might tell you that we need more information or a more detailed outline, or we might tell you that the article isn't suitable for our site. But you will hear something!
The first article usually takes a bit longer than the rest, as all authors are paid by IBM through a third-party billing company, and you will be required to fill out the paperwork in a process that is, mysteriously, called alignment. The alignment procedure will get underway once we've accepted your first article.
The goal of alignment is to make sure -- before any work gets started -- that we can pay you. The terms are negotiable, so don't feel intimidated to ask questions or to ask for adjustments to the terms.
And if you have questions or run into problems with the process, please ask your editor! Editors are not copied on alignment paperwork or negotiations, so we won't know about any problems unless you tell us.
Just remember: you only have to be aligned once, and then you can experience the joy of writing for developerWorks again and again.
19. I don't have a story idea, but I have an idea/question/comment/suggestion. Where can I send it?
- Itching to send us an idea? E-mail us or submit it to the article submission database.
- If you love XML, or if you are writing for other areas, refer to Authoring with the developerWorks XML article template. The Power Architecture content area also accepts a simplified plain text template for authors who don't want to muck around in XML; ask your editor for details, and for the most recent copy of the content area's article wishlist.
- For more information, take a look at the developerWorks author guidelines and the editor's content wish list.
- If you're authoring in XML on a Mac, a previous developerWorks author suggests using the TestXSLT program for help.
- The following articles provide good examples of what an article that has all of the necessary elements looks like (but if you browse around at different articles in different zones, you will find many more). If you're wondering what to put into your author byline or bio, browsing through the ones included in these articles is a good source of inspiration.
- The Power Architecture Community Newsletter includes full-length articles as well as recent news about members of the Power Architecture community and upcoming events of interest. Learn more about the Power Architecture Community Newsletter and how to contribute to it. Subscription is free.
- Authoring with the developerWorks XML tutorial template provides the information you need to know about creating tutorials. See the following developerWorks tutorials to better understand the format (registration is required for tutorials):
- The developerWorks graphics team has written an article to show authors how to create and submit appropriate technical graphics (such as figures, diagrams, screen shots, and photographs) for their articles or tutorials.
- Have a question or comment on Power Architecture technology? Post it in the Power Architecture technical forum or send in a letter to the editors. You can also find more articles and resources on Power Architecture technology and all things related in the developerWorks Power Architecture technology content area.
Dig deeper into developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.