Tue 17 MayDisplayed time zone: Eastern Time (US & Canada) change
22:00 - 22:50 | Session 1Technical Papers / Registered Reports at MSR Main room - even hours Chair(s): Hongyu Zhang University of Newcastle, Masud Rahman Dalhousie University | ||
22:29 7mTalk | Recommending Code Improvements Based on Stack Overflow Answer Edits Registered Reports Pre-print |
Wed 18 MayDisplayed time zone: Eastern Time (US & Canada) change
03:00 - 03:50 | Session 2: Maintenance (Issues & Smells) Technical Papers / Registered Reports / Data and Tool Showcase Track / Industry Track at MSR Main room - odd hours Chair(s): Alessio Ferrari CNR-ISTI | ||
03:25 4mTalk | Towards Using Gameplay Videos for Detecting Issues in Video Games Registered Reports Emanuela Guglielmi University of Molise, Simone Scalabrino University of Molise, Gabriele Bavota Software Institute, USI Università della Svizzera italiana, Rocco Oliveto University of Molise Pre-print | ||
03:29 4mTalk | Is Surprisal in Issue Trackers Actionable? Registered Reports James Caddy University of Adelaide, Markus Wagner University of Adelaide, Australia, Christoph Treude University of Melbourne, Earl T. Barr University College London, UK, Miltiadis Allamanis Microsoft Research DOI Pre-print Media Attached |
05:00 - 05:50 | Session 3: Introspection, Vision, and Human Aspects Technical Papers / Data and Tool Showcase Track / Industry Track / Registered Reports at MSR Main room - odd hours Chair(s): Alexander Serebrenik Eindhoven University of Technology, Sebastian Baltes SAP SE & University of Adelaide | ||
05:29 4mTalk | Investigating the Impact of Forgetting in Software Development Registered Reports Utku Unal METU, Eray Tüzün Bilkent University, Tamer Gezici Bilkent University, Ausaf Ahmed Farooqui Bilkent University Pre-print |
Thu 19 MayDisplayed time zone: Eastern Time (US & Canada) change
04:00 - 04:50 | Session 9: Scaling & CloudIndustry Track / Registered Reports / Data and Tool Showcase Track / Technical Papers at MSR Main room - even hours Chair(s): Lwin Khin Shar Singapore Management University | ||
04:26 4mTalk | Toward Granular Automatic Unit Test Case Generation Registered Reports Fabiano Pecorelli Tampere University, Giovanni Grano LocalStack, Fabio Palomba University of Salerno, Harald C. Gall University of Zurich, Andrea De Lucia University of Salerno Pre-print |
05:00 - 05:50 | Session 10: SecurityTechnical Papers / Data and Tool Showcase Track / Registered Reports at MSR Main room - odd hours Chair(s): Triet Le The University of Adelaide | ||
05:30 4mTalk | CamBench - Cryptographic API Misuse Detection Tool Benchmark Suite Registered Reports Michael Schlichtig Heinz Nixdorf Institute at Paderborn University, Anna-Katharina Wickert TU Darmstadt, Germany, Stefan Krüger Independent Researcher, Eric Bodden University of Paderborn; Fraunhofer IEM, Mira Mezini TU Darmstadt Pre-print |
21:00 - 21:50 | Session 13: Security & QualityTechnical Papers / Data and Tool Showcase Track / Registered Reports / Industry Track at MSR Main room - odd hours Chair(s): Gias Uddin University of Calgary, Canada | ||
21:32 4mTalk | Evaluating few shot and Contrastive learning Methods for Code Clone Detection Registered Reports Mohamad Khajezade University of British Columbia, Fatemeh Hendijani Fard University of British Columbia, Mohamed S Shehata University of British Columbia Pre-print |
Fri 20 MayDisplayed time zone: Eastern Time (US & Canada) change
11:00 - 11:50 | Session 15: Collaboration & Open SourceRegistered Reports / Data and Tool Showcase Track / Technical Papers / Industry Track at MSR Main room - odd hours Chair(s): Massimiliano Di Penta University of Sannio, Italy, Fiorella Zampetti University of Sannio, Italy | ||
11:30 4mTalk | Towards Understanding Barriers and Mitigation Strategies of Software Engineers with Non-traditional Educational and Occupational Backgrounds Registered Reports Tavian Barnes University of Waterloo, Ken Jen Lee University of Waterloo, Cristina Tavares University of Waterloo, Gema Rodríguez-Pérez University of British Columbia (UBC), Mei Nagappan University of Waterloo Pre-print | ||
11:34 4mTalk | Can instability variations warn developers when open-source projects boost? Registered Reports Alejandro Valezate Rey Juan Carlos University, Rafael Capilla Universidad Rey Juan Carlos, Gregorio Robles Universidad Rey Juan Carlos, Victor Salamanca Rey Juan Carlos University Pre-print |
14:00 - 15:00 | Session 16: Non-functional Properties (Availability, Security, Legal Aspects)Industry Track / Technical Papers / Registered Reports / Data and Tool Showcase Track at MSR Main room - even hours Chair(s): Maxime Lamothe Polytechnique Montreal, Montreal, Canada, Jin L.C. Guo McGill University | ||
14:32 4mTalk | Is GitHub's Copilot as Bad As Humans at Introducing Vulnerabilities in Code? Registered Reports Owura Asare University of Waterloo, Mei Nagappan University of Waterloo, N. Asokan University of Waterloo Pre-print |
Tue 24 MayDisplayed time zone: Eastern Time (US & Canada) change
09:00 - 10:30 | Blended Technical Session 3 (Smells and Maintenance)Technical Papers / Mining Challenge / Registered Reports / Data and Tool Showcase Track at Room 315+316 Chair(s): Andy Zaidman Delft University of Technology | ||
10:01 8mTalk | CamBench - Cryptographic API Misuse Detection Tool Benchmark Suite Registered Reports Michael Schlichtig Heinz Nixdorf Institute at Paderborn University, Anna-Katharina Wickert TU Darmstadt, Germany, Stefan Krüger Independent Researcher, Eric Bodden University of Paderborn; Fraunhofer IEM, Mira Mezini TU Darmstadt Pre-print |
11:00 - 12:15 | Blended Technical Session 4 (Introspection, Vision, and Human Aspects)Technical Papers / Registered Reports / Data and Tool Showcase Track at Room 315+316 Chair(s): Ayushi Rastogi University of Groningen, The Netherlands | ||
11:46 8mTalk | Investigating the Impact of Forgetting in Software Development Registered Reports Utku Unal METU, Eray Tüzün Bilkent University, Tamer Gezici Bilkent University, Ausaf Ahmed Farooqui Bilkent University Pre-print |
Accepted Papers
Call for Registrations
Empirical Software Engineering Journal (EMSE), in conjunction with the conference on Mining Software Repositories (MSR), is continuing the RR track. The RR track of MSR 2022 has two goals: (1) to prevent HARKing (hypothesizing after the results are known) for empirical studies; (2) to provide early feedback to authors in their initial study design. For papers submitted to the RR track, methods and proposed analyses are reviewed prior to execution. Pre-registered studies follow a two-step process:
- Stage 1: A report is submitted that describes the planned study. The submitted report is evaluated by the reviewers of the RR track of MSR 2022. Authors of accepted pre-registered studies will be given the opportunity to present their work at MSR.
- Stage 2: Once a report has passed Phase 1, the study will be conducted and actual data collection and analysis take place. The results may also be negative! The full paper is submitted for review to EMSE.
Paper Types, Evaluation Criteria, and Acceptance Types
The RR track of MSR 2022 supports two types of papers:
Confirmatory: The researcher has a fixed hypothesis (or several fixed hypotheses) and the objective of the study is to find out whether the hypothesis is supported by the facts/data.
An example of a completed confirmatory study:
- Inozemtseva, L., & Holmes, R. (2014, May). Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th international conference on software engineering (pp. 435-445).
Exploratory: The researcher does not have a hypothesis (or has one that may change during the study). Often, the objective of such a study is to understand what is observed and answer questions such as WHY, HOW, WHAT, WHO, or WHEN. We include in this category registrations for which the researcher has an initial proposed solution for an automated approach (e.g., a new deep-learning-based defect prediction approach) that serves as a starting point for his/her exploration to reach an effective solution.
Examples of completed exploratory studies:
- Gousios, G., Pinzger, M., & Deursen, A. V. (2014, May). An exploratory study of the pull-based software development model. In Proceedings of the 36th International Conference on Software Engineering (pp. 345-355).
- Rodrigues, I. M., Aloise, D., Fernandes, E. R., & Dagenais, M. (2020, June). A Soft Alignment Model for Bug Deduplication. In Proceedings of the 17th International Conference on Mining Software Repositories (pp. 43-53).
The reviewers will evaluate RR track submissions based on the following criteria:
- The importance of the research question(s).
- The logic, rationale, and plausibility of the proposed hypotheses.
- The soundness and feasibility of the methodology and analysis pipeline (including statistical power analysis where appropriate).
- (For confirmatory study) Whether the clarity and degree of methodological detail is sufficient to exactly replicate the proposed experimental procedures and analysis pipeline.
- (For confirmatory study) Whether the authors have pre-specified sufficient outcome-neutral tests for ensuring that the results obtained can test the stated hypotheses, including positive controls and quality checks.
- (For exploratory study, if applicable) The description of the data set that is the base for exploration.
The outcome of the RR report review is one of the following:
- In-Principal Acceptance (IPA): The reviewers agree that the study is relevant, the outcome of the study (whether confirmation / rejection of hypothesis) is of interest to the community, the protocol for data collection is sound, and that the analysis methods are adequate. The authors can engage in the actual study for Stage 2. If the protocol is adhered to (or deviations are thoroughly justified), the study is published. Of course, this being a journal submission, a revision of the submitted manuscript may be necessary. Reviewers will especially evaluate how precisely the protocol of the accepted pre-registered report is followed, or whether deviations are justified.
- Continuity Acceptance (CA): The reviewers agree that the study is relevant, that the (initial) methods appear to be appropriate. However, for exploratory studies, implementation details and post-experiment analyses or discussion (e.g., why the proposed automated approach does not work) may require follow-up checks. We’ll try our best to get the original reviewers. All PC members will be invited on the condition that they agree to review papers in both, Stage 1 and Stage 2. Four (4) PC members will review the Stage 1 submission, and three (3) will review the Stage 2 submission.
- Rejection The reviewers do not agree on the relevance of the study or are not convinced that the study design is sufficiently mature. Comments are provided to the authors to improve the study design before starting it.
Note: For MSR 2022, a confirmatory study is granted only a IPA. Exploratory study in software engineering often cannot be adequately assessed until after the study has been completed and the findings are elaborated and discussed in a full paper. For example, consider a study in an RR proposing defect prediction using a new deep learning architecture. This work falls under the exploratory category. It is difficult to offer IPA, as we do not know whether it is any better than a traditional approach based on e.g., decision trees. Negative results are welcome; however, it is important that the negative results paper goes beyond presenting “we tried and failed”, but rather provide interesting insights to readers, e.g., why the results are negative or what that means for further studies on this topic (following criteria of REplication and Negative Results (RENE) tracks, e.g., https://saner2019.github.io/cfp/RENETrack.html). Furthermore, it is important to note that authors are required to document all deviations (if any) in a section of the paper.
Submission Process and Instructions
The timeline for MSR 2022 RR track will be as follows:
Feb 4: Authors submit their initial report. * Submissions must not exceed 6 pages (plus 1 additional page of references). The page limit is strict. Please register by Feb 2nd and then you can edit up until Feb 4th AoE.
*All authors should use the official “ACM Primary Article Template”, as can be obtained from the ACM Proceedings Template page. LaTeX users should use the sigconf option, as well as the review (to produce line numbers for easy reference by the reviewers). To that end, the following LaTeX code can be placed at the start of the LaTeX document:
\documentclass[sigconf,review]{acmart}
Mar 4: Authors receive PC members’ reviews.
Mar 18: Authors submit a response letter + revised report in a single PDF.
- The response letter should address reviewer comments and questions.
- The response letter + revised report must not exceed 12 pages (plus 1 additional page of references).
- The response letter does not need to follow ACM formatting instructions.
April 8: Notification of Stage 1
- (Outcome: in-principal acceptance, continuity acceptance, or rejection).
April 15: Authors submit their accepted RR report to arXiv
- To be checked by PC members for Stage 2
- Note: Due to the timeline, RR reports will not be published in the MSR 2022 proceedings.
Before Feb 3, 2023: Authors submit a full paper to EMSE. Instructions will be provided later. However, the following constraints will be enforced:
- Justifications need to be given to any change of authors. If the authors are added/removed or the author order is changed between the original Stage 1 and the EMSE submission, all authors will need to complete and sign a “Change of authorship request form”. The Editors in Chief of EMSE and chairs of the RR track reserve the right to deny author changes. If you anticipate any authorship changes please reach out to the chairs of the RR track as early as possible.
- PC members who reviewed an RR report in Stage 1 and their directly supervised students cannot be added as authors of the corresponding submission in Stage 2.
Submissions can be made via the submission site (https://msr2022-registered-report.hotcrp.com/) by the submission deadline. Any submission that does not comply with the aforementioned instructions and the mandatory information specified in the Author Guide is likely to be desk rejected. In addition, by submitting, the authors acknowledge that they are aware of and agree to be bound by the following policies:
- The ACM Policy and Procedures on Plagiarism and the IEEE Plagiarism FAQ. In particular, papers submitted to MSR 2022 must not have been published elsewhere and must not be under review or submitted for review elsewhere whilst under consideration for MSR 2022. Contravention of this concurrent submission policy will be deemed a serious breach of scientific ethics, and appropriate action will be taken in all such cases (including immediate rejection and reporting of the incident to ACM/IEEE). To check for double submission and plagiarism issues, the chairs reserve the right to (1) share the list of submissions with the PC Chairs of other conferences with overlapping review periods and (2) use external plagiarism detection software, under contract to the ACM or IEEE, to detect violations of these policies.
The authorship policy of the ACM and the authorship policy of the IEEE.
Author's Guide
NB: Please contact the MSR RR track chairs with any questions, feedback, or requests for clarification. Specific analysis approaches mentioned below are intended as examples, not mandatory components.
I. Title (required)
Provide the working title of your study. It may be the same title that you submit for publication of your final manuscript, but it is not mandatory
Example: Should your family travel with you on the enterprise? Subtitle (optional): Effect of accompanying families on the work habits of crew members
II. Authors (required)
At this stage, we believe that a single blind review is most productive
III. Structured Abstract (required)
The abstract should describe the following in 200 words or so:
-
Background/Context
What is your research about? Why are you doing this research, why is it interesting?
Example: “The enterprise is the flag ship of the federation, and it allows families to travel onboard. However, there are no studies that evaluate how this affects the crew members.”
-
Objective/Aim
What exactly are you studying/investigating/evaluating? What are the objects of the study? We welcome both confirmatory and exploratory types of studies.
Example (Confirmatory): We evaluate whether the frequency of sick days, the work effectiveness and efficiency differ between science officers who bring their family with them, compared to science officers who are serving without their family.
Example (Exploratory): We investigate the problem of frequent Holodeck use on interpersonal relationships with an ethnographic study using participant observation, in order to derive specific hypotheses about Holodeck usage.
-
Method How are you addressing your objective? What data sources are you using?
Example: We conduct an observational study and use a between subject design. To analyze the data, we use a t-test or Wilcoxon test, depending on the underlying distribution. Our data comes from computer monitoring of Enterprise crew members.
IV. Introduction
Give more details on the bigger picture of your study and how it contributes to this bigger picture. An important component of phase 1 review is assessing the importance and relevance of the study questions, so be sure to explain this.
V. Hypotheses (required for confirmatory study) or research questions
Clearly state the research hypotheses that you want to test with your study, and a rationalization for the hypotheses.
Hypothesis: Science officers with their family on board have more sick days than science officers without their family
Rationale: Since toddlers are often sick, we can expect that crew members with their family onboard need to take sick days more often.
VI. Variables (required for confirmatory study)
- Independent Variable(s) and their operationalization
- Dependent Variable(s) and their operationalization (e.g., time to solve a specified task)
- Confounding Variable(s) and how their effect will be controlled (e.g., species type (Vulcan, Human, Tribble) might be a confounding factor; we control for it by separating our sample additionally into Human/Non-Human and using an ANOVA (normal distribution) or Friedman (non-normal distribution) to distill its effect).
For each variable, you should give: - name (e.g., presence of family) - abbreviation (if you intend to use one) - description (whether the family of the crew members travels on board) - scale type (nominal: either the family is present or not) - operationalization (crew members without family on board vs. crew members with family onboard)
VII. Participants/Subjects/Datasets (required)
Describe how and why you select the sample. When you conduct a meta analysis, describe the primary studies / work on which you base your meta analysis.
Example: We recruit crew members from the science department on a voluntary basis. They are our targeted population.
VIII. Execution Plan (required)
Describe the experimental setting and procedure. This includes the methods/tools that you plan to use (be specific on whether you developed it (and how) or whether it is already defined), and the concrete steps that you plan to take to support/reject the hypotheses or answer the research questions.
Example: Each crew member needs to sign the informed consent and agreement to process their data according to GDPR. Then, we conduct the interviews. Afterwards, participants need to complete the simulated task …
Examples:
Confirmatory:
https://osf.io/5fptj/ - Do Explicit Review Strategies Improve Code Review Performance?
Exploratory:
https://osf.io/kfu9t - The Impact of Dynamics of Collaborative Software Engineering on Introverts: A Study Protocol
https://osf.io/acnwk - Large-Scale Manual Validation of Bugfixing Changes