Papers FAQ
Technical Papers FAQs
FAQ Table of Contents
1. New at SC13 Tech Papers
2. State of the Practice (SOP)
3. Rebuttals to Reviews (based on the SIGGRAPH rebuttal process)
4. Plagiarism (including self-plagiarism)
5. Conflict of Interest Guidelines
1. New at SC13 Tech Papers
Question: What is new at SC13 for technical papers?
Answer:
- We have modified topical areas and keywords from SC12. Authors may submit high-quality, original research contributions along the following topical areas: 1. Algorithms; 2. Applications; 3. Architectures and Networks; 4. Clouds and Grids; 5. Performance Analysis and Tools; 6. Programming Systems; 7. Storage, Visualization, and Analytics; 8. System Software; 9. State of the Practice.
- The “Performance Analysis and Tools” area is intended to capture all aspects of performance, including speed, greenness (e.g., energy or power), and resilience, for example.
- The "State of the Practice," originally introduced as a separate event in the SC11 Technical Program, was integrated into technical papers as a topical area for SC12 and continues for SC13. Authors may submit high-quality contributions with new and generalizable insights that can advance the practice of high-performance computing, including facilities, services and systems. See Section 2 below for more information.
- We have retained a rebuttal process to enhance the rigor of peer-review to determine acceptance of submissions. Authors may address factual errors in the reviews and answer specific questions posed by reviewers during the review rebuttal period. See Section 3 below for more information.
Q. What are the main review criteria for acceptance?
A. We will focus on originality, technical soundness, presentation quality, timeliness, impact, and relevance to SC. These criteria will be applied uniformly across the nine topical areas to drive the acceptance of contributions that measurably improve upon the state of the art along dimensions that are relevant for SC. Consequently, for the State of the Practice, they will be tailored to value the new and generalizable insights as gained from the practice of high-performance computing (see Section 2 below for further information).
Q. Is it mandatory for authors to select the primary area of their contribution?
A. Yes. Authors must indicate the primary area of contribution from the nine topical areas above. We understand that contributions may straddle more than one area and in such cases, we encourage authors to indicate a secondary area of contribution.
Q: What do you expect the acceptance rate to be?
A. With our focus on quality and the observed trend towards substantial increases in submissions from year to year, we expect about a 20 percent acceptance rate for SC13.
Q: Will there be best paper awards?
A. Yes. Awards will be given for Best Paper and Best Student Paper. Extended versions of papers selected as finalists for the Best Paper and Best Student Paper Awards may be published in a selected journal.
2. State of Practice (SOP)
Q: Will my SOP paper count as a regular SC paper so that I can claim the same impact factor, etc.?
A: Yes, this is the point of making the SOP a part of the Technical Papers program. A SOP paper is just as good as any other paper in the Technical Papers program, and the entire Technical Papers Committee collectively endorses its academic quality.
Q: What constitutes a SOP paper?
A: A SOP paper can describe a first-of-its-kind technology or methodology or can capture a unique perspective (or experience) on issues, challenge, and solutions for dealing with aspects of unprecedented scale and complexity, particularly the experiences and knowledge that can be generalized to wide ranges of systems and usages. As stated in the Call for Papers, concrete case studies within a conceptual framework would likely serve as the basis for submitted papers, but efforts to generalize the experience for wider applicability will be highly valued.
Q: Who will review the SOP papers?
A: As with any other tech paper, they will be reviewed by a set of Technical Papers Committee members who are experts in the field and will comprise the "SOP area." In fact, SOP is one of the 9 areas for tech papers we have this year. The area review committee consists of a balance of people with research, development, and operational experience for large-scale high-performance computing, networking, storage, and analytics.
Q: I am concerned that if the standards for SOP are the same as for the regular papers, the SOP papers will be rejected for not being sufficiently academically rigorous. How will you handle this?
A: Although SOP papers will be reviewed under the same rigorous academic peer review process as the papers in other areas, e.g., careful reviews and face-to-face discussions by anonymous reviewers, the acceptance criteria will be tailored to value the new and generalizable insights as gained from experiences of a particular instance in HPC machines/operations/applications/benchmarks, overall analysis of the status quo of a particular metric of the entire field, historical reviews of the progress of the field, etc.
Such types of papers are actually common in other academic disciplines, including branches of computer science. For example, software engineering highly values the "experience papers" of particular frameworks and methodologies; human-computer interaction embodies numerous works on analysis of human behavior given a particular interface; social science is about collecting data on social phenomenon and providing meaningful insights based on their statistical analysis.
Q: At the same time, if you apply less rigor to the SOP papers won't the prestige of the entire conference suffer?
A: We do plan to apply rigor in a sense that, although we will not necessarily require the particular technology that would be the subject matter of the paper to be novel, we do require that the insights gained to be novel and useful. That is to say, papers with contents of the nature "this is how we do things here" without new, generalizable insights provided to the peers will likely have low chance of acceptance.
3. Rebuttals to reviews (based on the SIGGRAPH rebuttal process)
Q: What is a rebuttal?
A: The rebuttal is for addressing factual errors in the reviews and for answering specific questions posed by reviewers. There will be an opportunity to upload a rebuttal to address factual errors and specific questions in the reviews via the online submission system during a rebuttal period. Then, authors may upload up to 750 words of text in the system before the rebuttal deadline. The rebuttals will be read by the referees and factored into the discussion leading up to the acceptance decisions made at the Technical Papers Committee meeting.
Q: Should I write a rebuttal?
A: Any author may upload a rebuttal. The choice of whether to submit one and how much time to spend on it is up to each author. As a general guideline, submitting a rebuttal is a good idea if the paper seems to have a chance of being accepted, and if the reviews contain errors that can be corrected or specific questions than can be answered with short textual descriptions.
Q: What should be included in the rebuttal?
A: The rebuttal is for addressing factual errors in the reviews and for answering specific questions posed by reviewers. The rebuttal can also help clarify the merits and novelty of the paper with respect to prior work, if it is felt that the reviewers misunderstood the paper’s contributions and scope. It is very limited in length, and must be self-contained. It cannot, for instance, contain URLs to external pages.
Q: Now that I've read the reviews of my paper, I see much better how to organize it so it will be clear to the reader. Can I do this reorganization and upload the new version during the rebuttal period?
A: No. The rebuttal period is only for addressing factual errors in the reviews, not for getting revised text into the review process. The committee members will have only a short time in which to read and act on your rebuttal, and it must be short and to the point. Hence, it will be limited to 750 words of text.
Q: Between paper submission and the rebuttal period, we've gotten some really cool new results for our paper. Can I upload those results during the rebuttal period? I'm sure that they will make the reviewers realize the importance of our approach.
A: No. The rebuttal period is for addressing factual errors in the reviews, not for getting new results into the review process.
Q: Reviewer #4 clearly didn't read my paper carefully enough. Either that or this reviewer doesn't know anything about the field! How should I respond during the rebuttal period?
A: We've all received reviews that made us angry, particularly on first reading. The rebuttal period is short and doesn't allow for the cooling-off period that authors have before they write a response to a journal review. As a result, authors need to be particularly careful to address only factual errors or reviewer questions in the rebuttals rather than letting their emotions show through.
Please don't say: "If reviewer #4 had just taken the time to read my paper carefully, he would have realized that our algorithm was rotation invariant." Instead say: "Unfortunately, Section #4 must not have been as clear as we had hoped because Reviewer #4 didn't understand that our algorithm was rotation invariant and he was therefore skeptical about the general applicability of our approach. Here is a revised version of the second paragraph in Section 4, which should clear up this confusion."
Remember that your rebuttal gets sent to all the reviewers; you don't want to offend or alienate them. In particular, you want the reviewers to come out of the rebuttal process sufficiently enthused about your paper to champion it at the committee meeting, and if the paper is accepted and needs revision, then you want them to feel sufficiently comfortable with you as an author that they are willing to "shepherd" the paper through the revision process.
Q: I uploaded a rebuttal, but got no feedback. How can I be sure the reviewers received and actually read my rebuttal?
A: If you can view your rebuttal comments in the online review system, so can your reviewers. Rest assured that rebuttal information is considered and can be very helpful in the selection process.
4. Plagiarism (including self-plagiarism)
Q: What is plagiarism?
A: Please see the IEEE website for more information on identifying plagiarism. Identifying plagiarism: http://www.ieee.org/publications_standards/publications/rights/ID_Plagiarism.html
Plagiarism FAQ: http://www.ieee.org/publications_standards/publications/rights/plagiarism_FAQ.html.
5. Conflict of Interest Guidelines
Q: What are the SC13 guidelines for Conflicts of Interest (COI)?
A: A potential conflict of interest occurs when a person is involved in making a decision that 1) could result in that person, a close associate of that person, or that person’s company or institution receiving significant financial gain, such as a contract or grant, or 2) could result in that person, or a close associate of that person, receiving significant professional recognition, such as an award or the selection of a paper, work, exhibit, or other type of submitted presentation.
Authors and Technical Papers Committee members will be given the opportunity to list the potential conflicts during the submission and review process. Technical Papers Committee chairs and area chairs will make every effort to avoid assignments that have a potential COI.
For SC13, we define a conflict of interest as:
- Your Ph.D. advisors, post-doctoral advisors, Ph.D. students, and post-doctoral advisees forever.
- Family relations by blood or marriage, or equivalent (e.g., a partner), forever.
- People with whom you collaborated in the past five years. Collaborators include
- co-authors on an accepted/rejected/pending research paper,
- co-PIs on an accepted/pending grant,
- those who fund your research,
- researchers whom you fund, or
- researchers who you are actively collaborating with on a project.
- People who were employed by, or a student at, your primary institution(s) in the past five years, or people who are active candidates for employment at your primary institution(s).
- Close personal friends or others with whom you believe a conflict of interest exists.
Note that “service” collaborations, such as writing a DOE, NSF, or DARPA report, or serving on a program committee, are not a conflict-of-interest per se.
Other possible conflicts can exist, and you should contact the Technical Papers Chairs for questions or clarification on any of these issues.