A journal lives and dies not just by submissions but by reviewers. Someone has to take those submissions, read them, and determine if they fit in the journal. It isn’t just one person that has to decide it goes it, it takes three reviews to pass muster.
That means for everyone one paper submitted to DTRAP, we need three people to read it.
I’ve often been asked what it means to be a reviewer because outside of academia, it isn’t that prevalent. Remember reading comprehension exercises? It’s something like that, only… not.
I’m going to talk about DTRAP because that’s what I do. I want to talk about DTRAP’s review questions. These are questions we want the reviewer to fill out once they’ve read the paper.
- What is the paper about?
- What does this paper contribute to the field of Digital Threats? What are the strengths of this paper?
- How can the paper be improved? What are its weaknesses? How can it be strengthened?
- Is this paper of potential interest to developers and engineers?
I’m going to talk about what we mean for each question, hopefully to demystify them.
We’re asking you to start by summarizing the paper. Demonstrate to the editor in charge of the paper that you understood the details explained in the paper. This is so that if anyone questions us, we can say “Yup, the reviewer understood it!”.
Now tell what you liked about the paper. How it contributes to the field, like “There’s a new method here” or “The analysis is useful” or maybe “That is a new approach I never thought of”. We’re not asking you to write paragraphs and paragraphs, but we do know what you think. This isn’t like school where there’s a right answer to the meaning of a paper, this is truly “We want your opinion.”
The next question asks what you didn’t like about the paper. Maybe the authors didn’t clearly explain their method. Maybe you think this problem has been solved already in a similar fashion. We want your expertise on this, which is why we asked you.
DTRAP wants practical results. We want results that aren’t just laboratory focused but can be used. That means we’re going to ask you if you think the results in the paper are applicable to engineers and developers.
Finally, you get to make your recommendation about the paper. After your opinions in the above paragraphs, now you need to put that all together. Are there too many problems in the paper that you don’t think can be fixed? Then select “reject”. Are there no problems, nothing at all, the paper is perfect, couldn’t be better? Then select “accept”. The two options in the middle are for ‘Hey, there’s a few things that should be fixed’ (minor revision) and ‘I think the paper has merit but you really need to fix all these things’ (major revision).
I want to reiterate that there’s no right or wrong answer here. This is truly your opinion. The reason we ask three people (yes, three!) people to review is to get a consensus of what to do with the paper.
The editor in charge of the paper then takes your reviews, your opinion of what we should do, and makes the decision based on that.
This is your way of contributing your opinion to the field. This is your way of stepping up and letting us know what you think. You may not think you can write a paper, but you can certainly read one and tell us what you think.
Sign up today Be a reviewer. Let your opinion be known.