Find research datasets worth reusing

opencc-by-4.0Aug 2021View details →

Artifacts supplementing the EuroUSEC '22 paper "Assessing Real-World Applicability of Redesigned Developer Documentation for Certificate Validation Errors"

This upload supplements the conference EuroUSEC 2022 submission by providing the full questionnaire, anonymized dataset and all performed analyses presented in the paper specified below. <ul> <li>Title: Assessing Real-World Applicability of Redesigned Developer Documentation for Certificate Validation Errors</li> <li>Authors: Martin Ukrop, Michaela Balážová, Pavol Žáčik, Eric Vincent Valčík, Vashek Matyas</li> <li>Paper details: https://crocs.fi.muni.cz/public/papers/eurousec2022</li> <li>Paper abstract: We face certificate validation errors commonly, yet the related tools and documentation had been shown to have very poor usability. Previous research suggests that just improving the error messages and corresponding documentation can have significantly positive effects. Our work aims at increasing the usability of certificate validation by 1) redesigning the API error messages and the corresponding documentation, and 2) validating the real-world applicability of the redesign by investigating the opinions of 180 IT professionals. We focus on the perceived obstacles, desired ideal form and overall satisfaction. The redesigned documentation exhibits a reliable significant decrease in perceived incompleteness, with a small amount of perceived bloat and tangle. The redesigned documentation, now published on a dedicated website, is preferred by 89% of our study participants.</li> </ul> The artifacts accompanying this paper contain three major parts: <ul> <li>The questionnaire used in the main study (described in Sections 3.1 and 3.2 of the paper and mostly present in Appendices A and B of the paper).</li> <li>The anonymized dataset (multiple formats) of all valid questionnaire answers and qualitative coding performed. Analyses of this dataset are the core of the paper and are present in subsection 3.4 and all parts of Sections 4 and 5.</li> <li>The set of analyses files (IBM SPSS scripts and outputs) producing all statistical results presented in the paper are included.</li> </ul> More details about the artifacts can be found in the README file in the artifacts archive.

opencc-by-4.0May 2022View details →

Artifacts for Keyword Extraction From Specification Documents for Planning Security Mechanisms

This dataset contains the data used for evaluating VDocScan - a keyword extraction based security vulnerability prediction method. The repository includes an extensive list of Products and Vulnerability reports from CVE, a custom created dataset mapping vulnerability reports to product documentations, as well as, intermediate results from the study such as decision trees rendered for each vulnerability, correlation matrix of vulnerabilities etc.

opencc-by-4.0Feb 2023View details →

Present day human hand grasping the same artifact by hand and hafted

Examples of a present day human hand demonstrating a precision grip (top left) when grasping an artifact by hand and a power "squeeze" grip (top right) when grasping a hafted artifact (both palmar view). In turquoise (first metacarpal) and purple (trapezium) are the present day human and Neanderthal bones forming the trapeziometacarpal complex at the base of the thumb and responsible for its movements.

openmit-licenseFeb 2023View details →

A StackExchange Dataset of Developer Questions Related to Checked-in Secrets in Software Artifacts

Throughout 2021, GitGuardian's monitoring of public GitHub repositories revealed a two-fold increase in the number of secrets (database credentials, API keys, and other credentials) exposed compared to 2020, accumulating more than six million secrets. To our knowledge, the challenges developers face to avoid checked-in secrets are not yet characterized. In our artifact, we provide a dataset containing 779 questions mined from three StackExchange sites asked by developers related to checked-in secrets from three StackExchange sites. In addition, we provide 434 accepted answers provided by the other users of StackExchange to mitigate the challenge of checked-in secrets.   <table> <caption>An overview of StackExchange artifact</caption> <thead> <tr> <th scope="col">Field Name</th> <th scope="col">Description</th> </tr> </thead> <tbody> <tr> <td>Id</td> <td>An unique identifier of the question.</td> </tr> <tr> <td>Title</td> <td>The title of the question.</td> </tr> <tr> <td>Body</td> <td>The description of the question.</td> </tr> <tr> <td>Tags</td> <td>The tags related to the question such as "security", "git" and "key-management".</td> </tr> <tr> <td>CreationDate</td> <td>The date when the question is posted.</td> </tr> <tr> <td>Score</td> <td>The count of upvotes in the question.</td> </tr> <tr> <td>ViewCount</td> <td>The number of users who viewed the question.</td> </tr> <tr> <td>AnswerCount</td> <td>The total number of answers posted in the question.</td> </tr> <tr> <td>CommentCount</td> <td>The total number of comments posted in the question.</td> </tr> <tr> <td>FavouriteCount</td> <td>The total number of users who marked the question as favourite.</td> </tr> <tr> <td>ClosedDate</td> <td>The date when the community marked the question as closed. </td> </tr> <tr> <td>URL</td> <td>The url of the question.</td> </tr> <tr> <td>AcceptedAnswerId</td> <td>The unique identifier of the accepted answer for the question.</td> </tr> <tr> <td>Answer</td> <td>The accepted answer of the question.</td> </tr> </tbody> </table>

