Write a Blog >>
MSR 2021
Mon 17 - Wed 19 May 2021
co-located with ICSE 2021

The International Conference on Mining Software Repositories (MSR) has hosted a mining challenge since 2006. With this challenge, we call upon everyone interested to apply their tools to a common dataset. The challenge is for researchers and practitioners to bravely use their mining tools and approaches on a dare.

Dates
Mon 17 May 2021
Wed 19 May 2021
Tracks
MSR Awards
MSR Data Showcase
MSR FOSS Award
MSR Hackathon
MSR Keynotes
MSR MIP Award
MSR Mining Challenge
MSR Registered Reports
MSR Shadow PC
MSR Technical Papers
MSR Tutorials
MSR content
You're viewing the program in a time zone which is different from your device's time zone change time zone

Mon 17 May

Displayed time zone: Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna change

17:00 - 17:50
Mining Challenge SessionMining Challenge / Technical Papers at MSR Room 1
Chair(s): Miltiadis Allamanis Microsoft Research, UK, Rafael-Michael Karampatsis The University of Edinburgh, Charles Sutton Google Research
17:01
2m
Welcome by the Mining Challenge Co-chairs
Mining Challenge
Miltiadis Allamanis Microsoft Research, UK, Rafael-Michael Karampatsis The University of Edinburgh, Charles Sutton Google Research
17:03
3m
Talk
A large-scale study on human-cloned changes for automated program repair
Mining Challenge
Fernanda Madeiral KTH Royal Institute of Technology, Thomas Durieux KTH Royal Institute of Technology, Sweden
Link to publication Pre-print
17:06
3m
Talk
Applying CodeBERT for Automated Program Repair of Java Simple Bugs
Mining Challenge
Ehsan Mashhadi University of Calgary, Hadi Hemmati University of Calgary
Pre-print Media Attached
17:09
3m
Talk
PySStuBs: Characterizing Single-Statement Bugs in Popular Open-Source Python Projects
Mining Challenge
Arthur Veloso Kamienski University of Alberta, Luisa Palechor University of Alberta, Abram Hindle University of Alberta, Cor-Paul Bezemer University of Alberta
Pre-print
17:12
3m
Talk
How Effective is Continuous Integration in Indicating Single-Statement Bugs?
Mining Challenge
Jasmine Latendresse Concordia University, Rabe Abdalkareem Queens University, Kingston, Canada, Diego Elias Costa Concordia University, Canada, Emad Shihab Concordia University
Pre-print
17:15
3m
Talk
Mea culpa: How developers fix their own simple bugs differently from other developers
Mining Challenge
Wenhan Zhu University of Waterloo, Michael W. Godfrey University of Waterloo, Canada
Pre-print
17:18
3m
Talk
On the Distribution of "Simple Stupid Bugs" in Unit Test Files: An Exploratory Study
Mining Challenge
Anthony Peruma Rochester Institute of Technology, Christian D. Newman Rochester Institute of Technology
Pre-print Media Attached
17:21
3m
Talk
On the Rise and Fall of Simple Stupid Bugs: a Life-Cycle Analysis of SStuBs
Mining Challenge
Balázs Mosolygó University of Szeged, Norbert Vándor University of Szeged, Gabor Antal University of Szeged, Peter Hegedus University of Szeged
Pre-print
17:24
3m
Talk
On the Effectiveness of Deep Vulnerability Detectors to Simple Stupid Bug Detection
Mining Challenge
Jiayi Hua Beijing University of Posts and Telecommunications, Haoyu Wang Beijing University of Posts and Telecommunications
Pre-print

Wed 19 May

Displayed time zone: Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna change

02:00 - 02:50
02:05
3m
Talk
On the Effectiveness of Deep Vulnerability Detectors to Simple Stupid Bug Detection
Mining Challenge
Jiayi Hua Beijing University of Posts and Telecommunications, Haoyu Wang Beijing University of Posts and Telecommunications
Pre-print

Call for Mining Challenge Papers

This year, the mining challenge is about ManySStuBs4J, a dataset of fixes to Java simple bugs. The dataset focuses on “SStuBs“, i.e., simple stupid bugs. SStuBs are bugs that appear on a single statement and the corresponding fix is within that statement.

The dataset was collected to facilitate the study of such bugs towards addressing empirical questions about these bugs and related program repair techniques. The included fixes are classified — where possible — into one of 16 syntactic templates, such as accidentally swapped method arguments, incorrect operator usage, or wrong variable usage. For each bug in the challenge dataset, we include the provenance of the bug (GitHub project, commit SHA), the diff between the buggy and fixed version of the files, and an annotation of which (if any) of the 16 SStuBs patterns it matches.

