Chatbot has become an important solution to rapidly increasing customer care demands on social media in recent years. However, current work on chatbot for customer care ignores a key to impact user experience - tones. In this work, we create a novel tone-aware chatbot that generates toned responses to user requests on social media. We first conduct a formative research, in which the effects of tones are studied. Significant and various influences of different tones on user experience are uncovered in the study. With the knowledge of effects of tones, we design a deep learning based chatbot that takes tone information into account. We train our system on over 1.5 million real customer care conversations collected from Twitter. The evaluation reveals that our tone-aware chatbot generates as appropriate responses to user requests as human agents. More importantly, our chatbot is perceived to be even more empathetic than human agents.

Users are rapidly turning to social media to request and receive customer service; however, a majority of these requests were not addressed timely or even not addressed at all. To overcome the problem, we create a new conversational system to automatically generate responses for users requests on social media. Our system is integrated with state-of-the-art deep learning techniques and is trained by nearly 1M Twitter conversations between users and agents from over 60 brands. The evaluation reveals that over 40% of the requests are emotional, and the system is about as good as human agents in showing empathy to help users cope with emotional situations. Results also show our system outperforms information retrieval system based on both human judgments and an automatic evaluation metric.

Modern IDEs contain sophisticated components for inferring missing types, correcting bad syntax and completing partial expressions in code, but they are limited to the context that is explicitly defined in a project's configuration. These tools are ill-suited for quick prototyping of incomplete code snippets, such as those found on the Web in Q&A forums or walk-through tutorials, since such code snippets often assume the availability of external dependencies and may even contain implicit references to an execution environment that provides data or compute services. We propose an architecture for smart programming playgrounds that can facilitate rapid prototyping of incomplete code snippets through a semi-automatic context resolution that involves identifying static dependencies, provisioning external resources on the cloud and injecting resource bindings to handles in the original code fragment. Such a system could be potentially useful in a range of different scenarios, from sharing code snippets on the Web to experimenting with new ideas during traditional software development.

StackOverflow's primary goal is to serve as a platform for users to solicit answers regarding programming questions, though its archives are often used by other users who face similar issues and thus it serves a secondary purpose of documenting common problems. The two driving mechanisms for filtering out low quality posts and highlighting the best answers are community votes and the mark of acceptance by the original question asker. But does the asker's choice always match the popular vote? If so, is the asker's choice influenced by the community vote or is the community vote biased towards the accepted answer? And if the asker and community disagree, then can we determine any particular characteristics of posts that influence the choice of the asker and community differently, such as its size, readability, presence of code snippets and external links as well as similarity to the original question? In this paper, we explore the answers to these questions by studying a data-set of all posts on StackOverflow from its launch in September 2008 to September 2014.

Several news articles in the past year highlighted incidents in which malicious users stole API keys embedded in files hosted on public source code repositories such as GitHub and Bit Bucket in order to drive their own work-loads for free. While some service providers such as Amazon have started taking steps to actively discover such developer carelessness by scouting public repositories and suspending leaked API keys, there is little support for tackling the problem from the code sharing platforms themselves. In this paper, we discuss practical solutions to detecting, preventing and fixing API key leaks. We first outline a handful of methods for detecting API keys embedded within source code, and evaluate their effectiveness using a sample set of projects from GitHub. Second, we enumerate the mechanisms which could be used by developers to prevent or fix key leaks in code repositories manually. Finally, we outline a possible solution that combines these techniques to provide tool support for protecting against key leaks in version control systems.

Most software development tools allow developers to subscribe to notifications about code checked-in by their team members in order to review changes to artifacts that they are responsible for. However, past user studies have indicated that this mechanism is counter-productive, as developers spend a significant amount of effort sifting through such feeds looking for items that are relevant to them. We present NeedFeed, a system that models code relevance by mining a project's software repository and highlights changes that a developer may need to review. We evaluate several techniques to model code relevance, from a naive TOUCH-based approach to generic HISTORY-based classifiers using temporal code metrics at file and method-level granularities, which are then improved by building developer-specific models using TEXT-based features from commit messages. NeedFeed reduces notification clutter by more than 90%, on average, with the best strategy giving an average precision and recall of more than 75%.

