What’s Up, ASF? Using Imhotep to Understand Project Activity

Posted on by Jack Humphrey

As I described in an earlier post, we built Imhotep as a data analytics platform for the rapid exploration and analysis of large time-series datasets. In the previous post, I showed how an Imhotep dataset based on Atlassian Jira can drive improvements to the development process.

We’re continually searching for new ways to collect metrics. Examining actions in Jira, the tool we use for tracking our development process, seemed like a natural fit for gaining process insights. We decided to find a way to convert Jira issue history for a large set of projects into an Imhotep dataset of actions, organized by time.

The open source Jira Actions Imhotep Builder transforms issue activity in a Jira instance into an Imhotep dataset. Each document in the resulting dataset corresponds to a single action on a Jira issue, such as creation, edit, transition, or comment.

The builder queries the Jira REST API for each Jira issue in the specified time range, then deconstructs the issue into a series of actions. The actions are written to a series of .TSV (tab-separated values) files, which are uploaded to an Imhotep dataset.

Using that builder, we created a dataset of activity on projects in the Apache Software Foundation (from their Jira instance). We hope Apache projects take advantage of the dataset to gain insights about ways they can improve processes for their developer and user communities.

 

Diving into the ASF Jira data

We created an Imhotep dataset of ASF Jira data from January 1, 2016 through the present. As of October 17, 2018, the apachejira dataset:

  • contains nearly 3.4 million Jira actions, including 230,298 issue creations, 1.8 million edits, and 1.3 million comments
  • requires only 274MB on disk, or about 81 bytes per action

Using the apachejira dataset, we can answer many questions about what’s happening in ASF projects, such as the following examples.

Who reported the most bugs in ASF projects from July-September?

from apachejira 2018-07-01 2018-10-01
   where action="create" issuetype="Bug"
   group by actor

Beam JIRA Bot, with presumably actual person Sebb in the #2 position:

Screenshot of top ten query results for ASF project query, with 7,675 bugs total; #1 is Beam JIRA Bot with 74 issues; #2 is Sebb with 56 issues

Which projects have the most bugs reported from July-September?

from apachejira 2018-07-01 2018-10-01
   where action="create" issuetype="Bug" 
   group by project

Ignite edges out Ambari for the top spot, with 401 bugs reported.

Screenshot of top 10 query results for projects with most bugs, with 7,675 bugs total; #1 is Ignite with 401 bugs; #2 is Ambari with 349 bugs

The next two questions explore some differences in project workflows.

How many distinct status values exist in the most active projects?

from apachejira 2018-01-01 today
   group by project[10] 
   select count(), distinct(status)

Five of the top ten projects have 6 distinct statuses, and the other five have 5 distinct statuses. For example, Apache Beam has 5, and Apache Hive has 6.

Screenshot of top 10 query results for most active ASF projects, showing the distinct status values for each project.

How do the statuses used by Apache Beam and Apache Hive compare to one another?

from apachejira 2018-01-01 today
   where project in (Beam, Hive)
   group by status
   select project='Beam',project='Hive'

Hive uses the Patch Available state, Beam doesn’t. It turns out that about 11% of the Apache JIRA projects take advantage of this state.

Screenshot of query results comparing Beam and Hive projects, listing the issues in Open, In Progress, Resolved, Reopened, Closed, and for Hive only, Patch Available status

Which projects had the most contributors changing issue status to Patch Available in 2018?

from apachejira 2018-01-01 2019-01-01
   where fieldschangedtok='status' 
      status='Patch Available'
   group by project[10]
   select distinct(actor)

Hadoop ecosystem projects (Hive, HDFS, Hadoop Common, YARN, HBase, and Hadoop Distributed Data Store) claim six of the top 10 spots.

Screenshot of results for top 10 projects where contributors changed issue status to Patch Available in 2018; led by Hive, Hadoop HDFS, Ignite

Who contributed to (set status to Patch Available in) Apache Hive in 2018?

from apachejira 2018-01-01 2019-01-01
   where fieldschangedtok='status' 
      status='Patch Available' project = 'Hive'
   group by actor[10]
   select count(), distinct(issuekey)

The top 10 contributors contributed to 578 issues in 2018.

Screenshot of results for top 10 contributors who set issue status to Patch Available in Apache Hive in 2018, including count per contributor

How long does it take to get a patch accepted in the 20 most active projects?

from apachejira 2018-01-01 2019-01-01
   where prevstatus="Patch Available" 
      status="Resolved" 
      fieldschangedtok="status"
   group by project[10]
   select count(), timeinstate\3600/count() 
      /* hours in state */