In this challenge, participants can use two variants of the dataset. A small version of the dataset that contains 25,539 SStuBs changes mined from 100 Java projects in GitHub that use Maven. These projects can be built and tested (if they contain tests) in an automated fashion. The large version of the data set contains 153,652 SStuBs mined from 1,000 popular open-source Java projects in GitHub, but not all of these projects use Maven, so it may not be feasible to build and test them.

The challenge is open-ended: participants can choose the research questions that they find most interesting. Our suggestions include:

  • Bug detection: What methods are most effective for locating SStuBs?
  • Program repair: What methods are most effective for proposing repairs to SStuBs? This could be a separate step or combined.
  • Why SStubS occur: What context do SStuBs appear in? What are common root causes? Are there characteristics of the software project, the development team, or the individual source file that make SStuBs more likely to appear?
  • What encourages fixing SStuBs: What factors characterize SStuBs that are more quickly found and fixed?
  • Testing: How is testing related to SStuBs? Do projects with more or better unit tests have fewer or easier-to-fix SStuBs?

These are just some of the questions that could be answered using the ManySStuBs4J dataset. Participants may combine the SStuBs data with other code or metadata: for example, data about project popularity or contributor experience. We will not provide such data, but participants are encouraged to “bring their own data” (BYOD) by joining SStuBs data with data from other public, readily available, sources such as GHTorrent or GitHub. We ask the participants to carefully consider any ethical implications that stem from using other sources of data, such as the use of personally identifiable information.

How to Participate in the Challenge

First, familiarize yourself with the ManySStuBs4J dataset:

  • Read the MSR 2020 paper about ManySStuBs4J.
  • Study the download page of ManySStuBs4J, which includes the most recent version and links to download the dataset as well as the documentation page.
  • Create a new issue here in case you have problems with the dataset or want to suggest ideas for improvements.

Finally, use the dataset to answer your research questions, report your findings in a four-page challenge paper (see information below), submit your abstract before January 19, 2021, and your final paper before January 26, 2021. If your paper is accepted, present your results at MSR 2021 in Madrid, Spain!

Join us on Slack for informal discussions among participants at http://msr2021challenge.slack.com/

Submission

A challenge paper should describe the results of your work by providing an introduction to the problem you address and why it is worth studying, the version of the dataset you used, the approach and tools you used, your results and their implications, and conclusions. Make sure your report highlights the contributions and the importance of your work. See also our open science policy regarding the publication of software and additional data you used for the challenge.

Challenge papers must not exceed 4 pages plus 1 additional page only with references and must conform to the MSR 2021 format and submission guidelines. Each submission will be reviewed by at least three members of the program committee. Submissions should follow the IEEE Conference Proceedings Formatting Guidelines, with title in 24pt font and full text in 10pt type. LaTEX users must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf option.

IMPORTANT: The mining challenge track of MSR 2021 follows the double-blind submission model. Submissions should not reveal the identity of the authors in any way. This means that authors should:

  • leave out author names and affiliations from the body and metadata of the submitted pdf
  • ensure that any citations to related work by themselves are written in the third person, for example “the prior work of XYZ” as opposed to “our prior work [2]”
  • not refer to their personal, lab or university website; similarly, care should be taken with personal accounts on GitHub, BitBucket, Google Drive, etc.
  • not upload unblinded versions of their paper on archival websites during bidding/reviewing, however uploading unblinded versions prior to submission is allowed and sometimes unavoidable (e.g., thesis)

Authors having further questions on double blind reviewing are encouraged to contact the Mining Challenge Chairs via email.

Papers must be submitted electronically through HotCRP, should not have been published elsewhere, and should not be under review or submitted for review elsewhere for the duration of consideration. ACM plagiarism policy and procedures shall be followed for cases of double submission. The submission must also comply with the IEEE Policy on Authorship.

Upon notification of acceptance, all authors of accepted papers will be asked to complete a copyright form and will receive further instructions for preparing their camera ready versions. At least one author of each accepted paper is expected to register and present the results at MSR 2021. All accepted contributions will be published in the electronic conference proceedings.

This year’s mining challenge can be cited as:

title={MSR Mining Challenge: The Life of Simple, Stupid Bugs (SStubS)},
author={Karampatsis, Rafael-Michael and Allamanis, Miltiadis and Sutton, Charles},
year={2021},
booktitle={Proceedings of the International Conference on Mining Software Repositories (MSR 2021)},
}

The dataset itself can be cited as:

