►
Description
Presented by Kyle Daigle, GitHub.
GitHub has a vibrant ecosystem of developer tools that our customers use every day. When the API launched 8 years ago, a few small integrations started to build businesses on top of GitHub's Platform. Today, there are thousands of tools that build on-top of GitHub to provide unique features and functionality to GitHub customers. In this session, we'll share best practices from some of GitHub's integration partners, lessons in scaling integrations for open source, business, and enterprise customers, and discuss how to sell your integration in GitHub Marketplace. You'll leave this talk with some tips for building a SAAS business on a thriving Platform like GitHub.
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
Good
afternoon,
everybody
I
want
to
start
by
sharing
a
quick
story
in
2015.
Github
had
its
first
universe
and
I
was
very
excited
to
talk
at
it,
because
I
wanted
to
share
what
we
were
doing
with
the
github
API.
So
at
the
time,
if
you
wanted
to
integrate
with
github
you're
using
our
REST
API
and
generally,
you
were
using
an
OAuth
application
or
a
personal
access
token.
A
We
shared
how
you
can
use
the
API
where
the
docs
are
how
you
could
get
support,
so
that
was
sort
of
the
initial
version
of
how
we
could
do
things
and
then
the
next
year
we
introduced
the
graph
QL
API.
We
thought
we
had
found
a
better
way
to
integrate
with
the
API
and
we
announced
early
access
for
github
apps,
which
is
a
lot
much
better
way
to
connect
organization
to
a
user
or
an
application.
A
A
Building
and
selling
integrations
and
I
also
want
to
shout
out
to
hubs
that
really
made
this
talk
possible,
so
Corey
and
Yvonne
Corey's,
hero
Vaughn,
is
possibly
watching
on
the
livestream
from
Switzerland.
Thank
you.
So
much
for
your
help
in
this
I
could
not
have
done
this
talk
without
your
help.
I
also
want
to
call
out
all
the
ecosystem,
folks
that
are
here
in
this
talk,
and
here
at
github
and
watching
at
home.
A
They
are
the
ones
that
truly
build
everything
here
to
make
it
possible
to
actually
integrate
with
us
and
so
I
don't
want
to
get
away
without
giving
them
a
shout
out.
So,
like
I
mentioned
first
we'll
talk
about
building
what
it's
like
to
build:
an
integration,
we're
not
going
to
go
into
too
much
detail.
There
were
two
talks
earlier
on
Wednesday
from
Brooks
and
keavy
talking
about
graph,
QL
and
github
apps,
and
we'll
send
you
to
some
resources
to
learn
more
about
that
common
problems
that
people
have
once
they
hit
scale.
A
A
lot
of
integrations
start
great
and
then,
once
you
hit
scale,
things
fall
down
and
then
finally,
we'll
talk
a
little
bit
about
the
experience
and
making
money
convincing
people
to
use
your
integration
and
a
little
bit
more
about
our
marketplace.
But
let's
start
with
building
and
integration
like
I
said
I'm
just
gonna
give
you
a
quick
overview
of
this
there's
a
lot
more
at
developer,
get
hub
com.
A
So,
if
you're
not
familiar
with
an
API
or
github
apps,
we're
not
gonna
go
in-depth,
but
hopefully
I
can
teach
you
enough
just
so
you
can
follow
along
with
an
OAuth
app
you're,
identifying
yourself
as
just
me.
So
usually
this
is
ID
ease
or
places
where
you
want
to
see
the
entire
visibility
of
what
Kyle
can
see.
A
We
have
the
REST
API,
which
is
our
v3
API.
This
is
the
API
that
we've
primarily
had
the
past
eight
or
nine
years.
It
covers
a
bevy
of
data,
a
bevy
of
use
cases
and
is
compatible
with
both
Olaf
personal
access,
tokens
and
github
apps,
and
now
we
have
the
graph
QL
API,
which
is
the
v4
version
of
our
API,
that
we
moved
into
a
production
ready
state
at
satellite.
A
This
doesn't
have
the
bevy
of
data
that
the
REST
API
currently
has
because
of
our
strategy
of
having
our
own
engineers
build
the
graph
QL
API
as
they
power
the
UI
features,
and
so,
instead
of
our
teams
trying
to
skip
ahead
and
get
everything
right
and
then
realize.
Oh,
we
screwed
up
our
own
teams,
can't
use
this
we're
working
with
the
application
engineering
teams
to
implement
the
graph.
A
Ql
schema
that
as
necessary
to
power
this
so
over
time,
it'll
become
more
and
more
powerful,
but
right
now
it's
possible
that
you'll
want
to
use
graph,
QL
and
then
you'll
realize.
Oh,
it
doesn't
have
this
one
piece
of
data
that
I
need.
In
that
case,
you
can
definitely
contact
us
in
the
platform
community
for
him
and
we
can
share
some
more
information
with
you
all
right.
So
that's
the
quick,
deep
dive
on
how
to
integrate
with
us
now.
I
want
to
talk
about
general
best
practices
for
building
an
integration.
A
I
want
to
introduce
you
to
a
Vaughn.
If
you've
ever
emailed
in
to
github
support
about
platform,
you
have
almost
certainly
contacted
Vaughn,
whether
you
knew
it
or
not.
He
was
kind
enough
to
provide
me
a
bunch
of
quotes
about
his
experience
in
helping
you,
we've
also
pulled
some
quotes
from
your
help
tickets
without
identifying
any
of
you
and
we've
also
gotten
quotes
directly
from
you.
So,
let's
start
through
this.
This
is
something
that
we
notice,
especially
at
events.
A
Everyone
seems
a
little
bit
trepidatious
and
reaching
out
and
just
saying
I,
don't
know
you
know,
I,
don't
know
how
to
build
this
I,
don't
know
how
to
use
this
API
I
hit
a
401
I,
don't
know
how
to
I.
Don't
know
how
to
go
from
here.
Please
reach
out
to
us
we're
very
excited.
A
Vaughn
is
great.
Francis
is
great,
who
also
works
in
the
support
team,
and
all
of
our
engineers
are
really
tied
in
to
the
help
system
or
internal
help
tool.
In
order
to
answer
your
questions
for
you.
A
These
are,
these
are
actual
quotes
from
him.
This
isn't
me
putting
this
in.
One
of
the
things
we
want
to
make
sure
is
clear.
Is
that
if
you're
starting
today,
we
would
like
you
to
look
at
graph
QL
very
seriously,
primarily
because
over
time
as
graph
fuel
becomes
more
full-featured,
eventually
we
will
stop
putting
more
things
into
the
rest.
A
So
it's
exciting
my
my
my
favorite
thing
and
I
was
talking
to
the
team
about
this
is,
and
we
could
finally
ship
it
like.
We
know,
there's
so
many
things
that
were
sort
of
not
allowing
you
to
do
or
we
don't
give
you
the
functionality
I
think
over
time,
you'll
see
more
and
more
that
go
into
graph
QL.
The
next
thing
is
this:
nice
quote
from
Vaughn.
That
says:
please
consider
that
graph.
Ql
excuse
me
that
github
apps
are
right
for
your
use
case
and
I
responded
with
yeah.
A
Definitely
just
use
github
apps,
because
Olaf
apps
aren't
meant
to
do
the
things
that
you
really
have
been
doing,
but
you
didn't
have
any
other
options:
o
auth
apps
to
just
be
abundantly
clear,
is
Kyle.
Once
you
see
everything,
Kyle
can
see
not
Kyle
the
business
Kyle,
the
human
being.
So
please,
please,
please
look
at
github
apps
they're
a
much
better
experience
for
our
mutual
customers,
though
they
will
take
some
effort
to
migrate
if
you're
starting
today,
almost
certainly
look
at
github
apps.
A
A
Travis
has
found
that
using
the
configuration
file
in
the
repository
instead
of
having
the
configuration
in
their
web
UI
was
a
better
experience
for
their
customers.
Customers
are
already
comfortable
with
github
they're,
already
comfortable
with
the
UI
and
get,
and
they
likely
already
have
configuration
files.
A
We
talk
about
this
a
lot
at
github
and
Chris
mentioned
this,
and
Jason
mentioned
this
today
and
sometimes
I
think
it
can
sound
like
marketing
fluff.
But
it's
really
true.
It's
important
to
focus
on
the
person
using
your
tool
unless
so
on,
the
person
buying
the
tool.
If
the
people
that
use
the
tool
enjoy
your
tool,
the
person
buying
the
tool
will
want
it.
A
You
can
see
that
in
codices
presentation
today
they
can
share
the
stats
with
the
people
buying
the
people
using
it
can
really
enjoy
it,
and
so
circle
circle
see
I
shared
a
quote
with
us
around
this
too
important
to
start
from
the
beginning,
with
solving
the
pain.
Don't
start
with
a
thing
that
you
think
you
need
to
do.
A
We
need
to
build
CI,
we
need
to
build
project
management
and
then
try
to
graft
paint
on
to
that
after
right
start
with
solving
the
pain
in
waffle,
Andrew,
a
waffle,
provided
this
great
quote,
everyone
sort
of
thinks
that
the
customer
that's
an
open
source,
is
different
than
the
customer
at
a
paid
organization,
that's
different
than
a
customer
at
enterprise.
What
are
customers
that
serve?
All
of
those
are.
A
Excuse
me
what
the
integrators
that
serve
all
those
audiences
have
found
that,
whether
they're
an
open
source
on
github.com
or
on
premises
with
github
enterprise,
it's
the
same
developer.
It's
someone
that
wants
to
have
a
powerful
tool
to
help
their
workflow
and
though
they
have
to
work
in
different
environments.
People
are
choosing
those
tools
across
all
those
segments
and
not
just
sort
of
focusing
on
just
open
source
or
just
on-premises.
So
that's
the
quick
effort
on
building
an
integration.
A
Now
you
have
an
integration.
Hopefully
it
seemed
a
little
bit
seen
a
little
bit
of
success,
maybe
you're
on
product
hunt
or
hacker
news,
and
your
thing
is
blowing
up
what
is
scale.
We
pulled
some
numbers
to
kind
of
give
you
a
rough
idea
to
compare
against
your
your
own
integrations
and
I'll
share
all
my
slides
on
Twitter
after
this.
So
please
feel
free
to
take
take
shots
if
you
want,
but
I'll
put
it
up
just
in
case
I,
move
too
fast
for
you.
A
The
average
API
request
for
an
OAuth
application,
which
isn't
the
best
way
for
us
to
measure,
but
it's
the
broadest
and
so
we're
gonna
use
that
it's
about
6800
per
day.
We
attribute
this
when
looking
at
the
stats,
primarily
that
a
lot
of
people
build
workflow
tools,
scripts,
etc.
So
the
number
kind
of
skews
down
from
an
average.
So
I
wanted
to
look
at
top
integrators
names.
You
would
know,
without
necessarily
focusing
on
the
too
high
or
too
low
and
that's
about
23,000
requests
per
day.
A
So
the
tail
is
huge
right,
primarily
because
a
lot
of
people
are
building
their
own
workflows,
their
own
scripts
for
their
company,
and
it
might
only
have
you
know,
5
to
20
to
100
calls
a
day,
but
when
you're
looking
at
how
quickly
things
can
ramp,
it's
pretty
exponential
very
quickly
now
you're
at
scale
you're
generally
experiencing
some
new
things.
Maybe
your
servers
aren't
so
happy,
maybe
you're
starting
to
get
rate
limit
problems,
and
so
we
started
to
talk
to
the
support
team
to
ask.
A
What's
the
best
thing
that
you
can
do
and
it
starts
with
tracking
requests
and
adding
logging
on
your
side,
which
is
usually
the
thing
you
do
once
there
are
problems
already
hit
I'm
a
developer
too.
I
know
that,
but
it's
important
to
start
a
little
bit
early,
especially
when
calling
out
to
our
API
Yvonne
had
some
suggestions.
A
Let's
make
sure
that
you're
reducing
your
requests
as
you
grow
or
you're
using
conditional
requests
so
that
way,
you're
not
getting
charged
for
the
rate
limit.
Sometimes,
we've
seen
integrators
introduce
bugs
which
immediately
eat,
through
all
the
rate
limit
for
that
hour,
because
you
accidentally
create
a
loop
or
you
create
a
background
job
or
your
jobs,
go
crazy,
at
cetera.
So
there's
a
couple
different
ways
to
manage
that,
like
internally,
we
can
use
like
circuit
breakers,
etc.
It's
usually
good
to
know
if
suddenly
you're
making,
you
know
10,000
more
requests
than
you
were.
A
That's
probably
a
bad
sign
on
your
side.
You
don't
want
to
lock
your
customers
out
for
an
hour
if
you're
using
too
much
of
a
single
person's
quota,
it
can
sometimes
be
important
to
note.
Maybe
I
should
only
run
this
once
they
hit
our
web
UI.
If
that's
an
option,
maybe
I
should
only
run
this
once
we
have
an
event
and
there's
been
a
actual
push,
etc.
A
A
lot
of
you
use
our
REST
API
is
for
get
data,
but
there's
kind
of
a
problem
with
that
because
in
this
example,
which
I
won't
again
not
naming
who
it
is,
you
see
a
situation
where
immediately
with
git
data
right,
you
have
a
variety
of
files.
You
have
a
variety
of
pieces
of
information
that
you
want
to
get
or
add
to
a
repository
and
over
time
you
realize
ok
with
growth.
I.
Just
can't
get
this
out.
A
I
can't
get
everything
that
I
need
out,
I'm
running
out
of
rate
limits,
and
so,
as
you
grow,
it
stops
working
and
so
we'd
like
to
suggest.
Please
don't
you
the
rest.
Dpi's
forget
data.
We
really
would
prefer
you
use
git
itself.
It's
a
better
interface
for
getting
a
large
amount
of
data.
It's
already
figured
out.
The
REST
API
is
very
transactional
and
eventually
we
think-
and
we've
seen
over
the
past
eight
years,
that
you
feel
pain
with
that
API.
A
There's
also
the
situation
where
you
need
lots
of
data,
and
this
is
primarily
for
integrations
that
want
to
understand
an
entirety
of
github
or
how
you
compare
against
the
entirety
of
github
a
lot
of
social
things.
Things
like
libraries
do
want
a
lot
of
data
and
our
API
isn't
really
intended
for
you
to
sort
of
scrape
the
entirety
of
everything
that
we
have
in
the
way
that
it's
built
and
so
there's
kind
of
a
couple
options
here.
The
first
one
is
use
web
hooks
if
you've,
probably
ever
emailed
in
this,
is
usually
answer
number
one.
A
When
you
have
rate
limit
problems,
Web
books
allow
you
to
get
information,
as
the
events
happen
on
a
repository
or
organization
basis.
If
you're
a
github
application,
you
can
maintain
one
single
web
hook.
Instead
of
having
to
maintain
a
variety
of
web
hooks
ask
for
the
events
you
want
and
then,
as
users
install
your
app
that
one
web
hook
will
get
that
new
traffic.
So
it's
a
lot
easier
than
managing
all
these
separate
web
hooks,
which
is
what
some
of
the
applications
that
have
been
in
the
ecosystem
for
a
while
I've
had
to
do.
A
But
this
is
only
really
useful
if
you
can
look
at
the
data,
meaning
it's
installed
on
you,
you
can
have
access
to
it,
but
we
have
a
variety
of
ways
in
which
we
help
partners,
take
all
the
public
data
and
make
it
queryable.
So
there's
a
blog
post
on
our
blog
that
talks
a
little
bit
about
this,
but
the
kind
of
three
major
things
is.
A
A
If
you
don't
want
to
open-source
everything
you
have,
you
need
money
to
eat
and
live
and
have
families
etc,
and
so
now
we
want
to
make
it
a
little
bit
easier.
So
the
first
thing
I'm
just
gonna,
get
out
of
the
way.
Cuz,
it's
the
obvious
one
is
use
marketplace
with
marketplace.
You
integrate
our
billing
api's.
You
can
create
and
manage
your
listing
choose
pricing
plans.
Currently
we
offer
two
ways
to
do
this.
We
offer
it
with
a
sort
of
a
normal
flat
monthly
fee.
Like
you
think
of
most
SAS
offerings.
A
We
also
offer
a
per
unit
option.
We've
seen
integrators
use
this
for
things
like
per
seat.
I
want
to
buy
25
seats,
but
that
unit
is
configurable
by
you.
So
if
you
have
a
set
up
where
the
unit
option
makes
sense,
it
could
be
builds,
it
could
be
something
new
that
doesn't
really
make
sense
in
the
way
that
we've
currently
been
selling
them.
That's
an
option.
You
can
offer
free
plans,
whether
just
generally
or
to
open
source,
which
is
a
very
common
theme
and
we'll
talk
a
little
bit
more
about
that
in
a
minute.
A
Free
trials
like
I
mentioned,
are
coming
October
31st.
You
can
go
through
your
plans
after
that
date
and
decide
to
make
those
plans
free
for
14
days
and
then
at
the
bottom,
we're
finding
ways
to
ensure
that
people
know
about
your
integration,
and
so
one
of
the
value-added
services,
though
there
are
many
more
to
come,
is
making
people
go
to
it
by
doing
Co,
marketing
and
using
marketing
development
funds
in
order
to
send
send
folks
to
your
listing.
So
if
you've
been
on
Facebook
or
Twitter,
you
might
have
seen
an
advertisement
for
this.
A
That's
like
hey
check
out.
We
think
you
should
check
out
Co
Taseer.
We
think
you
should
check
out
circle,
CIO,
etc.
You
can
use
those
that
we
have
funds
that
can
help
you
do
that,
and
so,
once
you
get
going,
you
can
reach
out
to
us
or
email
partnerships
at
github
comm,
and
we
can
talk
more
about
that.
A
We're
done
think
you
were
out,
but
this
is
true
for
enterprise
as
well.
The
on-premises
customers
also
want
these
amazing
tools
and
there's
companies
like
replicated
if
you're
not
familiar
with
them,
give
them
a
Google.
They
might
be
here
as
well.
They
were
at
platform
day,
they're
a
really
great
company
to
make
it
easier
for
you
to
bring
your
application.
On-Premises,
don't
miss
out
on
these
customers
that
are
dying
for
first-class
new
modern
tools.
A
There's
companies
there
are
companies
that
can
help
you
through
that
process,
replicated
being
being
one
of
them
so
consider
free
trials.
Let
people
use
your
tool.
Another
option
is
using
free
trials
alongside
github
identity.
You
don't
need
to
force
people,
especially
in
an
on-premises
environment,
to
set
up
a
new
identity
flow,
set
up
a
new
account.
It's
a
lot
easier
of
a
process
if
they
can
just
click.
Yes,
I
want
this
thing,
whether
on-premises
or
via
SAS,
offering
and
get
going.
A
This
is
sort
of
the
beginning
of
the
ecosystem.
Right
everyone
can.
Presumably,
if
you
are
there,
Travis
really
started
this
going
with
Travis
org
they
offered
free
CI,
builds
and
continue
to
for
open
source.
Many
other
CCI
providers
offer
that
now,
but
it
really
created
a
very
interesting
change
in
how
we
talk
about
these
tools,
because
it's
not
just
goodwill,
though
that
is
a
benefit
to
do
that.
It's
also
a
tool.
A
It's
also
a
tool
for
these
companies
to
grow,
and
so
companies
can
offer
these
options
free
for
open
source,
and
then
you
get
to
see.
Oh,
oh,
that's,
cool
circle
is
powering
this
app
that
I
really
enjoy
using
in
the
open
source,
community
or
Travis,
or
any
other
number
of
tools
that
offer
free
for
open
source.
It
acts
as
a
great
funnel
into
your
integration,
because
you
for
free
in
our
UI,
get
to
have
a
sort
of
mini
advertisement
everywhere
that
you're
helping
another
developer,
which
is
what
we
want
to
encourage.
A
We
want
to
encourage
you
to
help
this
open
source
community
and
then,
if
that
brings
you
more
business,
which
we've
seen
it
do
across
a
variety
of
verticals.
That's
a
benefit
for
everyone.
A
reason
why
this
works
is
your
tool
needs
to
be
integrated
into
github.
The
tools
that
we've
seen
have
the
most
success
and
I
think
the
reason
why
we
tend
to
think
of
CI
first-
and
we
think
of
this
way,
is
because
they're
integrated
right.
A
They
have
that
statuses
block
that
we're
all
sort
of
trained
to
immediately
look
at,
but
there's
lots
of
other
ways
that
you
can
make
a
visible
change
in
the
UI.
Those
statuses
is
the
easiest.
There's
issue
comments.
There's
deployments
you
can
go
to
developer
at
github
home
and
see
all
the
options
to
sort
of
make
sure
in
a
meaningful
way.
That
is
valuable.
Not
in
a
dropping
your
advertisements
and
every
repo
you
join.
You
can
make
sure
that
customers
know
ok.
This
this
feature
is
powered
by
us
again.
A
Travis
CI,
like
I,
said
immediately.
You
install
it.
It
starts
building.
You
immediately
get
a
status,
that's
the
easiest
way
to
get
a
quick
win
for
your
customers
or
potential
customers.
If
they
haven't
paid
you
anything
yet
it's
important
to
show
what
your
integration
is
doing.
The
experiences
where
you
say
I
want
to
install
this
go
on
to
your
application
and
then
do
all
the
work
in
the
application
and
nothing
ever
goes
back
to
github.
A
Don't
tend
to
be
as
successful,
because
it's
not
as
sticky
I
have
to
go
over
here
and
do
this
thing
we're
going
to
give
you
more
options
in
this
space.
We
know
that
we're
the
limiter
in
some
ways
and
making
sure
that
your
information
is
integrated
and
so
we're
exploring
ways
in
the
coming
months
to
ensure
that
all
integration
tools
have
a
sensible
way
to
put
information
in
instead
of
the
issue,
comments
way
or
pull
requests
comments
way,
which
is
the
majority
of
how
folks
are
currently
integrating
with
us
outside
of
statuses.
A
This
is
really
cool.
This
is
what
I
mean
at
the
power
of
this
one
into
trials
can
convert
one
into
customers
can
convert.
If
they
immediately
see
the
value,
the
more
setup
steps
you
have,
the
more
configuration
you
have,
the
less
likely
you're
going
to
grab
that
customer.
So
it's
very
important
to
ensure
that
whatever
tool,
you're
building,
whether
that
be
project
management,
deployment,
continuous
integrations
that
a
code
analysis,
security
scanning,
if
you're
a
security
scanning
app
and
you
get
access
to
that
repo
presents
a
vulnerability.
The
first
time
I
see
your
site
right
immediately.
A
I
see
value
because
odds
are
I,
have
one
and
that's
true
for
every
option.
That's
true
for
every
vertical,
but
a
lot
of
tools
spend
a
little
bit
too
much
time
asking
who
should
I
invite
to
this
thing?
How
should
it
work?
What
what
repose
do
you
have?
What
would
you
like
me
to
look
at
right?
All
those
things
are
important.
A
You
have
to
get
make
sure
that
everyone
can
go
to
the
tool
and
actually
use
it,
but
if
you
can
provide
that
first
piece
of
functionality
from
the
get-go
you're,
much
more
likely
to
have
a
sticky
customer
getting
into
sales
terms
pretty
aggressively,
but
land
and
expands
we've
seen
a
lot
of
companies.
You
know,
including
in
some
ways,
github
find
a
way
to
get
that
first
customer
that
first
small
team
and
then
suddenly
it
grows
and
grows
and
grows.
Because
again,
if
you
focus
on
the
developer,
you
provide
immediate
value.
A
You
have
a
much
better
chance
at
getting
a
much
larger
installation,
and
so
then
hope
found
this
to
be
true
right.
A
lot
of
folks
think
that
you
start
at
the
highest
person
at
the
company
that
you
can
give
access
to
get
access
to.
You
say:
hey
we're
gonna,
make
your
developers
so
much
more
successful
trust
us
look,
I
have
stats,
but
that
person's
going
ok,
this
tool
is
gonna.
Cost
me
fifty
thousand
dollars
this
year
sure
at
six
percent.
A
Eight
five
four
year,
lifespans
so
far,
so
I
want
to
wrap
up
with
basically
how
you
can
contact
us,
how
we
can
help
you
how
we
can
stay
in
touch
because
I
know
this
is
just
the
beginning
and,
like
I
said,
I'm
gonna
put
the
slides
up.
So
that
way
you
can
give
them
a
look
get
and
if
you
have
questions
we'll
be
in
the
ass
github
booth
right
after
this,
and
also
you
can
feel
free
to
email
me
hit
me
up
on
Twitter,
etc.
I'm
happy
to
answer
questions.
A
The
easiest
way
is
github.com,
slash
contact
and
it's
funny
because
everyone
has
such
an
aversion
to
go
into
this,
because
I
know
that
we've
all
had
bad
customer
support.
Experiences.
The
support
team
at
github
is
first-class.
They
are
the
best.
It's
an
amazing
experience.
Half
the
time
when
you
email
in
and
you
get
someone
like
a
vonner
Francis,
the
engineering
team,
the
product
team
etc
never
have
to
intervene.
They
can
answer
your
questions
much
faster
than
us.
So
while
I
am
happy
to
answer
your
questions
directly,
please
do
not
be
shy.
A
You
will
get
a
response.
You'll
get
a
response
quickly
and
it'll
be
correct.
So
please
take
advantage
of
this.
We
for
the
folks
on
the
stream
that
work
at
github
truly
I
applaud
you.
We
could
not
do
our
job
without
you.
We
also
have
our
more
open
option,
which
is
platform
duck
github
community.
This
is
the
forum
just
for
platforms,
so
we
heard
about
the
get
up
community
forum.
A
This
is
just
for
folks,
like
you,
they're
using
our
API
is
looking
to
start
integrations
looking
to
build
businesses,
and
so
we've
started
to
see
since
we
launched
this.
Excuse
me
at
last
universe,
when
we
were
trying
to
just
get
feedback
about
early
access,
that
our
customers
are
starting
to
interact
with
each
other
and
our
integrators
are
starting
to
interact
with
each
other
in
really
amazing
ways.
We're
seeing
two
people
from
two
different
project
management:
apps
discuss,
ok!
A
Well,
how
do
you
model
the
data
internally
and
how
do
because
it
doesn't
matter
right
like
that
sort
of
conversation
should
happen
between
us,
because
if
it
were
so
simple
that
modeling,
the
data
correctly
would
make
you
have
a
successful
business.
Then
we'd
all
be
millionaires.
It's
not
that
simple,
and
so
please
go
in
there,
please
be
as
open
as
you
can,
because
the
value
we're
seeing
isn't
that
you
get
to
go
in
and
say:
hey
I
have
this
problem
and
then
a
github
er
comes
in
and
goes
oh
yeah.
That
is
a
problem.
A
While
that
will
happen.
The
very
interesting
thing
is
when
someone
comes
in
and
just
says:
hey
I
spent
the
weekend
on
this
project.
I
ran
into
this
interesting
graph,
QL
thing
and
here's
the
solution,
and
then
we
all
just
give
get
to
give
little
hearts
in
there
and
that's
the
end
of
that
right.
So
please
go
give
this
a
look.
A
It's
been
really
fun
for
us
and
it
also
allows
us
to
sort
of
have
a
view
into
you
into
what
your
experience
is
without
necessarily
having
to
do
a
one-on-one
conversation
that
we
then
have
to
replicate
over
and
over
again
we're
in
the
ass
github
area.
There's
a
platform
specific
booth
over
there
that
we'd
be
happy
to
talk
to
you
about
this
or
what
you're
working
on
or,
if
you
have
ideas
just
doesn't
stop
here,
please
feel
free
to
reach
out
like
I
did
and,
last
but
not
least,
a
more
important
booth
over
there.
A
For
me,
personally
is
the
hiring
lounge.
If
you
would
love
to
come,
work
on
api's
identity
help
us
build
the
best
developer
to
a
market
place
in
the
world
or
help
companies
integrate
with
github
by
our
partner
engineering
team.
We
are
hiring
for
all
of
those
teams.
Please
do
not
be
shy.
There's
a
team
over
there
that
can
help
you
put
you
in
touch
with
me
and
I'd
love
to
work
with
you.
Hopefully
this
has
been
a
helpful,
quick
guide
into
how
you
can
get
started.