This continues our series of student reflections and analysis authored by our research team.
Growth Means Change
Morgan Demboski
As the semester comes to a close, the project is now close to its fourth year. Since its birth, the Prosecution Project has evolved and improved through a lot of trial and error and collaborative brainstorming. On our last day of class for the Fall 2019 semester, the team split into small groups and discussed problems we found with the project, as well as came up with possible solutions to these problems. Being lucky enough to have been apart of this project since Fall 2017, I have witnessed how this project has grown, expanded, and changed for the better. However, one problem we continuously run into is keeping uniformity in the cases as the codebook, manual, and variables are altered.
We run into new cases daily that make us reevaluate an aspect of our codebook. For example, until this semester, we had no ‘Threat/Harassment’ option underneath the ‘Tactic’ variable. We had the option of ‘Bomb threat/Hoax’ or ‘Armed intimidation/standoff;’ however, threatening a person/property for a social or political motive was not included in the tactics.
Furthermore, in the variable ‘Completion of Crime,’ we had the option of ‘Planned but not Attempted,’ ‘Attempted,’ ‘Carried through,’ and ‘Unknown,’ but we had no option in which a threat fell under. We were confronted with many cases that involved threats, such as William Patrick Syring from Arlington, VA who threatened employees of the Arab American Institute (AAI), and Rick Lynn Simmons from Grand Rapids, MI who left a racist, threatening voicemail to Democratic presidential candidate, Senator Cory Booker. As a result, we added the option ‘Threat/Harassment’ to the ‘Tactic’ variable and ‘Threat’ to the ‘Completion of Crime’ variable.
This is one example of how our codebook and variables change constantly. However, when the codebook or something in the variables is altered, the cases that have already been completed are often left un-updated. Before we had the new variable, cases involving threats were always coded as ‘Other’ (recently changed to ‘Uncategorized’) in ‘Tactic,’ so when we added ‘Threat/Harassment’ as an option, these past cases needed to be changed. With the almost weekly modifications in coding language, variables, and formats, a lot of these older cases tend to slip through the cracks. To deal with this, my small group came up with an idea that we believe would help create more uniformity in coding past, present, and future cases.
Currently, the project is organized into a class of students, a handful of independent coders, and a small group of senior team members. A large majority of the class, along with the independent coders, work on adding cases and creating new case starters, coding and expanding on uncompleted cases, and updating pending or completed cases. We have assignments throughout the semester that help us keep on track, with a total of around 30 case starters per student due by the end of the semester, around 30 completely coded cases per each student pair due by the end of the semester, and other assignments such as scraping source files or swapping out source documents.
Though we have completed a lot of work this semester, our group suggests that it would be more efficient and effective to create different categories of coders in which students are organized into at the beginning of the semester. The first category is New Case Coders or coders who work solely on adding cases/case starters. They would focus on looking at Twitter and social media posts, the news, and other sources to find cases that have not yet been included in our database. They would then create a case starter, simply including the Date, Date Descriptor, Case ID, Name, and a Short Narrative. This role is great for members who have very little to no experience in coding with the project, and for members who prefer researching and finding new cases instead of deciphering specific variables.
We named the second category of coders Expanding Coders. Members in this category would focus on expanding those case starters and filling in the necessary variables. Working off of the source document and basic information that the New Case Coder found, the Expanding Coder will finish the case and prepare it to be checked and finalized by a senior coder. The third category, the category I believe to be most important at this stage in the project, is the Updating Coders. The members in this category will focus solely on updating previous and already completed cases with new information and new modifications to the codebook and manual. This would include updating pending cases with new information as well as updating finalized cases with newly found information or changes in variable language or codebook definitions.
The last category of team members, which already exists in the current structure, is the steering team, or senior members. This is a group of team members who have extensive experience with the project and have a deep understanding of the coding process. These members manage the more logistical side of the project, along with Project Director Dr. Michael Loadenthal, but they also have the important task of checking finished cases for mistakes and discrepancies and moving them to the completed (For Official Use Only) spreadsheet.
After discussing our experiences with the project, each of my small group members had a preference of which category they would like to be a part of. We think that others in the project also prefer starting cases over updating and vice versa. By splitting people into their preferred categories, people can focus on a specific area rather than having to juggle both new cases and updating old cases. The first week of class (or training) can be spent teaching students what each role does and giving a small assignment that introduces the different roles so that students can decide their preferred job. New members to the team will generally be New Case Coders so that they can become familiar with the structure of the project and the coding process. Senior coders are typically designated before the year starts, and the rest of the team is welcome to choose whether they want to focus on adding new cases or updating old ones. By narrowing the duties of the members, each person can focus on perfecting their area and not worry about whether the other tasks need to be done.
This is not to say that the members will work solely on new cases or old cases, there are a lot of tasks in the project still needing to be completed that are unrelated to coding entirely. As the project expands and more cases are added, our team has to reorganize and find ways to create uniformity among the thousands of cases in our database. Our small group’s suggestion was one among many offered by the team, each containing novel aspects that will grow and improve the project. We have excelled so far at making modifications to meet the fast-paced growth of the database, and we will continue to come up with ways to meet the changing needs of the team and the project as a whole.