Conferences

Guidelines for In-Coop Association of Conferences/Workshops
August 2011

ACM would like to involve with only conferences and other events of highest technical quality. ACM only rarely involves with the administrative, financial, or organizational aspects of conferences (other than the flagship conferences of the Special Interest Groups). The in-coop status is a route to host the proceedings of top-class conferences on the ACM Digital Library, which has the highest image for its quality in related areas.

This document tries to capture some of the important points that can guide the conduct of the technical programme, which is the cornerstone of conferences.

See the official ACM conference manual. The points regarding the roles and responsibilities of the General Chair(s) and Program Chair(s) are to be noted. The guidelines given there with respect to the process and timeline of appointing the chairs as well as the technical program committee are especially important. So are the brief guidelines given on the reviewing process. You may also see similar points at IEEE's conference manual.

Some of the points that are especially important to conferences organized by Indian institutions are summarized below. Achieving a high quality technical program through fair and transparent processes is the primary intent of this effort.

  1. The goal of the conference is to disseminate results of top class research performed by the authors. Focus of the conference should be sufficiently narrow. It is easier to establish quality especially for a new conference when it is focused narrowly and several top players of that area are part of the conference process. Conferences that are very broadly focused do not get submissions from top researchers as they may not perceive the contributions to be well received at such events.
  2. Its General Chairs and Program Chairs are well respected and recognized individuals with a good track record in the areas of the conference. The practice of appointing VC/Director/Head of institutions to this role may convey a lack of technical focus to the event. Other committees such as Advisory Committee and Patrons have very little value to project the image of the conference in the light of potential contributors. Filling them with names does not help the conference.
    Duties and roles of General and Program Chairs is defined quite well in the ACM and IEEE manuals referred above. The Program Chairs should be individuals of high technical repute and respect. The names of these key individuals should be announced well in advance. It is recommended to do that 9-12 months before the conference dates.
  3. A proper and qualified program committee is at the very core of all conferences. A conference can be good only if good individuals in that area from the country and outside are involved with its process, especially the paper selection process. The program chairs and program committee should have many of the recognized experts in the area from the country and outside.
    The program committee of experts should be set up early and well advertised on the conference website about 7-9 months before the conference. Potential contributors use the quality and stature of the program committee as the primary guide to judge the quality of the conference.
  4. Sound process for paper submission and review. A thorough and fair review process provides quality and stature to conferences. The process of submission and review should be outlined (or even detailed) early on the conference website and implemented diligently. This is especially important for a new conference.
    The process should cover the following aspects:
    a) A safe electronic submission portal is recommended.
    b) Each paper should be assigned to as many expert reviewers as possible, 3 being the recommended minimum number before a paper is accepted.
    c) Blind reviews are mandatory, where the authors have no way to know the identity of the reviewers. This alone prompts reviewers to express their views freely.
    d) A double blind review system where the identity of the authors is hidden from the reviewers is highly recommended. This shields the reviewer from the pressure a top-name author or institution may exert indirectly.
    e) The reviewing process should be sufficiently long to facilitate thorough reviewing. It is recommended that the review submission date be not earlier than 6 weeks after the final (extended, if any) submission deadline. Reviews are unlikely to be serious if sufficient time is not given.
    f) A broad program committee meeting to evaluate the reviews before deciding on the selected papers is mandatory. It is not a sound process if only one or two individuals are involved in the final decisions based on the reviews. If travel is a problem, the PC meeting can be electronic, yet sound. The process should be fair and transparent, and known to the whole program committee before the decisions are announced to the authors. Summary of the process should also be made known widely to the entire community.
    g) A sound policy on key committee members and others from their from their institution NOT submitting papers will enhance the credibility of the conference. This is especially true for young conferences; a conference with many papers from the key organizers or their institutions does not convey an image of high quality to the future editions.
  5. A long term plan for a conference will enhance its quality and standing over time. A conference gains in stature over multiple editions. It is fine to start small as one has to start somewhere. However, a one-off conference is unlikely to be of high quality. A plan for continuity of the conference should be made right at the start. This again requires the active involvement of a good team of experts in the subject area. These can be in the form of a broad steering committee.

The DevOps Phenomenon

ACM Queue’s “Research for Practice” consistently serves up expert-curated guides to the best of computing research, and relates these breakthroughs to the challenges that software engineers face every day. This installment of RfP is by Anna Wiedemann, Nicole Forsgren, Manuel Wiesche, Heiko Gewald, and Helmut Krcmar. Titled “The DevOps Phenomenon,” this RfP gives an overview of stories from across the industry about software organizations overcoming the early hurdles of adopting DevOps practices, and coming out on the other side with tighter integration between their software and operations teams, faster delivery times for new software features, and achieving a higher level of stability.

ACM Case Studies

Written by leading domain experts for software engineers, ACM Case Studies provide an in-depth look at how software teams overcome specific challenges by implementing new technologies, adopting new practices, or a combination of both. Often through first-hand accounts, these pieces explore what the challenges were, the tools and techniques that were used to combat them, and the solution that was achieved.

Why I Belong to ACM

Hear from Bryan Cantrill, vice president of engineering at Joyent, Ben Fried chief information officer at Google, and Theo Schlossnagle, OmniTI founder on why they are members of ACM.
https://india.acm.org/conferences/guidelines-for-in-coop-association
india.acm.org
crawl=CC-MAIN-2019-35
34986
application/http; msgtype=response
sha1:IMNSEC2IONXVA7YPLX7KJ5EF2INTJDVP
<urn:uuid:33ed7588-65d5-414f-b389-fba9850680f7>
2019-08-25T20:11:09Z
5.79.89.114
text/html
sha1:LVPHS4B2SIANNGEER4POWHQKJEFH75Y5
<urn:uuid:00023afb-da90-4037-92bc-2a34a9b7143b>
https://india.acm.org/conferences/guidelines-for-in-coop-association
response
<urn:uuid:7062a08a-743d-4106-ab26-471683a8bb3f>
isPartOf: CC-MAIN-2019-35
publisher: Common Crawl
description: Wide crawl of the web for August 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-156.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/