Unacceptable: We measure performance factors such as volatility, scalability, etc. Exercise: The above rule is violated at least once in this document. Find the violations. Never say "for various reasons". Example: We decided not to consider the alternative, for various reasons. While revising you also need to ensure that all the objectives have been ascertained in the report as per the topic is given.
While writing your report, you may need to use some diagrams or graphs to make the reader understand what you are talking about. Technical information is best put across by use of other means other than word, so you need to know the right format for this diagrams and tables to ensure success in your work.
Below are some of the guide on how to oriented various appendices in your report: Graphs — your graph should be well labelled to avoid confusion of the variables. When it comes to graphs, you can use pie charts and even bar graphs to indicate the trend of what you are analyzing.
Diagrams — for the diagrams you should draw simple diagrams, and they should appear after or before the content you are discussing so that the reader can be able to understand its relation. Tables — tables are used for summary purposes. A table can help you list points and explain them in brief which helps the reader go through everything in a brief summary.
You should also number your tables for easy reference in your work. Mathematics — while writing a technical report that involves some analysis, it is better to use mathematics because it makes the analysis easier and convenient.
Tips on writing a good technical report For you to have a good technical report, you should avoid overusing different fonts in your work because it makes it fussy. You should use different fonts to pinpoint an idea that you want the reader not to miss on it. You can also use underlining and bolding to serve the same purpose. Rather than asking 3 people to read the same version of your paper, ask one person to read the paper, then make corrections before asking the next person to read it, and so on.
This prevents you from getting the same comments repeatedly — subsequent readers can give you new feedback rather than repeating what you already knew, and you'll get feedback on something that is closer to the final version. If you ask multiple reviewers at once, you are de-valuing their time — you are indicating that you don't mind if they waste their time saying something you already know.
You might ask multiple reviewers if you are not confident of their judgment or if you are very confident the paper already is in good shape, in which case there are unlikely to be major issues that every reviewer stumbles over.
It usually best not to email the document, but to provide a location from which reviewers can obtain the latest version of the paper, such as a version control repository or a URL you will update. That way, you won't clutter inboxes with many revisions, and readers can always get the most recent copy.
Be generous with your time when colleagues need comments on their papers: you will help them, you will learn what to emulate or avoid, and they will be more willing to review your writing.
Some of your best feedback will be from yourself, especially as you get more thoughtful and introspective about your writing.
To take advantage of this, start writing early. One good way to do this is to write a periodic progress report that describes your successes and failures. The progress report will give you practice writing about your work, oftentimes trying out new explanations.
Whereas you should start writing as early as possible, you don't need to put that writing in the form of a technical paper right away. In fact, it's usually best to outline the technical paper, and get feedback on that, before you start to fill in the sections with text.
You might think that you can copy existing text into the paper, but it usually works out better to write the information anew. With your knowledge of the overall structure, goals, and audience, you will be able to do a much better job. When outlining, I like to start with one sentence about the paper; then write one sentence for each section of the paper; then write one sentence for each subsection; then write one sentence for each paragraph think of this as the topic sentence ; and at that point, it's remarkably easy just to flesh out the paragraphs.
Responding to conference reviews This section is most relevant to fields like computer science where conferences are the premier publication venue. Responding to journal reviews is different. Many conferences provide an author response period: the authors are shown the reviews and are given limited space say, words to respond to the reviews, such as by clarifying misunderstandings or answering questions.
Your paper will only be accepted if there is a champion for the paper: someone who is excited about it and will try to convince the rest of the committee to accept the paper.
Your response needs to give ammunition to your champion to overcome objections. If there isn't a champion, then the main goal of your response is to create that champion.
Read the reviews and decide what points you will respond to. You need to focus on the most important and substantive ones. In your responses, admit your errors forthrightly.
Don't ignore or avoid key issues, especially ones that multiple reviewers brought up. Your response to each point will be one paragraph in your response.
Start the paragraph with a brief heading or title about the point. Do not assume that the reviewers remember everything that was written by every reviewer, nor that they will re-read their reviews before reading your response.
A little context will help them determine what you are talking about and will make the review stand on its own. This also lets you frame the issues in your own words, which may be clearer or address a more relevant point than the reviews did. Organize your responses thematically. If a given section has just one paragraph, then you can use the paragraph heading as the section heading. Order the sections from most to least important.
This is better than organizing your response by reviewer, first addressing the comments of reviewer 1, then reviewer 2, and so forth. Downsides of by-reviewer organization include: It can encourage you not to give sufficient context. It does not encourage putting related information together nor important information first.
You want to encourage all reviewers to read the entire response, rather than encouraging them to just look at one part. When multiple reviewers raised the same issue, then no matter where you address it, it's possible for a reviewer to overlook it and think you failed to address it. You don't want to make glaringly obvious which issues in a review you had to ignore for reasons of space or other reasons.
You don't want to make glaringly obvious that you spent much more time and space on one reviewer than another. Make the response be about the science, not about the people. Finally, be civil and thankful the reviewers. They have spent considerable time and energy to give you feedback even if it doesn't seem to you that they have! Rejection If you submit technical papers, you will experience rejection. In some cases, rejection indicates that you should move on and begin a different line of research.
In most cases, the reviews offer an opportunity to improve the work, and so you should be very grateful for a rejection! It is much better for your career if a good paper appears at a later date, rather than than a poor paper earlier or a sequence of weak papers. Even small flaws or omissions in an otherwise good paper may lead to rejection.
This is particularly at the elite venues with small acceptance rates, where you should aim your work. Referees are generally people of good will, but different referees at a conference may have different standards, so the luck of the draw in referees is a factor in acceptance. The wrong lesson to learn from rejection is discouragement or a sense of personal failure.
Many papers — even papers that later win awards — are rejected at least once. The feedback you receive, and the opportunity to return to your work, will invariably improve your results. Don't be put off by a negative tone in the reviews. The referees are trying to help you, and the bast way to do that is to point out how your work can be improved. I often write a much longer review, with more suggestions for improvement, for papers that I like; if the paper is terrible, I may not be able to make as many concrete suggestions, or my high-level comments may make detailed comments moot.
If a reviewer didn't understand something, then the main fault almost always lies with your writing. If you blame a lazy or dumb reviewer, you are missing the opportunity to improve. Reviewers are not perfect, but they work hard to give you helpful suggestions, so you should give them the benefit of the doubt. Remember that just as it is hard to convey technical ideas in your paper and if you are getting a rejection, that is evidence that you did not succeed!
You should closely attend to both the explicit comments, and to underlying issues that may have led to those comments — it isn't always easy to capture every possible comment in a coherent manner.
Think about how to improve your research and your writing, even beyond the explicit suggestions in the review — the prime responsibility for your research and writing belongs with you. Should you submit an imperfect paper? On the plus side, getting feedback on your paper will help you to improve it. On the other hand, you don't want to waste reviewers' time nor to get a reputation for submitting half-baked work.
If you know the flaws that will make the referees reject your paper, or the valid criticisms that they will raise, then don't submit the paper.
Only submit if you aren't aware of show-stoppers and you are not embarrassed for the community to associate your name with the work, in its current form. Norman Ramsey's advice Norman Ramsey's nice Teach Technical Writing in Two Hours per Week espouses a similar approach to mine: by focusing on clarity in your writing, you will inevitably gain clarity in your thinking.
Don't bother to read both the student and instructor manuals — the student one is a subset of the instructor one. Write correct English, but know that you have more latitude than your high-school English teachers may have given you.
Consistent names. Refer to each significant character algorithm, concept, language using the same word everywhere. Give a significant new character a proper name.
To distinguish one-to-one relationships from n-to-m relationships, refer to each item in the singular, not the plural. Subjects and verbs. Put your important characters in subjects, and join each subject to a verb that expresses a significant action. Information flow. In each sentence, move your reader from familiar information to new information.
For material you want to carry weight or be remembered, use the end of a sentence. In a coherent passage, choose subjects that refer to a consistent set of related concepts. Parallel structure.
Order your text so your reader can easily see how related concepts are different and how they are similar. In an abstract, don't enumerate a list of topics covered; instead, convey the essential information found in your paper. Practices Write in brief daily sessions. Ignore the common myth that successful writing requires large, uninterrupted blocks of time — instead, practice writing in brief, daily sessions.
Avoid sudden introduction of new terms or ideas; you must present everything in the introduction, to be confronted with your results here. Speculations on possible interpretations are allowed, but these should be rooted in fact, rather than imagination.
To achieve good interpretations think about: How do these results relate to the original question or objectives outlined in the Introduction section? Do the data support your hypothesis? Are your results consistent with what other investigators have reported?
Discuss weaknesses and discrepancies. If your results were unexpected, try to explain why Is there another way to interpret your results? What further research would be necessary to answer the questions raised by your results?
Explain what is new without exaggerating 5. Revision of Results and Discussion is not just paper work. You may do further experiments, derivations, or simulations. Sometimes you cannot clarify your idea in words because some critical items have not been studied substantially. In some journals, it's a separate section; in others, it's the last paragraph of the Discussion section. Whatever the case, without a clear conclusion section, reviewers and readers will find it difficult to judge your work and whether it merits publication in the journal.
A common error in this section is repeating the abstract, or just listing experimental results. Trivial statements of your results are unacceptable in this section. You should provide a clear scientific justification for your work in this section, and indicate uses and extensions if appropriate. Moreover, you can suggest future experiments and point out those that are underway. You can propose present global and specific conclusions, in relation to the objectives included in the introduction.
A good introduction should answer the following questions: What is the problem to be solved? Are there any existing solutions? Which is the best? What is its main limitation? What do you hope to achieve? Editors like to see that you have provided a perspective consistent with the nature of the journal. You need to introduce the main scientific publications on which your work is based, citing a couple of original and important works, including recent review articles.
However, editors hate improper citations of too many references irrelevant to the work, or inappropriate judgments on your own achievements. They will think you have no sense of purpose. Here are some additional tips for the introduction: Never use more words than necessary be concise and to-the-point.
Don't make this section into a history lesson. Long introductions put readers off. We all know that you are keen to present your new data.
You might ask multiple reviewers if you are not confident of their judgment or if you are very confident the paper already is in good shape, in which case there are unlikely to be major issues that every reviewer stumbles over. One good way to do this is to write a periodic progress report that describes your successes and failures. You don't want to make glaringly obvious that you spent much more time and space on one reviewer than another. Trivial statements of your results are unacceptable in this section.
When the body of your paper contains information that belongs in a caption, there are several negative effects.
Using acronyms should only be done if used again within the abstract. All of the steps to create your final paper should be clearly documented — say, in comments or in a notes file that you maintain with the paper — and, preferably, should be automated so that you only have to run one command that collects all the data, creates the tables, and generates the final PDF.
In some cases, rejection indicates that you should move on and begin a different line of research. On the other hand, you don't want to waste reviewers' time nor to get a reputation for submitting half-baked work. What is its main limitation?
But writing more clearly will help you think more clearly and often reveals flaws or ideas! Full length papers are peer reviewed in detail and edited, and multiple review periods are possible. If English is not your native language, it would help if one of the reviewers is a native English speaker, or have a trained technical editor proofread your paper.
It is also not a science lab report. If these guidelines are followed, then your abstract will become a perfect selling point for your paper. Another way of saying this is that you should give away the punchline.
Use mean and standard deviation to report normally distributed data. If the details of the figure cannot be seen when shrunk down, then consider breaking it into multiple figures. The meat of the paper is contained in the middle sections, Work Done, Results, and Discussion, and the labeling or titles for these sections vary depending on the topic. Furthermore, the discussion should focus on differences from the successful technique, and if at all possible should provide general rules or lessons learned that will yield insight and help others to avoid such blind alleys in the future.
To achieve good interpretations think about: How do these results relate to the original question or objectives outlined in the Introduction section? Afterward, organize what you wrote thematically, bringing related points together. A running example used throughout the paper is also helpful in illustrating how your algorithm works, and a single example permits you to amortize the time and space spent explaining the example and the reader's time in appreciating it. Discuss weaknesses and discrepancies. Abstracts are typically extracted from each paper and published separately in an abstract listing, for readers to browse when deciding which papers they want to read in full or attend for the actual presentation of the paper. I am intelligent.
To achieve good interpretations think about: How do these results relate to the original question or objectives outlined in the Introduction section? If you do, they should generally come after, not before, the successful one. Computer program source code Your code examples should either be real code, or should be close to real code. This is better than organizing your response by reviewer, first addressing the comments of reviewer 1, then reviewer 2, and so forth. You should be straightforward and honest about the limitations, of course do mention them early on, even if you don't detail them then , but don't destroy the coherence of your narrative or sour the reader on your technique.
Also ask whether that point contributes to the goals of the section. Whatever the case, without a clear conclusion section, reviewers and readers will find it difficult to judge your work and whether it merits publication in the journal. Less commonly, it can be acceptable to state an imperfect solution first if it is an obvious solution that every reader will assume is adequate; but use care with this rationalization, since you are usually wrong that every reader will jump to the given conclusion.