Hadoop Distributed Data Store is the fastest, with an average of 102 hours between the Patch Available and Resolved states.

Screenshot of query results of top 20 ASF projects with fastest time between Patch Available and Resolved states, ranked by lowest hours in state

The average for Kafka is really high, but it turns out that about 28 outliers with resolutions of Not A Problem, Auto Closed, Duplicate, Won’t Fix, and Won’t Do contributed to the high average.

from apachejira 2018-01-01 2019-01-01
   where prevstatus="Patch Available" 
      status="Resolved" 
      fieldschangedtok="status" project = Kafka
   group by resolution
   select count(), timeinstate\3600/count() 
      /* hours in state */

Screenshot of query results of Kafka project issues by resolution, ranked from high to low hours in state; led by Not A Problem and Auto Closed.

That might be a bad thing or an okay thing for the community. Either way, digging into numbers like these can raise interesting questions.

These are a small sample of the questions we could explore in this dataset.

Creating and analyzing your own Jira datasets

We’ve made the Jira Actions Imhotep Builder available as open source. We hope you will use it to build your own Jira-based Imhotep datasets. This builder is the first one we’ve published, and we’ve also listed it in a new Imhotep Builder Directory.

If you have an idea for a new builder, or need help getting started with Imhotep, open an issue in the GitHub repository or reach out on Twitter.

In the next post in this series, I describe Hindsight, an internal tool we use to make internal contributor work visible and drive coaching insights.

Read the full series of blog posts:

Cross-posted on Medium.

Metrics-Driven Process Improvement: A Case Study

Posted on by Jack Humphrey

In the previous post, I described how we use a measure-question-learn-improve cycle to refine development processes. To reiterate:

  1. Measure everything we possibly can.
  2. Learn by asking questions and exploring the data we’ve collected.
  3. Use our learnings to try to improve.
  4. Measure continuously to confirm improvement.

At Indeed, we get as much data as we can into Imhotep — everything that happens in our products, but also everything that happens in the development process. Process-oriented Imhotep datasets at Indeed include Git commits, Jira issue updates, production deploys, wiki edits, and more.

Let’s take a look at how we applied the measure-question-learn-improve cycle to a problem at Indeed: translation verification.

Image translates "measure-question-learn-improve" cycle text into French to illustrate Translation Verification.

How long are translations in “Pending Verification”?

Our international team believed it was taking way too long to verify string translations in our products. We track translation work in Jira, and we track Jira issue updates in an Imhotep dataset. So we started asking questions of our measurements that might help us understand this problem.

This Imhotep query gives us a day-by-day grouping of time spent in the Pending Verification state. It includes only Translation issues (in a sample project called LOREM) that moved out of that state:

from jiraactions 2017-01-08 2017-04-02
where issuetype = 'Translation' AND
      prevstatus = 'Pending Verification' AND
      status != 'Pending Verification' AND
      project = 'LOREM'
group by time(1d)
select timeinstate/86400 /* days pending */

We ask Imhotep to graph that metric cumulatively over time. We see that for the given 3-month period, Translation issues spent a total of ~233 days in Pending Verification.

Graph of translation issues in Pending Verification over 3 months in 2017, showing the issues were in Pending for about 233 days total.

That sounds like a lot of time, but it’s important to ask more questions! Be skeptical of the answers you’re getting, whether they support your hypothesis or not.

  • Can we dig into the data to better understand it?
  • What other information do we need to interpret?
  • What are the sources of noise?
  • Do we need to iterate on the measurement itself before it is generally useful?

In this example, what if only a few issues dominated this total? Let’s tweak our query to look at how many issues are contributing to this time.

from jiraactions 2017-01-08 2017-04-02
where issuetype = 'Translation' AND
      prevstatus = 'Pending Verification' AND
      status != 'Pending Verification' AND
      project = 'LOREM'
group by time(1d)
select distinct(issuekey) /* number of issues */

Graph of number of translation issues over 3 months in 2017, showing 5 brief, distinct spikes

Our translators shared with our engineers their perspective on the root cause. Translation changes had to wait for a full build before they would show up in a testing environment. Translators would move on to other work and return to verify later. We paid the cost of these context switches in a slower rate of translation.

The spikes we see in the graph above show that delay. Each time a set of changes reached a testing environment, a number of verification events closely followed. The visualized data confirms the inefficiency described by the people actually doing the work.

When we switch that graph to cumulative, we see that translators verified 278 issues in the time period. That is probably a large enough dataset to validate the hypothesis.

Graph of cumulative number of translation issues over 3 months in 2017, showing a stepped climb to 278 issues

