Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
3,363
datasets available to search
ShareScore release 0.7.1
Dataset results
3,363 results for “Replication”
Replication package for "Wikifying Software Artifacts"
<p>This replication package contains all data files necessary to verify and replicate our findings presented in the manuscript "Wikifying Software Artifacts".</p>
Replication Data for: Continuously moving table MRI with golden angle radial sampling
<p>Continuously moving table (CMT) MRI is a high throughput technique that has multiple applications in whole-body imaging. In this work, CMT MRI based on golden angle (GA, 111.246° azimuthal step) radial sampling is developed at 3 Tesla (T), with the goal of increased flexibility in image reconstruction using arbitrary profile groupings.</p>
SURF: Replication Package for: "What Would Users Change in My App? Summarizing App Reviews for Recommending Software Changes"
<p>Description of the content of folder "SURF_replication_package": 1) "Experiment I" contains: a) the folder "summaries" which contains all the html summaries generated through SURF and browsed by study participants involved in the Experiment I. b) the folder "XMLreviews" which contains, for each of the apps involved in the Experiment I, the corresponding XML file containing all the collected reviews for that app. These xml files have been used as input files for the SURF tool for generating the summaries contained in the "summaries" folder c) "Experiment_I_results.xlsx" which contains all the answers to our survey collected from the Experiment I participants.</p> <p>2) "Experiment II" contains: a) the folder "summaries" which contains the two html summaries generated through SURF and browsed by study participants in the Experiment II. b) the folder "XMLreviews" which contains, for each of the two apps involved in the Experiment II, the corresponding XML file containing all the collected reviews for that app. These xml files have been used as input of the SURF tool for generating the summaries contained in the "summaries" folder. c) "Experiment_II_results.xlsx" which contains all the user feedbacks extracted/validated by survey participants in the two sub-experiments. d) "Experiment_II_survey_answers.xlsx" which contains all the answers to our survey collected in the Experiment II participants.</p> <p>3) "Survey.pdf" which contains the pdf version of the survey performed by the participants</p> <p>4) "SURF_tool.zip" contains: a) "SURF.jar", which contains the class files of a prototypical implementation of SURF b) "README.txt" which contains the instructions to run the SURF tool c) the "lib" folder, which contains all the java libraries needed for running SURF.</p>
Anthropoid morphometric and phylogenetic data, with R replication code.
<p>This repository contains four files: 1) a NEXUS phylogeny of 100 anthropoid primates; 2) a CSV text file of anthropoid primate lower molar areas, body mass, and primary dietary category; 3) a CSV text file of modern human lower molar area proportions; and, 4) an R script containing replication code for fitting Bayesian phylogenetic generalized linear mixed models to the morphometric data. These files are associated with the paper "The Evolution of Anthropoid Molar Proportions" in BMC Evolutionary Biology (2016).</p>
Can Developers Prompt? A Controlled Experiment for Code Documentation Generation [Replication Package]
<h2>Artifact Summary</h2> <p>This repository contains the replication package for the paper 'Can Developers Prompt? A Controlled Experiment for Code Documentation Generation,' presented at the <em><a href="https://conf.researchr.org/home/icsme-2024" target="_blank" rel="noopener">40th IEEE International Conference on Software Maintenance and Evolution (ICSME'24)</a></em>.</p> <p>The purpose of the package is to facilitate the verification and reproduction of the study results. It provides all data of the controlled experiment, the developed <em>Visual Studio Code (VS Code)</em> extension, as well as the slides of the conference presentations.</p> <h2>Paper Abstract</h2> <p>Large language models (LLMs) bear great potential for automating tedious development tasks such as creating and maintaining code documentation. However, it is unclear to what extent developers can effectively prompt LLMs to create concise and useful documentation. We report on a controlled experiment with 20 professionals and 30 computer science students tasked with code documentation generation for two Python functions. The experimental group freely entered ad-hoc prompts in a ChatGPT-like extension of Visual Studio Code, while the control group executed a predefined few-shot prompt. Our results reveal that professionals and students were unaware of or unable to apply prompt engineering techniques. Especially students perceived the documentation produced from ad-hoc prompts as significantly less readable, less concise, and less helpful than documentation from prepared prompts. Some professionals produced higher quality documentation by just including the keyword Docstring in their ad-hoc prompts. While students desired more support in formulating prompts, professionals appreciated the flexibility of ad-hoc prompting. Participants in both groups rarely assessed the output as perfect. Instead, they understood the tools as support to iteratively refine the documentation. Further research is needed to understand which prompting skills and preferences developers have and which support they need for certain tasks.</p> <h2>References</h2> <p>The published paper is available on <a href="https://doi.org/10.1109/ICSME58944.2024.00058" target="_blank" rel="noopener">IEEE Xplore</a> and the preprint on <a href="https://doi.org/10.48550/arXiv.2408.00686" target="_blank" rel="noopener">arXiv</a>.</p>
An Exploratory Study of Documentation Strategies for Product Features in Popular GitHub Projects [Replication Package]
<h2>Artefact Summary</h2> <p>This repository contains the replication package for the paper 'An Exploratory Study of Documentation Strategies for Product Features in Popular GitHub Projects,' presented at the <em><a href="https://cyprusconferences.org/icsme2022/" target="_blank" rel="noopener">38th IEEE International Conference on Software Maintenance and Evolution (ICSME'22)</a></em>.</p> <p>The purpose of the package is to facilitate the verification and reproduction of the study results.<br>It provides all computational notebooks used to collect and analyse data, as well as the slides of the conference presentation.</p> <h2>Paper Abstract</h2> <p>[Background] In large open-source software projects, development knowledge is often fragmented across multiple artefacts and contributors such that individual stakeholders are generally unaware of the full breadth of the product features. However, users want to know what the software is capable of, while contributors need to know where to fix, update, and add features. [Objective] This work aims at understanding how feature knowledge is documented in GitHub projects and how it is linked (if at all) to the source code. [Method] We conducted an in-depth qualitative exploratory content analysis of 25 popular GitHub repositories that provided the documentation artefacts recommended by GitHub’s Community Standards indicator. We extracted strategies used to document software features in textual artefacts and which strategies were used to link the feature documentation with source code. [Results] We observed feature documentation in all studied projects in artefacts such as READMEs, wikis, and website resource files. However, the features were often described in an unstructured way. Additionally, tracing techniques to connect feature documentation and source code were rarely used. [Conclusions] Our results suggest a lacking (or a low-prioritised) feature documentation in open-source projects, little use of normalised structures, and a rare explicit referencing to source code. As a result, product feature traceability is likely to be very limited, and maintainability to suffer over time.</p> <h2>References</h2> <p>The published paper is available on <a href="https://doi.org/10.1109/ICSME55016.2022.00043" target="_blank" rel="noopener">IEEE Xplore</a> and the preprint on <a href="https://doi.org/10.48550/arXiv.2208.01317" target="_blank" rel="noopener">arXiv</a>.</p>
Replication Package for "Compatibility Issues in Deep Learning Systems: Problems and Opportunities"
<p>This dataset contains scripts and data used to generate relevant results for this paper. Detailed information and procedure to reproduce our results are described in README.md. </p> <p>code</p> <p>This folder contains two Python scripts: soextractor.py is used to extract 3,072 high-quality StackOverflow (SO) posts and soextractor_tags.py is used to extract the number of posts for the tags on SO. For detailed data collection criteria, please refer to Section 3.1 of our paper.</p> <p>DL compatibility issues.xlsx</p> <p>This file provides all the collected 3,072 issues, in which each line indicates whether the issue is a DL compatibility issue. Among them, 352 are DL compatibility issues. We also provide information on the library, stage, symptom, type, solution, root cause, and exception type for the DL compatibility issues. For the type CORE-TPL, we also provide backward-incompatible or forward-incompatible as well as API evolution patterns. For detailed manual classification of DL compatibility issues, please refer to Section 3.2 of our paper.</p> <p>Tool Survey.xlsx </p> <p>This file includes all the papers collected from the three top SE conferences (i.e., ICSE, FSE, and ASE) in recent five years (18-22). Each line of each sheet provides the following information: (a) Title, (b) Year, (c) Conference, and (d) Type. For the detailed paper collection procedure, please refer to Section 5 of our paper.</p>
PRIMPOL ensures robust handoff between on-the-fly and post-replicative DNA lesion bypass.
<p><strong>Supplementary Table 6. CRISPR screen raw sgRNA counts.</strong></p><p>Excel sheet 'Mellor et al Table S6_sgRNA_count.xlsx'.</p><p>Output of the MAGeCK count command aligning Illumina sequencing reads to the sgRNA sequences within the Human Improved Genome-wide Knockout CRISPR library, following CRISPR/Cas9 screens in WT and <i>primpol</i> TK6 cells.</p><p> </p><p><strong>Supplementary Table 7. CRISPR screen untreated summary.</strong></p><p>Excel sheet 'Mellor et al Table S7_untreated_summary.xlsx'.</p><p>Output of the MAGeCK test command comparing sgRNA abundance between the sequencing libraries produced following a CRISPR/Cas9 knockout screen in WT versus <i>primpol</i> TK6 cells in untreated conditions.</p><p> </p><p><strong>Supplementary Table 8. CRISPR screen cisplatin treated summary.</strong></p><p>Excel sheet 'Mellor et al Table S8_cddp_treated_summary.xlsx'.</p><p>Output of the MAGeCK test command comparing sgRNA abundance between the sequencing libraries produced following a CRISPR/Cas9 knockout screen in WT versus <i>primpol</i> TK6 cells challenged with 7 days continuous 0.25 μM cisplatin treatment.</p><p> </p><p><strong>readme.xlsx</strong></p><p>Tab 1: List of files</p><p>Tab 2: Summary of CRISPR screen samples & conditions</p><p> </p><p><strong>Raw sequencing data (zipped fastq files)</strong></p><p>WT_un_1.fastq.gz Wild type untreated replicate 1<br>WT_un_2.fastq.gz Wild type untreated replicate 2<br>WT_cis_1.fastq.gz Wild type cisplatin-treated replicate 1<br>WT_cis_2.fastq.gz Wild type cisplatin-treated replicate 2<br>Pp_un_1.fastq.gz <i>primpol </i>untreated replicate 1<br>Pp_un_2.fastq.gz <i>primpol </i>untreated replicate 2<br>Pp_cis_1.fastq.gz <i>primpol </i>cisplatin-treated replicate 1<br>Pp_cis_2.fastq.gz <i>primpol </i>cisplatin-treated replicate 2</p><p> </p>
Auxiliary files for invasion resistance in multispecies systems based on the replicator equation
<p>In this study we propose a replicator equation framework to model multi-species dynamics. In this replicator equation, the coefficients describe pairwise invasion fitnesses between constituent members, and an explicit quadratic term represents the systemic invasion resistance. This invasion resistance (<em>system trait</em>) is dependent on species frequencies and can be linked with specific structures of their pairwise invasion fitness matrix. Within this replicator framework, mean invasion fitness arises, evolves dynamically, and may undergo critical shifts with global environmental changes (e.g. mean growth rate, mean propensity for co-colonization). In the paper, extending an analogy with an SIS epidemiological model, we derive the conceptual mechanistic link between such replicator equation and <em>N </em>microbial species' growth and interaction traits, stemming from micro-scale environmental modification. We also study several specific invasion matrix structures in detail, their role for the quality of species dynamics and also for systemic invasion resistance. In this Dryad repository, we provide some auxiliary files and links to simulation codes, used and presented in our paper, to aid a mathematical understanding of invasion resistance using the replicator equation. We propose the framework can be applied to study colonization resistance in a wide range of microbial ecosystems. </p>
Replication Package for: Detecting Edgeworth Cycles (Version 2)
<p>This replication package contains the <strong>data </strong>and the <strong>code </strong>to generate the main results reported in <strong>"Detecting Edgeworth Cycles"</strong> by <strong>Timothy Holt, Mitsuru Igami, and Simon Scheidegger</strong>, to be published in the February 2024 issue of <em>The Journal of Law and Economics</em>. </p> <p>Additionally, this package also allows the users to<strong> apply these pre-trained models to new datasets</strong> of their choice. As an example of such a new dataset, we include the <strong>entire German dataset available at the time of our research (2014:Q4–2020:Q4)</strong>, including both manually labeled and unlabeled subsamples.</p> <p>Finally, this package includes <strong>tools to facilitate the acquisition and pre-processing of the most recent data from Germany</strong>, which is updated every day on the <em>Tankerkoenig</em> website (at the time of our preparation of this package).</p> <p><strong>[3/29/2024 update]</strong> The URL for the German antitrust authority's fuel-data website has changed to <a href="https://www.bundeskartellamt.de/EN/Tasks/markettransparencyunit_fuels/markettransparencyunit_fuels.html" target="_blank" rel="noopener">https://www.bundeskartellamt.de/EN/Tasks/markettransparencyunit_fuels/markettransparencyunit_fuels.html</a>.</p>
Replication data for An Empirical Approximation of the Effects of Trade Sanctions with an Application to Russia
<p>This is the dataset to replicate all the tables and figures in the paper <a href="https://doi.org/10.1093/epolic/eiad027">"An Empirical Approximation of the Effects of Trade Sanctions with an Application to Russia"</a>, published in <i>Economic Policy</i>, 2023, by Jean Imbs and Laurent Pauwels. All data manipulations and programming are detailed on the GitHub site:<a href="https://github.com/laurentpauwels/sanctionpaper"> https://github.com/laurentpauwels/sanctionpaper</a>. The raw and processed data are in this <i>sanctionpaperdata_v1/matlab/data folder. </i>For convenience the simulation output <i>(simulationoutput.txt) </i>required to build the scatter plots in Figure 1 with STATA is available in<i> sanctionpaperdata</i>_v1<i>/matlab/output</i>.</p><p><strong>Instructions</strong> </p><p> If you clone the GitHub repository:</p><p>1. Place the downloaded <i>data</i> folder (located in <i>sanctionpaperdata_v1/matlab/)</i> in the <i>matlab</i> folder of the GitHub repository. </p><p>2. Place the downloaded <i>simulation_output.txt</i> I(located in <i>sanctionpaperdata_v1/matlab/output/) </i>in the <i>matlab/output </i>folder of the GitHub repository if you do not want to run the simulations as detailed on GitHub.</p><p><strong>Description</strong></p><p>The <i>matlab/data/raw</i> folder contains an <i>ICIO21</i> folder with the ICIO21 data, and a <i>WIOD</i> folder with the SEA16 data (in <i>data/raw/WIOD/SEA16</i>) and the WIOT16 data in CSV format (in <i>data/raw/WIOD/WIOT16</i>).</p><p>NOTE: WIOD provides the data in XLSB format. The XLSB WIOD data is in the <i>WIOT_in_EXCEL.zip</i> located in the <i>matlab/data/raw/WIOD/</i>. Python is used to convert XLSB into CSV files. See python code in GitHub repository for unzipping and conversion to CSV. The converted CSV files are provided for convenience.</p><p>The parsed and pre-processed ICIO21, SEA16, and WIOT16 data are stored in the <i>/matlab/data/processed</i> folder into three separate .mat structure files:</p><p><i>icio21_strc.mat</i> contains:</p><ul><li>the meta data (<i>icio21_text</i>), i.e., the information about the structure of the numerical data such as lists of countrycode, countries, industrycode, industries, isic_rev4 codes, years covered, name of final categories, etc.</li><li>the numerical data (<i>icio21_data</i>):<ul><li>Z (<i>icio21_data.Z</i>), the intermediate IO data for the listed industries (R), countries (N), and years (T). Its structure is 3-dimensionsal: (NxR)x(NxR)xT.</li><li>F (<i>icio21_data.F</i>), the final demand data for the same countries, industries and years. Its structure is 3-dimension: (NxR)x(NxC)xT. The columns are NxC where C are the number of final demand categories.</li></ul></li></ul><p><br><i>wiod16_strc.mat</i> has the same structure as <i>icio21_strc.ma</i>t with the meta data in <i>wiot16_text</i> and the numerical data in <i>wiot16_data</i>.</p><p><i>sea16_strc.mat</i> has the meta data in <i>sea16_text</i> and the numerical data in <i>sea16_data</i>. SEA16 contains 16 variables instead of Input-Output type data. The country, industry, and year coverage is not the same as ICIO21.</p><p>NOTE: <i>matlab/scripts/convertMatlabStruc2data.m</i> in the GitHub repository converts <i>MATLAB v7.3 </i>format ("structure data") to an updated format without structure so that it is more easily compatible with other software. All data parsing and preprocessing are done with MATLAB, see GitHub repository for details.</p><p><strong>Sources</strong></p><p>The raw data come from these sources:</p><p>1. OECD Inter-Country Input-Output (ICIO) data November 2021 release (downloaded on 2 July 2023)</p><p>- Source: OECD-ICIO 2021 release data is available at <a href="http://oe.cd/icio">http://oe.cd/icio</a></p><p>2. WIOD Socio-Economic Accounts (SEA) data 2016 release (downloaded on 30 May 2023)</p><p>- Source: <a href="https://www.rug.nl/ggdc/valuechain/wiod/wiod-2016-release">https://www.rug.nl/ggdc/valuechain/wiod/wiod-2016-release</a></p><p>3. WIOD World Input-Output Tables (WIOT) data November 2016 (downloaded on 23 June 2023)</p><p>- Source: <a href="https://www.rug.nl/ggdc/valuechain/wiod/wiod-2016-release">https://www.rug.nl/ggdc/valuechain/wiod/wiod-2016-release</a> </p>
Replication package for the paper "A configurational approach to job quality analysis: forms of inequalities at work in Europe"
<p>The following replication package is appended to the article <span><span><span><span>Étienne Penissat</span><span>, </span></span><span><span>Cécile Rodrigues</span><span> & </span></span><span><span>Alexis Spire</span></span></span></span> <span>(2024)</span> "<span>A configurational approach to job quality analysis: forms of inequalities at work in Europe",</span> <span>European Societies,</span> <span>DOI: <a href="https://doi.org/10.1080/14616696.2024.2312950">10.1080/14616696.2024.2312950</a></span></p> <p>The scripts to be run in the following order are:</p> <p>- 1_Penissat_EuropeanSocieties_2023_DataPreparation.R : Recoding, formatting and scope of data used</p> <p>- 2_Penissat_EuropeanSocieties_2023_DataAnalysis.Rmd : Analysis and statistical results</p> <p>The data used in the article comes from the EWCS (2015) - European Working Condition Survey - provided by the European foundation for the improvement of living and working conditions. The data is not available on free access but can be obtained on request. Information on the survey wave used can be found here : https://www.eurofound.europa.eu/surveys/european-working-conditions-surveys/sixth-european-working-conditions-survey-2015</p> <p>- In the first "1_Penissat_EuropeanSocieties_DataPreparation.R" script, the file containing data named "ewcs_1991-2015.dta" is used. The file called "eseg2_trad.csv" contains english labels for the nomenclature of professional positions ESeG. As "ewcs_1991-2015.dta" is not freely available, it is not included in the package and "eseg2_trad.csv" is located in the "data" folder.</p> <p>- The first script creates the data file "Penissat_EuropeanSocieties_2023_EWCS15_cleanData.rds" in the "results" folder.</p> <p>- The second script called "2_Penissat_EuropeanSocieties_DataAnalysis.Rmd" uses the "Penissat_EuropeanSocieties_2023_EWCS15_cleanData.rds" data file and produces the "2_Penissat_EuropeanSocieties_DataAnalysis.html" file containing all code and results presented in the article.</p>
Replication package: Dataset and stata-do-file for analysis in "Intragroup communication in social dilemmas: An artefactual public good field experiment in small-scale communities"
<p>This dataset was used for the analysis in "Intragroup communication in social dilemmas: An artefactual public good field experiment in small-scale communities". The data was collected in Namibia in 2017 as part of the SASSCAL research project by Nils Christian Hoenow and Adrian Pourviseh as members of the Chair for Development and Cooperative Economics at the University of Marburg. Funded by the Southern African Science Service Center for Climate Change and Adaptive Land-UseManagement (SASSCAL) through the German Federal Ministry for Education and Research (Grant No. 01LG1201B).</p> <p> </p> <p>Article Title: Intragroup communication in social dilemmas: An artefactual public good field experiment in small-scale communities </p> <p>Authors: Nils Christian Hoenow* and Adrian Pourviseh**</p> <p> </p> <p>*RWI – Leibniz Institute for Economic Research, Essen, Germany and & School of Business and Economics, University of<br>Marburg, Marburg, Germany</p> <p>**School of Business and Economics, University of<br>Marburg, Marburg, Germany</p> <p>Abstract: <br>Communication is well-known to increase cooperation rates in social dilemma situations, but the exact mechanisms behind this remain largely unclear. This study examines the impact of communication on public good provisioning in an artefactual field experiment conducted with 216 villagers from small, rural communities in northern Namibia. In line with previous experimental findings, we observe a strong increase in cooperation when face-to-face communication is allowed before decision-making. We additionally introduce a condition in which participants cannot discuss the dilemma but talk to their group members about an unrelated topic prior to learning about the<br>public good game. It turns out that this condition already leads to higher cooperation rates, albeit not as high as in the condition in which discussions about the social dilemma are possible. The setting in small communities also allows investigating the effects of pre-existing social relationships between group members and their interaction with communication.We find that both types of communication are primarily effective among socially more distant group members, which suggests that communication and social ties work as substitutes in increasing cooperation. Further analyses rule out better comprehension of the game and increased mutual expectations of one’s group members’ contributions as drivers for the communication effect. Finally, we discuss the role of personal and injunctive norms to keep commitments made during discussions.</p>
Replication data for: Operating Strategies of an Industrial R717 Heat Pump Recovering Waste Heat of a Chiller
<p>This dataset contains the data of the publication:<br> Verdnik, M., Wagner, P., Rieberer, R., 2022. Operating Strategies of an Industrial R717 Heat Pump Recovering Waste Heat of a Chiller. Proc. International Congress of Refrigeration 2023, Paris, France</p>
Replication package for the paper: "A Study on the Pythonic Functional Constructs' Understandability"
<h1>Replication Package for "<em>A Study on the Pythonic Functional Constructs' Understandability</em>" to appear at ICSE 2024</h1> <ul> <li><strong>Authors</strong>: Cyrine Zid, Fiorella Zampetti, Giuliano Antoniol, Massimiliano Di penta</li> <li><strong>Article Preprint:</strong> <a href="https://mdipenta.github.io/files/ICSE24_funcExperiment.pdf">https://mdipenta.github.io/files/ICSE24_funcExperiment.pdf</a></li> <li><strong>Artifacts:</strong> <a href="https://doi.org/10.5281/zenodo.8191782">https://doi.org/10.5281/zenodo.8191782</a></li> <li><strong>License</strong>: <a>GPL V3.0</a></li> </ul> <p>This package contains folders and files with code and data used in the study described in the paper. In the following, we first provide all fields required for the submission, and then report a detailed description of all repository folders.</p> <h2>Artifact Description</h2> <h3>Purpose</h3> <p>The artifact is about a controlled experiment aimed at investigating the extent to which Pythonic functional constructs have an impact on source code understandability. The artifact archive contains:</p> <ol> <li>The material to allow replicating the study (see Section <a>Experimental-Material</a>)</li> <li>Raw quantitative results, working datasets, and scripts to replicate the statistical analyses reported in the paper. Specifically, the executable part of the replication package reproduces figures and tables of the quantitative analysis (RQ1 and RQ2) of the paper starting from the working datasets.</li> <li>Spreadsheets used for the qualitative analysis (RQ3).</li> </ol> <p>We apply for the following badges:</p> <ul> <li><strong>Available and reusable</strong>: because we provide all the material that can be used to replicate the experiment, but also to perform the statistical analyses and the qualitative analyses (spreadsheets, in this case)</li> </ul> <h3>Provenance</h3> <ul> <li><strong>Paper preprint link:</strong> <a href="https://mdipenta.github.io/files/ICSE24_funcExperiment.pdf">https://mdipenta.github.io/files/ICSE24_funcExperiment.pdf</a></li> <li><strong>Artifacts:</strong> <a href="https://doi.org/10.5281/zenodo.8191782">https://doi.org/10.5281/zenodo.8191782</a></li> </ul> <h3>Data</h3> <p>Results have been obtained by conducting the controlled experiment involving <a href="https://www.prolific.com/">Prolific</a>workers as participants. Data collection and processing followed a protocol approved by the University ethical board. Note that all data enclosed in the artifact is completely anonymized and does not contain sensible information.</p> <p>Further details about the provided dataset can be found in the Section <a>Results' directory and files</a></p> <h3>Setup and Usage (for executable artifacts):</h3> <p>See the Section <a>Scripts to reproduce the results, and instructions for running them</a></p> <h2><a>Experiment-Material/</a></h2> <p>Contains the material used for the experiment, and, specifically, the following subdirectories:</p> <h3><a>Google-Forms/</a></h3> <p>Contains (as PDF documents) the questionnaires submitted to the ten experimental groups.</p> <h3><a>Task-Sources/</a></h3> <p>Contains, for each experimental group (G-1...G-10), the sources used to produce the Google Forms, and, specifically: - The cover letter (Letter.docx). - A directory for each experimental task (Lambda 1, Lambda 2, Comp 1, Comp 2, MRF 1, MRF 2, Lambda Comparison, Comp Comparison, MRF Comparison). Each directory contains: (i) the exercise text (in both Word and .txt format), the source code snippet, and its .png image to be used in the form. <strong>Note:</strong> the "Comparison" tasks do not have any exercise as the purpose is always the same, i.e., to compare the (perceived) understandability of the snippets and return the results of the comparison.</p> <h3><a>Code-Examples-Table1/</a></h3> <p>Contains the source code snippets used as objects of the study (the same you can find under "Task-Sources/"), named as reported in Table 1.</p> <h2>Results' directory and files</h2> <p> </p> <h3><a>raw-responses/</a></h3> <p>Contains, as spreadsheets, the raw responses provided by the study participants through Google forms.</p> <h3><a>raw-results-RQ1/</a></h3> <p>Contains the raw results for RQ1. Specifically, the directory contains a subdirectory for each group (G1-G10). Each subdirectory contains: - For each user (named using their Prolific IDs, a directory containing, for each question (Q1-Q6) the produced python code (Qn.py) its output (QnR.txt) and its StdErr output (QnErr.txt). - "expected-outputs/": A directory containing the expected outputs for each task (Qn.txt).</p> <h4><a>working-results/RQ1-RQ2-files-for-statistical-analysis/</a></h4> <p>Contains three .csv files used as input for conducting the statistical analysis and drawing the graphs for addressing the first two research questions of the study. Specifically:</p> <ul> <li> <p><a>ConstructUsage.csv</a> contains the declared frequency usage of the three functional constructs object of the study. This file is used to draw Figure 4. The file contains an entry for each participant, reporting the (text-coded) frequency of construct usage for Comprehension, Lambda, and MRF.</p> </li> <li> <p><a>RQ1.csv</a> contains the collected data used for the mixed-effect logistic regression relating the use of functional constructs with the correctness of the change task, as well as the logistic regression relating the use of map/reduce/filter functions with the correctness of the change task. The csv file contains an entry for each answer provided by each subject, and features the following columns:</p> <ul> <li><em>Group</em>: experimental group to which the participant is assigned</li> <li><em>User</em>: user ID</li> <li><em>Time</em>: task time in seconds</li> <li><em>Approvals</em>: number of approvals on previous tasks performed on Prolific</li> <li><em>Student</em>: whether the participant declared themselves as a student</li> <li><em>Section</em>: section of the questionnaire (lambda, comp, or mrf)</li> <li><em>Construct</em>: specific construct being presented (same as "Section" for lambda and comp, for mrf it says whether it is a map, reduce, or filter)</li> <li><em>Question</em>: question id, from Q1 to Q6, indicate the ordering of the question</li> <li><em>MainFactor</em>: main factor treatment for the given question - "f" for functional, "p" for procedural counterpart</li> <li><em>Outcome</em>: TRUE if the task was correctly performed, FALSE otherwise</li> <li><em>Complexity</em>: cyclomatic complexity of the construct (empty for mrf)</li> <li><em>UsageFrequency</em>: usage frequency of the given construct</li> </ul> </li> <li> <p><a>RQ1Paired-RQ2.csv</a> contains the collected data used for the ordinal logistic regression of the relationship between the perceived ease of understanding of the functional constructs and (i) participants' usage frequency, and (ii) constructs' complexity (except for map/reduce/filter). The file features a row for each participant, and the columns are the following:</p> <ul> <li><em>Group</em>: experimental group to which the participant is assigned</li> <li><em>User</em>: user ID</li> <li><em>Time</em>: task time in seconds</li> <li><em>Approvals</em>: number of approvals on previous tasks performed on Prolific</li> <li><em>Student</em>: whether the participant declared themselves as a student</li> <li><em>LambdaF</em>: result for the change task related to a lambda construct</li> <li><em>LambdaP</em>: result for the change task related to the procedural counterpart of a lambda construct</li> <li><em>CompF</em>: result for the change task related to a comprehension construct</li> <li><em>CompP</em>: result for the change task related to the procedural counterpart of a comprehension construct</li> <li><em>MrfF</em>: result for the change task related to an MRF construct</li> <li><em>MrfP</em>: result for the change task related to the procedural counterpart of a MRF construct</li> <li><em>LambdaComp</em>: perceived understandability level for the comparison task (RQ2) between a lambda and its procedural counterpart</li> <li><em>CompComp</em>: perceived understandability level for the comparison task (RQ2) between a comprehension and its procedural counterpart</li> <li><em>MrfComp</em>: perceived understandability level for the comparison task (RQ2) between a MRF and its procedural counterpart</li> <li><em>LambdaCompCplx</em>: cyclomatic complexity of the lambda construct involved in the comparison task (RQ2)</li> <li><em>CompCompCplx</em>: cyclomatic complexity of the comprehension construct involved in the comparison task (RQ2)</li> <li><em>MrfCompType</em>: type of MRF construct (map, reduce, or filter) used in the comparison task (RQ2)</li> <li><em>LambdaUsageFrequency</em>: self-declared usage frequency on lambda constructs</li> <li><em>CompUsageFrequency</em>: self-declared usage frequency on comprehension constructs</li> <li><em>MrfUsageFrequency</em>: self-declared usage frequency on MRF constructs</li> <li><em>LambdaComparisonAssessment</em>: outcome of the manual assessment of the answer to the "check question" required for the lambda comparison ("yes" means valid, "no" means wrong, "moderate<em>chatgpt" and "extreme</em>chatgpt" are the results of GPTZero)</li> <li><em>CompComparisonAssessment</em>: as above, but for comprehension</li> <li><em>MrfComparisonAssessment</em>: as above, but for MRF</li> </ul> </li> </ul> <h3><a>working-results/inter-rater-RQ3-files/</a></h3> <p>This directory contains four .csv files used as input for computing the inter-rater agreement for the manual labeling used for addressing RQ3. Specifically, you will find one file for each functional construct, i.e., comprehension.csv, lambda.csv, and mrf.csv, and a different file used for highlighting the reasons why participants prefer to use the procedural paradigm, i.e., procedural.csv.</p> <h3><a>working-results/RQ2ManualValidation.csv</a></h3> <p>This file contains the results of the manual validation being done to sanitize the answers provided by our participants used for addressing RQ2. Specifically, we coded the behaviour description using four different levels: (i) correct ("yes"), (ii) somewhat correct ("partial"), (iii) wrong ("no"), and (iv) automatically generated. The file features a row for each participant, and the columns are the following:</p> <ul> <li><em>ID</em>: ID we used to refer the participant in the paper's qualitative analysis</li> <li><em>Group</em>: experimental group to which the participant is assigned</li> <li><em>ProlificID</em>: user ID</li> <li><em>Comparison for lambda construct description</em>: answer provided by the user for the lambda comparison task</li> <li><em>Final Classification</em>: our assessment of the lambda comparison answer</li> <li><em>Comparison for comprehension description</em>: answer provided by the user for the comprehension comparison task</li> <li><em>Final Classification</em>: our assessment of the comprehension comparison answer</li> <li><em>Comparison for MRF description</em>: answer provided by the user for the MRF comparison task</li> <li><em>Final Classification</em>: our assessment of the MRF comparison answer</li> </ul> <h3><a>working-results/RQ3ManualValidation.xlsx</a></h3> <p>This file contains the results of the open coding applied to address our third research question. Specifically, you will find four sheets, one for each functional construct and one for the procedural paradigm. Each sheet reports the provided answers together with the categories assigned to them. Each sheet contains the following columns:</p> <ul> <li><em>ID</em>: ID we used to refer the participant in the paper's qualitative analysis</li> <li><em>Group</em>: experimental group to which the participant is assigned</li> <li><em>ProlificID</em>: user ID (as in the tables from the quantitative analysis)</li> <li>: question asked to the user</li> <li><em>Final Classification</em>: The outcome of our categorization according to the taxonomy shown in Table 10.</li> </ul> <h2>Scripts to reproduce the results and instructions for running them</h2> <p> </p> <h3><a>FuncConstructs-Statistics.r</a></h3> <p>This file contains an R script that you can reuse to re-run all the analyses conducted and discussed in the paper.</p> <h3><a>FuncConstructs-Statistics.ipynb</a></h3> <p>This file contains the code to re-execute all the analysis conducted in the paper as a Jupyter Notebook (using the R Kernel).</p> <h3><a>run-analysis.sh</a></h3> <p>This script can be used to run the R script <code>FuncConstructs-Statistics.r</code> using a Docker container (see Option 1 below) in Unix operating systems.</p> <h3><a>run-analysis.bat</a></h3> <p>This script can be used to run the R script <code>FuncConstructs-Statistics.r</code> using a Docker container (see Option 1 below) in Windows operating systems (power shell recommended).</p> <h3><a>run-jupyter-container.sh</a></h3> <p>This script can be used to run a local Jupyter server (with R kernel and all required packages) from a Docker container (see Option 3 below) in Unix operating system.</p> <h3><a>run-jupyter-container.bat</a></h3> <p>This script can be used to run a local Jupyter server (with R kernel and all required packages) from a Docker container (see Option 3 below) in Windows operating systems (power shell recommended).</p> <h3>How to Run the scripts</h3> <p>There are four options to run the scripts. In all cases, one has first to open a shell terminal window (e.g., bash or sh in Unixes) in the replication package directory. For Windows, we suggest to use a Power Shell.</p> <ol> <li> <p><strong>Running the R script using Dockerized R installation</strong>: this is the simplest option, and it simply requires a running Docker engine. In <strong>Unix (MacOS, Linux)</strong>, to produce the results, one has to run the shell script "run-analysis.sh" (e.g., by typing <code>sh run-analysis.sh</code> or simply <code>./run-analysis.sh</code> after making it executable). In <strong>Windows</strong>, one has to run the script "run-analysis.bat" instead (by typing <code>.\run-analysis.bat</code>). This script (either .sh or .bat) will:</p> <ul> <li>Pull a docker image named <code>mdipenta/rexp</code> which contains an R installation with all required packages.</li> <li> <p>Run R from the container created from the image and produce the paper's results under a directory named <code>results/</code>.</p> </li> <li> <p><strong>Note:</strong> An alternative would be to run everything from inside the container, after running it in interactive mode. To this aim, please execute the following commands:</p> <ol> <li>In <strong>Unix</strong>: <code>docker run -v${PWD}:/data --rm -ti --name shell mdipenta/rexp:latest bash</code>in <strong>Windows</strong>: <code>docker run -v %cd%:/data --rm -ti --name shell mdipenta/rexp:latest bash</code></li> <li><code>cd data</code></li> <li><code>R --no-save < FuncConstructs-Statistics.r</code> After exiting the container, the "results" directory will be again populated with the study results.</li> </ol> </li> </ul> </li> <li> <p><strong>Running the R script from own R installation</strong>: this option works if one has an R installation already (or wants to use an R installation) without relying on the Docker image. The steps to be followed are:</p> <ul> <li>Uncomment the <code>install.packages(..)</code> instruction in the first lines of the script. This will allow for the installation of the required packages.</li> <li>Just run, from the current directory, the script <code>FuncConstructs-Statistics.r</code>, using the command <code>Rscript FuncConstructs-Statistics.r</code> (making sure the directory containing Rscript is in your PATH, this should work fine in Unixes, it might require to modify the PATH environment variable in Windows). Should you experience problems with the first part of the script (installations), try to execute the <code>install.packages(..)</code> statement from your R GUI, and then run the script again.</li> </ul> </li> <li> <p><strong>Using the Jupyter Notebook using a Dockerized Jupyter lab with R kernel</strong>: this option allows for opening the Jupyter Notebook with all results without having to install Jupyter with the R kernel, nor all the required R packages. The steps required are:</p> <ul> <li>Run the <code>./run-jupyter-container.sh</code> (<strong>Unix</strong>) or <code>.\run-jupyter-container.bat</code> (<strong>Windows</strong>). It will download the <code>mdipenta/myjupyter</code> image and run Jupyter lab from it.</li> <li>Open a browser on <a href="http://localhost:8888/">localhost:8888</a> (or if it does not work, <a href="http://127.0.0.1:8888/">127.0.0.1:8888)</a> and, when being asked for a password, type <code>docker</code>.</li> <li>From the Jupyter lab page, open the "FuncConstruct-Statistics.ipynb" notebook, and (if you wish) re-run it, or simply browse its results. Note: differently from options 1 and 2, results are not saved, but just displayed in the notebook.</li> </ul> </li> <li> <p><strong>Using the Jupyter Notebook from your installation</strong>: this is similar to Option 3, but it can work if you have already Jupyter lab installed, with the R kernel enabled (for details see: <a href="https://github.com/IRkernel/IRkernel">https://github.com/IRkernel/IRkernel</a>). The steps to follow are:</p> <ul> <li>Run jupyter lab (e.g., jupyter lab from the command line) and open it on a webpage.</li> <li>Open the <code>FuncConstruct-Statistics.ipynb</code> notebook.</li> <li>If you want to re-execute it, uncomment the <code>install.packages()</code> line.</li> <li>Re-run it (if you wish).</li> </ul> </li> </ol> <h3>The output</h3> <p>If using Option 1 or 2, the <code>results</code> directory will contain the following files:</p> <ul> <li><strong>Figures 4 and 5</strong> as in the paper.</li> <li><strong>Tables 2-9</strong> as in the paper in various formats (csv, tex, and for Tables 3-5 also .txt). Some notes: The diagnostics (top part, up to "Fixed effects") for Tables 3-5 are shown in the .txt files only. However, these files do not report the "OR" columns that correspond to exp(Estimate). This is because the .txt file contains the statistics dump which does not include the ORs. The .csv and .tex tables report the Fixed effects as shown in the paper, including the ORs.</li> <li><strong>rq1-rq2-correlation</strong> (.tex and .csv) contains the correlation analysis between RQ1 and RQ2 results as discussed in the "Threats to construct validity" (Section 6).</li> <li><strong>rq3-inter-rater</strong> (.tex and .csv) contains the results of the inter-rater agreements analysis discussed in Section 3.6.</li> </ul>
Replication Package of Understanding Developers Well-Being and Productivity: a 2-year Longitudinal Analysis during the COVID-19 Pandemic
<p>The COVID-19 pandemic has brought significant and enduring shifts in various aspects of life, including increased flexibility in work arrangements. In a longitudinal study, spanning 24 months with six measurement points from April 2020 to April 2022, we explore changes in well-being, productivity, social contacts, and needs of software engineers during this time. Our findings indicate systematic changes in various variables. For example, well-being and quality of social contacts increased while emotional loneliness decreased as lockdown measures were relaxed. Conversely, people's boredom and productivity, remained stable. Furthermore, a preliminary investigation into the future of work at the end of the pandemic revealed a consensus among developers for a preference of hybrid work arrangements. We also discovered that prior job changes and low job satisfaction were consistently linked to intentions to change jobs if current work conditions do not meet developers' needs. This highlights the need for software organizations to adapt to various work arrangements to remain competitive employers. Building upon our findings and the existing literature, we introduce the Integrated Job Demands-Resources and Self-Determination (IJARS) Model as a comprehensive framework to explain the well-being and productivity of software engineers during the COVID-19 pandemic.</p>
Replication Data for the paper "Predicting Food-Security Crises in the Horn of Africa Using Machine Learning"
<p>This folder contains all input data necessary to run the machine learning model as described in the paper "Predicting Food Security Crises in the Horn of Africa Using Machine Learning". </p><p>This model is developed at the Institute for Environmental Studies, Vrije Universiteit Amsterdam. </p><p>Questions or remarks can be send to tim.busker@vu.nl</p>
Replication Package for "Software Quality Assurance Analytics: Enabling Software Engineers to Reflect on QA Practices" Paper (SCAM 2024)
<p>Welcome to our artifact!<br>In here we provide additional information for you to retrace our steps in the interview analysis.<br>It has the following contents:</p> <ul> <li><code>codebook.xlsx</code>: Our full codebook with our open codes, structured after the axial codes that emerged. <code>codebook-statistics.xlsx</code> lists for each code in which participant's interview it can be found.</li> <li><code>generate-figures</code>: The plain data and scripts used to generate the figures in the paper.</li> <li><code>survey.pdf</code>: An printout of our whole online questionnaire that guided the participants through the pretest-posttest study and the interview.</li> <li><code>survey-answers.xlsx</code>: The complete data for our participants answers in the online survey during the interviews.</li> <li><code>repoinsights-dashboard-software</code>: The code of our prototype repoinsights. As it is under active development, this is not yet documented for replicating the study setup or extending it. Still, we are providing the source code for transparency and will publish a version with comprehensive setup instructions later.</li> </ul>
Replication data for: Vereinfachtes Simulationsmodell einer NH3-HTWP in einem Molkereibetrieb
<p>This dataset contains the data of the publication:<br>Verdnik, M., Eliskases, P., Rieberer, R., 2023. Vereinfachtes Simulationsmodell einer NH3-HTWP in einem Molkereibetrieb. Proc. Deutsche Kälte-Klima-Tagung 2023, Hannover, Germany</p>
On-the-Fly Syntax Highlighting: Generalisation and Speed-ups - Replication Package
<p><strong>On-the-Fly Syntax Highlighting: Generalisation and Speed-ups</strong></p> <p>On-the-fly syntax highlighting involves the rapid association of visual secondary notation with each character of a language derivation. This task has grown in importance due to the widespread use of online software development tools, which frequently display source code and heavily rely on efficient syntax highlighting mechanisms. In this context, resolvers must address three key demands: speed, accuracy, and development costs. Speed constraints are crucial for ensuring usability, providing responsive feedback for end users and minimizing system overhead. At the same time, precise syntax highlighting is essential for improving code comprehension. Achieving such accuracy, however, requires the ability to perform grammatical analysis, even in cases of varying correctness. Additionally, the development costs associated with supporting multiple programming languages pose a significant challenge. The technical challenges in balancing these three aspects explain why developers today experience significantly worse code syntax highlighting online compared to what they have locally. The current state-of-the-art relies on leveraging programming languages' original lexers and parsers to generate syntax highlighting oracles, which are used to train base Recurrent Neural Network models. However, questions of generalisation remain. This paper addresses this gap by extending previous work validation dataset to six mainstream programming languages thus providing a more thorough evaluation. In response to limitations related to evaluation performance and training costs, this work introduces a novel Convolutional Neural Network (CNN) based model, specifically designed to mitigate these issues. Furthermore, this work addresses an area previously unexplored performance gains when deploying such models on GPUs. The evaluation demonstrates that the new CNN-based implementation is significantly faster than existing state-of-the-art methods, while still delivering the same near-perfect accuracy.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.