opencc-by-4.0Jul 2019View details →

Artifacts supplementing the ACM DTRAP 2020 article "Will You Trust This TLS Certificate? Perceptions of People Working in IT (extended version)"

These research artifacts supplement the following two publications: <ul> <li>Will You Trust This TLS Certificate? Perceptions of People Working in IT [ACSAC 2019], DOI 10.1145/3359789.3359800, more details at https://crocs.fi.muni.cz/public/papers/acsac2019</li> <li>Will You Trust This TLS Certificate? Perceptions of People Working in IT (extended version) [ACM DTRAP 2020], DOI 10.1145/3419472, more details at https://crocs.fi.muni.cz/public/papers/dtrap2020</li> </ul> The artifacts contain the full experimental setup (as described in Section 2.1 of the paper) and the complete anonymized dataset underlying the evaluation presented in Sections 3 and 4. The experimental setup contains the documents accompanying the task: the informed consent, pre-task questionnaire, task description, trust scales, and the list of questions posed during the post-task interview (all in PDFs). We further include the custom website with certificate validation documentation for the “redesigned” condition (static HTML). While working on the task, participants in the “redesigned” condition could access this website via a link that was in the redesigned error messages. Furthermore, we provide the software with which the participants interacted.  It contains the displayed error messages and validated certificates. These things are available both individually and incorporated in a snapshot of a virtual machine used at the experiment (importable directly into VirtualBox). The collected data is presented in a single dataset (SPSS format; you can use PSPP as a free alternative). It includes the analysis syntax files to obtain the numerical results presented in the paper. For each participant, the dataset contains: 1) pre-task questionnaire answers, 2) reported trust ratings, 3) sub-task timing, 4) information on whether they browsed the Internet and 5) the interview codes assigned. Note that we do not publish the interview transcripts to preserve participant privacy.

opencc-by-4.0Jul 2018View details →

Artifacts supplementing the RSA-CT 2018 paper "Why Johnny the Developer Can't Work with Public Key Certificates"

