►
From YouTube: Heat, Light, and Love: Telling Twitter's Open Source Program Office's Story | Sean & Remy |CHAOSScon
Description
Session: Heat, Light, and Love: Telling Twitter's Open Source Program Office's Story
Making it simple to trust, ship, and grow open source at Twitter demanded visibility into contribution trends that were not readily available. Twitter's open source program office and the Augur project collaborated with CHAOSS using student interns from Google's Summer of Code, Twitter's intern program and the University of Missouri. First, this talk will describe Twitter's engaging interface design and its fit to the needs of Open Source stakeholders within Twitter, but outside the open source program office. Second, we will describe how an open API and data collection tool, Augur, evolved in close collaboration with Twitter.
Slides: https://chaoss.github.io/website/CHAOSScon/2020EU/slides/heat_light_love.pdf
-----
About CHAOSScon
Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, Value, and Common Metrics.
https://chaoss.community/chaosscon-2020-eu/
A
So
when
you
want
to
create
metrics
I
want
metrics,
your
organization
says:
I
want
metrics
chances
are
there's
somebody
down
here
in
the
corner.
Photobombing,
you
saying
you,
don't
really
know
what
you
mean.
Do
you,
and
so
this
is
an
iterative
process
when
we're
we're
learning
what
all
these
metrics
actually
mean
in
one
particular
organizational
context:
oops
and
we
had
kind
of
an
unexpected
journey-
didn't
want
to
put
pictures
of
interns
or
my
students
up
there
without
permission.
So
these
are
penguins.
A
A
What
you
want
to
see
me
about
that?
Keep
going,
yeah,
okay,
so
the
first
time
we
did
this.
We
had
this
sort
of
beautiful
vision
of
these
elaborate
things
that
would
explain
succinctly
what
were
the
clusters
of
activity
on
a
project
and
how
do
we
drill
in
on
them,
and
we
kind
of
ended
up
with
augers
front
end
being
a
little
bit
like
this
child's
drawing.
A
Pull.
Requests
issues
comments,
my
own
lists,
those
kinds
of
things
and
then
Remy
had
a
really
great
team
of
interns
who
focused
on
these
beautiful
visualizations.
That
summarize
that
data
you
know
in
a
meaningful
and
important
way.
So
we
went
from
kind
of
disorganized
trying
to
figure
it
out
to
our
group
really
focused
on
collecting
data
and
available
and
Ramiz
group
made
it
beautiful.
Yeah.
B
B
A
B
B
We
wanted
to
put
together
a
multidisciplinary
group
of
people
who
both
had
front-end
and
back-end
design
skills,
as
well
as
some
data
science
and
metrics,
and
we
came
up
with
a
really
simple
set
of
requirements.
We
said:
okay,
if
we're
gonna,
do
any
review,
what
some
low-hanging
fruit
we
can
go
after
github
activity,
metrics
that
were
being
published
and
auger
was
a
really
simple
way.
We
could
do
that
and
at
the
Twitter
open
source
program
office
we
sort
of
hey.
What
would
this
thesis
about?
B
So
we
broke
down
those
different
gift,
hub
activity,
metrics
and
put
it
into
these
buckets,
and
he
said
well,
if
we're
gonna,
look
at
it
from
that
perspective
in
a
year
in
review,
we
want
to
be
able
to
show
the
work,
that's
being
put
in
the
contributions
that
we
made
and
the
different
ways
that
we
interact
with
the
community,
and
this
website
looks
gorgeous.
It
was
built
all
on
open-source
software.
B
The
repo
is
on
github,
it's
open
licensed,
people
can
fork
it
and
it's
there
for
anybody
to
use,
and
it
is
a
12-month
sliding
look
back
window.
So
it
doesn't,
it
doesn't
just
when
we
built
the
year-in-review.
We
knew
that
you
know,
like
Sean,
said
interns
really
the
the
wheels
on
the
wagon
that
kept
the
program
moving.
So
we
had
to
anticipate
that
we
were
not
going
to
have
active
developers
to
regenerate
this
year
in
review
every
month
or
every
day
or
every
whatever.
So
we
have
travesty.
B
I
they've
runs
the
scripts
that
hit
auger
that
pulls
in
the
data
that
commits
it
to
a
repo
that
puts
it
then
and
regenerates
the
website
on
a
weekly
basis.
So
you
can
see
over
the
past
months
what
has
happened
and
I'm
just
gonna
reload
it,
because
Jenny
Yin
did
a
great
job
of
putting
all
these
animations
in
here,
so
that
it's
a
little
visual
and
engaging.
So
the
first
is
a
top-ten
repo.
So
this
is
just
a
straight
up.
You
know
aggregate
and
count
up
all
of
the
top
commits.
B
This
is
the
one
that
we
kind
of
fudged.
This
is
like
github
does
a
location
field?
It's
just
though
it's
a
free
text
field.
So
it's
not
easy
to
geocode
all
those
things
and
figure
you're,
not
chromatically,
so
this
is
as
of
maybe
July
of
2019.
We
broke
it
down
by
across
the
different
parts
of
the
world
where
all
of
our
top
contributors
come
from
when
it
comes
to
heat
commits
as
well
as
committers,
where
the
metrics
that
we
were
thinking
of.
B
It's
using
an
upstream
data
source
that
was
cool,
but
there
were
some
challenges
that
we
had
in
doing
that,
too,
there
were
instances
where
we
had
been
scraping
because
of
work.
We
had
done
in
previous
year
as
Shana
talked
about.
We
had
been
scraping
it
of
ourselves.
So
when
we
mint
went
to
make
this
visualization,
we
actually
found
out
that
there
was
missing
data
on
the
hoggar
side.
B
So
not
only
were
we
able
to
send
pull
requests
and
feature
requests
back
and
forth
and
slack
between
the
gsok
students
and
the
interns
in
the
Osmo,
but
we
were
also
able
to
then
contribute
our
own
data
that
we
scraped
back
upstream
to
auger
and
make
that
upstream
database
more
complete
and
a
little
more
granular,
so
that
other
people
could
use
the
data
too.
So
this
is
sort
of
a
culmination
of
three
seasons
of
development
right.
It's
it's
sweet
to
be
here.
B
The
first
time
that
I
got
to
talk
about
this
work
was
at
here
and
Kaos
Khan
in
this
room,
when
we
did
the
bee
swarm
visualization,
and
that
was
a
product
of
an
undergraduate
capstone
research
project.
And
then
we
came
back
the
next
year
and
we
built
out
the
metrics
reports
and
then
last
year,
to
top
it
off
after
third
time's
the
charm
we're
able
to
put
together
something
that
was
a
little
more
cohesive
and
a
little
more
presentable.
B
A
Really
think
it's
I
think
it's
that
story
of
students
and
organizations
working
together
to
try
to
figure
their
way
through
this
unstructured
space
that
that
is
interesting
and
I.
Think
I
think
it's
important
like
when
you
go
to
see
that
you
want
to
have
trends
and
you
want
to
have
them
go
back
farther
in
time.
You've,
probably
if
you've
been
collecting
data,
there's
some
things
like
github
or
other
platforms
only
give
you
at
a
moment
in
time,
and
if
you
collect
that,
then
you
can
share
it
into
a
tool
like
auger
and
use
it.
A
It's
so
like
metadata
about
the
total
fork,
total
contributors,
things
like
that
github
doesn't
let
you
get
that
back
in
time.
They
just
let
you
pull
it
at
a
point
in
time,
and
so
by
being
able
to
integrate
the
metrics
that
you've
been
gathering,
we
can
show
up
a
bet
that
longer
period,
and
you
know,
as
we
go
forward,
trying
to
get
g-shock
students
this
summer
and
find
ways
to
work
with
Remy's
next
round
of
interns
and
also
function
a
slide.
A
A
We
can
do
that
and
then
the
next
things
that
we're
working
on
with
auger
that
we
think
will
be
interesting
to
a
lot
of
people
are
a
push
notification
to
slack.
We've
got
a
slack
pot
now
that
just
really
lacks
a
configuration
page,
so
you
can
specify
your
auger
instance,
and
we
also
realized
that
we
don't
want
to
build
front
ends
for
all
of
the
possible
data.
B
So
there
was
some
rudimentary
work
that
the
my
predecessor
Chris
had
built.
We
had
a
Python
script,
you
could
run
by
hand,
they
would
populate
a
spreadsheet
somewhere
with
like
one
row
per
repo
with
some
of
this
data
right,
but
it
was
very
brittle.
It
was
based
on
the
older
api's.
It
was
something
you
had
to
run
manually.
B
It
was
something
we
knew
we
wanted
to
upgrade
so
the
when
we
started
the
beast
one
visualization
in
2017
that
was
sort
of
one
of
the
first
ways
to
grok
like
the
whole
history
of
a
repo
and
present
it
in
one
quick
visualization
to
give
people
who
were
just
trying
to
figure
out
what's
going
on
with
the
project,
a
good
view
into
it.
From
that
we
were
able
to
say,
okay,
we
need
metrics
reports
and
we
need
them
by
repo,
but
we
also
would
like
to
have
them
by
org.
B
So
we
built
open-source
doctora,
comm,
slash
metrics
and
you
can
go
in
and
restfully
go
and
say
what
the
github
org
is.
What
the
repo
is.
It'll
show
you
a
weekly
diff
of
what's
happened
as
far
as
plus
or
minus
on
each
of
those
github
metrics,
but
that
wasn't
engaging
across
the
board.
It
wasn't
visually
beautiful.
We
had
one
student
Himanshu
Mishra,
who
built
most
of
the
backend
and
then
built
some
of
this
front-end
stuff,
and
we
said
okay,
we'll
get
around
to
putting
a
more
beautiful
front
end
on
it.
B
B
Like
I
said,
we
had
a
very
strong
front-end
development
team,
Jennifer,
Z
and
Jennifer
Yin.
Both
worked
on.
You
know,
building
that
out
with
our
internal,
like
spiritual
successor
to
bootstrap
called
feather
and
a
few
other
things
too
so
I
mean
this,
isn't
just
about
Lake,
there's
a
whole
story
here
and
we
could
not
have
done
it
without
the
support
of
the
cast
community,
professor
Goggins
and
the
partners
we
had,
especially
the
two
Sox
students.
B
B
B
So
I'm
an
open-source
guy
right
I
believe
that
these
metrics
are
already
public
and
they're
just
hard
to
put
together.
So
all
of
the
data
that
we
used
to
generate
the
metrics
reports
is
all
saved
alongside
the
web
forms
that
we
put
it
into
so
we
have
those
metrics
in
raw
form
in
the
JSON
and
from
the
API
calls
that
we're
pulling
they're
also
from
our
github
scraping.
But
we
also
have.
Can
you
repeat
the
question
again.
C
B
That's
where
our
external
audience,
that
is
us
being
transparent
about
the
work
that
we're
doing
so
that
we
can
be
accountable
to
ourselves
in
others,
but
inside
of
the
company,
really
it
was
about
giving
those
specific
teams
metrics
on
a
weekly
basis,
so
that
they
could
use
them
in
their
stand-ups.
There
wasn't.
This
is
the
beginning
right.
This
is
where
the
baseline
is.
Once
we
have
like
sort
of
the
set
of
what
where
we
are
at
from
there,
then
you
start
to
do
sort
of
derived
metrics
from
it.
B
Project
and
product
managers
really
enjoy
to
have
so
that
they
can
make
those
goals
and
target
that
more
we're
at
the
point
now
at
the
Osmo
twitter
they're,
at
the
point
where
that
information
is
being
delivered
on
a
weekly
basis
and
they
can
action
on
it
as
they
want
being
more
strategic
about,
it
is
sort
of
where
all
of
the
open
source
projects
are
trying
to
get
to
right.
This
is
the
easier
part.
The
harder
part
is,
how
do
we
move
them
and
take
the
next
step?
B
Well,
I
will
take
the
time
then
to
say
thank
you
to
Professor
Goggins.
This
was
again
it
was
a
three-year
endeavor.
It
started
with
spreadsheets.
It
turned
into
metrics
reports
and
ended
up
with
an
API
layer
with
a
beautiful
regenerated
sliding
look-back
built
NCI
automated
thing
that
you
know
we
ship
this
in
July,
I
haven't
touched
the
repo
since
then,
and
it's
still
up.
B
So
these
are
the
kinds
of
things
that
when
we
build
on
Rails
with
the
upstream
partners,
we
donate
and
we
dedicate
that
data
back
to
the
community
and
other
people
can
fork
and
work
off
of
it.
I
think
that
this
is
the
kind
of
way
that
we
want
to
be
building
metrics
in
the
future,
so
that
across
the
board,
so
that
people
can
not
have
to
spend
their
time
worrying
about
building
things
versus
building
communities
that
build
metrics
to
understand
things
right.
B
So
from
a
company
standpoint,
we
did
not
have
the
resources
to
do
the
type
of
work
without
Professor
Goggins
and
without
the
gsok
students
and
without
the
undergraduate
research
fellows
that
we
worked
with
at
University
of
San
Francisco
and
Matt
your
students
as
well
I
mean
it
was.
It
was
a
team
effort.