Open-source software projects are primarily driven by community contribution. However, commit access to such projects' software repositories is often strictly controlled. These projects prefer to solicit external participation in the form of patches or pull requests. In this paper, we analyze a set of 89 top-starred GitHub projects and their forks in order to explore the nature and distribution of such community contribution. We first classify commits (and developers) into three categories: core, external and mutant, and study the relative sizes of each of these classes through a ring-based visualization. We observe that projects written in mainstream scripting languages such as JavaScript and Python tend to include more external participation than projects written in upcoming languages such as Scala. We also visualize the geographic spread of these communities via geocoding. Finally, we classify the types of pull requests submitted based on their labels and observe that bug fixes are more likely to be merged into the main projects as compared to feature enhancements.

There is an increasing trend to outsource maintenance of large applications and application portfolios of a business to third parties, specialising in application maintenance, who are incented to deliver the best possible maintenance at the lowest cost. To do so, they need to identify repeat problem areas, which cause more maintenance grief, and seek a unified remedy to avoid the costs spent on fixing these individually. These repeat areas, in a sense, represent major, evolving areas of need, or requirements, for the customer. The information about the repeating problem is typically embedded in the unstructured text of multiple tickets, waiting to be found and addressed. Currently, repeat problems are found by manual analysis; effective solutions depend on the collective experience of the team solving them. In this paper, we propose an approach to automatically analyze problem tickets to discover groups of problems being reported in them and provide meaningful, descriptive labels to help interpret these groups. Our approach incorporates a cleansing phase to handle the high level of noise observed in problem tickets and a method to incorporate multiple text clustering techniques and merge their results in a meaningful manner. We provide detailed experiments to quantitatively and qualitatively evaluate our approach

Bugs are inevitable in software projects. Resolving bugs is the primary activity in software maintenance. Developers, who fix bugs through code changes, are naturally important participants in bug resolution. However, there are other participants in these projects who do not perform any code commits. They can be reporters reporting bugs; people having a deep technical know-how of the software and providing valuable insights on how to solve the bug; bug-tossers who re-assign the bugs to the right set of developers. Even though all of them act on the bugs by tossing and commenting, not all of them may be crucial for bug resolution. In this paper, we formally define essential non-committers and try to identify these bug resolution catalysts. We empirically study 98304 bug reports across 11 open source and 5 commercial software projects for validating the existence of such catalysts. We propose a network analysis based approach to construct a Minimal Essential Graph that identifies such people in a project. Finally, we suggest ways of leveraging this information for bug triaging and bug report summarization.

Success of a Q&A forum depends on volume of content (questions and answers) and quality of content (are the questions asked relevant, answers provided correct etc). Community participation is essential to create and curate content. Since their inception in 2008, stack exchange based forums have been able to engage a large number of users to create a rich repository of good quality questions and answers. In this paper, we wish to investigate the “activeness” of users in the stackexchange network particularly from a perspective of content creation. We also attempt to measure how the forums' incentive mechanism has enabled user's activeness. Further, we investigate how user's have diffused to other parts of the stack exchange network over time, hence bootstrapping new forums.

An analysis of commit history of Android reveals that Android has a code base of 550K files, where on an average each file has been modified 8.7 times. 41% of files have been modified at-least once. In terms of contributors, it has an overall contributor community of 1563, with 58.5% of them having made >; 5 commits. Moreover, the contributor community shows high churn levels, with only 13 of contributors continuing from 2005 to 2011. In terms of industry participation, Google & Android account for 22% of developers. Intel and RedHat account for 2% of contributors each and IBM, Oracle, TI, SGI account for another 1% each. Android code can be classified into 5 sub-projects: kernel, platform, device, tools and toolchain. In this paper, we profile each of these sub-projects in terms of change volumes, contributor and industry participation. We further picked specific framework topics such as UI, security, whose understanding is required from perspective of developing apps over Android, and present some insights on community participation around the same.