@inproceedings{sstubs,
title={How Often Do Single-Statement Bugs Occur? The ManySStuBs4J Dataset},
author={Karampatsis, Rafael-Michael and Sutton, Charles},
year={2020},
booktitle={Proceedings of the International Conference on Mining Software Repositories (MSR 2020)},
preprint={https://arxiv.org/abs/1905.13334}
}

Open Science Policy

Openness in science is key to fostering progress via transparency, reproducibility and replicability. Our steering principle is that all research output should be accessible to the public and that empirical studies should be reproducible. In particular, we actively support the adoption of open data and open source principles. To increase reproducibility and replicability, we encourage all contributing authors to disclose:

  • the source code of the software they used to retrieve and analyze the data
  • the (anonymized and curated) empirical data they retrieved in addition to the SOTorrent dataset
  • a document with instructions for other researchers describing how to reproduce or replicate the results

Already upon submission, authors can privately share their anonymized data and software on archives such as Zenodo or Figshare (tutorial available here). Zenodo accepts up to 50GB per dataset (more upon request). There is no need to use Dropbox or Google Drive. After acceptance, data and software should be made public so that they receive a DOI and become citable. Zenodo and Figshare accounts can easily be linked with GitHub repositories to automatically archive software releases. In the unlikely case that authors need to upload terabytes of data, Archive.org may be used.

We recognise that anonymising artifacts such as source code is more difficult than preserving anonymity in a paper. We ask authors to take a best effort approach to not reveal their identities. We will also ask reviewers to avoid trying to identify authors by looking at commit histories and other such information that is not easily anonymised. Authors wanting to share GitHub repositories may want to look into using https://anonymous.4open.science/ which is an open source tool that helps you to quickly double-blind your repository.

We encourage authors to self-archive pre- and postprints of their papers in open, preserved repositories such as arXiv.org. This is legal and allowed by all major publishers including ACM and IEEE and it lets anybody in the world reach your paper. Note that you are usually not allowed to self-archive the PDF of the published article (that is, the publisher proof or the Digital Library version).

Please note that the success of the open science initiative depends on the willingness (and possibilities) of authors to disclose their data and that all submissions will undergo the same review process independent of whether or not they disclose their analysis code or data. We encourage authors who cannot disclose industrial or otherwise non-public data, for instance due to non-disclosure agreements, to provide an explicit (short) statement in the paper.

Best Mining Challenge Paper Award

As mentioned above, all submissions will undergo the same review process independent of whether or not they disclose their analysis code or data. However, only accepted papers for which code and data are available on preserved archives, as described in the open science policy, will be considered by the program committee for the best mining challenge paper award.

Best Student Presentation Award

Like in the previous years, there will be a public voting during the conference to select the best mining challenge presentation. This award often goes to authors of compelling work who present an engaging story to the audience. Only students can compete for this award.

One of the secret ingredients behind the success of the International Conference on Mining Software Repositories (MSR) is its annual Mining Challenge, in which MSR participants can showcase their techniques, tools and creativity on a common data set. In true MSR fashion, this data set is a “real” data set contributed by researchers in the community, solicited through an open call. There are many benefits of sharing a data set for the MSR Mining Challenge. The selected challenge proposal explaining the data set will appear in the MSR 2021 proceedings, and the challenge papers using the data set will be required to cite the challenge proposal or an existing paper of the researchers about the selected data set. Furthermore, the authors of the data set will become the official 2021 Mining Challenge Chairs, responsible for the reviewing process (e.g., composing a Challenge PC, managing the submissions and review assignments, etc.). Finally, it is not uncommon for challenge data sets to feature in MSR and other publications well after the conference is finished! If you would like to compete for a chance to have your data set featured in the 2021 MSR Mining Challenge and all the benefits that come with it, please submit a 1-page proposal with up to 3 pages of appendix at https://msr2021.hotcrp.com/, containing the following information:

  1. Title of data set.
  2. What does your data set contain?
  3. How large is it?
  4. How accessible is it and how can the data be obtained?
  5. How representative is it?
  6. Does it require specialized tools to mine it?
  7. What would challenge participants need to work with the data set?
  8. What kind of questions do you expect challenge participants to answer?
  9. A link to a small sample of the data (e.g., via dropbox, github, etc.).

The above conform to the IEEE formatting instructions IEEE Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt type, LaTeX users must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf options). For more information see here: https://www.ieee.org/conferences/publishing/templates.html Once the winning proposal will be selected, its authors will become the MSR 2021 Challenge Chairs and will be responsible for choosing the MSR 2021 Mining Challenge program committee. The major deadline for this is the 15th of September 2020, at which time the Challenge CFP along with the PC will be announced, and the full challenge data set will be publicly released. By making the challenge data set available by early fall, we hope that many student teams will be able to use the challenge data set for their graduate class projects.

Timeline:

  • Deadline for proposals: August 14th, 2020
  • Proposal accepted and all submitters notified: August 21st, 2020
  • Challenge CFP: September 16th, 2020
  • Challenge PC formed: September 16th, 2020
  • Challenge data made available: September 14th, 2020
  • Challenge papers deadline: Feb 19th, 2021 (tentative)
:
: