Fábio Macêdo Mendes
email: fabiomendes@unb.br

Ricardo Poppi

Henrique Parra
email: henrique@cidadedemocratica.org.br

Bruna Moreira
email: brunamoreira@unb.br

EJ: A free software platform for social participation

Keywords: Social Participation, E-governement, Web, Free Software

As the Internet grows on importance as a forum for political activity, it is necessary to occupy it with proper tools for democratic discussion, dialogue and deliberation. Currently, a substantial part of political debate is conducted on social media inside proprietary networks. Those solutions are flagrantly inadequate to build consensus seeking understandings and to mediate the interaction between the government and the citizenry. This work present EJ, a platform for crowdsourced social participation which uses machine learning based intelligence and gamification techniques to increase engagement and counteract the formation of opinion bubbles and the "echo chamber" effect of social networks.

Introduction

As a growing proportion of the world's population gains access to the Internet, so grows its importance as a place for public discourse and social organization. An optimistic stance on this fact points to a networked democracy in which information flows horizontally and the common citizen can exert real decision making power and produce solutions to societal problems. On the other hand, the same Internet has allowed mechanisms that support privacy violation, surveillance [START_REF] Albrechtslund | Online social networking as participatory surveillance[END_REF] and spread of misinformation [START_REF] Del Vicario | The spreading of misinformation online[END_REF] in a scale never seen before. For better or for worse, it is unquestionable that the Internet plays an important role in shaping societies and political systems of the present and of the future [START_REF] Best | The Internet and Democracy: Global Catalyst or Democratic Dud?[END_REF].

This contradiction of potentialities is perhaps better demonstrated in today's largest social network, Facebook, with its more than 2 billion users 3 . The rise of modern social networks has indeed delivered novel forms of horizontal communication and has given voice to actors that would otherwise be excluded from traditional processes. At the same time, Facebook's business model is centered around keeping users connected to the platform to deliver targeted marketing content, while gathering any information useful for profiling. This model has been frequently abused to obtain audience and political gain via questionable practices such inflammatory and sensationalist discourse, disinformation, hate speech 4 , etc; all very detrimental to further democratic values, albeit frequently treated as a tolerable source of revenue by the social network itself 5 .

We believe that a platform for social participation must be explicitly designed to be resilient to those forms of manipulation rather than arise as an accessory feature of a larger social network. Moreover, participation technologies (digital and otherwise) should be seen as social goods and thus must employ greater levels of transparency and public oversight than for-profit products. An acceptable level of public control of software products is perhaps only attained by using open source tools and technologies.

This report introduces a platform for social participation named EJ (Empurrando Juntas) that aims to fill an specific niche in this universe. We present EJ both at technical level and contextualize it in a more conceptual and perhaps sociological discussion. Technical aspects are considered in sections 3 and 4, and technically oriented readers are invited to go there to understand the rationale behind the technology and the most important architectural decisions. The rest of the paper is dedicated to analyzing the role of the platform in promoting participation and the challenges we perceived to creating the networked democracy hinted in the first paragraph.

Platforms for social participation

Compared to more traditional processes for consultation and public debate, the Internet enables a much faster flow of information which helps making large scale decentralized organizations viable. Those features have certainly sparkled many initiatives towards building tools for a networked democracy that aims to bring prominence to the common citizen in shaping collective decisions. Those initiatives can usually be categorized in 4 broader areas (with many possible intersections): transparency 6 , petitions and public awareness 7 , debating 8 and deliberation 9 . We can also classify initiatives with regard to its relationship with the State, in which some take a decisively anti-government stance (e.g., Wikileaks 10 ), while others are directly conducted or sponsored by the State.

While we acknowledge that all of those areas are similarly important, we decided to focus our efforts on debating and consultation. We took this path out of the belief that the two major features of a platform for social participation should be the possibility of probing opinions and listening to novel inputs that users might add to the debate. The archetypal tools for handling each of those cases are the discussion forum and the poll. The first is useful to construct and refine positions and ideas in an unstructured fashion, in open dialogue; the second probes perceptions of the crowd from a predefined set of options.

Internet forums have (an often deserved) reputation for leading to toxic behaviors. Even when discounting for this possibility, participation in those environments demand users to invest time and knowledge, presenting a substantial barrier for engagement. There are of course many examples of groups of engaged and uniquely qualified individuals that produce rich discussions and communities, but we believe that the discussion forum model is severely limited when applicable to wide audiences.

If only a minority of interested users decide to participate, discussions may feature an unfair representation. This fragility undermines the political weight of those initiatives by making it easier to portray conclusions as instances of groupthink and undemocratic. Excluding the rare cases in which a hard consensus is obtained, it is hard to elicit opinions in a structured form. How then should the result of open discussions be used to support a collective decision?

While platforms for open ended discussion produce barriers to participation and engagement, polls suffer from the opposite problem: the cost of participation is very low, but more qualified users are unable to enrich the debate or introduce novel ideas even when willing to do so. Polling make it relatively easy to educe the preferences of the majority since data is created in a quantitative form. However, users might feel alienated from the decision making process if they perceive all options as unappealing or, worst yet, as being designed to fulfill some specific agenda.

Crowdsourcing

In order to bridge those two approaches, we believe that the design of collective deliberation must consider the pedagogical aspect of interaction. A good example of digital tools with accessible interfaces that take elements from both ends are the so called "crowdsourced discussion" architectures11 [START_REF] Brabham | Crowdsourcing the Public Participation Process for Planning Projects[END_REF][START_REF] Salganik | Wiki Surveys: Open and Quantifiable Social Data Collection[END_REF]. As a crude approximation, those platforms are based on a polling mechanism in which the list of alternatives can be continuously expanded with user interaction.

Participants of those platforms can control the energy dedicated to each discussion by switching from "voting" to "making new contributions" modes. Since users are constantly evaluating contributions from other users, it should be possible to automate data analysis to understand and identify different opinion profiles.

A good example of this kind of platform is the open source application Pol.is. In its current state, it provides a simple interaction in which administrators propose a theme for discussion and users can express their positions either by publishing a simple paragraph of text or by evaluating other user opinions. Pol.is then uses machine learning algorithms to identify affinity groups and present this information to all participants. While this is a promising approach, we believe that there are improvements to be made on how to use this information to promote some kind of effective collective action. We use Pol.is as the main inspiration of our approach, but add an additional layer of gamification in order to put some incentives for user to engage and create prolific debates and deliberation.

Social Networks

The enormous user base of social network websites (Facebook alone comprises almost a third of human population) guarantees a diverse audience. In spite of that, each user may experience very low diversity of ideas: algorithms that perform content selection end up placing users into "echo chambers" that recirculate a small set of ideas without challenging them with input from different social groups [START_REF] Pariser | The Filter Bubble: What The Internet Is Hiding From You[END_REF]. Diversity of viewpoints are rarely appreciated and debates tend to be contentious. This dynamics shifts the goal of political struggle from seeking democratic compromises and consensus to establishing (real or apparent) numeric majorities to subject the opposition to the rule of the crowd.

Those proprietary networks use their position as keepers of giant volumes of data to control the flow of information and influence user behaviours. One plausible response to those threats is to advocate for decentralization. This crucial aspect can be handled in many different ways, the most simple one is distribution of a software product as open source. This gives the possibility of users and organizations to manage their own deploys and set their own rules of governance.

Beyond that, some projects advocate for protocols and formats that enable different instances to communicate and share data in a federated fashion. Notable projects in this area include PeerTube12 and Mastodon 13 . More radical approaches like Tim Berners-Lee's Solid [START_REF] Sambra | Solid: A platform for decentralized social applications based on linked data[END_REF] and the Dat network [START_REF] Ogden | Dat-distributed dataset synchronization and versioning[END_REF] even calls for an overhaul of the Internet structure to favor local computation, granular access controls and P2P communication. It is conceivable those projects they might experience short term success, but it is unlikely to be in a scale that significantly changes the current panorama of social networks in spite of the very interesting technical achievements.

The role of the state in participation platforms

It seems to be a clear desire of governmental and civil society organizations to have tools for democratic dialogue and direct communication. There are many examples of governmental entities that sponsored initiative based on collective intelligence, but most of those experiences suffered from difficulties in scaling or generating the desired impact.

A notable experience took place in Brazil during the consultations for the Marco Civil da Internet (Brazil Rights Framework for the Internet), in which an existing Open Source Social Network developed in Brazil called Nosfero 14 was used. This lead to number of other public consultations using similar technologies for collective deliberation. State's collaboration with those open source communities to build shared digital goods preserves sovereignty, while ensuring that citizens have autonomy to develop civic technologies independent of a direct custody from a State actor.

Conception and architecture

EJ was conceived to work both as a standalone product and as an embedded component in some existing application. In both cases, we expect that most of our user base will access the platform using mobile devices since that number is growing worldwide and already accounts to most of web traffic, nowadays 15 . Mobile access implies that we have the opportunity to engage our users in a continuous manner, either by expecting constant availability, or by using more active approaches such as push notifications and web apps.

User experience

EJ organizes topics of discussion around "conversations". Each conversation is introduced with a single paragraph of text that should try to frame how users should contribute to the discussion, like in Fig. 1. Users are then able to insert comments associated with a conversation or vote if they agree or disagree with other user's propositions.

As users interact with some conversation (either proposing new comments or by voting on propositions), it gradually become possible to recognize the different opinion profiles. As soon as the platform is able to classify users into distinct opinion groups, it display results to all participants. That way, not only owners of each conversation can extract useful metrics to guide policy and decision making, but they can also justify their decisions from the shared information available on the platform. Moreover, each participant is able to access how their own opinions, or those from their network of peers and compare with the whole. We believe that this form of transparency towards information is an important factor to counteract the "echo chamber" effect of traditional social networks.

Only minimal personal information is requested from new users and none of it is exposed publicly like a social network. A potential threat of this model is that it provides little safeguards against bots and other malicious users since it lowers the barrier for creating new accounts. We decided not to tackle this difficult 14 http://noosfero.org/ 15 StatCounter, a firm specialized on web traffic analysis, shows worldwide mobile usage slightly above desktop at 52.98% vs 47.02% (http://gs.statcounter.com/platformmarket-share/desktop-mobile-tablet/worldwide). A more detailed account (https://www.stonetemple.com/mobile-vs-desktop-usage-study/) shows even large gaps depending on the selected metric (e.g., page views, unique users, time on site, etc). problem, but rather to make it possible to exclusively use external authentication via OAuth and rely on an identity provider trusted by deployment.

Machine learning

Machine learning enriches the platform in the detection of opinion groups and understanding how each user relates to each group. In Machine Learning jargon, detection of opinion groups is a non-supervised classification problem. We tried a few classical methods (K-means and SVM) with moderate success. More reliable outcomes are obtained when making allowance for prior information. Our approach to classification requires conversations to be created in association with some stereotypical opinion groups. Stereotypes are controlled by the conversation author and behave similarly to regular users when interacting with comments. Those users define their initial centroids in the clusterization algorithm and serve as labels that more reliably identify clusters across different classifications.

EJ encodes votes as +1 (agree), -1 (disagree) and 0 (skip). The set of user interactions is thus a vector of components in that range. In a typical situation, this data set comprises mostly of missing data entries, and requires a good imputation strategy. We used a mean-value based imputation for simplicity and computational efficiency and better results were obtained by using collaborative filtering [17], but at a significant efficiency cost.

Traditional K-means consists of 4 steps: 1) centroid initialization, 2) labeling elements to the closest centroid, 3) re-calculation of each centroid, and 4) go to 2 until convergence. Our modification uses stereotypes as the initial centroids in step 1) and forces that each stereotype will stay in its own cluster by never relabeling them in step 2). This simple modification not only is able to introduce some form of prior information, but has the positive side-effect of generating predictable labels for each run of the classification algorithm.

The default visualization display cluster sizes, similarities and diversity in a stylized manner. We also employ classic machine learning algorithms for dimension reduction aimed at other visualization options. For instance, a scatter plot of user inputs displays the opinion of each user together with the stereotypes. Our empirical evaluation selected principal component analysis (PCA) as opposed to more sophisticated alternatives such as t-SNE[9] or MDS [START_REF] Cox | Multidimensional scaling[END_REF] for its superior reliability and efficiency. PCA is a rotation based method, which preserves some intuitive geometric relationships between elements, making it more accessible to non-experts.

Web platform

As a web native platform, EJ subscribes to a few broad principles that guides all architectural decisions.

Progressive enhancement: Web applications are created using HTML, CSS and JavaScript. Progressive enhancement postulates that the website must be usable in its most basic HTML-only form and each new layer (CSS, JavaScript) should progressively enhance the user experience instead of being a hard requirement. Mobile first design: UX (user experience) and UI (user interaction) is designed primarily for mobile, and desktop experience is enhanced with CSS media queries. It also implies that the application should be usable from poor connections on underpowered devices. We prioritize small JavaScript size, since loading, parsing and executing implies non-trivial CPU costs which blocks the main application thread. Progressive web app: EJ only uses functionality available in the web platform. We developed it as Progressive Web App (PWA) in order to avoid the costs of a native implementation. PWAs blur the distinction of native mobile applications and web sites. Users can install an icon on their home screens and it spawns a background process that allows push notifications and offline interaction. Those are not intrusive technologies and we were able to develop most of the platform largely ignoring any specific needs for "PWAs". API as a product: Since we expect EJ to be easily embedded on user applications, the REST API is designed as an independent product and should be able to easily expose any information or interaction to third parties. The API also implements business logic regarding authentication and authorization policies in the platform.

Technology stack

EJ was initially conceived as fork of the open source project Pol.is 16 , which is based on Node.js and Clojure (for a in-house implementation of Machine Learning algorithms). This initial experience was afflicted with a bad deployment story and poor communication with Pol.is core development team. This lead to the decision of abandoning Pol.is and change the stack in favor of Python. EJ uses the Django Framework17 for web development and the Pydata stack (Numpy [START_REF] Van Der Walt | The NumPy Array: A Structure for Efficient Numerical Computation[END_REF], Pandas [START_REF] Mckinney | Data Structures for Statistical Computing in Python[END_REF], Scikit-Learn [START_REF] Pedregosa | Scikit-learn: Machine Learning in Python[END_REF]) for building the data analysis pipelines. On the frontend side, it uses Sass to manage CSS and adopts a somewhat traditional web architecture in which pages are rendered server-side rather than by the client. This approach is sometimes touted as ROCA 18 (Resource Oriented Client Architecture) to confront with the recent SPA (Single Page Application) architectural trend, and is perhaps nothing more than adoption of what used to be considered the best practices for web development a few years ago. Following the principles of ROCA, we used a library for unobtrusive JavaScript named Unpoly 19 and decided to avoid client-side frameworks completely.

By following the principle of progressive enhancement, it was possible to create a product that is accessible by many clients, ranging from command line web-browsers, web spiders, screen readers to the evergreen versions of major Browsers. While we expect most users to lie in the last category, progressive enhancement also benefit this audience by providing a workable (but degraded) website even when connection is poor and downloads fail.

Development and results

EJ is still in active development and has released only a single stable version. We do not have data about its real use performance. This section rather discuss how development was organized and which results were obtained.

Team

