Guide for Authors
Read the guide before you start writing an article and again before you submit the draft. The more work you do to follow the guide, the easier it is for us to publish your work. The harder you make the editors work, the less likely you will see your writing in TPR soon.
Once you submit your article, the editors decide whether or not the topic would be a good fit for The Perl Review. If they accept the article, you will be asked to submit a draft which will be sent to the technical editors. Once an article passes the technical review, it may be assigned an editor who will work with you to prepare it for publication. If you make sufficient progress, the article may be scheduled for publication. You should start this process as soon as possible since it may take you a couple of months to go through all the steps. See the submission deadlines.
- The Elements of Style provide guidelines for simple and effective writing.
- Bugs in Writing has a lot of simple wisdom about when to use which words where.
- Use the active voice. These resources may help you use the active voice.
- Use the first person singular ( "I" instead of "we" or "you" ).
- Do not carry on a conversation with the reader. Talk about yourself, not the reader. This is your chance to shine!
- When you talk about yourself, use the first person singular unless you have a co-author.
- Code is never straightforward. Always explain the code in the prose. If you use phrases like "obvious" or "straightforward" you are doing it wrong.
Your article should have something for everyone, although we do not specify how much. Consider three main audiences: beginner, intermediate, and wizard Perl programmers. Choose a main audience, and try to add something for the other two.
Write as much as you need to, but not less or more. You should try to give the user everything that they need to know about the topic without assuming too much about their previous experience.
Your article should cover more than just the mechanics of Perl. For example, instead of writing an article which demonstrates a module, discuss the motivation for the module, how it makes life better, and why it is better than its alternatives. Previously published articles provide the best guide to what we look for.
We would like to work with plain text, but we can accept almost anything that you would like to send us. If you have a question about a particular format, please ask us first