These are just a few examples of questions we can quickly and iteratively ask using Imhotep. When we have good measurements and we ask good questions, we learn. And based on our learnings, we can try to improve.

Translation verification: There is a better way

If a translation change could go straight to a testing environment as soon as it was submitted, we would eliminate the inefficiency described above. In fact, a couple of engineers at Indeed figured out a way to deploy translations separate from code. They started to try that incrementally on a project-by-project basis. This capability enabled translators to verify issues minutes after completing their changes.

After a period of time, we were able to compare two similar projects. The IPSUM project used the new translation deployment mechanism, while the LOREM project used the old method.

To illustrate the benefits of the new mechanism, it’s worth comparing the worse case scenarios. This query lets us see the 90th percentile time in Pending Verification for just those two projects.

from jiraactions 2016-09-15 2017-02-28
where issuetype = 'Translation' AND
      prevstatus = 'Pending Verification' AND
      status != 'Pending Verification'
group by project in ('LOREM','IPSUM')
select percentile(timeinstate, 90)

Screenshot of query results for Lorem project at 1,043,964 (12 days) and Ipsum project at 154,533 (1.8 days)

The new process does look faster, with a 90th percentile of 1.8 days, compared to 12 days for the project using the old mechanism.

After digging into the data, asking more questions, and further verifying, we decided to move more projects onto the new system and keep measuring the impact.

Using Imhotep to understand your process

In order to track Jira activity with Imhotep, we wrote a tool that we run daily to extract the data from Jira into an Imhotep dataset. We’ve open sourced this tool, and you can find it in the Imhotep Builder Directory. In the next post, I describe using that builder to analyze Apache Software Foundation projects.

Read the full series of blog posts:

Cross-posted on Medium.

Using Metrics to Improve the Development Process (and Coach People)

Posted on by Jack Humphrey

In the previous post, I described Imhotep, our scalable, efficient, and fast open source data analytics platform. Imhotep helps us use metrics at Indeed for fast, iterative experimentation, which drives improvement to our products.

Improving process and coaching people

We use the same tools and techniques to improve development processes, following a measure-question-learn-improve cycle:

  1. Measure everything we possibly can.
  2. Learn by asking questions and exploring the data we’ve collected.
  3. Use our learnings to try to improve.
  4. Measure continuously to confirm improvement.

Beyond process improvements, this approach can also work for people. Data can help us understand our own work and coach others.

  • How much am I getting done?
  • How am I engaging with other teams?
  • How has my work changed over time?
  • What are my blind spots?

Is measuring processes and people a good idea?

You might be skeptical of using this approach for improving process and measuring people. It’s good to be skeptical. To truly benefit from this approach, you must proceed with caution.

Gaming the stats (Goodhart’s Law)

The first caution is Goodhart’s Law, which states that “When a measure becomes a target, it ceases to be a good measure.” For example, your manager might say: “Our measurements show that our team productivity is declining. Let’s set a target to increase features completed by 20% next quarter. If we hit it, big bonuses all around!”

Okay, but your team might then start “gaming the stats” — making changes that improve the metric without improving productivity. Now your measure is meaningless for gauging productivity, and you’ve rewarded your team for counterproductive measures that don’t advance your goals.

The Number Six Principle

The second caution is something I’ve named the Number Six Principle (inspired by a classic TV character and his famous line): Don’t reduce people to a set of numbers.

Image illustrating the Number Six Principle with header text "I am not a number" and a silhouette of character Number Six from TV show "The Prisoner."

No one enjoys being judged entirely by numbers. If you tell people you’re measuring them, you run the risk of seriously damaging morale. Many people will assume you’re not considering qualitative performance elements.

It’s how you use them

You can avoid these pitfalls if you’re careful. Consider the example above in which your team is concerned about slipping productivity metrics. If you take a close look at the numbers, understand them in context, and diagnose the situation, you can have a productive dialog about how to improve.

Perhaps your team tackled more complex features, therefore completing fewer. That might be okay, or you might agree as a team that you could have done a better job of simplifying the feature work.

Or maybe you look at a different metric and see that your overall support load went up 50% due to growth in your customer base. You can then decide to live with that balance or try to augment your team’s capacity to handle support while developing new features.

Starting with the measurements, a considered discussion can lead to tangible process improvement. In the next post, I describe a process improvement we validated and measured with Imhotep.

Read the full series of blog posts:

Using Metrics to Improve the Development Process (and Coach People) cross-posted on Medium.

©2025 Indeed - Cookies, Privacy and Terms of Service

Do Not Sell My Personal Information - Accessibility at Indeed