EJ has gone through two different development phases, each one carried by a different team. In the first phase, it was developed by HackLab/Sï¿oeo Paulo 20 , which is a socially oriented Startup that employs and develops free software technologies. This initial phase was focused on a product for the Perseu Abramo Foundation, which is a Brazilian think tank associated with the Partido dos Trabalhadores (Workers' Party, of ex-president Lula da Silva fame). In the second phase, development moved to the University, in which part of the original team was replaced by students. This report describes the second phase of development in which all authors took an active role and was a collaboration with the Federal Government to create a participation platform to teenagers via the National Secretary for the Rights of Children and Adolescents.

The team was divided roughly into 4 parts: design/UX, frontend, backend and operations. Since EJ was developed as a University project in a Software Engineering department, we took into account pedagogical outcomes when allocating team members. Every two weeks, students could then negotiate the allocation in each of the last 3 teams in which we encouraged a moderate level of rotation so everyone could experience different aspects of development (sometimes at expense of raw productivity).

Continuous delivery and deployment

Continuous deployment was an important part of the development culture in EJ. After some adjusting, we finally ended up organized our Git repository 21 into two main branches: a master branch which only receives tagged release commits and a development branch that is used to integrate contributions from all developers. Any commit in those branches that pass an automated test suite automatically trigger a deploy script pointing to some specific instance of the platform.

The system is also integrated with Codeclimate 22 , a static analysis tool that tracks the evolution of code quality metrics, test coverage and can alert to the introduction of defects and regressions. Since most development takes place in feature-specific branches, those warnings can prevent some defects from entering into the main development branch. A negative side effect of requiring manual merging of feature branches with explicit code review is that it burdens team members assigned to those tasks. We decided that changes deemed low risk (e.g., updates to translation strings, documentation, small CSS fixes or improvements to the test suite) should be developed directly into the development branch without any external review step before merging.

Generally speaking, productivity increases when good tools and automations are available [START_REF] Barry | How software process automation affects software evolution: a longitudinal empirical analysis[END_REF]. Since we made the initial decision of hosting the code on Github, the choice of tools was largely guided by the options that platform already provides (e.g., issue tracker, project management Kanban board) and have a good story of integration.

Since a large part of the development team is comprised of students with high rotation rate and considerable learning curve, we decided to avoid emphasizing too much the role of processes and culture and tried to rely heavily on automation. The objective is to gain better efficiency and shorter learning curve due to better tooling, at the same time we guarantee all contributions to the development process are crystallized in the form of code. Creation of automation scripts is thus treated as an important part of the development as is writing application code. This includes code responsible for deployment and testing, but also automation of everyday chores such as creating new environments, building assets and test databases, managing and executing Docker images, etc.

21 https://github.com/ejplatform/ej-server/ 22 https://codeclimate.com/

Conclusions

Building effective and constructive social participation mechanisms is a chief problem of contemporary democracies. Citizens are increasingly reporting a sense of misrepresentation and frustration with democracy worldwide, and the perceived efficacy of the government is diminishing [START_REF] Van Reybrouck | [END_REF]. Some scholars have pointed that this growing scepticism on the capacity of democracies to solve social issues may lead us to an unprecedented state of "a recession"[7], in the number of democracies in the world. All this in a time in which humanity faces unique and very pressing challenges in politics[8], economy [START_REF] Piketty | Capital in the twenty-first century[END_REF], environment preservation [START_REF] Masson-Delmotte | [END_REF], health, education and many others aspects of life.

Of course, none of those problems have simple solutions. We, as technologists, may offer tools that improve the collective capacity for finding answers to those dilemmas. This report introduces EJ, a simple system of participation that can be used to improve the dialogue between the government and autonomous organizations with the population. While the technology has not been adopted in any large deployment yet, we believe that it was built taking into consideration important aspects of collective participation.

Our two fundamental working hypothesis is that EJ is able to promote a higher level of engagement than existing platforms for social participation, and that its mechanisms to counteract polarization are effective for building civil dialogue and discussion. While engagement is easy to measure, polarization requires more indirect observation. Existence of clearly separated opinion groups is not necessarily an indication of polarization, but might rather stem from valid and rational disagreements between different perspectives. Nevertheless, it is still possible to probe some indirect effects of polarization. Polarized discussions arise from unfair and distorted perceptions about the other group's motivations and points of view and generally produces a mismatch in familiarity with basic facts about a subject and acceptance of fake and incorrect information.

EJ was built on the notion that socially relevant technologies should be created as common goods: making it free (as in freedom) for anyone to use, to study, and to adapt. This provides a good level of control and oversight and protects collectivity from vested interests from corporate owners of proprietary solutions.

Fig. 1 .

 1 Fig. 1. EJ user interface showing a conversation

https://newsroom.fb.com/company-info/

https://www.allourideas.org/

https://joinpeertube.org/

https://joinmastodon.org/

https://pol.is/

https://www.djangoproject.com/

https://roca-style.org

https://unpoly.com/

https://hacklab.com.br/

Acknowledgements

The authors would like to thank Funda à § ão Perseu Abramo and the former Ministry of Human Rights (now transformed into a secretary by the current Brazilian government) for recognizing the importance of direct social participation in shaping public policy and for financial support.


Yutaro Kashiwa
email: kashiwa.yutaro@g.wakayama-u.jp

Akinori Ihara
email: ihara@sys.wakayama-u.ac.jp

Masao Ohira

What Are the Perception Gaps between FLOSS Developers and SE Researchers? -A case of bug finding research

Keywords: Open Source Software, High Impact Bug, Interview

In recent years, many researchers in the SE community have been devoting considerable efforts to provide FLOSS developers with a means to quickly find and fix various kinds of bugs in FLOSS products such as security and performance bugs. However, it is not exactly sure how FLOSS developers think about bugs to be removed preferentially. Without a full understanding of FLOSS developers' perceptions of bug finding and fixing, researchers' efforts might remain far away from FLOSS developers' needs. In this study, we interview 322 notable GitHub developers about high impact bugs to understand FLOSS developers' needs for bug finding and fixing, and we manually inspect and classify developers' answers (bugs) by symptoms and root causes of bugs. As a result, we show that security and breakage bugs are highly crucial for FLOSS developers. We also identify what kinds of high impact bugs should be studied newly by the SE community to help FLOSS developers.

Introduction

The importance of FLOSS is increasing day by day, not only for personal use but also for enterprises to incorporate it into parts of their products. With the increase in the number of FLOSS users, use cases have also been expanding. As a result, lots of bugs are being reported to FLOSS projects. In the field of software engineering, many methods have been proposed to help FLOSS developers predict faults in modules, localize and repair faults in source code, and so on. However, these methods are too diverse for FLOSS developers to follow and effectively adapt to their projects as needed. Although several studies [START_REF] Shafiq | Automated Debugging and Bug Fixing Solutions: A Systematic Literature Review and Classification[END_REF] provided a systematic review to mitigate the difficulty in understanding existing methods, they are neither beyond grouping existing studies nor necessarily in line with FLOSS developers needs for support. Ideally speaking, we should try to thoroughly understand which bugs cause the most trouble for FLOSS developers and propose solutions to fix the bugs effectively and efficiently. In this study, we try to reveal the gap between the way that FLOSS developers and researchers perceive bug finding and fixing, through interviews with 322 notable GitHub developers. In the interviews, we do not directly ask the developers about what troubleshooting tools are highly in-demand, but instead we ask them about what kinds of bugs causes them severe troubles, in order to enable us to precisely understand the problems they face. After the interviews, we discuss what kinds of high impact bugs are able to be solved or not by existing studies, in order to provide researchers with insights to come up with new solutions. This work is separate from general bug categorizations, and to the best of our knowledge, our work is the first bug categorization focusing on only high impact bugs. In this paper, we address the following research questions;

RQ1: What kinds of high impact bugs are mainly considered high impact by FLOSS developers? RQ2: What kinds of high impact bugs do FLOSS developers encounter most frequently? RQ3: What kinds of high impact bugs should be studied newly by the SE community in order to support FLOSS developers?

Our contributions to the study are as follows;

-We revealed symptoms and causes of bugs considered high impact by FLOSS developers, through interviews and manual inspections of bug reports. -For FLOSS developers, we identified which kinds of high impact bugs are supported by previous studies. -For researchers, we showed the area where FLOSS developers' needs are still not fulfilled.

High Impact Bugs

Over the past two decades, the SE community have dedicated considerable efforts to help software developers to predict faults in modules, localize and repair faults in source code, and so on. Although the existing, traditional studies had not thoroughly considered the characteristics nor the impacts of bugs, in recent years they began to tackle with the impacts of bugs on users and the development process. In what follows, we introduce some existing studies on finding and fixing high impact bugs. A Security bug [START_REF] Gegick | Identifying security bug reports via text mining: An industrial case study[END_REF] can cause serious problems which often impacts on uses of software products directly. Since Internet devices (e.g., smartphones) usage is increasing every year, security issues of software products are of interest to many people. In general, security bugs are fixed as soon as possible.

A Performance bug [START_REF] Nistor | Discovering, reporting, and fixing performance bugs[END_REF] is defined as "programming errors that causes significant performance degradation." The performance degradation contains poor user experience, laggy application responsiveness, lower system throughput, and waste computational resources [START_REF] Molyneaux | The Art of Application Performance Testing: Help for Programmers and Quality Assurance[END_REF]. [START_REF] Nistor | Discovering, reporting, and fixing performance bugs[END_REF] showed that a performance bug needs more time to be fixed compared with a non-performance bug.

A Breakage bug [START_REF] Shihab | High-impact defects: A study of breakage and surprise defects[END_REF] is a type of functional bug which is introduced into a product when the source code is modified to add new features or to fix existing bugs. Though it is well-known as regression, a breakage bug mainly focuses on regression in functionalities. A breakage bug causes problems which make available functions in one version unusable after releasing newer versions.

A Blocking bug [START_REF] Garcia | Characterizing and Predicting Blocking Bugs in Open Source Projects Categories and Subject Descriptors[END_REF] is a bug that prevents other bugs from being fixed. It is often caused due to a dependency relationship among software components. Since a blocking bug inhibit developers from fixing other dependent bugs, it can highly impact on developers task scheduling since a blocking bug takes more time to be fixed [START_REF] Garcia | Characterizing and Predicting Blocking Bugs in Open Source Projects Categories and Subject Descriptors[END_REF] (i.e. a developer would need more time to fix a blocking bug and other developers need to wait for being fixed to resolve the dependent bugs).

A Surprise bug [START_REF] Shihab | High-impact defects: A study of breakage and surprise defects[END_REF] is a new concept of software bugs. It can disturb the workflow and/or task scheduling of developers since it appears at unexpected times (e.g., bugs detected in post-release) and locations (e.g., bugs found in files are rarely changed in pre-release). As a result of a case study of a proprietary, telephony system which has been developed for 30 years, [START_REF] Shihab | High-impact defects: A study of breakage and surprise defects[END_REF] showed that the co-changed files and the amount of time between the latest pre-release date and the release date can be good indicators of predicting surprise bugs.

A Dormant bug [START_REF] Chen | An empirical study of dormant bugs[END_REF] is also a new concept on software bugs and is defined as "a bug that was introduced in one version (e.g., Version 1.1) of a system, yet it is not reported until after the next immediate version (i.e., a bug is reported against Version 1.2 or later)." [START_REF] Chen | An empirical study of dormant bugs[END_REF] showed that 33% of the reported bugs in Apache Software Foundation projects were dormant bugs and were fixed faster than non-dormant bugs.

Study Design

Overview

In this study, we e-mail and ask notable developers in GitHub [9] to answer a questionnaire about high impact bugs. After aggregating collected responses, we show the developers' demographic information (Q1), and the distribution of the bugs that are considered high impact (Q2-1). As the questionnaire includes an open question (Q2-2) to tell us actual bug reports which caused troubles in the past, we manually inspect the bug reports and categorize them by symptoms.

Participant selection

In order to select notable developers to invite to our interview in this study, we use contribution which represents the amount of the developer's commit activity to GitHub repositories and can be calculated with GitHub API [10]. First, we make a list of all repositories in GitHub and calculate the total number of contributions for each repository. Note that we only calculate contributions for the most committed repositories if the repositories have the same name, since forked repositories partly (sometimes largely) include the same commits from original repositories and we need to avoid multiple counts for the same contributions by the same developer. Next, the total contributions of each developer is calculated based on the selected repositories above, and we choose candidates who mark over 100 contributions. Finally, we sent e-mails to 22,228 candidate developers to ask them to participate in our interview.

Questionnaire

We prepared Google Forms for our interview which consisted of three questions to know the developers demography (Q1), one closed question to reveal a distribution of high impact bugs considered important by developers (Q2-1), and one open question to collect and further analyze actual reports on high impact bugs (Q2-2). The questionnaire has six more questions, but in this paper, we only focus on the five questions above due to the space limitations.

Categorization of bug symptoms

Based on the responses of Q2-2, we collect actual bug reports from developers' projects and confirm the symptoms of the bugs, in order to discuss what techniques have been already proposed or that will be required to find and fix those high impact bugs. The first and second authors independently and manually inspect symptoms of actual high impact bugs and classify them by the card sort technique [START_REF] Nurmuliani | Using card sorting technique to classify requirements change[END_REF]. After the independent classification, the two authors discuss each classification result together and merge the results by mutual consent to make one classification. Here, the inspectors include one Ph.D. student (first author), who worked at a software company for two years as a full-time developer, and one professor who has been studying FLOSS development over ten years.

Interview and Classification Results

Developer demography (Q1)

As we described earlier, we invited 22,228 developers to join our interview. During the two weeks interview period, we got responses from 322 developers. Table 1 shows the product domains where the developers participated. We can see "web application" is the most popular domain (7%) but it does not stand out from the others. The product domains spread across a wide area. We can assume that the results of our interviews reflect a wide range of situations across FLOSS development. Table 2 shows the developers' experience with FLOSS development. The majority of the developers have over five years experiences. It is no surprise because we only invite active developers who have made at least over 100 commits to GitHub repositories. Table 3 shows developers' motivations to FLOSS development. 59% (126+64) of the developers contribute to FLOSS projects as part of work. 4.2 RQ1: What kinds of high impact bugs are mainly considered high impact by FLOSS developers?

In Q2-1, we asked the developers to select one of the six kinds of high impact bugs which are introduced in the previous section and have been well studied in the SE community. Table 4 shows the responses from the developers. We can see the FLOSS developers from GitHub attach greater importance on security bugs (53%) and breakage bugs (22%). It was unexpected for us that the other four bugs attract less attention from the FLOSS developers. It partly indicates the perception of gaps between researchers and FLOSS developers. Some researchers in the SE community might misunderstand FLOSS developers' actual needs. Researchers in the SE community have been studying to help developers find and fix bugs especially in terms of impacts on users' satisfaction and during the development process (release) [START_REF] Kashiwa | A pilot study of diversity in high impact bugs[END_REF]. Although high impact bugs have been studied individually so far, it was not clear if FLOSS developers are mostly concerned with particular high impact bugs. From the result of Q2-1, we now answer RQ1 as follows.

Answer to RQ1: Researchers have been dedicating to provide a means to find and fix a variety of high impact bugs, but FLOSS developers mainly emphasize a focus on security and breakage bugs. In Q2-2, we asked the developers to describe the high impact bugs they have encountered in the past. Many of the developers described characteristics of high impact bugs in the free text format and also gave us direct links to actual bug reports which present symptoms discussed among developers and users. Table 5 shows symptoms of bugs considered high impact by the respondents. In the table, we count multiple times if a developer described several high impact bugs. The percentage in the table is the ratio of developers' answers in each category, but the total percentage does not become 100% due to the above reason. As we described earlier, we manually inspected and categorized the information on high impact bugs by symptom. In what follows, we summarize the classification result.

We had 249 valid answers from 192 developers about symptoms of high impact bugs which actually get FLOSS developers in trouble in the past. In Table 5, the most common symptom was "unexpected processing" responded by 17% of developers (42 cases). As regards "unexpected processing", we could confirm less in common with bug reports. They ranged from different calculation results to unexpected rendering. The next most frequent was "sudden stop" responded by 16% of developers (39 cases). The corresponding bug reports shown by the developers suggested us that it often happened due to null exception, run-time error exception, segmentation error, and overflow. Although the above two are related to "Behavior" of a program, the third and fourth most common symptoms were "Security" concerns such as "vulnerability" and "unauthorized access." About "vulnerability," the corresponding bug reports suggested the developers especially concerned with XSS and SQL injection attacks. The OpenSSL problem (i.e., and the hidden way of leaking user data were included in bug reports about "unauthorized access."

In RQ1, 53% of developers think that security is the biggest concern among high impact bugs in the previous studies. However, the result in RQ2 shows that the developers come across high impact bugs about Behaviour more often than the one about security. In fact, one developer said, "Since the mentioned project is (mostly) a client-side javascript library, security problems aren't common." Based on the results here, we answer RQ2 as follows.

Answer to RQ2: FLOSS developers most frequently encounter bugs relating to behaviors such as unexpected behaviors and sudden stops. Security bugs such as vulnerabilities and unauthorized accesses are also often encountered.

4.4 RQ3: What kinds of high impact bugs should be studied newly by the SE community in order to support FLOSS developers?

The percentages in Table 5 are indicated by boldface if the corresponding symptoms account for about 80% of all the symptoms (i.e., the developers frequently encounter the symptoms with boldface.). For the majority of the symptoms, we surveyed existing studies which have tried to find and/or resolve the symptoms and showed references as "Ref" in Table 5.

The percentages of the symptoms in "Behavior" category are relatively high and these have been well-studied by the SE community [START_REF] Abate | Mining component repositories for installability issues[END_REF] [START_REF] Zhao | An empirical study of bugs in build process[END_REF]. For instance, "never start function" is well studied breakage bugs [START_REF] Shihab | High-impact defects: A study of breakage and surprise defects[END_REF] so-called regressions which disable existing functions due to additional changes to software products. Although in the paper we did not introduce this as a high impact bug, "unexpected processing" is well studied as a functionality bug or feature bug [START_REF] Tan | Bug characteristics in open source software[END_REF]. "disable start" and "sudden stop" are also studied as build bugs [START_REF] Zhao | An empirical study of bugs in build process[END_REF] and crash bugs [START_REF] An | An empirical study of crash-inducing commits in Mozilla Firefox[END_REF] respectively.

[2][5][25][26][27][30] [31][32][33][34]
As we confirmed "vulnerability" and "unauthorized access" achieved relatively high attention from the developers, security bugs are also considered high impact by researchers and have been well studied [START_REF] Gao | BovInspector: automatic inspection and repair of buffer overflow vulnerabilities[END_REF] [12] [START_REF] Mathis | Detecting information flow by mutating input data[END_REF][17] [START_REF] Near | Finding security bugs in web applications using a catalog of access control patterns[END_REF][29] [START_REF] Zaman | Security Versus Performance Bugs: A Case Study on Firefox[END_REF]. "Lower performance" in "Effect" category is also well studied [START_REF] Nguyen | An industrial case study of automatically identifying performance regression-causes[END_REF][21] [START_REF] Nistor | Discovering, reporting, and fixing performance bugs[END_REF][35] as performance bugs. However, to the best of our knowledge, there is no study on "data loss" in "Data" category which is of relatively high concern to FLOSS developers (5%). For instance, a bug on "data loss" in "Data" category is observed when deleting data related to the operation under a condition. Other data loss bugs occured due to executing the wrong processing of multi-transaction or by using variables not multi-threaded (e.g., HashMap in Java). In fact, for instance, loss of users' data such as their pictures was recently reported in the update of Windows 10 [3]. We regard it is one of the perception gaps between FLOSS developers and SE researchers and should be should be studied, allowing us to address the issue. Based on the results here, we answer RQ3 as follows.

Answer to RQ3: Existing studies can cover FLOSS developers' concerns about high impact bugs, but researchers still have space to further study other kinds of high impact bugs such as "data loss".

Discussions

5.1 Is the current support for high impact bugs enough? How can we help FLOSS developers fix bugs?

Many studies focus on symptoms of bugs and observe their characteristics and impacts [START_REF] Chen | An empirical study of dormant bugs[END_REF] of high impact bugs. In this section, similar to the classification of the symptoms, we classify causes of high impact bugs obtained in the answers from the interviews. With the classification of the causes, we discuss how we can support fixing the high impact bugs in each category.

Table 6 shows the causes of bugs considered high impact by the respondents. Here, we had 182 valid answers including the root causes of high impact bugs (from 142 developers ). In Table 6, the most common root cause was "insufficient processing" reported by 35% developers (49 cases). Furthermore, we broke down the 49 cases of "insufficient processing" and found that they consisted of 13 cases of "insufficient checks for inputs by users", nine cases of "insufficient checks against malicious inputs", five cases of "insufficient null checks such as arguments and return values", four cases of "insufficient authority checks" (e.g., database), and "others" (16 cases). The second and third most common root causes were "problem in 3rd party" and "change in 3rd party" respectively which relate to 3rd party libraries and systems.

Figure 1 depicts the relationship between symptoms and causes. The line width shows how symptoms and causes have strong relationships. For ease of reading graph, we only show the relationships that appeared more than twotimes (which account for 52% of all the relationship). For further information, we provide the data and the figures showing all the relationships on our online appendix [24]. Looking into the causes of "unexpected processing", the most frequent causes are "insufficient processing" (11 cases), and" problem in 3rd party" (5 cases), and "usage" (4 cases) are following. Furthermore, we investigated the detail of the bugs and found that nine of 11 cases were happened via regular usages and two cases were occurred by abnormal usage. These bugs should be found by unit test, or developers can utilize many studies (e.g, test case generation) to find them. "Sudden stop" is also caused by "insufficient processing" (11 cases). Eight of the 11 cases are caused by insufficient checks for inputs by users or by insufficient null checks, which are able to be applied by binary analysis [START_REF] Pham | Hercules: Reproducing crashes in real-world application binaries[END_REF].

The causes of both "disable start" and "never start function" are related on 3rd parties. The main causes of "disable start" are "changes in 3rd party".

We found two interesting answers indicating difficulty in finding the bugs are brought by "changes in 3rd party". One developer said, "It was just to update dependencies but finding bug was hard". Moreover, another developer said, "Because there are too many packages in the repository, nobody can keep an eye on all the packages". Even though developers roughly know that the causes of the bugs are caused by changes in 3rd parties, it is difficult to specify which changes by third party products created the bug. Although Ma [START_REF] Ma | How do developers fix cross-project correlated bugs? A case study on the GitHub scientific python ecosystem[END_REF] et al. investigated common practice to fix cross-project correlated bugs in the GitHub scientific Python ecosystem, there are no approaches to specify the root causes of cross-project bugs.

"Vulnerability" and "unauthorized access" are mostly caused by "insufficient processing" (6 cases each). Among the subcategories of insufficient processing, the most common causes are derived from insufficient checks against malicious inputs (3 cases each). Fuzzing techniques [START_REF] Jiang | ContractFuzzer: fuzzing smart contracts for vulnerability detection[END_REF][14] are able to be used to find the insufficient checks.

The cause of "data loss" is "insufficient processing", which can be broken down into three different cases: "insufficient checks for input by users", "insufficient checks against malicious inputs", and "others". Because of no similarities, we could not find any approaches to address "data loss" bugs, therefore it requires further work in the future.

Threats to Validity

Internal validity: The categorization of Table 5 and 6 may not be perfect. We have a good deal of knowledge about software, but we also recognize the limitations of our knowledge about specific domains. We also might bias in creating the category. External validity: Although the developer demography consists of developers working in a wide range of product domains, a judgment if a bug is high impact or not would depend on a product domain. Construct validity: To avoid bias in the developers responses, we asked them about high impact bugs without providing rigorous definitions of high impact bugs. Attitudes towards high impact bugs might be different among the developers.

Conclusion and Future Work

In this study, we interviewed 322 notable GitHub developers to reveal the perception gaps between FLOSS developers and researchers on bug finding and fixing. We manually inspected and classified actual bug reports which were presented and considered high impact by the developers. As a result, we concluded that security and breakage bugs are highly important for FLOSS developers. We also identified "data loss" bugs should be studied newly by the SE community to support FLOSS developers. Based on the bug report data presented by the developers in this study, we plan to investigate actual impacts of bugs on the size of source code change, resolution time, and so forth in the future.

[

Fig. 1 .

 1 Fig. 1. Relationships between symptoms (left axis) and causes (right axis)

  Please tell us high impact bug(s) you encountered in the past.

	Q1. Profile]
	Q1-1 Your main project
	Q1-2 Your experience with FLOSS development
	Q1-3 Your motivation to participate in FLOSS development
	[Q2. High impact bugs]
	Q2-1 What kind of bug would be much more important to be fixed?
	-a bug threatening systems security (Security bug)
	-a bug deteriorating systems performance (Performance bug)
	-a bug blocking other bug fixes (Blocking Bug)
	-a bug found in unexpected timing and location (Surprise bug)
	-a bug introduced in older releases and found in a newer releases (Dor-
	mant bug)
	-a bug introduced in a newer release and breaking functions of older
	releases (Breakage bug)
	-others [free text]
	Q2-2

Table 1 .

 1 Product domains where GitHub developers join (Q1-1)

	Domain	# %	Domain	# %	Domain	# %
	web application	22 7% database	9 3% machine learning	5 2%
	development tool	19 6% network server	9 3% UI		5 2%
	analysis	19 6% messaging tool	9 3% mobile app	5 2%
	language & compiler 17 5% education	8 2% desktop system	4 1%
	OS	15 5% simulator	7 2% mail		4 1%
	graphic	14 4% finance	7 2% browser	3 1%
	game	13 4% resource monitoring 7 2% others	37 11%
	programming tool	12 4% image editor	6 2% no answer	34 11%
	blog	11 3% network tool	6 2%
	embedded OS	9 3% security tool	6 2%	Total	322 100

Table 2 .

 2 Experience

		with
	FLOSS development (Q1-
	2)
	Experience	Developers
	more than five years	213
	three to five years	63
	one to three years	45
	less than one year	1

Table 3 .

 3 Motivation to participate in FLOSS development (Q1-3)

	Motivation Developers
	hobby	111
	work	126
	both	64
	other	21

Table 4 .

 4 A distribution of high impact bugs in Q2-1

	high impact bugs # %
	Security bug	171 53%
	Breakage bug	72 22%
	Performance bug 20 6%
	Blocking bug	16 5%
	Dormant bug	12 4%
	Surprise bug	7 2%
	others	24 7%

Table 5 .

 5 Symptoms described in actual bug reports

	Category	Subcategory	Description	# %	Ref
		disable start	Users cannot install, compile or start an application	19 8% [1][27][36]
		never start function	A function never start once a user clicks a button	21 8% [5][30][32][34]
		sudden stop	A program suddenly stops during running 39 16% [2][25][26][33]
	Behav-ior	unexpected processing	A program does not output or behave as developers expected	42 17% [31][32]
		never finishing state	A process never finish (e.g, hang up and infinite loop)	5 2%
		unable to login	Users cannot login a system	4 2%
		others	Lack of items in display, wrong warnings, lower user experiences etc.	3%
		lower performance	A program lowers performance (e.g, too large memory usage)	13 5% [20][21][22][35]
	Effect	damage other systems	A program damages other systems (e.g, OS cannot boot)	5 2%
		others	Making a disk full etc.	3 1%
		vulnerability	Security defects allow an attack to cause an abnormal behavior	22 9% [6][17][29]
	Secur-ity	unauthorized access	An impersonating account accesses to a server, service, or data	28 11% [12][16][19]
		DDoS	Massive accesses from multiple terminals make a service unable	7 3%
	Data	data loss incorrect data	A program deletes data in a product (e.g., user data and database breakage) A program produces incorrect or dupli-cated data	12 5% 1 0%
		architecture change	It forces developers to change a architec-ture or core program in a product	3 1%
	Devel-opment	reproduce	Developers cannot reproduce a reported bug	3 1%
		others	Blocking other bugs fixed etc.	4 2%
	Reput-	compatibility	Compatibility is broken (e.g, API, hard-ware and OS)	7 3%
	ation execution env.	A product can not guarantee an execution environment	3 1%
	4.3 RQ2: What kinds of high impact bugs do FLOSS developers
	encounter most frequently?

Table 6 .

 6 Root causes described in actual bug reports

	Category	Subcategory	Description	# %
		usage	A program usage unanticipated by developers (e.g., no net-work)	12 7%
	Design	architecture wrong processing	An architecture has an inappropriate algorithm etc. A program has incorrect processing	2 1% 10 5%
		superfluous processing A program have superfluous processing	3 2%
		insufficient processing A program needs another processing (e.g., null checks)	39 21%
		others	Incorrect encryption etc.	6 3%
		exception handling	A program throws a wrong Exception or cannot catch it 11 6%
		condition	A program has wrong conditions (e.g., for and if)	7 4%
		usage of variables	A program use wrong variables or data type	5 3%
	Imple-ment	method use	Developers incorrectly use methods in their product or 3rd party library	8 4%
		memory management A program cannot appropriately manage memory	9 5%
		others	Wrong implementation of async, data or race competition etc.	6 3%
		problem in 3rd party	A program is affected on a problem in 3rd party library or systems	21 12%
	Oper-ation and	changes in 3rd party execution env.	A program is affected on a change in 3rd party library or systems Developers did not check if a program can run on some OS or shells	13 7% 9 5%
	Mainte-	change effects	A change in the module affects on other modules	5 3%
	nance setting	Developers use a wrong setting (e.g, buffer size and database access authority)	5 3%
		others	Incorrect document, refactoring, or operation etc.	11 6%

Acknowledgment

We really appreciate the cooperation of developers in GitHub in completing our survey. This research is conducted as part of Grant-in-Aid for Japan Society for the Promotion of Science Research Fellow and Scientific Research (JP17J03330, JP17H00731, JP18K11243).