In most software projects, resolved bugs are archived for future reference. These bug reports contain valuable information on the reported problem, investigation and resolution. When bug triaging, developers look for how similar problems were resolved in the past. Search over bug repository gives the developer a set of recommended bugs to look into. However, the developer still needs to manually peruse the contents of the recommended bugs which might vary in size from a couple of lines to thousands. Automatic summarization of bug reports is one way to reduce the amount of data a developer might need to go through. Prior work has presented learning based approaches for bug summarization. These approaches have the disadvantage of requiring large training set and being biased towards the data on which the model was learnt. In fact, maximum efficacy was reported when the model was trained and tested on bug reports from the same project. In this paper, we present the results of applying four unsupervised summarization techniques for bug summarization. Industrial bug reports typically contain a large amount of noise---email dump, chat transcripts, core-dump---useless sentences from the perspective of summarization. These derail the unsupervised approaches, which are optimized to work on more well-formed documents. We present an approach for noise reduction, which helps to improve the precision of summarization over the base technique (4% to 24% across subjects and base techniques). Importantly, by applying noise reduction, two of the unsupervised techniques became scalable for large sized bug reports.

The complex process of adapting pre-packaged applications, such as Oracle or SAP, to an organization's needs is full of challenges. Although detailed, structured, and well-documented methods govern this process, the consulting team implementing the method must spend a huge amount of manual effort to make sure the guidelines of the method are followed as intended by the method author. MATCON breaks down the method content, documents, templates, and work products into reusable objects, and enables them to be cataloged and indexed so these objects can be easily found and reused on subsequent projects. By using models and meta-modeling the reusable methods, we automatically produce a CASE tool to apply these methods, thereby guiding consultants through this complex process. The resulting tool helps consultants create the method deliverables for the initial phases of large customization projects. Our MATCON output, referred to as Consultant Assistant, has shown significant savings in training costs, a 20 - 30% improvement in productivity, and positive results in large Oracle and SAP implementations.

The success of an open-source project depends to a large degree on the proactive and constructive participation by the developer community. An important role that developers play in a project is that of a code committer. However, code-commit privilege is typically restricted to the core group of a project. In this paper, we study the phenomenon of the induction of external developers as code committers. The trustworthiness of an external developer is one of the key factors that determines the granting of commit privileges. Therefore, we formulate different hypotheses to explain how the trust is established in practice. To investigate our hypotheses, we developed an automated approach based on mining code repositories and bug-tracking systems. We implemented the approach and performed an empirical study, using the Eclipse projects, to test the hypotheses. Our results indicate that, most frequently, developers establish trust and credibility in a project by contributing to the project in a non-committer role. Moreover, the employing organization of a developer is another factor--although a less significant one--that influences trust.

In this paper we present an automated technique for localizing faults in data-centric programs. Data-centric programs primarily interact with databases to get collections of content, process each entry in the collection(s), and output another collection or write it back to the database. One or more entries in the output may be faulty. In our approach, we gather the execution trace of a faulty program. We use a novel, precise slicing algorithm to break the trace into multiple slices, such that each slice maps to an entry in the output collection. We then compute the semantic difference between the slices that correspond to correct entries and those that correspond to incorrect ones. The "diff" helps to identify potentially faulty statements.

Model transforms are a class of applications that convert a model to another model or text. The inputs to such transforms are often large and complex; therefore, faults in the models that cause a transformation to generate incorrect output can be difficult to identify and fix. In previous work, we presented an approach that uses dynamic tainting to help locate input-model faults. In this paper, we present techniques to assist with repairing input-model faults. Our approach collects runtime information for the failing transformation, and computes repair actions that are targeted toward fixing the immediate cause of the failure. In many cases, these repair actions result in the generation of the correct output. In other cases, the initial fix can be incomplete, with the input model requiring further repairs. To address this, we present a pattern-analysis technique that identifies correct output fragments that are similar to the incorrect fragment and, based on the taint information associated with such fragments, computes additional repair actions. We present the results of empirical studies, conducted using real model transforms, which illustrate the applicability and effectiveness of our approach for repairing different types of faults.

