►
Description
Presented by Emma Dickson, Data Scientist/Data Engineer, IBM
How do you track whether GitHub is supporting and increasing the frequency of good coding behaviors like code review, continuous integration, and social coding for your company? When faced with this problem, IBM dove into their instance of GitHub Enterprise. In doing so, they gained insight into how IBM's internal coding practices within GitHub have developed since 2015 and information about the health of the ecosystem that has sprung up within GitHub. In this talk, you'll hear about their methods of investigation that can be applied to any organization and enterprise-specific datasets to apply business context to the data.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hi
I
am
Emma
Dixon,
my
pronouns.
Are
they
them
I
work
at
IBM
in
a
small
four-person
squad,
and
this
year
we
did
kind
of
an
octave
arson.
Spired
intern
choose.
Why
I'm
here
to
talk
to
you
today?
So
the
talk
is
called
insights
into
github
Enterprise,
how
IBM
analyzes
the
impact
of
github
adoption
so
I
want
to
give
a
little
context
about
where
my
small
four-person
squad
sits
within
IBM,
because
I
think
it's
helpful
to
understand
why
we
undertook
this
project
in
the
first
place,
why
it
was
interesting
to
us.
A
So
we
sit
under
toolbox
and
toolbox.
Is
the
larger
group
within
IBM
that
works
to
bring
the
best
third-party
tools
in
the
industry?
Things
like
slack,
github,
Safari
books
to
IBM
errs
in
order
to
support
their
work,
and
we
manage
instances
of
these
tools
and
we
surface
insights
into
their
usage
across
all
of
IBM,
and
that
team
sits
under
the
CIO
directly,
which
is
Fletcher
Previn,
and
so
my
squad
is
the
insight
squad,
which
is
part
of
toolbox,
we're.
Basically,
the
data
analytics
team
within
toolbox.
We
use
machine
learning,
data
science.
A
We
create
analytical
pipelines
to
derive
insights
into
tool
usage
across
the
company,
as
well
as
predicted
option
trends.
We
perform
analysis
on
all
of
the
14
tools
that
toolbox
covers
and
we
have
a
total
population
of
users
of
about
500,000
people.
So
in
2019
we
wanted
to
analyze
the
usage
of
github
across
IBM
and
see
how
it
had
impacted
the
way
that
IBM
has
worked.
A
So
it's
important
to
understand
before
we
get
into
all
of
that
kind
of
how
github
came
to
IBM,
because
obviously
it
wasn't
always
there
so
IBM
adopted
github
in
2015,
and
the
idea
was
that
it
would
improve
developers,
productivity
and
engagement,
that
it
would
encourage
collaboration
code
sharing
code,
reuse,
all
of
that
good
kind
of
social
coding
stuff,
and
we
also
thought
that
it
would
probably
improve
talent,
attraction
and
retention
so
currently
or
the
last
time.
I
checked
some
time.
A
A
So
in
2019
it's
been
four
years
since
github
came
to
IBM
and
we
hadn't
done
any
real,
in-depth
level
of
analysis
into
how
github
was
being
used.
Aside
from
just
those
kind
of
general
usage
numbers
that
I
mentioned,
so
we
knew
how
many
people
were
active
within
github
and
we
could
see
how
that
trended
over
time,
but
we
hadn't
done
any
in-depth
analysis
of
what
was
going
on
with
how
people
were
actually
using
the
tool.
So
we
came
up
with
a
couple
of
questions.
We
were
just
trying
to
brainstorm.
A
You
know
how
do
we
see
what's
going
on
and
we
wanted
to
know
how,
with
practices
around
coding
and
specifically
with
regards
to
collaboration
code
sharing
and
reuse
changed
over
time?
How
are
these
behaviors
around
coding,
distributed
across
IBM
from
kind
of
a
business
perspective
and
as
IBM
ears
have
self-organized
in
github
Enterprise?
Is
there
a
need
for
garbage
collection?
So
the
first
question
was
important
because
we
wanted
to
see
if
github
had
fulfilled
its
use
case,
if
it
had
actually
kind
of
done
the
things
that
we
thought
it
would
do.
A
The
second
one
was
important
because
we
wanted
to
see
how,
from
a
business
perspective,
certain
areas
of
the
company
were
performing
in
those
above
behaviors
and
the
last
one
was
important,
mostly
because
if
you
have
things
that
are
unnecessary
in
a
large
enterprise
organization
like
IBM
you're,
probably
costing
money,
you
could
probably
save
money
by
getting
rid
of
whatever
is
redundant
and
you
might
have
people
looking
for.
You
know
orgs
that
don't
exist
for
repos
that
aren't
relevant
anymore.
So
there's
there's
motivation
to
keep
your
organization
pretty
clean.
A
So
our
initial
thought,
with
how
to
undergo
this
type
of
analysis,
was
to
look
at
the
github
API.
We
figured
out
pretty
quickly
that
that
would
not
work
for
our
scale.
It
was
just
way
too
much
both
on
github
Zen
to
handle
and
ours.
So
we
decided
to
look
at
the
database,
so
I
want
to
go
into
kind
of
how
we
set
up
the
technical
part
of
that
report
and
then
I'll
get
into
what
we
actually
found.
We
did
it,
but
you
know
immediately
when
you
sit
down
to
a
new
project
like
this.
A
You
come
up
with
the
constraints,
so
the
first
one
was
we
had
to
replicate
the
database.
Our
sre
squad
was
the
one
who
was
managing
our
IBM's
instance
of
the
github
enterprise
database,
and
we
absolutely
could
not
touch
that
instance,
because
it
was
our
production
instance
and
for
a
report
like
this
in
the
early
stages.
A
Negotiating
that
and
dealing
with
that
level
of
risk
was
just
not
something
that
anybody
wanted
to
undertake.
So
instead
we
decided
all
right.
We're
gonna
have
to
replicate
the
database
instance
and
host
it
ourselves.
So
that
was
the
first
constraint.
The
second
was
sanitation.
We
couldn't
surface
any
private
repo
content,
basically
anything
to
do
with
repos
that
were
merged
private
or
sensitive
user
information
from
the
github
enterprise
database,
and
we
couldn't
increase
our
authority
over
the
github
data
and
what
that
means
was.
A
Basically,
we
didn't
want
any
of
the
additional
responsibility
that
our
sorry
squad
was
dealing
with
because
they
had
the
authority
over
the
data
to
look
at
those
sorts
of
things
and
kind
of
do
that
in-depth
analysis.
We
wanted
to
remain
pretty
normal
users
of
github,
so
by
necessity
we
had
to
censor
certain
information
that
we
weren't
privy
to
and
the
third
was
creating
a
pipeline,
and
this
was
partially
just
because
of
how
the
inside
squad
usually
works.
We
prefer
to
make
things
in
pipelines
because
we
want
things
to
be
repeatable.
A
So
those
were
our
constraints
and
I'm
gonna
go
into
kind
of
how
we
addressed
each
of
them.
The
first
one
we
started
with
was
how
we
replicate
the
database
and
host
it
and
kind
of
deal
with
that.
So
it's
helpful
to
understand
how
we
managed
our
other
data
sources,
because
we
basically
just
slotted
the
database
into
our
existing
setup.
So
the
data
insight
squad
uses
a
data
lake
with
hive
and
presto
to
manage
multiple
data
stores.
A
We
manage
these
instances
with
helm
charts
and
we
host
them
on
our
own
kubernetes,
cluster,
hoster
and
IBM
cloud,
so
the
github
enterprise
database
instance,
we
decided
would
just
be
hosted
on
our
kubernetes
cluster
and
connected
to
the
existing
infrastructure
and
that's
a
little
wordy.
So
here's
just
a
quick
diagram
that
kind
of
makes
it
really
clear.
Presto,
sits
above
everything
else
over
hive
connects
directly
to
the
MySQL
github
enterprise
database.
A
Your
views
and
hive
is
where
we
put
the
tool
stuff,
like
slack
Safari,
all
those
14
tools,
as
well
as
the
business
information,
which
is
what
blue
pages
is
so
we're
able
to
pretty
easily
connect
the
github
enterprise
database
to
presto
and
use
the
existing
presto
structure
to
connect
that
information
to
anything
else
we
want,
and
then
we
moved
on
to
sanitization.
So
privacy
was
a
big
concern
for
us.
We
talked
with
the
SRA
squad
and
other
domain
experts
about
where
private
repo
content
and
SBI
might
be
stored
in
the
database.
A
Schema
I,
also
looked
through.
All
of
the
like
I
think
that
it
was
300
nearly
400
table
schemas
just
to
see
what
seemed
like
it
could
potentially
be
sensitive
information.
We
had
a
sit-down
meeting
where
we
figured
out
what
exactly
we
wanted
to
censor
and
once
we
identified
what
we
weren't
allowed
to
look
at,
we
censored
columns
with
zeros
rather
than
removing
them.
A
You
never
want
to
actually
delete
the
information
right,
so
we
decided
the
best
thing
was
just
to
zero
out
any
columns
that
we
didn't
want
to
surface
and
we
managed
all
of
that
with
switch,
which,
if
you're
not
familiar,
it's
just
a
tool,
a
database
management
tool
that
allows
you
to
have
a
deployment
job
which
in
our
case,
was
the
sensor
job,
the
verification
associated
with
that
deployment
and
a
revert
job.
So
we
had
an
individual
job
for
every
act
of
censorship
that
we
wanted
to
perform
on
the
database.
A
We
could
verify
each
of
those
to
make
sure
that
the
information
was
actually
zeroed
out
and
if
it
wasn't,
we
could
revert
it
try
to
figure
out
what
went
wrong
and
so
all
of
that
kind
of
went
into
building
the
pipeline
and
there's
a
diagram
that
goes
into
this
a
little
bit
better
on
the
next
slide.
But
I'm
just
going
to
talk
a
little
bit
about
big
part
of
setting
up
our
pipeline
was
negotiating
with
the
SRA
squad
about
how
often
we
would
receive
the
data,
so
we
settled
on
a
monthly
basis.
A
We
could
handle
that
about
once
a
month,
so
it
made
the
most
sense
for
our
initial
use
case,
and
once
we
have
that
data,
we
update
the
kubernetes
AML
file
to
point
to
the
latest
database,
backup
in
our
object
storage.
We
run
switch
against
the
new
database
instance
to
ensure
that
it's
sanitized
and
then
it's
basically
ready.
So
this
is
just
kind
of
a
step
by
step
breakdown.
We
get
the
monthly
backup
into
our
cloud
object.
Storage.
We
manually
delete
the
old
database.
A
A
That's
the
part
that
takes
about
24
hours,
because
it's
dealing
with
all
of
this
data
and
then
once
that's
done,
we
drop
the
old
switch
database,
create
a
new
switch
pod
and
if
all
of
those
sanitization
jobs
complete
successfully,
then
we
declare
it
ready
to
be
queried
and
query
in
the
database.
Like
I
said
earlier,
since
it's
connected
to
our
existing
data
lake,
we're
able
to
just
query
it
directly
through
presto
access
to
the
Presto
instance
is
limited
to
the
insight
squad
members.
A
So
only
people
directly
on
my
team
are
able
to
actually
directly
touch
this
instance
of
the
database
and
we
use
chario
as
a
data.
Visualization
tool
and
chario
is
basically
just
a
dashboarding
tool.
It
allows
you
to
connect
to
data
stores
like
presto,
so
we
to
secure
SSH
tunnel
that
we
also
hosted
in
our
cluster.
You
connect
cheerio
to
that
and
you're
able
to
just
create
a
new
dashboard
and
directly
query.
The
database
instance.
A
So
we
had
all
of
the
technical
stuff
in
place.
We
were
able
to
query
the
database
and
we
had
a
vague
idea
of
what
we
were
trying
to
figure
out,
but
just
what
we
wanted
to
analyze.
But
now
I
want
to
go
through
how
we
broke
down
each
of
those
three
questions
I
mentioned
earlier,
and
what
we
actually
materially
looked
at
in
the
database
to
come
to
those
conclusions.
So
the
first
one
that
we
looked
at
was
how
do
we
analyze
these
coding
behaviors?
A
Because
again,
we
wanted
to
see
if
github
had
fulfilled
its
original
use
case.
Had
it
increased
the
social
behaviors
that
we
were
expecting
it
to
you.
So
we
talked
to
our
service
quad
and
some
other
people
with
domain
knowledge
to
figure
out
what
would
help
track
the
behaviors
which
we
were
interested
in.
We
also
wanted
to
look
at
the
number
of
private
versus
public
repos,
because
we
considered
that
to
be
a
fairly
good
measurement
of
if
people
were
engaging
in
social
coding
and
kind
of
breaking
down
silos.
A
A
Don't
want
to
say
shallow,
because
that
that's
kind
of
passing
judgment,
but
just
different
levels
of
engagement,
the
first
being
people
who
are
just
opening
are
commenting
on
issues
and
we
knew
that
those
users
existed
because
we
talked
to
people
in
sales
and
other
kind
of
non-technical
roles
who
just
really
liked
using
github
for
issue
tracking.
So
that's
one
level
of
engagement
and
the
second
is
people
who
push
code.
The
third
are
people
who
open
PRS
and
the
fourth
or
people
who
were
viewing
PRS.
A
So
we
kind
of
imagined
this
tiered
approach
to
you
know
a
shallow
involvement
with
just
using
kind
of
the
tools
for
issue
tracking,
engaging
in
coding,
behaviors,
engaging
in
coding,
behavior,
subject
to
peer
review
and
then
actually
providing
the
valuable
service.
A
peer
review,
and
the
database
has
tables
that
correlate
to
all
of
those
pretty
directly.
So
there's
a
table
dealing
with
when
people
are
reviewing
PR
is
opening.
A
Pr
is
pushing
code,
so
it's
fairly
easy
to
just
break
that
down
by
when
those
behaviors
occurred,
connect
them
to
unique
identifiers
and
get
the
aggregate
count
just
how
we
approached
it.
And
the
second
question
was:
how
do
we
connect
this
to
business
info?
So
we
decided
to
break
down
the
results
of
some
of
our
queries
across
business
units
and
that's
an
internal
IBM
term.
There's
about
ten
of
them
in
the
company.
A
They
range
in
size
from
10,000
employees
to
around
a
hundred
thousand,
and
we
picked
business
units
because
one
they
were
of
interest
or
stakeholders.
Vps
are
usually
pretty
interested
in
how
their
huge
group
is
doing.
That's
kind
of
the
level
that
they,
you
know,
tend
to
look
at
things,
but
also
because
it
was
high
enough
in
the
employee
chain
that
reverse
engineering,
any
sort
of
personal
information
would
be
completely
impossible.
A
We
wanted
to
eliminate
the
scenario
where
you're
able
to
search
by
manager,
and
you
stumble
across
a
three-person
team
and
suddenly
you're
able
to
figure
out
how
your
neighbors
performing
or
your
boss
is
able
to.
You
know
criticize.
Why
haven't
you
contributed
to
our
commit
numbers
recently?
We
wanted
to
avoid
that
entirely
and
there's
really
no
way
that
somebody's
going
to
pick
you
out
of
a
crowd
of
you
know
ten
thousand
to
a
hundred
thousand.
A
How
can
people
self
organize
and
there's
basically
only
three
there's
repositories,
teams
and
organizations,
and
those
are
the
structures
that
you
can
create
on
your
own
and
manage,
and
this
one
actually
was
kind
of
the
most
interesting
thing
to
debate,
because
it
raised
a
lot
of
really
interesting
questions
about
what
what
is
something
that's
unnecessary,
especially
in
this
kind
of
enterprise
space?
Is
it
a
repo
that
hasn't
been
touched
in
six
months?
Is
it
a
year?
Is
it
an
org?
A
That's
kind
of
just
a
duplicate
of
a
team,
you
know
what
is
unnecessary
and
we
basically
decided
to
just
go
with
the
strictest
possible
definition.
So
after
some
discussion
we
decided
that
the
only
way
something
was
unnecessary.
It
was
if
it
had
been
abandoned
and
things
were
abandoned
if
they
had,
if
they
were
comprised
only
of
people
who
no
longer
worked
at
IBM.
A
I
want
to
go
over
the
results,
broadly,
because
I
think
that
that's
I
think
that
that's
more
helpful
than
just
kind
of
pointing
out
some
charts
and
talking
about
them.
So
the
first
question
that
we
looked
at
was
how
have
practices
around
coding
changed
over
time
and
we
found
a
steady
increase
in
the
numbers
of
users
pushing
code
engaging
in
collaborative
behavior
over
the
years.
A
We
also
saw
a
similar
number
of
private
versus
public
repos
and
I'll
get
into
that
a
little
bit
later,
because
it's
one
of
our
kind
of
follow
up
actions
and
how
are
behaviors
around
coding
distributed
across
IBM.
They
we
saw
a
really
wide
variation.
We
were
able
to
connect
them
in
kind
of
expected
ways,
so
sales
teams
had
fairly
low
percentages
of
people
reviewing
code,
which
is
what
you
would
usually
expect,
and
then
the
last
one
was
as
IBM
errs
of
self-organized.
A
Is
there
a
need
for
garbage
collection
and
we
did
find
abandoned
structures,
so
there
was
a
need
for
garbage
collection,
but
we
didn't
see
as
many
as
we
had
feared,
especially
with
a
really
large
company.
We
were
a
little
bit
afraid
that
once
we
got
in
there,
we
would
see
that
there
were
a
lot
of
abandoned
teams
or
orgs
or
repos,
and
the
numbers
were
actually
pretty
low.
So
we
were
happy
with
that
and
I've
broken
up
some
of
the
charts
that
I
want
to
look
at
just
by
the
questions.
So
again
how?
A
If
practices
around
coding
changed
over
time,
and
so
you
can
see
that
the
pusher
count
is
climbing
steadily
and
significantly
to
around
42,000
and
at
the
same
time
you
see
the
centage
of
users
who
are
pushing
code
dropping.
So
the
percentage
is
the
the
overall
percentage
of
users
of
get
FN
price
who
have
ever
pushed
code
or
the
count
of
users
in
the
github
enterprise
system
who
have
ever
pushed
code
and
for
us
when
we
saw
this,
we
immediately
connected
it
to
that
first
tier
of
the
user
engagement
that
we
identified
earlier.
A
So
if
you
look
at
the
beginning,
you
know
in
2015,
oh
I
think
we
only
had
three
people
using
github
and,
of
course
those
three
people
are
early
adopters,
they're,
the
first
people
to
get
on
the
system,
they're
going
to
be
developers
who
are
really
interested
in
using
github
for
it
development
use
case.
But
as
time
goes
on,
we
see
more
people
adopt
github
for
issue
tracking.
Only
and
that's
why
we
see
the
increase
in
the
count
and
the
simultaneous
decrease
in
the
overall
percentage.
A
And
this
is
a
graph
of
the
count
of
public
and
private
repositories,
so
a
little
bit
of
explanation,
basically
at
any
month
and
year
on
this
graph,
it's
looking
at
the
of
the
repos
created
in
that
month
and
year.
What
is
the
count
of
public?
What
is
the
count
of
private
public
being
green,
private
being
red?
A
And
this
further
validated
our
kind
of
four
tier
model,
because
we
saw
that
there
were
around
26,000
people
who
were
opening
pool
requests
so
less
than
people
who
were
pushing
code
and
even
less
people
who
were
actually
reviewing
code
only
around
19,000
and
that's
you
know,
that's
kind
of
to
be
expected.
There
are
always
less
people
reviewing
code
than
you
want.
There's
always
people
more
willing
to
open,
PRS
and
review,
but
it
was
interesting
to
see
the
same
overall
trend
of
the
count
continuing
to
grow,
while
the
percentage
of
overall
users
shrinks
slightly.
A
A
Same
for
again,
the
pull
requests
versus
performing
review,
even
among
like
similar
business
units,
you'll,
see
that
you
know
maybe
there's
for
some
reason.
The
bottom
one
second
from
the
right
has
a
lot
of
people,
opening
pull
requests,
but
an
extremely
low
and
out
of
people
reviewing
pull
requests
so
that
one
this
behavior
was
pretty
interesting
to
us
and
as
IBM
herself
organized
is
there
a
need
for
garbage
collection.
So
the
first
thing
we
made
was
a
heat
map
that
was
just
shot.
A
Oh
sorry,
I
shouldn't
touch
that
we
made
a
heat
map
that
was
showing
the
number
and
the
count
of
abandoned
structures
and
each
of
those
rows
again.
I
guess
each
of
those
columns
corresponds
to
a
business
unit
whose
name
I've
chopped
off
at
the
bottom.
But
you
can
see
there
were
kind
of
clusters
of
organizations
that
were
abandoned
versus
repositories
versus
teams,
and
actually
we
found
that
the
most
likely
thing
to
be
abandoned
was
an
organization.
Repositories
were
pretty
rarely
abandoned
and
teams
were
kind
of
middling.
A
You
know
somewhat
often
abandoned,
but
not
as
much
as
organizations,
and
when
we
looked
at
the
actual
accounts,
we
were
pretty
pretty
happy,
because
each
of
these
lines
represents
a
business
unit
and
at
the
maximum
we
saw
56
abandoned
teams
which,
in
a
group
of
you
know
up
to
a
hundred
thousand
employees,
is
pretty
decent
and
same
for
repos.
We
only
saw
at
max
17
abandoned
repos,
so
people
were
doing
a
pretty
good
job
of
cleaning
up
after
the
repos
and
shutting
them
down
when
they
were
no
longer
necessary.
A
So
the
implications
of
these
findings
like
what
do
we?
What
do
we
do
with
this?
What
do
we
take
away
from
it?
And
we
saw
it
pretty
clearly,
we
have
a
fairly
high
percentage
of
users
at
IBM
who
use
github
enterprise
without
pushing
code
or
engaging
in
those
collaborative
coding
practices
that
we
were
trying
to
measure
in
the
first
place.
So
who
are
these
people
from
talking
to
some
users?
We
had
a
pretty
fair
idea
that
they
were
mostly
salespeople
or
managers.
A
Who
were
you
know
in
touch
with
technical
teams
and
wanted
to
stay
on
top
of
what
people
were
doing,
but
weren't
actually
engaging
in
code?
But
we
didn't
do
a
really
in-depth
analysis
of
that
user
population.
For
this
report,
our
initial
focus
was
more.
How
has
the
use
case
of
github
been
carried
out,
so
we
saw
pretty
clearly
that
we
needed
to
do
further
analysis
on
this
population
and
figure
out.
You
know
what
were
they
contributing
to
the
github
ecosystem
at
IBM?
How
is
their
use
affecting
how
other
people
were
using
it?
A
A
It's
tricky
to
contact
somebody
to
clean
up
an
org
when
everybody
in
that
org
has
no
longer
works
for
your
company,
so
we
need
to
figure
out
a
solution
for
maybe
preemptively
recognizing
that
something
is
at
risk
of
being
deprecated
or
taking
authority
over
something
where
everybody
is
gone
from
the
company.
That's
a
question
that
we
still
have
to
address
and
the
number
of
public
and
private
repos
is
near.
A
Even
is
there
anything
we
can
do
to
encourage
more
public
repos
like
I
mentioned
earlier,
we
had
a
colleague
who
attempted
to
do
something
like
this
kind
of
early
on
in
github
at
IBM
and
his
solution
involved,
putting
a
hook
on
every
repo
opening
up
an
issue
and
the
private
ones
kind
of
politely
asking.
Are
you
sure
that
this
needs
to
be
private?
Could
you
please
make
it
public
and
that
quickly
became
unfeasible
due
to
the
scale
of
what
we
were
dealing
with?
A
So
we
haven't
attempted
anything
similar
to
that
since
then,
and
this
kind
of
seen
how
post
the
numbers
were
kind
of
made.
Us
think
that
we
need
to
address
this
moving
forward,
whether
through
communication
or
some
other
method,
and
so
we
came
away
with
a
couple
next
steps.
Further
automation
of
the
pipeline
using
air
flow.
We've
recently
used
air
flow
on
our
team
to
complete
Ulta
schedule,
a
couple
of
things
for
some
other
repeatable
processes
that
we
had
to
do
and
we
found
it
helpful.
We
also
want
to
reduce
the
latency.
A
Obviously,
like
I
said
it
takes
about
24
hours
to
spin
up
a
fully
functional
instance
of
the
database
and
start
querying
it.
So
we
would
love
to
get
that
time
down
slightly.
We
want
to
keep
promoting
the
work
with
n
IBM
as
a
resource
for
people
to
use
to
keep
abreast
of
trends
within
github,
so
I
didn't
show
you,
you
know
the
whole.
The
whole
report
exists.
A
Basically,
is
this
big
chart
IO
dashboard
with
a
bunch
of
a
bunch
of
charts,
and
the
full
report
is
available
to
anybody
who
works
at
IBM,
because
it's
all
information
that
they're
able
to
look
at
so
they
can
see
how
their
bu
is
doing,
how
trends
increase
or
decrease
over
time?
So
we
want
to
continue
to
promote
that
and
encourage
people
to
look
at
it
and
kind
of
get
a
feel
for
their
place
and
a
larger
github
community.
A
We
also
want
to
continue
the
conversation
with
stakeholders
and
domain
experts
about
how
to
get
the
information
from
the
github
database.
The
database
is
a
really
really
rich
source
of
information.
I
didn't
go
into
it
too
much,
but
they
have
tables
that
would
allow
us
to
figure
out
the
mean
closing
time
for
an
issue
like
clustering
patterns
around
comments,
and
that's
something
that
we
want
to
look
at
in
the
next
version
of
this
report
is
okay,
you
open
a
pull
request.
What's
the
actual
mean
time
for
a
pull
request
to
get
closed
in
IBM?
A
Do
we
see
how
that
changes
over
time?
Does
that
tell
us
anything
there's
a
lot
that
we
can
still
pull
out
from
that
data
store,
and
we
want
to
do
similar,
in-depth
studies
on
other
tools
that
we
manage.
So
the
the
type
of
analysis
that
we
can
do
on
tools
is
limited
by
the
data
that
we
receive
and
luckily
for
us,
the
github
database
has
a
wealth
of
information,
but
this
is
really
the
only
type
of
report
like
this
that
we've
been
able
to
do.