## 3 Materials and Methods
### Materials
#### 3.1.2 Traversal Algorithm  
We developed an algorithm to procure the initial buggy commit and related information. The code we created for this process can be found [[https://github.com/anonsstubs/sstubs](https://github.com/anonsstubs/sstubs)]([https://github.com/anonsstubs/sstubs](https://github.com/anonsstubs/sstubs)). Our algorithm leveraged various git commands as follows [22] (Listing 1):  
```
1 gitclone<projectgitlink><foldername>
2 gitlog-1--format=%%ae%a%a%c%c%c%c1--date=iso<commithash>
3 gitlog--source-pretty='%F'-S<buggycode>--<BugFilePath>
4 gitshow<possibleinitialcommithash>--<filepathtobuggycode>
```  
**Listing 1**. Git commands used in the traversal algorithm. We first cloned every available project with the first git command in Listing 1 in order to be able to run further git commands from within each project. We then gathered all information about the fix commit, including the author's email, the date the code was authored (author date), the committer's email, and the day the code was committed (commit date) using the second command in Listing 1. It is important to note that the author and committer do not have to be the same user and often are not. In GitHub, an author is the person who wrote the code, whereas the committer is the user that allows the code into the project. Committers usually have a higher level of privileges and authority within the project. After getting this information, we then used the third command in Listing 1 to find all the potential initial buggy commits, in other words, commits in which the buggy code is found as a change in the specified file. We then looked at each of these potential commits using the fourth command in Listing 1 to find the definite initial commit. We did this by implementing several checks. We first made sure that the author-date for the potential initial buggy commit was before the fix commit author-date. If this test passed, we checked if the buggy code was in the git show file following a '+', indicating that the buggy code was an addition in this commit instead of following a '\(-\)' signaling a deletion. Then, we gathered information about each of the projects. We first started by creating a relevant time frame per project. The purpose behind this is to be able to describe project activity on an individual project basis. By getting the oldest and earliest dates per project present in our results, we constructed a time frame of interest for each project. We padded this time frame by adding a month before the earliest date and a month after the latest date since some projects only had one bug commit fixed in less than a day in the dataset. If kept with the raw time frame, the statistics would not represent the project's activity around the time of the commit. We then used git commands to grab the number of authors, committers, and commits made in this time frame. These quantities were then used in our calculations for Commit Rate and Commit Cycle from Equations (1) and (2) proposed in the introduction of this chapter, which allow us to gauge how long each bug took to get fixed in proportion to its project's Commit Rate in the time of interest. After gathering the available initial buggy commit hashes and project information, we further processed the data to get other attributes. These attributes consisted of the following Boolean columns: whether the same author wrote the initial commit and fix commit, whether the same user authored and committed the initial buggy commit, whether the bug was authored during a standard U.S. weekend (Saturday, Sunday), whether the bug was authored during standard U.S. working hours (9 AM-5 PM), and whether the commit was part of a project with more than 25 active committers or more than 40 active authors. These Boolean attributes allow us to get insight into what factors affect the time it takes to fix Simple Stupid Bugs.