main.tex

%\documentclass[10pt, conference]{IEEEtran}
\documentclass[sigconf]{acmart}

% ACM stuff
\setcopyright{rightsretained}
\acmDOI{10.475/123_4}

% ISBN
\acmISBN{123-4567-24-567/08/06}

%Conference
\acmConference[ICSE'18]{International Conference on Software Engineering}{May 2018}{Gothenburg, Sweden} 
\acmYear{2017}
\copyrightyear{2017}
\acmArticle{4}
\acmPrice{15.00}
% ACM stuff (end)

\usepackage{color}
\usepackage{url}
%\usepackage{cite}
\newcommand{\todo}[1]{{\textcolor{red}{\textbf{TODO:}~#1}}} 
\newcommand{\sa}[1]{{\textcolor{red}{\textbf{Sven:}~#1}}}  
\newcommand{\sn}[1]{{\textcolor{green}{\textbf{Sarah:}~#1}}}  
\newcommand{\rk}[1]{{\textcolor{red}{\textbf{Raffi:}~#1}}} 
%\newcommand{\updated}[1]{{\textcolor{blue}{#1}}}
\newcommand{\updated}[1]{#1}
\newcommand{\shortname}{WAPI}

\begin{document}

\title{\shortname{}: International Workshop on API Usage and Evolution}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations
\newcommand\tud[0]{\textsuperscript{\normalfont \textdagger}}
\newcommand\iowa[0]{\textsuperscript{\normalfont \textparagraph}}
\newcommand\utd[0]{\textsuperscript{\normalfont \ddag}}
\newcommand\lanu[0]{\textsuperscript{\normalfont \textsection}}
\newcommand\ualberta[0]{\textsuperscript{\normalfont \textasteriskcentered}}

% authors
% IEEE authors
%\author{\IEEEauthorblockN{Sven Amann\textsuperscript{\textdagger}, Sarah Nadi\textsuperscript{\ddag}, Hoan Anh Nguyen\textsuperscript{\textsection}, Tien N. Nguyen\textsuperscript{*}, Raffi Katchadourian\textsuperscript{$\top$}}
%\IEEEauthorblockA{Technische Universit\"{a}t Darmstadt\textsuperscript{\textdagger}, University of Alberta\textsuperscript{\ddag}, Iowa State University\textsuperscript{\textsection},\\ University of Texas at Dallas\textsuperscript{*}, City University of New York\textsuperscript{$\top$}}
%}
% ACM authors
\author{Sven Amann}
\affiliation{Technische Universit\"{a}t Darmstadt}
\author{Sarah Nadi}
\affiliation{University of Alberta}
\author{Hoan Anh Nguyen}
\affiliation{Iowa State University}
\author{Tien N. Nguyen}
\affiliation{University of Texas at Dallas}
\author{Raffi Katchadourian}
\affiliation{City University of New York}
% authors (end)

% ACM stuff

%\begin{CCSXML}
%\end{CCSXML}

%\ccsdesc[500]{Computer systems organization~Embedded systems}
%\ccsdesc[300]{Computer systems organization~Redundancy}
%\ccsdesc{Computer systems organization~Robotics}
%\ccsdesc[100]{Networks~Network reliability}

%\keywords{ACM proceedings, \LaTeX, text tagging}

% ACM stuff (end)


% IEEE wants it here
% \maketitle

\begin{abstract}
Application Programming Interfaces (APIs) are an essential mechanism for software reuse. Over the past two decades, many researchers have addressed inherent problems with APIs, such as providing more useful documentation for proper use, detecting wrong usage patterns, migrating between API versions, and evolving APIs. While research efforts have advanced the state of the art, most of these problems still exist today. We believe it is time to reflect and compare experiences from different perspectives and come up with new solutions to the above challenges. This workshop will advance the state of research of APIs by combining perspectives of the end users, designers, and maintainers of APIs.

In addition to attracting the community of researchers that usually attend ICSE and its co-located events (e.g., MSR, ICPC), we will make intensive efforts to involve local industry participants who can share their experience in using and maintaining APIs, as well as researchers from Scandinavia.
\end{abstract}

% ACM wants it here
\maketitle


\section{Organizer Contact Information}
\begin{itemize}
\setlength\itemsep{5pt}
\item \textbf{Sven Amann (main contact),} Technische Universit\"{a}t Darmstadt, Email: amann@cs.tu-darmstadt.de
\item \textbf{Sarah Nadi,} University of Alberta,\\Email: nadi@ualberta.ca
\item \textbf{Tien N. Nguyen,} University of Texas at Dallas,\\Email: tien.n.nguyen@utdallas.edu
\item \textbf{Hoan Anh Nguyen,} Iowa State University,\\Email: hoan@iastate.edu
\item \textbf{Raffi Khatchadourian,} City University of New York,\\Email: raffi.khatchadourian@hunter.cuny.edu
\end{itemize}

\section{Motivation and Objectives}
%Motivation of the workshop's relevance to the field of software engineering.
Application Programming Interfaces (APIs) are an essential mechanism for software reuse. Software developers use a library or framework's APIs to leverage already implemented functionality. In order to do so, they first have to understand which available libraries provide the desired functionality, what each library's trade-offs are\updated{~\cite{ZHHK17}}, and which special setup each may require. Once an adequate library has been identified, developers need to figure out the respective API's \textit{specification}, which defines the way the API can be used. For example, they need to understand which types to use and which methods to call in which order and with which parameter-values, in order to leverage the desired functionality. This is only the beginning of the journey. If the library's developers decide to change its APIs, this might break existing software that relies on a previous version of the API\@. Thus, as the API evolves, users must decide whether or not they want to migrate to the new API version and determine how the changes will impact their code\updated{, a process that is subject to complex dynamics~\cite{JKR+17}}.

There has been a vast amount of research that tackles each of the above problems separately (e.g.,~\cite{Subramanian:2014,RobillardInferenceSurvey,RobillardLearn09, NNP+09, ThungLibRec}). However, recent work shows that API usability and evolution are still issues~\cite{NKMB16, BKHT:FSE16, SunshineAPIProtocol}, often with severe consequences such as security vulnerabilities. For example, a recent study showed that 83\% of 269 studied security vulnerabilities are due to the incorrect use of cryptography APIs~\cite{Lazar2014}. Similarly, Egele et al.~found that 88\% of almost 12,000 studied Android apps make at least one security violation when using the Java cryptography APIs~\cite{EgeleBFK13}. An even scarier fact is that well-established companies such as Amazon and PayPal also seem to make mistakes when using the APIs for SSL certificate validation~\cite{GeorgievIJABS12}. Misusing security APIs definitely has dire consequences, and some of the difficulties developers have are specific to the complex nature of these APIs~\cite{NKMB16}. However, other studies showed that developers still struggle with more general-purpose APIs~\cite{SunshineAPIProtocol} and that many software-crashing bugs are actually due to not understanding the implicit specifications of the underlying APIs~\cite{amani2016mubench}\updated{, partly due to a lack of up-to-date documentation~\cite{RMS17}. This is especially true in the fast-lived, dynamic domain of Web APIs~\cite{WYZ+17} where we have comparably little support by established mechanisms, such as type systems. Even statically typed environments do not provide as much assistance to developers as they could~\cite{KS17}.}

\subsection{Goals and Outcomes}\label{sec:goals}
%Anticipated goals and outcomes of the workshop (e.g., open research problems to pursue, validation objectives, empirical studies).
To create a more comprehensive solution that allows easier and more correct usages of APIs, we believe that it is time to reflect and consolidate results and experiences from different perspectives on APIs and to come up with solutions to some of the open problems that still need to be addressed such as:

\begin{itemize}
\setlength\itemsep{5pt}

\item \textbf{API Design:} How can we connect API designers with developers consuming their APIs? Can we help API designers improve their API based on how developers use it? Can we automatically identify frequent similar usages or usage clones as candidates to extend a library's functionality?

\item \textbf{API-Usage Recommenders and Misuse Detectors:} To propose ways to use an API or to detect whether some client code correctly uses an API, most techniques rely on mining patterns or specifications from large amounts of client code. The underlying assumption here is that the majority of users ``do it right,'' while the anomalous behavior represents the misuse. However, this is not always the case. One important example is security APIs. How can we make use of the vast amount of available client code but still accurately identify correct patterns? What would be the best representation for these patterns? Additionally, what is the best way to present these usage recommendations or misuse-detection results to the developer? 

\item \textbf{API Quality:} When faced with a choice of multiple APIs that provide the same functionality, what makes one API better than another? What are suitable quality metrics of an API and can we automatically measure them?

\item\textbf{API Documentation:} How can we provide better documentation for APIs? What kind of documentation would end users find useful? How can we ensure up-to-date documentation? And which format best supports developers in grasping an API's specification?

\item \textbf{API Maintenance \& Evolution:} How can we help library designers safely evolve their APIs, e.g., to take advantage of new language features and/or platforms? How can we detect breaking changes in APIs? How can we help the API users migrate their code to new API versions?

\end{itemize}

The aim of the workshop is to create a synergy between the above research topics with the overall goal of improving the design and use of APIs. Addressing these topics combines multiple research areas such as program analysis, program transformation (e.g., refactoring), usability and HCI, mining software repositories, information retrieval in software engineering, and software evolution. The workshop also provides a means for young researchers to understand the open challenges in the area and to discuss their ideas for addressing them. \updated{To further these goals, we plan to submit the workshop results as a New Ideas Paper at one of the top software engineering venues.}

\section{Format and Required Services}

%Workshop format (e.g., paper presentations, keynotes, breakout sessions, panel-like discussions) and plans for generating and stimulating discussions.
%Desired length of the workshop (i.e. 1 or 2 days).
%Special services that are needed; logistic and/or equipment constraints.
\updated{In the first edition of the workshop (2017), we had three sessions with presentations and one session with a discussion at the end. The first edition of the workshop already brought up many interesting challenges during the discussions. In the second edition of 2018, we want to produce actionable ideas for how to address these challenges. Inspired by the work of Robillard et al.~\cite{RMT+17}, we plan to document these ideas by writing, together with the participants, a New Ideas Paper that can be published in one of the upcoming software engineering conferences. In preparation of the workshop, we will derive a set of questions from the accepted submissions and ask participants for feedback, to ensure that the questions adequately reflect the current challenges that the community faces. These questions will serve as a framework for the workshop discussions and to keep them focused on actionable ideas. After the workshops we will draft a publication from the discussion results and ask participants to contribute to it.
%
Based on this idea,} we propose a 1-day workshop with the following format:

\begin{itemize}
\setlength\itemsep{5pt}
\item \textbf{Morning keynote speaker.} This will either be an established researcher who provides some background of the area and the open challenges or a practitioner who can highlight the current challenges faced in industry.
\item \textbf{Presentation session.} \updated{The presentations will be kept short and focus on presenting the main open challenges of the respective work, as inspiration for the following breakout sessions.}
\item \textbf{Breakout sessions.} \updated{We will have breakout sessions in the afternoon, where participants will be divided into different groups. The goal of these sessions is to enable more in-depth discussion of challenges presented in the talks. This will also help those interested in similar topics to foster new collaborations. We will provide guidelines of what the outcomes of these discussions will be, such that participants can present their results at the end of the workshop.}
\end{itemize}

To run the workshop, we would need a room that is equipped with a projector and a flip chart/whiteboard, and that can hold around 40 people.

\section{Target Audience}

Our goal is to have 20--40 participants from both industry and academia. Given the relevance of the workshop's topic to the ICSE audience, we expect around 30 participants.

\subsection{Attendee Background} 
%Required background of the workshop attendees.
%Whether a Mix of industry and research participants is being sought.
%Desired minimum and maximum number of workshop participants, expected number of participants.
We aim for a variety of target-audience background, with respect to the perspective from which participants look at APIs. For example, the audience may have backgrounds such as program analysis, usability and HCI, mining software repositories, or software evolution. Alternatively, they may be end-users of APIs who are interested in voicing suggestions or concerns about their current experience in using (certain) APIs in their projects. That way, participants who specialize in one aspect of working with APIs can learn about other related areas and share insights from their particular viewpoints.

\subsection{Participant Selection}
%Participant solicitation and selection process, including whether the workshop will be open or closed.
The goal of the workshop is to come up with new directions for improving the design, maintenance, and use of APIs and overcoming the challenges that emerged over the past several years. To that end, the workshop will be open to anyone who would like to attend and contribute to the discussion. While paper proceedings and talks will undergo a selection process, everyone is welcome to register for attending the workshop. 

\section{Proceedings}
%How many and what type of contributions will be solicited (number of pages and type: extended abstracts, position and/or research papers, etc.).

We will solicit research papers, practice papers, position papers, or experience reports. All types of papers will be four pages long. To encourage local industry participation, we will also call for talk abstracts. Such talks can focus on challenges faced in industry and stir up interesting discussion in the workshop. We will seek help from the local ICSE organizers to get us in touch with local contacts and forward the workshop's CFP to relevant industry participants.

\subsection{Evaluation Process}
%Evaluation process that will be used to decide the acceptance of submissions.
%A list of program committee members, including proposed and committed members.
All four types of submissions will be peer-reviewed by three program committee (PC) members. Below is a list of the proposed PC members, where names in bold are members who have already agreed to serve on the PC\@.

\begin{enumerate}
\setlength\itemsep{5pt}
\item \textbf{Christoph Treude, University of Adelaide}
\item \textbf{Martin Robillard, McGill University}
\item \textbf{Erik Wittern, IBM T. J. Watson Research Center}
\item Danny Dig, Oregon State University
\item \textbf{Aiko Yamashita, Oslo and Akershus University College of Applied Sciences}
\item \textbf{Collin McMillan, University of Notre Dame}
\item \textbf{Rob Walker, University of Calgary}
\item \textbf{Hyrum Wright, duolingo}
\item \textbf{Hidehiko Masuhara, Tokyo Institute of Technology}
\item \textbf{Mehdi Bagherzadeh, Oakland University}
\item Paige Rodeghero, University of Notre Dame
\item Martin Montperrus, KTH Royal Institute of Technology
\item Sebastian Proksch, University of Zurich
\item Michael Pradel, TU Darmstadt
\item Shigeru Chiba, University of Tokyo
\end{enumerate}

\subsection{Call for Papers}
%Links to preliminary web site of the workshop and call for papers.
The preliminary website for the workshop as well as the call for papers can be found here:

\begin{center}
  \texttt{\url{https://w-api.github.io/}}
\end{center}

\section{Workshop History}

\updated{The first edition of the workshop was held on May 23, 2017, co-located with ICSE 2017 in Buenos Aires, Argentina. The workshop had five accepted papers out of nine submissions, one industry talk from Google, a keynote by Prof. Brad Myers, and 16 registered attendees. It's website is available here:}

\begin{center}
  \texttt{\url{https://w-api.github.io/2017/}}
\end{center}

\section{Organizers' Bios}
%a brief description of each organizer's background, including relevant past experience in organizing conferences and workshops.
\begin{itemize}
\setlength\itemsep{5pt}
\item \textbf{Sven Amann} is currently a fifth-year PhD student at the Technische Universit\"{a}t Darmstadt. His research interests include developer-assistance tools for API use, bug detection, mining software repositories, and software testing. He was involved in organizing WAPI'17.

\item \textbf{Dr. Sarah Nadi} is an assistant professor at the University of Alberta. Her research interests include mining software repositories, software product lines, and helping developers use APIs correctly. She was the main organizer for WAPI'17.

\item \textbf{Dr. Hoan Nguyen} is a post-doctoral researcher at Iowa State University. His research interests include program analysis, software evolution and maintenance, and mining software repositories. He has extensive expertise in mining API specifications and adaptations from client code. He has been involved in organizing tutorials at ICSE'14 and SPLASH'15, the first Midwest Big Data Summer School 2016, and ICSE'17 (WAPI'17).

\item \textbf{Dr. Tien Nguyen} is an associate professor at The University of Texas at Dallas. His research interests include program analysis, large-scale mining software repositories, and statistical approaches in software engineering. He has been involved in organizing workshops and tutorials at ICSE'14, SPLASH'14, SPLASH'15, and ICSE'17 (WAPI'17).

\item \textbf{Dr.~Raffi Khatchadourian} is an assistant professor at Hunter College and the Graduate Center at the City University of New York. His research interests include program analysis, program transformation, and automated refactoring, including its impact on API consumption. He was a participant at WAPI'17, organized the LaMod'16 workshop at MODULARITY'16. He has also served as the web chair for ECOOP'11 and is currently serving as the publicity chair for ESEC/FSE'18.
\end{itemize}

% IEEE references
%\bibliographystyle{myabbrv_withpagesandpublisher}
% ACM references
\bibliographystyle{ACM-Reference-Format}
\bibliography{refs.bib}

\newpage
\onecolumn

\begin{center}
\Large{\textbf{Call For Papers}}
\end{center}

Application Programming Interfaces (APIs) are an essential mechanism for software reuse on many levels, such as libraries or web services. However, over the past two decades, many researchers have shown inherent problems with APIs, such as providing useful documentation for proper use, detecting correct usage patterns or wrong usages, and migrating between API versions. While these efforts have advanced the state of the art, most of these problems still exist today. We believe it is time to reflect and compare experiences from different perspectives and to come up with new solutions to the above challenges. 

The 2nd International Workshop on API Usage and Evolution (\shortname{}) provides a venue for researchers and practitioners to come together and discuss the open challenges that API users and designers face. For example, how can we measure the quality of an API\@? How can we accurately rely on client code for identifying patterns when the rule of ``the majority do it right'' does not always hold (e.g., in security-related APIs)? What is the best way to present API recommendations and API usages to a developer?
%
\updated{The goal of the workshop is to identify the current open challenges in the area and define a roadmap for innovative solutions. Together with all workshop participants, we aim to publish this roadmap as a New Ideas Paper, e.g., in ASE'18, ICSE'19, SANER'19, or FSE'19.
Before the workshop, the organizers will derive questions from the accepted papers and ask participants for feedback. This will serve as a framework for workshop discussions. After the workshop, the organizers will draft a respective publication from the results of the discussions and ask participants to contribute to it.}


\vspace{0.2cm}

\noindent
\textbf{\large Topics}
\vspace{0.2cm}

Topics of interest include, but are not limited to:
\begin{itemize}
\setlength\itemsep{5pt}

\item API design
\item API specification/documentation
\item API quality metrics
\item API usage recommendation
\item API misuse detection
\item API maintenance
\item API evolution and migration
\item Evolution of API documentation
\item Leveraging different sources of data to perform/support any of the above tasks
\item Suitable representations for usage patterns
\item User-friendly ways of presenting API and API-usage recommendations to the developer
\item User or designer perspectives of API usage and evolution
\item Negative experiences (what did not work)
\item Identification of open challenges and proposed solutions
\item Transfer of approaches between different types of APIs, such as library APIs or web APIs
\item Synergies between API-research challenges and other research areas  
\end{itemize}


\vspace{0.2cm}
\noindent
\textbf{\large Submission Information}
\vspace{0.2cm}

\shortname{} 2018 invites contributions in the form of \textbf{4-page papers} from both researchers and practitioners, as well as \textbf{talk abstracts} from practitioners. Submissions can be research papers, practice papers, position papers, or experience reports. All submissions should describe unpublished work and must have been neither previously accepted for publication nor concurrently submitted for review in another journal, book, conference, or workshop. Submissions are peer-reviewed and accepted papers will appear in the workshop proceedings.

\vspace{0.2cm}
\noindent
\textbf{\large Important Dates}
\vspace{0.2cm}

\textbf{Workshop papers submissions due}: Monday February 5th 2018

\textbf{Notification to accepted papers:} Monday March 5th 2018

\textbf{Camera-ready copies due:} Monday March 19th 2018

\vspace{0.2cm}

The official publication date of the workshop proceedings is the date the proceedings are made available in the ACM Library. This date may be up to two weeks prior to the first day of ICSE 2018. The official publication date affects the deadline for any patent filings related to published work.

\end{document}