Supplemental materials for the paper "Why Johnny the Developer Can't Work with Public Key Certificates" (DOI 10.1007/978-3-319-76953-0_3, more details at https://crocs.fi.muni.cz/public/papers/rsa2018) contain the following: <ul> <li>Informed consent participants had to sign (experiment design approved by Research Ethics Committee of Masaryk University)</li> <li>General questionnaire & System usability scale questionnaire</li> <li>User tasks & certificates to validate</li> </ul>

opencc-by-4.0Aug 2023View details →

Data Artifact: Rebasing Microarchitectural Research with Industry Traces

Data Artifact of the paper "Rebasing Microarchitectural Research with Industry Traces", published at the 2023 IEEE International Symposium on Workload Characterization. It includes the original CVP-1 traces used in the paper.Note: the improved converted traces used in the paper are available at https://doi.org/10.5281/zenodo.10199624.Abstract: Microarchitecture research relies on performance models with various degrees of accuracy and speed. In the past few years, one such model, ChampSim, has started to gain significant traction by coupling ease of use with a reasonable level of detail and simulation speed. At the same time, datacenter class workloads, which are not trivial to set up and benchmark, have become easier to study via the release of hundreds of industry traces following the first Championship Value Prediction (CVP-1) in 2018. A tool was quickly created to port the CVP-1 traces to the ChampSim format, which, as a result, have been used in many recent works. We revisit this conversion tool and find that several key aspects of the CVP-1 traces are not preserved by the conversion. We therefore propose an improved converter that addresses most conversion issues as well as patches known limitations of the CVP-1 traces themselves. We evaluate the impact of our changes on two commits of ChampSim, with one used for the first Instruction Championship Prefetching (IPC-1) in 2020. We find that the performance variation stemming from higher accuracy conversion is significant.

opencc-by-4.0Jan 2020View details →

ASPLOS20-AE Artifact Dataset for 'Noise-Aware Dynamical System Compilation for Analog Devices with Legno'

The empirical model database and dataset for the ASPLOS 2020 Paper 'Noise-Aware Dynamical System Compilation for Analog Devices with Legno'

opencc-by-4.0Jan 2020View details →

CC20 Artifact - Automatic Fusion

1. Getting started The title of our paper submitted to CC20 is Improving Database Query Performance with Automatic Fusion This repository is created for showing the reproducibility of our experiments in this paper. We provide the details of scripts and original data used in the experiments. There are mainly two systems: HorsePower and RDBMS MonetDB. We supply step-by-step instructions to configure and deploy both systems in the experiments. On this page, you will see: <ul> <li>how to run experiments (Section 2); and</li> <li>the results used in the paper (Section 3);</li> </ul> 2. Experiments All experiments were run on a server called <code>sable-intel</code> equipped with <ul> <li>Ubuntu 16.04.6 LTS (64-bit)</li> <li>4 Intel Xeon E7-4850 2.00 GHz</li> <li>total 40 cores with 80 threads</li> <li>128GB RAM</li> </ul> Docker setup Download the docker image: cc20-docker.tar (About 13GB) <pre><code>docker load < cc20-docker.tar </code></pre> Generate a named container (then exit) <pre><code>docker run --hostname sableintel -it --name=container-cc20 wukefe/cc20-docker exit </code></pre> Then, you can run the container <pre><code>docker start -ai container-cc20 </code></pre> Open a new terminal to access the container (optional) <pre><code>docker exec -it container-cc20 /bin/bash </code></pre> Introduction to MonetDB Work directory for MonetDB <pre><code>/home/hanfeng/cc20/monetdb </code></pre> Start MonetDB (use all available threads) <pre><code>./run.sh start </code></pre> Login MonetDB using its client tool, <code>mclient</code> <pre><code>mclient -d tpch1 ## ... MonetDB version v11.33.3 (Apr2019) sql> SELECT 'Hello world'; +-------------+ | L2 | +=============+ | Hello world | +-------------+ 1 tuple </code></pre> Show the list of tables in the current database <pre><code>sql> \d TABLE sys.customer TABLE sys.lineitem TABLE sys.nation TABLE sys.orders TABLE sys.part TABLE sys.partsupp TABLE sys.region TABLE sys.supplier </code></pre> Leave the session <pre><code>sql> \q </code></pre> Stop MonetDB before we can continue our experiments <pre><code>./run.sh stop </code></pre> Reference: <a href="https://www.monetdb.org/Documentation/Guide/Installation">How to install MonetDB and the introduction of server and client programs.</a> Run MonetDB with TPC-H queries MonetDB: server mode Invoke MonetDB with a specific number of threads (e.g. 1) <pre><code>mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=1 </code></pre> Open a new terminal <pre><code>docker exec -it container-cc20 /bin/bash cd cc20/monetdb </code></pre> Note: Type <code>\q</code> to exit the server mode. Run with a specific number of threads (Two terminals required) 1 thread <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=1 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_1.log" </code></pre> 2 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=2 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_2.log" </code></pre> 4 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=4 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_4.log" </code></pre> 8 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=8 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_8.log" </code></pre> 16 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=16 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_16.log" </code></pre> 32 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=32 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_32.log" </code></pre> 64 threads <pre><code>## terminal 1 mserver5 --set embedded_py=true --dbpath=/home/hanfeng/datafarm/2019/tpch1 --set monet_vault_key=/home/hanfeng/datafarm/2019/tpch1/.vaultkey --set gdk_nr_threads=64 ## terminal 2 (time ./runtest | mclient -d tpch1) &> "log/log_thread_64.log" </code></pre> Post data processing - MonetDB Fetch average execution time (ms) <pre><code>grep -A 3 avg_query log/log_thread_1.log | python cut.py 699.834133333 // q1 85.9178666667 // q4 65.0172 // q6 101.730666667 // q12 58.212 // q14 60.1138666667 // q16 248.926466667 // q19 77.6482 // q22 grep -A 3 avg_query log/log_thread_2.log | python cut.py grep -A 3 avg_query log/log_thread_4.log | python cut.py grep -A 3 avg_query log/log_thread_8.log | python cut.py grep -A 3 avg_query log/log_thread_16.log | python cut.py grep -A 3 avg_query log/log_thread_32.log | python cut.py grep -A 3 avg_query log/log_thread_64.log | python cut.py </code></pre> Note: The above numbers can be copied to an Excel file for further analysis before plotting figures. Details can be found in Section 3. Run with HorseIR The HorsePower project can be found on GitHub. In the docker image, it has been placed in <code>/home/hanfeng/cc20/horse</code>. <pre><code>https://github.com/Sable/HorsePower </code></pre> Execution time We then run each query 15 times to get the average execution time (ms). <pre><code>(cd /home/hanfeng/cc20/horse/ && time ./run_all.sh) </code></pre> The script <code>run_all.sh</code> runs over three versions of generated C code based on different levels of optimizations. <pre><code>- naive : no optimization - opt1 : with optimizations - opt2 : with automatic fusion </code></pre> In each version, it first compiles its C code and runs the generated binary with a different number of threads (i.e. 1/2/4/8/16/32/64). Each run computes a query 15 times and returns the average. As a result, all output is saved into a log file, for example, <code>log/naive/log_q6.log</code> contains the result of query 6 in the naive version with all different number of threads. Log file structures <pre><code>log/naive/*.txt log/opt1/*.txt log/opt2/*.txt </code></pre> Fetch a brief summary of execution time from a log file <pre><code>cat log/naive/log_q6.txt | grep -E 'Run with 15 times' q06>> Run with 15 times, last 15 average (ms): 266.638 | 278.999 266.134 266.417 <12 more> # 1 thread q06>> Run with 15 times, last 15 average (ms): 138.556 | 144.474 137.837 137.579 <12 more> # 2 threads q06>> Run with 15 times, last 15 average (ms): 71.8851 | 75.339 72.102 72.341 <12 more> # 4 threads q06>> Run with 15 times, last 15 average (ms): 73.111 | 75.867 72.53 72.936 <12 more> # 8 threads q06>> Run with 15 times, last 15 average (ms): 56.1003 | 59.263 56.057 56.039 <12 more> # 16 threads q06>> Run with 15 times, last 15 average (ms): 56.8858 | 59.466 56.651 57.109 <12 more> # 32 threads q06>> Run with 15 times, last 15 average (ms): 53.4254 | 55.884 54.457 52.878 <12 more> # 64 threads </code></pre> It may become verbose when you have to extract information for all queries over three different kinds of versions. We provide a simple solution for it. <pre><code>./run.sh fetch log | python gen_for_copy.py </code></pre> Output data in the following format <pre><code>// query id | naive | opt1 | opt2 | ----------------------- | ... | ... | ... | # 1 thread | ... | ... | ... | # 2 threads ... ... ... | ... | ... | ... | # 64 threads </code></pre> Note that we copy the generated numbers into an Excel described in Section 3. Within an Excel file, we compare the performance difference in MonetDB and different versions of the generated C code. Compilation time Work directory <pre><code>/home/hanfeng/cc20/horse/codegen </code></pre> Fetch compilation time for different kinds of C code <pre><code>./run.sh compile naive &> log_cc20_compile_naive.txt ./run.sh compile opt1 &> log_cc20_compile_opt1.txt ./run.sh compile opt2 &> log_cc20_compile_opt2.txt </code></pre> Let's look into the result of query 1 in the log file <code>log_cc20_compile_naive.txt</code>. <pre><code>Time variable usr sys wall GGC phase setup : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 5%) 1266 kB ( 18%) phase parsing : 0.07 ( 54%) 0.07 ( 88%) 0.14 ( 64%) 3897 kB ( 55%) phase opt and generate : 0.06 ( 46%) 0.01 ( 12%) 0.07 ( 32%) 1899 kB ( 27%) dump files : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 9%) 0 kB ( 0%) df reg dead/unused notes : 0.01 ( 8%) 0.00 ( 0%) 0.00 ( 0%) 31 kB ( 0%) register information : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 5%) 0 kB ( 0%) preprocessing : 0.03 ( 23%) 0.02 ( 25%) 0.08 ( 36%) 1468 kB ( 21%) lexical analysis : 0.00 ( 0%) 0.03 ( 38%) 0.05 ( 23%) 0 kB ( 0%) parser (global) : 0.04 ( 31%) 0.02 ( 25%) 0.01 ( 5%) 2039 kB ( 29%) tree SSA other : 0.00 ( 0%) 0.01 ( 12%) 0.00 ( 0%) 3 kB ( 0%) integrated RA : 0.01 ( 8%) 0.00 ( 0%) 0.01 ( 5%) 726 kB ( 10%) thread pro- & epilogue : 0.02 ( 15%) 0.00 ( 0%) 0.00 ( 0%) 41 kB ( 1%) shorten branches : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 5%) 0 kB ( 0%) final : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 5%) 56 kB ( 1%) initialize rtl : 0.01 ( 8%) 0.00 ( 0%) 0.01 ( 5%) 12 kB ( 0%) rest of compilation : 0.01 ( 8%) 0.00 ( 0%) 0.00 ( 0%) 62 kB ( 1%) TOTAL : 0.13 0.08 0.22 7072 kB </code></pre> The whole compilation time is split into many parts. We take the total wall time as the actual time spent on the code compilation. In this query, it needs 0.22 seconds to complete the whole compilation. (Note that manual work is required for retrieving the compilation time.) 3. Results We have a lot of numbers generated by our experiments. We use R and Excel to process these performance numbers and R for plotting figures. There are two kinds of data: (1) the data can be used in R directly, such as the execution time of various versions of C code with different number of threads; and (2) the data needs to pre-processed in Excel before it is sent to R. In order to make it easy for further data analysis, we intentionally provide scripts to make an Excel-friendly format that allows us to copy and paste numbers easily. Work directory <pre><code>/home/hanfeng/cc20/plot </code></pre> For example, the R script for generating figure 10 <pre><code>fig10/plot-gmeans.R </code></pre> The Excel file <pre><code>result-book.xlsx </code></pre> Note: We use RStudio Version 1.2.1335 to generate figures from our R scripts. Since RStudio is a GUI-based software, you can install it on another machine with GUI and run scripts from it.

opencc-by-4.0Feb 2020View details →

Artifact for the EASE 2020 Paper: How Can I Contribute? A Qualitative Analysis of Community Websites of 25 Unix-Like Distributions

Artifact for the EASE 2020 Paper: How Can I Contribute? A Qualitative Analysis of Community Websites of 25 Unix-Like Distributions Jacob Krüger, Sebastian Nielebock, Robert Heumüller   Please refer to the readme for more details

Figure 4 in Philonthus hepaticus (Coleoptera, Staphylinidae) in eastern Canada: are distribution gaps distinctive features or collecting artifacts?

Figure 4. Nearest populations to Atlantic Canada of Cicindela marginipennis, Hyperaspis troglodytes, Diomus amabilis, Ephalus latimanus, and Rypobius marinus (derived from Leonard and Bell 1999; Majka et al. 2008; Majka and Cline 2006; Majka and McCorquodale 2006; Sabine 2004).

Figure 3 in Philonthus hepaticus (Coleoptera, Staphylinidae) in eastern Canada: are distribution gaps distinctive features or collecting artifacts?

Figure 3. Distribution of Philonthus hepaticus in northeastern North America (derived from Smetana 1995).

Figure 2 in Philonthus hepaticus (Coleoptera, Staphylinidae) in eastern Canada: are distribution gaps distinctive features or collecting artifacts?

Figure 2. Distribution of Gabrius ulpius, Philonthus rufulus, and Philonthus thoracicus in northeastern North America (derived from Smetana 1995).

Figure 1 in Philonthus hepaticus (Coleoptera, Staphylinidae) in eastern Canada: are distribution gaps distinctive features or collecting artifacts?

Figure 1. Distribution of Acylophorus caseyi, Hemiquedius ferox, and Quedius s. spelaeus in northeastern North America [derived from Smetana (1971) and Moseley et al. (2006)].

opencc-by-4.0Apr 2020View details →

Forensic Exchange Analysis of Contact Artifacts on Data Hiding Timestamps-ADS Experiment Supplementary Files

Da-Yu Kao is an Associate Professor at the Department of Information Management, Central Police University, Taiwan. He was a detective and forensic police officer at Taiwan's Criminal Investigation Bureau (under the National Police Administration). With a Master's degree in Information Management and a Ph.D. degree in Crime Prevention and Correction, he had led several investigations in cooperation with police agencies from other countries for the past 20 years. He is now the director of Computer Crime Investigation Lab at Central Police University and the webmaster of Cybercrime Investigation and Digital Forensics in the Facebook Group.

opencc-by-4.0May 2020View details →

Artifact for the ESEC/FSE 2020 Paper: An Empirical Analysis of the Costs of Clone- and Platform-Oriented Software Reuse

This dataset comprises the supplementary material for the paper "An Empirical Analysis of the Costs of Clone- and Platform-Oriented Software Reuse" by Jacob Krüger and Thorsten Berger, accepted at ESEC/FSE 2020. The dataset comprises: <ul> <li>bibFilesManualSearch: The bib files for all venues analyzed, as provided by DBLP (cf. Section 2.4)</li> <li>dataFromPapers: The pdf file documents all included studies and the data extracted from these (cf. Section 2.4, 3.2, and 3.3)</li> <li>interviewGuide: The guide/questions for our semi-structured intreviews in the cost assessment phase (cf. Section 2.3)</li> <li>anonymizedInterviewSummary: The anonymized and summarized data from the cost-assessment interviews (cf. Section 3.2 and 3.3)</li> <li>R: Our R script for creating our figures and the corresponding csv files</li> </ul>

opencc-by-nc-4.0Mar 2020View details →

Replication package for "Wikifying Software Artifacts"

This replication package contains all data files necessary to verify and replicate our findings presented in the manuscript "Wikifying Software Artifacts".

openother-openJan 2021View details →

Research Artifact: How are Project-Specific Forums Utilized? A Study of Participation, Content, and Sentiment in the Eclipse Ecosystem

Research Artifact: How are Project-Specific Forums Utilized? A Study of Participation, Content, and Sentiment in the Eclipse Ecosystem <a href="https://github.com/yusufsn/EclipseForumData">https://github.com/yusufsn/EclipseForumData</a> This is a research artefact for the paper: How are Project-Specific Forums Utilized? A Study of Participation, Content, and Sentiment in the Eclipse Ecosystem. This artifact is a repository consisting of collected dataset including (i) 289,061 threads, (ii) 216,864 extracted links from threads, (iii) 2,170 contributors, and the results of our qualitative analysis, (i) 1,142 manually annotated type of discussion and (ii) 1,142 manually annotated sentiment analysis. This artefact aims to enable researchers to replicate our mixed-methods quantitative results of the paper and reuse the dataset for further software engineering research. Contents <ul> <li>dataset: <ul> <li><code>289061_threads.csv.zip</code> - 289,061 collected main threads of all users without post from webmaster (.zip format)</li> <li><code>216864_links.csv.zip</code> - 216,864 extracted links from collected threads (.zip format)</li> <li><code>2170_contributors.csv</code> - 2,170 list of contributions (.csv format)</li> </ul> </li> <li>Results of manual analysis: <ul> <li><a href="https://docs.google.com/spreadsheets/d/e/2PACX-1vQoRpcbrV66OEB4vaCG9Njq65zW7XpLRITYG3BlUOoa_DmeOKcdQIgYJ8y2aSlmL3y9bCUhjpP3rYmT/pubhtml">Manual annotation of discussion type</a></li> <li><a href="https://docs.google.com/spreadsheets/d/e/2PACX-1vQfyvsP1Zq3b9p_BYwkkgYXuEePJB6sIroC47jOUMcR5P8t7DCJFNpOJD565SPgqi--L3AAIQWs2kC5/pubhtml">Manual annotation of sentiment analysis</a></li> </ul> </li> </ul> Authors <ul> <li><a href="https://yusufsn.github.io/">Yusuf Sulistyo Nugroho</a></li> <li><a href="https://syful-is.github.io/">Syful Islam</a></li> <li>Keitaro Nakasai</li> <li><a href="https://ifrazrehman.github.io/">Ifraz Rehman</a></li> <li><a href="https://hideakihata.github.io/">Hideaki Hata</a></li> <li><a href="https://raux.github.io/">Raula Gaikovina Kula</a></li> <li><a href="https://cs.uwaterloo.ca/~m2nagapp/">Meiyappan Nagappan</a></li> <li><a href="https://matsumotokenichi.github.io/">Kenichi Matsumoto</a></li> </ul>

opencc-by-4.0Sep 2022View details →

Accepted Artifact for Little Tricky Logic: Misconceptions in the Understanding of LTL

Datasets and source materials for our studies of Linear Temporal Logic (LTL). Includes: <ul> <li>  Labelled responses to our surveys </li> <li> The surveys themselves </li> <li> The coding rubric that guided our categorization </li> </ul>