Specifications TableSubject area*Computer Software*More specific subject area*Software Development Artifacts*Type of data*Tables, SQLite databases*Data format*Raw, processed and analyzed*How data was acquired*Automatic software repository mining and ex- traction*Data format*Raw, filtered, analyzed, etc.*Experimental factors*Two automated mining algorithms captured software artifacts from open source software.*Experimental features*A heuristic technique created trace links among the discovered artifacts.*Data source location*The original data are stored in respective project issue tracking systems and version control systems.*Data accessibility*Hosted on Harvard Dataverse*\
*DOI:*[*10.7910/DVN/PDDZ4Q*](10.7910/DVN/PDDZ4Q){#intref0020}\
*URL:*[*https://bit.ly/2wukCHc*](https://bit.ly/2wukCHc){#intref0025}Related research article*A subset of the data was used in Rath, M., Lo, D. and Mäder, P., Analyzing requirements and traceability information to improve bug localization. IEEE/ACM* 15th *International Conference on Mining Software Repositories (MSR), 2018, 442--453*[@bib11]*.***Value of the Data**•Empirical research in the software engineering domain lacks appropriate data. For example, available datasets used for studying software traceability, i. e. the relationships among different development artifacts, are highly restricted in terms of contained artifact types, traces and their overall size. Scientists studying software feature localization and bug localization, bug prediction, or software traceability often propose both: a novel technique and an accompanying dataset. This dataset overcomes the listed limitations and may establish a common baseline and enable direct comparison for benchmarking.•Large amounts of data is required to perform solid scientific investigations. Especially novel approaches building upon machine learning (ML) and information retrieval (IR) techniques require datasets for training, validation, and testing. This dataset supports these approaches offering development data with ≈300.000 issue tracker artifacts, ≈ 350.000 version control (source code) artifacts and ≈200.000 trace links among them.•This dataset spans 33 open-source projects from different domains including application servers, databases, web frameworks and widely used programming libraries. The complete timestamped history of each project in terms of typed artifacts (bug reports, feature requests, improvements, source code changes), manifold artifact properties (texts, stakeholder data), and trace links among these artifacts retrieved from issue trackers and source code repositories is included.•On project level, the dataset combines issue tracking systems and version control systems using trace links. The joint analysis of both systems permits studies that span whole software development processes. This includes bug localization [@bib7], [@bib11], [@bib15], bug prediction [@bib9], feature localization [@bib3], requirements traceability [@bib2], and studying social aspects [@bib8] of software development.•The data is provided in the form of relational databases facilitating convenient access, as requested by researchers [@bib6], and easy to embedded in existing approaches.

1. Data {#sec1}
=======

The data stems from 33 open-source projects and their respective issue tracking system (ITS) and version control system (VCS). [Fig. 1](#fig1){ref-type="fig"} shows an example of issue HHH-4489[1](#fn1){ref-type="fn"} of project [Hibernate]{.smallcaps} as represented in the ITS Atlassian Jira.[2](#fn2){ref-type="fn"} The VCS captures the evolution of a project\'s source code in form of changesets such as the example[3](#fn3){ref-type="fn"} from project [Hibernate]{.smallcaps} shown in [Fig. 2](#fig2){ref-type="fig"}. The retrieval process of all ITS and VCS artifacts is shown in [Fig. 4](#fig4){ref-type="fig"}. This process also reliably discovers traceability links among changesets of the VCS and referenced issue artifacts in the ITS. All issues, changesets and respective properties are part of the dataset on a project level and key figures are reported in [Table 2](#tbl2){ref-type="table"}. To unify project specific differences, the typed issues, e. g. *New Feature* or *Bug Report*, are mapped to five issue categories (see [Table 1](#tbl1){ref-type="table"}) resulting in the distribution shown in [Fig. 3](#fig3){ref-type="fig"}. An individual relational database consisting of nine tables (see [Table 3](#tbl3){ref-type="table"}) per project is used to store the projects data. [Fig. 5](#fig5){ref-type="fig"} shows the used database schema.Fig. 1Example of Jira issue of type *improvement* in project [Hibernate]{.smallcaps}. It shows all available data fields (title, description, status, etc) and the unique issue identifier HHH-4489 (marked red). Additionally, the *improvement* has a vertical trace link to issue HHH-8074. Individual-related data such as *reporter* is obfuscated for privacy reasons.Fig. 1Fig. 2Example for a git changeset in project [Hibernate]{.smallcaps}. It shows the unique commit hash 625d781 ... (marked red), a time stamp, the changed source code file, and the line-by-line modifications. The commit messages also contains a reference to an issue tracker artifact (HHH-4489, marked red). Individual-related data is obfuscated for privacy reasons.Fig. 2Fig. 3Issue category distribution according to mapping defined in [Table 1](#tbl1){ref-type="table"}. Details are shown in [Table 2](#tbl2){ref-type="table"}.Fig. 3Fig. 4The applied data collection process per project in the dataset. Infor-mation from each project\'s ITS and VCS is processed and stored into a combined database.Fig. 4Table 1Mapping from Jira issue types and their description to issue categories used in this paper. Both, the original issue type and the mapped typed, are contained in the dataset.Table 1Issue CategoryMapped Jira issue typesIssue Category Description**Bug**BugA problem which impairs or prevents the functions of the product.**Feature**Feature, New Feature, Feature RequestA new feature of the product.**Improvement**Improvement, EnhancementAn enhancement to an existing feature.**Task**Task, Sub-taskA task that needs to be done.**Other***various*: e. g. Brainstorming,\
Umbrella, Patch, Wish*miscellaneous*Table 2Key figures for the projects of the dataset. Issue links represent vertical and issue to change links horizontal trace links. The time period specifies the range between first and last artifact per project.Table 2ProjectTime Period \[month\]IssuesCommentsChange SetsIssue LinksIssue to Change Set LinksLinked Change Sets \[%\]**1**[Archiva]{.smallcaps}162192950508006510227526.42**2**[Axis2]{.smallcaps}164579617,14631,114484260918.93**3**[Cassandra]{.smallcaps}10613,96596,00723,5923363726337.03**4**[Derby]{.smallcaps}160696959,82981563529726383.17**5**[Drools]{.smallcaps}1465103976311,117633552847.24**6**[Erray]{.smallcaps}99106012167645406388.11**7**[Flink]{.smallcaps}43810069,57012,4191895532841.98**8**[Groovy]{.smallcaps}173813723,34512,378987490137.91**9**[Hadoop]{.smallcaps}15039,086453,76527,77623,62629,30997.13**10**[Hbase]{.smallcaps}13119,247249,92314,331769413,37990.06**11**[Hibernate]{.smallcaps}17211,97139,33981733110694282.20**12**[Hive]{.smallcaps}11318,025132,54811,179911011,05896.34**13**[Hornetq]{.smallcaps}1583286627411,121732228319.37**14**[Infinispan]{.smallcaps}106842217,38210,6542350749968.55**15**[Izpack]{.smallcaps}1081337964548973180430.73**16**[Jbehave]{.smallcaps}162123425632824154646.53**17**[Jboss-T.-M.]{.smallcaps}145288762172204814161571.64**18**[JBPM]{.smallcaps}15910,39728,63149192211113322.06**19**[Kafka]{.smallcaps}78621932,96044261699289363.17**20**[Keycloak]{.smallcaps}545523785610,1061408544351.73**21**[Log4j]{.smallcaps}117211413,3559792488330932.13**22**[Lucene]{.smallcaps}19717,329158,19428,995492319,11163.12**23**[Maven]{.smallcaps}183507317,29810,3151971259624.10**24**[Pig]{.smallcaps}123523429,89631341479298092.85**25**[Railo]{.smallcaps}1013326742839904598924.36**26**[Restasy]{.smallcaps}119164945653684280134534.77**27**[Seam2]{.smallcaps}147503112,57411,309953302425.88**28**[Spark]{.smallcaps}9322,20576,96620,829807014,30661.72**29**[Switchyard]{.smallcaps}86301095132928882242880.29**30**[Teeid]{.smallcaps}196489916,8087266723585872.38**31**[Weld]{.smallcaps}115251853418086665255530.45**32**[Wildfly]{.smallcaps}20324,56659,71936,71111,03322,38857.71**33**[Zookeeper]{.smallcaps}116290731,2511600966142387.12SUM278,5361,702,949358,72696,750204,59357.03Table 3Descriptions of the available tables (see [Fig. 5](#fig5){ref-type="fig"}) per project\'s SQLite database in the dataset.Table 3TableDescription**issue**This table contains all artifacts extracted from a project\'s issue tracker. Each issue includes a unique id, summary, a detailed description, information about type, status, names of people involved, and time stamps. The people names are available as full names (e.g. "John Doe") along with used login names (e. g. "jdoe") which allows to link them to user profiles used in source code version control system.**issue_link**This table represents vertical, typed trace links between issue tracker artifacts. The column name classifies the link (e.g. "Duplicate", "Reference") and column outward_label informs about the reading direction from source issue to target issue (e.g. "duplicates", "relates to"). The field is_containment is 1, when the target issue is a child of source issue.**issue_comment**User comments on the issue. Full names and login names are stored in the same way as for table issue.**issue_component**A mapping table from issue to a software component.**issue_component**The mapping table from issue to a version of the software, where the issue was (or will be) fixed.**issue_fix_version**The mapping table from issue to a version of the software, where the issue was (or will be) fixed.**change_set**This table contains the change sets mined from the projects\' source code version control system uniquely identified by a commit hash value. Additional information like the author, time of change and a textual description is also stored.**change_set_link**A mapping table from issue to change sets, which describe horizontal traces.**code_change**All source code changes with file granularity. Every change is linked to a change set and described as number of added and deleted lines of code. The actual modified file con- tent can be easily retrieved from the VCS if required. The columns file_path and old_file_path capture file renaming or moving to a different directory in the source file tree.**meta**A meta table containing detailed information about processed Jira and git repositories for the project, stored as key value pairs. This includes URLs to the used issue tracking systems and git repositories along with respective HEAD revision numbers, and the time stamp when the mining was done.Fig. 5Database schema used for each project in the dataset, primary keys in bold and arrows depict foreign key references among the tables. The tables highlighted in ![](fx1.gif) contain data retrieved from the project\'s ITS, while tables highlighted in ![](fx2.gif) contain data retrieved from the project\'s VCS. The table change_set_link contains the trace links connecting the ITS and VCS.Fig. 5

The trace links allow to navigate from the ITS artifacts to VCS artifacts and vice-versa. They serve as a building block for manifold active research areas supporting tasks like defect prevention, change impact analysis, coverage analysis and building recommendation systems.

2. Experimental design, materials, and methods {#sec2}
==============================================

This section introduces the *Software Engineering in Open Source Systems (SEOSS 33)* dataset and provides an overview and descriptive statistics of the contained projects, artifacts, and their origin.

2.1. Project selection {#sec2.1}
----------------------

We first settled on one combination of issue tracking system and version control system used by the projects to be potentially included in our dataset. We selected Atlassian Jira[4](#fn4){ref-type="fn"} and git[5](#fn5){ref-type="fn"} based on their popularity studied in various surveys,[6](#fn6){ref-type="fn"}^,^[7](#fn7){ref-type="fn"} and due to their tight integration. Focusing on one combination of ITS and VCS simplified the development of our data collection process. We also required that the projects in the dataset should be majorly written in one programming language easing analysis and tooling of scientist using the dataset. Considering programming language ranking polls,[8](#fn8){ref-type="fn"}^,^[9](#fn9){ref-type="fn"} and internet searches[10](#fn10){ref-type="fn"}, we chose Java as main language. Given the tooling restrictions, we considered three major and publicly available hosting providers: the Apache Software Foundation, JBoss, and the Atlassian Cloud. We ran a pre-study, to get a quantitative overview of artifacts and traceability links across all Java projects hosted by these providers. We further narrowed the selection based on the following criteria:1.A project shall capture a rich set of development artifacts, but at least requirements, bug reports, and source code.2.A project shall continuously capture vertical and horizontal trace links among these artifacts.3.A project shall be under active development for at least three years and shall have deployed stable releases.

After applying the information oriented selection strategy Maximum Variation Cases [@bib5] to draw representative samples with varying project characteristics, we eventually selected 33 open-source projects. The detailed project list (File projects.csv) formatted as comma-separated values (CSV) is part of the dataset [@bib12]. It provides the project name, a short description of the project, a link to its webpage, and the name of the database created by the data collection process.

2.2. Issue tracking systems (ITS) {#sec2.2}
---------------------------------

All projects contained in the dataset use the web-based life-cycle management tool Atlassian Jira to manage requirements, defects, and traceability links. In Jira, the fundamental artifact is an uniquely identifiable *issue* capturing a set of properties like a *type*, a short textual *summary*, a long *description* and information about the stakeholder that created it (see [Fig. 1](#fig1){ref-type="fig"}). Issues are typed to adapt them to different phases of a development project. The predefined list of issue types contains *bug*, *improvement*, *new feature*, and *task*. New issue types and properties can be created as needed for a project. The exact naming of issue types differs among the projects, e.g. some projects use *enhancement* instead of *improvement*, both expressing the same underlying concept. For generalization purposes, we apply a mapping between Jira issue types and a reduced set of five issue categories (see [Table 1](#tbl1){ref-type="table"}). However, the original issue type still is available in the dataset, along with the issue category. As depicted in [Fig. 3](#fig3){ref-type="fig"}, a majority of issues falls into these four categories, representing issue types present in every project. Examples for issue types categorized as Other are, e. g. "Umbrella" (used in [Hbase]{.smallcaps}, [Spark]{.smallcaps}), or "Patch" (used in [Hibernate]{.smallcaps}, [Seam2]{.smallcaps}). Similarly, Jira supports the creation and customization of traceability link types between issue types in addition to a set of predefined link types like *relates to* and *blocks*. For example, the improvement HHH-4489 (see [Fig. 1](#fig1){ref-type="fig"}) is linked to bug HHH-8074. Furthermore, comments can be added to issues providing additional details and facilitating collaboration with other developers. Hadoop provides the largest number of issue tracker artifacts in the dataset with ≈40,000 issues, ≈ 23,000 trace links among them and nearly half a million comments (see [Table 2](#tbl2){ref-type="table"}).

2.3. Version control system (VCS) {#sec2.3}
---------------------------------

The projects in the dataset use git as VCS. Upon a change, git stores differences to the previous version of each altered file as atomic changeset termed *commit*. Each commit is uniquely identified by a hash value. Besides the atomic set of modified files, a commit also comprises the person performing the change, a timestamp, and a commit message stating the purpose of the change (see [Fig. 2](#fig2){ref-type="fig"}). A commit message may contain information about, e.g., a newly implemented requirement, a changed or enhanced requirement, or a fixed defect. It is common practice that developers tag commits with the identifiers of issues they were working on when changing the code. In many projects, such as those hosted by the Apache Foundation, this procedure is demanded in the development guidelines, which, e.g., state that *"You need to make sure that the commit message contains at least \[\...\] a reference to the Bugzilla or JIRA issue \[\...\]"*.[11](#fn11){ref-type="fn"} For example, the changeset 625d781[12](#fn12){ref-type="fn"} of project Hibernate reads *"HHH-4489 need method "refresh(String entityName, Object obj)""* and mentions the issue identifier HHH-4489.

As shown in [Table 2](#tbl2){ref-type="table"}, the dataset contains a total of 350,000 commits, with project Wildfly contributing the largest share. Depending on the project, varying percentages of changesets are linked to issues. For example, in the [errai]{.smallcaps} project only 8% of the changesets are linked to issues, whereas in the Hadoop project 97% are linked.

2.4. Data collection process {#sec2.4}
----------------------------

A sequential capturing process was applied to gather data per project (see [Fig. 4](#fig4){ref-type="fig"}). It improves the technique used to create the "IlmSeven dataset" [@bib13], which aimed mainly to be a traceability dataset.

***Analyzing a Project\'s ITS*** The Jira platform offers a RESTful web service, which allows to interact with the system programmatically. We implemented a collector utilizing the provided application programming interface (API). The collector automatically discovers all artifacts of a project and downloads them to local files stored in *JavaScript Object Notation (JSON)* format (**1**). The downloaded files are then analyzed to extract artifact data and traceability links among these artifacts (**2**). These results are parsed (**3**) and stored into the respective tables of the project\'s database (**4**).

In Jira, each issue repository uses a common prefix for all contained artifacts, typically derived from the project name. Usually a project uses a single issue repository and thus all issues are prefixed in the same manner (e.g. projects [groovy]{.smallcaps}, [maven]{.smallcaps}, and [kafka]{.smallcaps}). However, some projects in our set use multiple issue repositories. For example, the Hadoop project uses four repositories[13](#fn13){ref-type="fn"}: HADOOP, MAPREDUCE, YARN, and HDFS, where each repository holds issues just for a specific part of the software. We determined all issue repositories per project by visiting the projects websites. Relevant meta information about all issue repositories is stored in the meta table contained in each project\'s database (see [Table 3](#tbl3){ref-type="table"}).

***Analyzing a Project\'s VCS*** A second collector was implemented to download the commit history held in each project\'s VCS (**5**). The retrieved version history is traversed in inverse chronological order, starting at the latest change (*HEAD* revision) back to the initial commit (**6**). During traversal, basic information of every visited commit is captured, including the commit time stamp, the author, and the list of affected files along with detailed line-by-line change information (**7**). The content of the source files is not part of the dataset, because of space and efficiency reasons. However the number of added and deleted lines per file in each changeset is stored to quantify the overall size of the change. In case the modified file content is required, it can easily be retrieved using the unique commit hash and file path to query the publicly available VCS. The command git show --pretty = -U \<commit_hash\> \<file_path\> shows the modified file content in commit referenced by the supplied commit hash.

It is a common practice to tag commit messages with issue identifiers and thus to create links between source code and issues [@bib14]. To retrieve these links, we scan individual commit messages (**8**) for Jira identifiers.[14](#fn14){ref-type="fn"} This technique reliably discovers traceability links among the changeset and the referenced issue artifacts in the ITS [@bib1]. For example, this process extracts the issue identifier HHH-4489 in the commit message *"HHH-4489 need method "refresh(String entityName, Object obj)" "* (see [Fig. 2](#fig2){ref-type="fig"}). Thus, a vertical trace link is created from improvement HHH-4489 to changeset 625d781a. All captured information is stored in the project\'s database (**9**), compressed with bzip2. The command bzip2 -d \<project_name\>.sqlite3.bz2 decompresses a file. We selected SQLite[15](#fn15){ref-type="fn"} as relational database management system. In contrast to client-server databases, SQLite is easy to setup, is directly embeddable into programs and offers bindings to many programming languages and tools for machine learning and statistical analysis, which eases accessing and working with the data. Each database and thereby project data complies to the same database schema. Depending on the research area specialized storage formats might be beneficial, such as graph databases for traceability analysis [@bib10]. For example, the authors in Ref. [@bib4] outline multiple data transformations from different input representations to a graph database. A similar approach can be applied to this dataset by querying the main artifact tables issue and change_set as well as the tables issue_link and change_set_link representing the links between the artifacts (see [Fig. 5](#fig5){ref-type="fig"}).

### 2.5. Post processing {#sec2.5}

Similar to issue tracking, a project may use multiple version control repositories (e.g. project [infinispan]{.smallcaps}[16](#fn16){ref-type="fn"}). The authors consulted the respective website to discover these repositories. Relevant meta information about all analyzed version control repositories is stored in the meta table per project database, e.g., the latest crawled commit hash (*HEAD* revision).

In order to facilitate usage of the retrieved data for different research topics, we avoided modifications of the raw data. This allows specific post processing steps depending on the actual uses case. For example, these steps may include filtering on artifact level (e. g., requirements, defects), on source code level (e. g. file names or paths) or on a specific temporal window. To simplify time based filtering, all time stamps are provided in universal coordinated time (UTC) and in their original time zone (respective \*\_zoned columns). All captured text fields are stored as is and may contain markup symbols[17](#fn17){ref-type="fn"} used for structuring.

### 2.6. Database schema description {#sec2.6}

Each database and thereby project data complies to the same schema containing of eight related tables and an additional meta-data table (see [Fig. 5](#fig5){ref-type="fig"}). The content of all nine tables is described in [Table 3](#tbl3){ref-type="table"}. Generally, date and time values are stored with ISO 8601 encoding[18](#fn18){ref-type="fn"} as text, e.g. 2015-10-21T07:28:00Z. Numbers and booleans are stored as integer and the remaining information are stored as column type text.

### 2.7. Data model design {#sec2.7}

The chosen data model supports multiple use cases and thus is applicable in different research areas.

A common approach in *bug localization* is to use information retrieval (IR) techniques. Thus a bug report is treated as text document to query the projects source code repository, which forms a list of documents in IR terminology. The result of the query is a ranked list of the most relevant matches among all source files (documents). Bug reports are stored the table issue identified by column type = Bug. The projects source code can be locally cloned using the URL stored in the meta table. In bug localization, the algorithm performance can be evaluated by comparing the computed ranked list with the actual set of files modified to fix the bug. This set is built by collecting all file_paths in table code_change for each bug report with resolution = Fixed using the traversal issue → change_set_link → change_set → code_change.

The features (type = Feature) in table issue and their relations (table issue_link) to other issues define the starting point to study *change inpact analysis*. The source code, either on file level or even line level (requires detailed analysis of all code_changes), implementing the feature can be identified using a similar traversal as described in bug localization. Using this information, *recommender systems* can by trained to propose possible code locations that need to be considered in case a feature is altered or a new one is linked to an existing one. One attempt to create a training and testing is to apply temporal filtering, i. e. before and after a given point in time, using the stored timestamps on all involved artifacts.

The core building block for manifold research areas is the navigation between ITS and VCS artifacts as briefly outlined by the two examples. One main difference among the applications is the selection of artifacts [@bib3], [@bib15], such as issue types, stakeholder data and texts found in issue descriptions, comments and commit messages for studying social aspects [@bib8] or project evolution based on time information [@bib2].

Transparency document {#appsec1}
=====================

The following is/are the supplementary data to this article:Multimedia component 1Multimedia component 1

Our work is funded by the BMBF grants: 01IS16003B, DFG grant: MA 5030/3--1, the EU EFRE/TAB grant: 2015FE9033, and DLR grant: D/943/67258261.

<https://hibernate.atlassian.net/browse/HHH-4489>.

<https://www.atlassian.com/software/jira>.

<https://bit.ly/2L4L5Sp>.

<https://www.atlassian.com/software/jira>.

<https://git-scm.com>.

<https://project-management.zone/ranking/category/issue>.

<https://insights.stackoverflow.com/survey/2018#work-version-control>.

<https://octoverse.github.com/>.

<https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages>.

<https://www.tiobe.com/tiobe-index/>.

<https://www.apache.org/dev/committers.html#applying-patches>.

<https://bit.ly/2L4L5Sp>.

<http://hadoop.apache.org/issue_tracking.html>

Regular expression pattern for Jira identifiers: <https://bit.ly/2L2iZHg>.

<https://www.sqlite.org>.

<https://github.com/infinispan>.

<https://bit.ly/2Fh8Vd8>.

<https://www.iso.org/iso-8601-date-and-time-format.html>.

Transparency document associated with this article can be found in the online version at <https://doi.org/10.1016/j.dib.2019.104005>.
