How to write technical paper

This shows a brief summary of why papers are published.

What IEEE editors and reviewers are looking for

• The reviewers are looking for original material, valid methods and rationale, conclusions that make sense, illustrations, tables and graphs, and references relevant and current to the subject.

What is the role of the reviewers?

• Reviewers should make rigorous comments that will help the author to understand why the paper was rejected, or what improvements need to be done to be accepted for publication.
• The insisted on English quality.
• The reviewers must go to technical details, and understand the motivations of the paper.
• The reviewer must look to the results, and, when needed, they must ask for improvements.

Why papers are rejected

• There is a lot of competition, and Europeans professors live in constant pressure. You must publish lots of papers in high-ranked journals.
• It is important to look to the paper templates, and there is no problem if you use the Latex that the conference or journal provide.
• The editors reject papers, because they look to the title and abstract.
• The editors look for reviewers that are suitable to the area of the paper.
• Poorly written, not addressing properly the problem, does not make a big impact, the work was published previously, or the reviewer did not understand what paper says.
• An editor does a quick judgement based on the title, and abstract.

Structure of the paper

• Title
• Abstract
• Keywords
• Introduction
• Methodology
• Results/Discussions/Findings
• Conclusion
• Reference

Title

• Must be short to the point.

Abstract

• Stand alone summary of your work that address: what and why did you do it, why they are useful/important, and how the results were.
• Write in the third person.

Keywords

Introduction

• A description of the problem
• What steps have been done: Information about the topic, prier studies, historical context to your research, your hypothesis, and overview of the result, and how the article is organized.
• Should not be broad or vague, more then 2 pages, and written in the present tense.

Methodology

• Problem formulation, and the processes used to solve the problem, prove or disprove the hypothesis.
• Use illustrations to clarify dieas, and support conclusions.

Result and discussion

• Demonstate that you solved he problem or made significant advances.
• Summarized data should be clear and concise, use figures with narrative to illustrate findings
• Discuss and interpret results of the research.

Conclusion

• Explain what the research has achieved.
• Provide benefits and shortcomings of the solution presented, the research and methodology.
• Suggest future research.

References

• To show the reviewer that I did the work well done.
• That I have studied the right papers
• Support and validate the hypothesis of the research,

Ethics

Types of misconduct

• Conflict of interest
• Plagiarism
  • IEEE checks for that before going to the editors. It is not easy to pass through it.
  • You cannot plagiarised yourself.
• Author attribution
• Author contributions
• Multiple submissions

Impact factor of the journal

The impact factor can depend on how industry is connected to. Utility people read more magazines, than transactions. But in the world of academia is the opposite.o

The editors rank reviewers, and there are reviewers that are star gold marked, and this reviewer is the one with more important voice. If editors are rejecting lots of papers, IEEE starts to questioning them. The editors can keep track of the reviews, but there is no one that can track for himself. Reviews are voluntary.

Open access journal. Submit a paper, and can be open access.

Q&A:

Should questions be used in the title? - The reviewers will always look to the paper, and not to just to the title. Personally, I do not like it.

Why it takes longer to publish in a journal than in a conference?

(this are just some points)

• The journal takes more time to publish because it is more exhaustive, but sometimes it does not justify a big gap line between the first acceptance till the final publication. IEEE is trying to diminish the gap line.
• In conference paper, the organizers want that people attend in conference. So, the pressure is bigger.

Review: A Modular Approach to Fault-Tolerant Broadcasts and Related Problems

    Fault-tolerant broadcasts and consensus have been widely studied, and they are important
parts to design fault-tolerant distributed applications. This paper explores these topics, and expose
these material in a coherent way. First, they start with weakest communication primitive, Reliable
Broadcast, and imposes additional requirements to create a stronger broadcast algorithm. Second,
they explore the paradigm of Consensus that is used to solve many distributed problems, such as
leader election or value agreement.
    The goal of the algorithms are to prevent inconsistency on faulty probability, or at least the
contamination of the correct ones in many situations. This is possible to all algorithms presented
here, and for all benign failures, but they have their limitations. In case of arbitrary faults, neither
inconsistency nor contamination can be prevented by these algorithms. The broadcast uses a
common point-to-point network.
    The several broadcasts algorithms explained here (FIFO, Causal, Atomic, FIFO Atomic, Causal
Atomic Broadcast) were created to deal with crash, or omission, or arbitrary faults, sometimes in
synchronous or asynchronous communication. They show that algorithms are correct when they all
satisfy the properties of Validity, Agreement, and Integrity. The mentioned algorithms were built
on top of Reliable Broadcast. Therefore, they all satisfy the properties of the reliable algorithm.
We can also place message delivery time on these broadcasts, turning them into timed broadcasts,
or add an uniform property so that the properties of broadcast algorithm would be imposed on
faulty processes. All the algorithms are built modularly. The authors show that given any Reliable
Broadcast algorithm, we can obtain any other broadcast algorithm by adding functionalities. E.g,
   • FIFO order + Reliable Broadcast = FIFO Broadcast;

   • Causal order + FIFO Broadcast = Causal Broadcast;

   • Total Order + Reliable, FIFO, Causal Broadcast = Atomic Broadcast.
The authors detail all the transformations that algorithms suffer to be turned into a new one, and
they proof that the algorithms respect all properties.
   They show that the consensus can be achieved from the Atomic Broadcast, and also showed that
Reliable Broadcast and Consensus can be transformed into Atomic Broadcast. In asynchronous
point-to-point networks, Atomic Broadcast can be implemented using failure detectors and randomized algorithms.

  All the algorithms have limitations and work on fault assumptions. The authors do not compare
the algorithms, do not list what faults they can handle, and do not show impossible results. They
only show the correctness of the algorithms, and how they respect all the properties. This makes
hard to understand and compare their limitations. This is the most significant point that the
authors do not address in the paper.
    Despite this negative point, the paper is interesting to read, and I have learnt the basics of
distributed algorithms. This paper is a compendium of broadcast algorithms, and consensus. The
authors start giving a beginners’ lesson about distributed system, and dwells into the main topics
where he writes a concise explanation. In overall, this is an important introductory paper.
    Nowadays, these algorithms does not follow the top of the edge research, but they are the basic
structure where all the new creation came from. The paper refers a big list of related work derived
from these ideas.
    In conclusion, this paper shows an insightful description of broadcast algorithms, and consensus,
and shows the importance of these topics in distributed systems. The contribution of this paper
comes from the fact that shows that we can create new algorithms by adding new functionalities
to an existent and modular broadcast algorithm.