Editorial Guidelines
This document is a guide to writing for Dev2Dev. We start off with a brief look at the content we'd like to see on Dev2Dev, and follow this up with an outline of our commissioning and editorial processes. Finally, we include a template you can use to get started.
Please feel free to
at any time.
Content We'd Like to See
Dev2Dev is all about "by developers, for developers." We're always on the lookout for great articles that will be of interest to our readers. We concentrate primarily on articles concerning:
- Java EE and Enterprise Java in general
- BEA products such as WebLogic Server, WebLogic Integration, WebLogic Portal, WebLogic JRockit, AquaLogic BPM Suite and controls
- Related technologies such as XML and Web services
- Architectural content such as SOA
- General specifications that affect developers and architects
The content need not be restricted to the article format. We are also looking for content types such as "how tos," tutorials and demos, technical and white papers, best practices and solutions, lessons learned, and case studies.
Finally, you can also look at our editorial calendar to get an idea of the topics we're particularly interested in. If there are other topics you'd like to write about that we haven't considered, then go ahead and surprise us
The Commissioning Process
Dev2Dev has a simple commissioning process. If you have an idea for an article, send an abstract or outline to
We will respond within a few days with an indication of whether it's a viable topic or not, or to discuss the proposal further. Please include links to examples of your previous work if you have any. Once we've agreed on an article topic, you will receive a contract to write the article.
If we've worked with you before, we may pitch article ideas on subjects we think you may be interested in writing about. For this reason, it's always a good idea to tell us about your strengths and your interests. This way we can build a relationship for future articles.
Initially, it's better to propose just one article. Writing is sufficiently different from developing and administering, and we've found it's best to ease into it gradually. After that, we can discuss your ten-volume epic on the history and interpretation of weblogic.xml. :)
Writing Your Article
Write in a compact, friendly way. Articles should generally be between 1,800 and 2,000 words in length. Your contract may specify otherwise, though. Use plenty of examples. If your article is technical, which is usually the case, include example code. Don't feel pressured to keep your example code very small; it's better to be complete and correct than to try to squeak in under the word limit. Don't count code in the word count.
The first few sentences of your article are critical in getting the attention of the reader: don't ramble and be sure to use these sentences to explain in clear and interesting terms what your article is about.
Include plenty of hyperlinks to related articles and specifications. Perform searches on Dev2Dev to find articles related to your own. Put hyperlinks to this related content in the body of your article, and try to include at least four links we can use to create a "Resources" section. It's a good idea to hyperlink the first use of any technology or specification to its home site.
For comprehensive guidelines on further style issues, please view the style guide.
First-Time Writers
If you don't have much experience writing an article for publication, we will work with you on your outline and drafts. It's not unusual for an article to end up much different from the original plan. Our job is to help you pick the right subject, tone, and approach to create an interesting and informative piece of work. We also want to find a good range of content to publish.
It's very important to achieve a good narrative flow. It's much easier to write from a well-organized outline than it is to rework a poorly organized article.
Reviewing
Please check your work before sending it to us. Don't proof your article right after writing it. Get a good night's sleep and come back to it fresh.
Asking trusted colleagues, friends, or community members to review your article will make everyone's life easier. While we can correct inevitable typos after the fact, and we know things change, it's often good to have another set of eyes looking over an article before handing it in. This has the additional benefit of getting a set of ready-made fans to promote your work when it goes live.
The Editing Process
After you've submitted an article, we will carefully read what you've written and compile and run all the code that is included. We will return the article to you with comments and questions. This part of the process allows us to work together to get the article in its best possible form before production. Often it is a matter of reorganizing what you have written or providing a reference or two. Nothing will be done to your article without your permission.
Before your article goes live, we will send you a link where you can preview how it will actually look. There may be minor formatting and copyediting changes between the preview and the actual publishing, but there will be no content changes unless you request them. We do want you to have the chance to make any final adjustments.
After Your Article Is Published
We'd like your article to get the widest possible readership, and you can help. If your article is of interest to some other community than might normally read Dev2Dev, you may like to draw it to their attention, or suggest ways for us to promote your article. Prime candidates for sites that may be interested in linking to your article are those you have listed in the Resources section.
The contract specifies that you maintain the copyright to your work. We ask that you do not republish the content on the Internet within 30 days, and we also ask that if you do republish it you include a link to the original URL.
Additional Details
If you haven't written for us before, please submit a short biography along with your article. This will go on your author page. You're also welcome to suggest updates to your author page as appropriate. If you have a headshot, please send it in the form of a tiff or a JPEG.
Article Format and Template
As our style guide indicates, we only accept articles that are in plain HTML, XHTML or plain text. The style guide gives a good description of what "plain" means. Articles saved by Microsoft Word as "HTML" do not qualify - if you view the source of these articles you'll see all sorts of ugly HTML.
We've created a template to help you get going. When you are ready to write a draft of your article, you should use this template as the basis for writing your article in the style and format we require. The template is written in XHTML, so open it up in your favorite text or HTML editor. For example, you can use the free Nvu or KompoZer editor.
Questions
If you have any questions or comments, or would like to start writing for us, please contact us at
Resources
|