Service-oriented applications can be expensive to test because services are hosted remotely, are potentially shared among many users, and may have costs associated with their invocation. In this paper, we present an approach for reducing the costs of testing such applications. The key observation underlying our approach is that certain aspects of an application can be tested using locally deployed semantic service stubs, instead of actual remote services.A semantic service stub incorporates some of the service functionality, such as verifying preconditions and generating output messages based on post conditions. We illustrate how semantic stubs can enable the client test suite to be partitioned into subsets, some of which need not be executed using remote services. We also present a case study that demonstrates the feasibility of the approach, and potential cost savings for testing. The main benefits of our approach are that it can (1) reduce the number of test cases that need to be run to invoke remote services, (2) ensure that certain aspects of application functionality are well-tested before service integration occurs.

Model-driven development (MDD) is widely used to develop modern business applications. MDD involves creating models at different levels of abstractions. Starting with models of domain concepts, these abstractions are successively refined, using transforms, to design-level models and, eventually, code-level artifacts. Although many tools exist that support transform creation and verification, tools that help users in understanding and using transforms are rare. In this paper, we present an approach for assisting users in understanding model transformations and debugging their input models. We use automated program-analysis techniques to analyze the transform code and compute constraints under which a transformation may fail or be incomplete. These code-level constraints are mapped to the input model elements to generate model-level rules. The rules can be used to validate whether an input model violates transform constraints, and to support general user queries about a transformation. We have implemented the analysis in a tool called XYLEM. We present empirical results, which indicate that (1) our approach can be effective in inferring useful rules, and (2) the rules let users efficiently diagnose a failing transformation without examining the transform source code.

User interface (UI) design is an integral part of the software design process. The UI design not only outlines the look and feel of the system, but also helps in flushing out the requirements - by identifying what data is visible to and processed by different users. However, in any SOA methodology, UI design is typically considered out of scope. In this paper, we highlight the importance of UI design specification in the SOA landscape, from a service- identification perspective. Service identification, which is a key activity in any SOA-based development, involves specification of business requirements as a set of granular service definitions. We propose an approach for harvesting the UI design specification to define service requirements for the intended system; more specifically in terms of information and business service requirements. Our approach consists of the following steps: (1) capture user interface design in a format amenable to automated analysis, with appropriate references to data and process models, (2) identify requirements for information services from data that is displayed in the user interface, and (3) identify business service requirements from the UI navigation flow and the links between the UI and the business process model. To illustrate our approach, we present a case study using the Amazon associate Web services. The study demonstrates how the use of UI designs can lead to better service identification. The proposed approach can complement any existing SOA methodology that follows a top-down approach to identify services.

In this position paper we argue that to effectively address coordination challenges in distributed software development, we need to go beyond making individual development tools more collaborative and design a framework that enables common understanding of the information from different tools and supports loose coupling between them. Stakeholders can go about doing their work in their choice of tools, and as long as these tools adhere to certain interface requirements imposed by the framework, information may be shared across tools in a seamless fashion. The framework should also be able to pick up on cues within the project execution environment, analyze them, and provide useful information as alerts and advisories to stakeholders. Finally, the framework should be adaptive to new tools introduced in the development process as well as to changing project governance needs. We present a preliminary architecture of the framework and discuss candidate technologies to realize it.

In recent years, a number of business reasons have caused software development to become increasingly distributed. Remote development of software offers several advantages, but it is also fraught with challenges. In this paper, we report on our study of distributed software development that helped shape a research agenda for this field. Our study has identified four areas where important research questions need to be addressed to make distributed development more effective. These areas are: collaborative software tools, knowledge acquisition and management, testing in a distributed set-up and process and metrics issues. We present a brief summary of related research in each of these areas, and also outline open research issues.