►
From YouTube: Ecosystem + Contributor Experience Deep dive
Description
Patrick Deuley (Sr. Product Manager, Ecosystem) and Lukas Epiert (Engineering Manager, Ecosystem) discuss the recent merger of the Ecosystem and Contributor Experience groups. Dives in to each category of work, current progress, where we're heading next, and more.
A
Here
we
hello
good
morning
good
afternoon
so
because
we're
recording
this
a
little
bit
of
context,
we
just
merged
the
ecosystem
and
contributor
experience
teams,
so
those
M
ours
are
currently
blight.
We're
getting
all
of
those
things
emitted
you're
the
next
couple
of
days
and
but
we
wanted
to
talk.
I
B
is
new
to
the
team
and
so
I'm
also
new
to
looking
through
experiences
up
to
you.
A
A
A
So
the
the
primary
use
case
that
we
have
been
supporting
has
been
third-party
integrations,
and
this
is
an
interesting
topic,
because
right
now,
the
biggest
one
that
we
that
we
support
is
JIRA
and
what
we've
learned
over
the
last
nine
months
for
canvas
is
that
third-party
integrations,
particularly
with
regard
to
things
like
workflow
management
like
JIRA,
or
the
project
management,
workflow
management
and
can
be
extremely
important
drivers
to
enterprise
sales.
So
we
have
a
lot
of
customers
that
use
JIRA
exclusively
because
they
are
kind
of
I've
started,
calling
it
like
soft
locked
in
right.
A
So
I
have
some
things
here,
so
the
cost
of
migrating
off
of
JIRA
is
extremely
high
right
for
companies
who
have
maybe
tens
of
thousands
I
even
had
one
example
that
I
ran
into
who
had
a
million
issues
open
and
right
right.
So
if
you
have
a
million
issues
like
the
cost
of
migrating
off
of
that
is
crazy,
they're
already
integrated
with
other
tools
in
their
tool,
train
right,
so
inside
that
company
they
may
have.
A
You
know
dozen
internal
tools
that
are
clipped
into
JIRA,
so
migrating
will
also
mean
rewriting
those
to
work
with
get
lab.
Sometimes
now,
JIRA
is
not
a
good
example
of
this,
but
there
are
other
integrations
that
we've
discussed
around
that
have
specific
regulatory
security
or
compliance
needs.
You
see
this
more
with
like
security
scanning,
but
that's
definitely
starting
to
come
up.
A
There
are
a
couple
of
things
that
we've
started
to
investigate
and
have
specific,
especially
for
like
US
federal
customers
that,
like
specific
project
planning
and
requirements,
management
needs
or
finally,
maybe
they
just
have
niche
where
you
meet
functionality.
That
is
so
that's
kind
of
a
high
level
of
that.
But
all
those
issues
also
apply.
The
API
is
great.
So
the
reason
that
API
is
valuable
is
because
we
can't
necessarily
support
everything.
We
don't
know
what
you're
gonna
need.
A
Similarly,
I
think
the
the
the
GDK
and
front-end
foundations
end
up
being
kind
of
the
other
side
of
the
coin.
So
you
have
two
options:
one!
You
can
integrate
your
system
from
connecting
with
our
api's
or
using
a
pretty
big
thing.
The
other
half
of
it
is,
you
can
contribute
an
integration,
and
so
I
fought
really
hard
for
getting
GDK
paired
with
our
API
for
awhile,
and
it
was
a
kind
of
a
long,
interesting
arc
to
get
to
where
we
are
today.
A
But
the
argument
I
kept
making
was
we
have
this
stance
where
we're
not
building
a
marketplace
today,
and
we
talked
about
that
on
the
integrations
category
specifically,
so
we
were
not
building
a
marketplace
today
and
part
of
the
and
the
rationale
behind
that
is.
We
have
an
open
code
base
right,
so
you
can
just
go,
contribute
your
integration
directly.
So
what
that
means
is
either
we're
asking
you
to
look
into
our
api's.
A
If
you
want
to
integrate
externally
or
if
you
want
to
integrate
internally,
you
have
to
go
use
the
GDK
great
so
like
the
GDK
ends
up
being
kind
of
the
other
half
of
our
integration
strategy
as
well
as
out.
Everybody
contributes
to
get
that
right.
So,
if
you're
contributing
to
get
live,
code
base,
use
the
GDK,
so
I
I
kind
of
view
them
as
two
sides
of
the
same
coin.
A
B
So
the
first
thing
I
can
say
is
that
there
is
not
going
on
not
much
going
on
right
now,
because
simply
we
have
nobody
dedicated
dedicated
to
work
on
this.
So
I
find
that
point
that
you're
making
about
you
know
the
GDK
being
actually
tying
in
with
integrations
is
pretty
interesting
and
I.
You
know
it
would
be
interesting
to
track
over
time
which
third-party
integrations
we
have,
and
maybe
you
know,
even
publicize.
You
know
that
hey
you
want
to
build
a
third
party
in
the
creation.
B
Do
it
yeah
our
API
or
you
know
directly
in
gitlab
pretty
interesting,
and
you
know
if
we
make
the
GDK
low.
If
we
lower
the
entry
barrier
even
more,
then
this
would
make
these
contributions
way
easier.
So
the
idea
behind
the
whole
country
contributor
experience
thing
has
been
that
you
know
we
want
to
make
easier.
It
won't
make
it
easier
to
contribute
and
want
to
make
it
easier
and
making
it
easier
will
help
us
and
you
know,
iterate
and
keep
our
velocity
a
lot
higher
because
yeah
the
easier
it
is
to
use
these
tools.
B
Let
because
hey
I
want
to
build
an
integration
in
gate,
lab
itself
and
the
product
I
can
just
use
these
design
components.
That
already
work
or
maybe
I'm
I'm,
building
an
integration
outside
of
gitlab
but
hey
I,
can
give
it
the
gitlab
look
and
feel
as
well
right
so
I
mean
we
already
see
that
some
other
internal
projects
that
are
now
using
the
gate
lab
design
system.
B
So,
if
you,
where,
let's
say
to
build
I,
don't
know
a
plugin
for
an
external
system,
you
could
theoretically
already
use
the
git
lab
design
system
as
well,
so
yeah.
So
at
the
moment
very,
very
high
level.
We
don't
even
have
like
issue
boards
or
any
any
big
issues
planned
the
front
end
foundation
part
has
been,
or
the
pyjamas
design
system
part
has
been
driven
by
UX,
so
I
think
there's
a
conversation
to
be
had
with,
for
example,
Tori
who
has
been
driving
this
effort
from
the
Excite
so
that
we
see
how
how
do
we?
B
How
are
we
going
to
proceed
with
these
efforts?
Because
the
design
system
in
itself
is
way
too
big
for
us
to
implement
so
I
see
the
front
end
foundation
more
as
as
a
team
that
supports
the
development
right
that
helps
with
the
direction
or
sometimes
if
there
are
hard
decisions
to
make
that
this
team
can
be
to
decision
maker
or
sometimes
you
know,
someone
wants
to
contribute
something,
but
there
will
be
a
blocker
that
this
team
could
be
could
be
the
the
new
resolve.
A
It's
actually
really
so
that's
that's
interesting
and
I
think
so
let
me
roll
the
clock
back
nine
months
yeah
when
we
started
this
team.
The
goal
was
to
have
so
where
we
were
at
nine
months
ago
was
every
group
was
contributing
to
the
api's
and
what
we
ended
up.
Seeing
was
some
amount
of
endpoints
and
resources
were
kind
of
falling
off
because
they
weren't
specifically
needed
by
that
team.
So
they
just
weren't
getting
created.
A
They
were
sitting
in
a
backlog
somewhere
and
the
stance
that
we
were
taking
previously
was
if,
if
a
thing
is
necessary
for
your
feature,
go
build
it
if
it's
not
necessary
for
your
feature
just
to
move
it,
ignore
it
move
on
right
and
then
we'll
collect
those
things,
and
that's
kind
of
that
was
our
stance.
So
one
of
the
one
of
the
initial
thoughts
behind
having
API.
A
Since
that
ecosystem
was,
we
can
have
a
team
that
can
be
a
catch-all
and
so
for
all
those
things
that
don't
specifically
map
to
feature
development,
that
is,
that
is
required
by
that
group
will
have
ecosystem
and
what
we
ended
up.
Learning
over
the
last
nine
months
was
that
doesn't
work
very
well
because
it
ends
up
being
API
endpoints
that
are
all
over
the
codebase
that
are
supporting
functionality.
We
maybe
don't
even
understand
right.
A
You
can't
have
one
team
that
you
know
and
acts
as
like
janitorial
services
right
like
that,
doesn't
work
here,
because
everybody's
creating
something
that
is
a
little
bit
bespoke.
Each
of
the
areas
may
function
slightly
differently,
I'm,
not
the
PM
for
everything.
So
I
don't
know
what
everything
does
so
it
was.
It
was
an
interesting
experiment,
but
I
think.
Ultimately
it
didn't
work
out
very
well
in
that
model
right.
So
one
of
the
things
that
I've
just
updated
our
direction
page
to
can
reflect
this
positioning.
Instead,
what
I've
been
proposing
is
API.
A
A
How
do
we
format
that
and
other
places
in
the
code
base?
Like
that's
a
good
question
for
ecosystems,
API
team
right
like
how
do
we
make
sure
that
everybody
is
kind
of
outputting,
a
similar,
similar
data
to
their
endpoints?
And
how
are
we
kind
of
aligning
around?
This
is
a
big
question
that
we
need
to
solve,
and
you
and
I
are
gonna
have
to
solve
this
right
like
how
are
we
treating
rest
versus
graph
QL
and,
like
is
more
important,
and
how
do
we
support
those
two
things?
They
have
very
different
reactions
in
the
audience.
A
We
can
talk
more
about
that
later.
I've
done
a
lot
of
research
around
how
people
think
about
those
two
things
so
like
I
think
that
I
view
them,
as
maybe
the
story
around
pajamas
is
a
little
different
and
the
friend
in
funding
I
think
specifically
like
there
are
two
pieces
right
because,
like
the
pajamas
stuff
actually
makes
a
lot
of
sense,
it
reminds
me
of
GDK
it's
GDK
for
us
right.
A
So
the
reason
that
web
pack
is
next
to
it
is
because
web
paddock
back
is
actually
next
to
it,
and
so
somebody
has
to
I
think
that's
fair
and
but
I
really
like
that
API
and
front-end
foundation
kind
of
have
similar
charters
right
we're
really.
These
are
two
categories
of
work
that
are
more
stewardship
roles,
they're
about
stewardship
and
governments
and
guidance
and
less
about.
A
We
go
build
all
the
things,
because
one
one
group
cannot
do
that
so
I
think
I
think
that's
actually
in
my
mind,
those
align
really
well
and
I
think
they
make
a
ton
of
sense
sitting
next
to
each
other
and
I.
Think
GDK
is
kind
of
similar.
It's
a
little
bit
different
right
because,
ultimately,
like
GDK
is
a
knowable
space
like
it's
it's
it's
not
small
right,
but
it's
small
enough
that
it
can
be
maintained
by
a
couple
of
people
and
actually
working,
but
it
does
still
need
input
from
everybody
exactly.
B
And
and-
and
we
have
people
you
know
who
worked
on
these
things
and
have
worked
on
it-
you
know
for
quite
some
time
and
definitely
we
don't
want
to
eliminate
just
people
right.
We
don't
want
you
know,
it's,
not
hey,
we're
going
to
start
a
team
and
we're
going
to
have
one
or
two
people
working
on
these
things.
B
B
So
I
don't
know
if
the
people
who
want
to
come
into
the
team
know
that,
but
probably
on
the
front
end
foundation
side
and
on
the
GDK
side
a
lot
of
research
is
needed
in
the
beginning.
So
maybe
you
know
instead
of
coding,
right
away,
there's
a
lot
of
planning
that
needs
to
be
done,
yeah
so
and
on
a
GDK.
It
just
comes
to
my
mind:
GDK
has
been
maintained
by
engineering
productivity
and
I'm
I'm.
Putting
maintained
in
in
air
quotes
because
engineering
productivity
has
a
fortnightly.
B
A
They
need
to
own
that
if
there
is
like
some
ridiculous
memory
leak
with
Ghibli's
process,
they
need
to
be
solving
that.
That's
not
the
GDK
coolants
right
gtk
is
about
the
packaging
and
wrapper
and
scripting
that
is
running
all
those
processes
and
kicking
them
all
off
appropriately
with
regards
specifically
to
running
it
in
a
local
development,
but
individually
like
there
are
a
ton
of
different
things
there
with
like
24
different
processes,
I
think
at
last
count
like
there
are
24
processes
that
are
running
and
you
run
a
local
little
environment.
A
Each
one
of
those
is
owned
by
their
individual
groups.
They
need
to
be
contributing
and
owning
those
things
right
and
like
all
of
the
all
of
the
stuff
that
we're
running
with
like
middleman
right.
Somebody
needs
to
own
that
and
work
on
that,
but
it
is
also
a
group
effort
and
so
I
think
it's
there's
really
good
alignment
in
the
language
and
kind
of
positioning
of
like
we
are
here
for
shepherding
the
whole
thing,
but
not
necessarily
owning
every
individual
part.
A
That's
not
that's,
not
really
fair
or
scalable
right,
like
it
just
doesn't
make
sense,
so
I
think
that's
really
good.
There's
a
really
good
points
and
I
can
I
think
all
of
this
is
great
and
I
can
take
that
into
kind
of
starting
to
write
those
Direction
pages
and
those
out
into
what
we're
doing
yeah
cool.
B
Ok
on
on
the
front
end
foundation,
side-
and
these
are
just
topics
that
I'm
very
interested
in
and
I-
think
they
tie
in,
is
you
know,
general
front-end
performance
and
all
these
kind
of
things.
So
there
are
certain
optimizations
that
can
be
done.
We
have
a
lot
of
skeletons
in
the
closet,
so
to
speak
on
the
front-end
side,
so
you
know
getting
rid
of
jQuery
and
all
these
kind
of
things
where
also
I
could
see
the
team
in
more
of
a
stewardship
role
right.
We
have
great
amount
of
people
that
are
contributing
to
certain
efforts.
B
You
know
to
improve
things,
but
it's
probably
best.
If
a
team
you
know
can
identify
which
ones
are
the
most
important
ones
that
we
should
tackle
first
and
then
coordinating
these
efforts.
Let's,
for
example
the
jQuery
example.
Let's
say
hey,
we
identify
as
we
need
to
do
these
five
steps
to
get
rid
of
it.
You
know
we
make
sure
that
over
a
course
of
time,
X
we're
doing
those
five
steps.
B
That
V,
for
example,
like
with
pajamas,
can
rely
on
the
other
stages
and
be
like
hey.
You
know
every
stage
is
responsible
for
their
part
of
the
code
base,
so
if
you're
using
jQuery,
you
know
in
the
next
two
release
cycles,
please
help
us
get
rid
of
jQuery.
We
can
help
you
if
you
don't
have
the
resources
or
we
can
help
you.
You
know
if
you
have
certain
questions
or
run
into
trouble,
but
generally
you
know
make
make
the
people
who
own
the
code
essentially
responsible,
yeah.
A
Yeah
I
think
that
makes
sense
and
I
would
kind
of
view
it
as
like.
That's
a
really
good
example
in
that
you
can
say
you
know
we
need
to
do
some
research.
Your
point
right,
like
let's
go,
do
some
research
find
find
what
those
big
pain
points
are
and
we're
may
need
to
tackle?
Maybe
let's
just
say:
jQuery
is
one
of
them
and
we
need
to
go
figure
out
so,
for
example,
like
what
functions
or
views
are
currently
using
jQuery
right.
A
What's
calling
jQuery
go,
get
a
list
of
those
figure
out
how
we
can
break
it
out
into
well
turns
out
across
these
40
different
instances,
they're
really
only
five
ways
that
jQuery
is
being
used
in
these
specific
ways.
Here's
how
you
tackle
each
one
of
those
things
like
this
is
how
you
migrate
off
of
to
a
different
library,
I.
Don't
honestly
I,
don't
even
know
what
we're
using
a
serger
like.
A
So
here's
how
you
use
this
other
library
or
how
you
use
something
native
to
view
or
whatever
right
and
create
those
patterns
and
then
roll
it
out
to
all
of
those
teams
and
go
okay.
Look:
we've
established
the
patterns,
here's
what
you
need
to
do
anytime,
you're,
calling
this
function
in
jQuery.
You
need
to
swap
it
out
with
this
component
view,
go
and
then
then
that's
really
easy
to
roll
out
and
tell
people
please
go!
Do
that
where
it's
really
hard
to
say:
stop
using
jQuery
right
yeah!
That's
pretty
tough!
A
B
A
So,
okay,
and
just
for
just
for
context
it
was
there
was
a
lot
of
debate
around
what
we
should
call.
The
group
I
decided
to
stick
with
ecosystem
because
it's
the
broadest
most
vague
term
right.
So
if
you
talk
about
contributor
experience,
what
are
the
integrations
have
to
do
with
contributor
experience
right?
So
I
figured
ecosystem
is
kind
of
a
broader
term
and
what
I
think
I'll
end
up
doing
is
I.
Think
we've
got
effectively
three
work
streams.
Here's
sort
of
all
right:
we've
got
integrations
which
are
kind
of
they're
they're.
A
Like
there's
API,
which
kind
of
sits
next
to
integrations
insofar
as
they're
both
how
you
connect
into
the
application
from
outside,
so
that's
a
little
bit
separate
and
then
we've
got
the
things
that
we're
in
contribu
experience
which
are
jihane
pyjamas,
but
then
also
the
tooling
around
them
right,
so
I
kind
of
think
of
it
as
those
three
chunks
of
work
and
they
all
somatically
again
I
think
they
all
somatically
go
together.
I
think
what
we'll
end
up
doing
is,
and
please
provide
feedback
and
I'm
not
saying
this
is
what
we
have
to
do.
I.
B
A
What
I'd
like
to
do
we've
been
having
a
weekly
team
fall
for
ecosystem
95%
of
the
conversation
has
always
been
around
integrations.
I.
Think
what
we
may
end
up
doing
is
breaking
into
a
couple
of
like
topic
based
calls
right,
so
maybe
we
do
have
like
a
monthly
ecosystem
wide
sink
or
something
and
I
think
that's
really
valuable.
Getting
some
getting
everybody
in
the
room
is
great,
but
I
think
we
may
want
to
break
it
up
against
topic
a
little
bit
right.
So
specifically,
we've
got
three.
A
You
Xers
rate,
who
are
working
on
pyjamas
in
totality.
Really
that's
all
they're
doing
is
the
front
the
UX
foundations
pieces
of
it.
So,
having
like
a
topic
call
around
UX
foundations
where
we
can
bring
in
the
people
who
are
implementing
it,
we'll
be
valuable
and
then
continuing
to
have
a
topic
around
integrations
is
really
valuable
and
then
maybe
we
do
have
another
one
that
is
just
about
GK
I
know
we
have
like
a
GK
working
groups.
B
Think
it's
I
think
it's
a
great
idea:
I,
definitely
want
don't
wanna
create
a
separation
within
I,
don't
wanna
create
a
separation
within
the
team.
One
suggestion
that
I
want
to
make
is
from
the
secured
group
what
I've
learned
there.
What
we
had,
which
was
pretty
great
I,
would
create
a
shared
calendar
for
all
the
stuff
that
goes
on
an
ecosystem
and
then
also
people
you
know,
can
decide
which
codes
they
want
to
join
and
generally
what
what
I
have
been?
What
I
have
found
to
be
helpful?
B
Is
that
or
what
I
think
would
be
helpful
for
us,
especially
in
this
thought,
is
that
we
kinda
leave
people
dedicated
to
certain
efforts
right,
because,
if
we
overwhelm
let's,
let's,
let's
take
Justin
as
an
example
as
a
front-end
engineer,
who
is
already
on
the
integrations,
API
who's
already
there
right.
If
we
now
bring
these
other
topics
in
and
say,
hey
Justin,
by
the
way
we
are
going
to
get
deliverables
here
and
there
and
everywhere-
and
you
have
to
now
join
three
calls
a
week
instead
of
one.
A
I
totally
agree-
and
you
know
previously,
our
schedule
was
very
straightforward.
I
think
you're
right
like
let's
say,
because
I
think
we're
also
the
way
I
view
it
from
just
the
like
nuts
and
bolts
product
management
side
like
I,
now
have
effectively
three
work
streams
to
also
prioritize
against
right.
So
I've
got
my
integration
of
stuff
that
I
have
pretty
clear
understanding
a
priority.
Then
I'm
gonna
have
things
that
are
coming
up
from
Tory,
formulate
UX
foundations,
which
says
these
are
the
most
important
patterns
that
need
to
get
implemented.
A
So
that's
another
input
on
prioritization
and
then
we're
gonna
have
stuff
coming
out
of
the
GDK
working
group
or
whatever
that
ends
up
being
right.
This
is
like
well,
this
is
the
number
one
impact
to
GT
K,
and
so
we've
got
I.
Think
what
we're
gonna
end
up
with
is
basically
like,
maybe
three
or
four
play
Falls,
depending
maybe
they
end
up
being
shorter
right
and
but
like
possibly
as
many
as
four
different
planning
Bowls,
where
we
have
one
the
topic
read
integrations
want
to
talk
about.
A
Gdk
want
to
talk
about
you
explanations
in
them,
one
to
roll
it
all.
Together
right
and
then
we've
got
maybe
sounds
like
three
topic:
calls
that
we've
possibly
doing
right
and
then
we
probably
had
I
should
have
one
like
roll
up.
Everybody
get
in
the
room,
so
we
can
just
kind
of
talk
about
what
everybody's
doing
call.
So
we've
got
like
eight
different
monthly
calls
now
and
I.
Think
you're,
absolutely
right,
like
I,
don't
Justin
does
not
need
to
be
on
all
eight
monthly
calls.
A
A
B
Think
I
think
one
one
way.
That's.
The
interesting,
though,
is
like
to
have
like,
because
we
have
the
people
on
the
team
and
at
some
point
people
might
be
working
on
topics
from
different
topics,
so
it
might
be
helpful
to
still
have
just
to
might
be
helpful
to
still
have
like
BOTS,
for
example,
that
show
everyone
on
the
team.
But
that's
more
of
my
business
to
be
honest,
yeah
and
we
do
have.
A
A
A
So
I
have
well
here.
Let
me
share
my
screen
since
we're
recording
this
okay,
so
I've
got
like
an
overall
board
that
is
all
ecosystem
work.
This
is
for
me
scheduling
each
milestone,
so
I
can
just
kind
of
see
a
high
level
of
the
milestones,
and
then
we
also
have
the
eco
system
workflow
board,
which
the
link
here
in
the
dock
gotcha.
A
B
A
A
Integrations
category
API
I
will
category
GDK
and
category
from
any
expectations
and
then
yeah
we
can
so
then
what
I
can
do,
which
would
be
great
because
then
I
can
continue
to
use
group
ecosystem
for
insight
into
the
entire
milestone
planning
and
what
all
is
happening
in
each
milestone.
And
then
that
also
allows
us
to
have
category
based
yeah.
B
A
Ok,
oh
let
me
show
my
screen
it.
This
realize
you're
not
looking
from
looking
okay.
So
the
the
big
thing
that
we
have
been
working
on
for
a
few
months
now
is
mass
integration.
So
a
little
bit
of
background
and
I
know
that
you
know,
but
again
part
of
the
let's
get
in
sync,
but
also
referring.
So
this
is
valuable
for
everybody.
A
Now,
mass
integration
is
a
concept
that
we're
in
a
way
deprecating
service
templates
were
still
investigating
that,
but
what
we've
done
previously
is,
if
you
need
to
integrate
one
thing:
lots
of
lots
of
places
you
use
service
templates.
Now,
that's
okay,
the
way
service
templates
work
is
they
take
a
set
of
configuration
that
you
you
would
define
in
the
surface
template
and
every
time
you
create
a
new
project,
it
goes
and
poppy's
those
over.
A
So
that's,
okay,
except
has
a
few
drawbacks,
one
it's
at
the
instance
level,
so
it
doesn't
work
for
anybody
on
get
lab
com2.
It
only
works
on
new
projects.
So
if
you
have
a
bunch
of
old
projects
now
you
have
to
still
programmatically
go
and
apply
those
and
three.
If
you
make
any
changes
like,
let's
say
you
want
to
do
something
crazy,
like
rotate
a
token
right
like.
If
you
want
to
rotate
a
password,
you
have
to
go
change
it
in
every
single
one
of
those
places
so
digging
into
how
people
are
using
these.
A
What
we
have
found
are
I
have
I
have
instances
that
I
have
failed
to
find
where
there
are
customers
with
12,000
projects
that
have
a
singing
integration,
and
what
we
are
seeing
in
those
cases
is.
There
are
examples
where
people
are
writing
a
script
that
is
going
through
iterating
through
every
project,
checking
it
against
the
service
template
and
then,
if
it
does
not
match
the
service,
template
updating
it
and
they're
having
to
do
this
on,
say
a
daily
basis.
One
example
that
I
found
has
four
thousand
projects.
A
They
do
a
check
once
an
hour
where
they're
going
and
verifying
these
things
has
changed,
because
they
have
had
cases
where
some
Engineer
somewhere,
maybe
the
small
edit
to
the
integration
and
then
it
broke
for
their
project.
But
then
they
didn't
have
an
access
to
the
original
credentials
or
whatever
right.
So,
like
those
kinds
of
things,
don't
make
a
ton
of
sense,
so
the
concept
behind
mass
integration
is
kind
of
most
easily
described
by
this
table
as
silly
as
it
is.
What
I?
What
I
want
to
create
in
this
in
this
design?
A
Is
you
can
set
an
integration
up
at
the
instance
level
and
then
it
gets
inherited
by
the
project.
You
can
also
create
an
integration
at
the
group
level
and
then
that'll
be
inherited
by
project,
and
so
this
kind
of
describes
like
an
inheritance
model
where,
if
you
have
an
instance
level
variable-
and
you
have
a
group
level
variable-
you
have
a
project
level
variable.
You
still
see
the
project
level
right
so
like
so.
A
We've
got
two
things
going
on
here:
one
is
inheritance
and
one
is
rights
and
between
those
two
concepts
you
end
up
with
a
really
cool
way
of
integrating
where
you
can
have
an
instance
level,
integration
that
flows
down
to
all
those
projects.
Each
project
can
customize
it
if
they
need
and
then,
if
they
remove
their
customizations,
it
just
revert
back
to
what
the
instance
was
to
it.
So
that
is
that
is
the
overall
idea.
Over
the
last
few
are.
B
A
Answer
is
no
we're
not
collaborating
with
them
and
I
think
so.
The
the
core
of
this,
the
core
code
that
we're
dealing
with
here
is
in
the
project
service
console
and
the
project
services,
which
were
also
renaming
by
the
way.
As
part
of
this
work
and
that's
probably
listed
in
here
as
well,
project
services
are
being
renamed
to
just
integrations
because
it
doesn't
really
make
a
lot
of
sense
to
have
a
project
service
that
applies
at
the
instance
rate,
so
don't
believe
so.
A
The
variables
themselves
are
distinct
concepts
inside
the
codebase
between
the
CIA
variables
and
the
way
project
services
are
set
up
gotcha,
although
yeah
I
mean
maybe
that
would
have
been
a
great
idea
if
we
had
been
designing
one
or
the
other
knowing
good
exists,
but
we
do
have
prior
art
for
how
that
works.
Okay,.
B
A
The
work
that's
been
done
so
far,
there's
been,
there's
been
a
number
of
things:
weak,
Morecambe,
we've
got,
we've
been
designing.
The
architecture
for
this
was
a
huge,
huge
lift
and
the
team
did
an
awesome
job
like
shout
out
to
arturo
for
really
leading
the
charge
on
designing
what
the
back
end
should
look
like
and
how
it
should
work.
And
but
we've
got
a
few
pieces
of
work
that
we've
had
to
do
so.
We
had
to
rename
project
services
to
be
more
generic.
We
had
to
add
the
ability
inside
that
integration.
A
What's
called
project
services
for
continuity
right
so
inside
a
project
service,
you
had
to
be
able
to
specify
whether
it
was
applying
at
the
instance
or
group
or
project
level
right.
So
we
had
to
change
the
data
structure
somewhat,
so
you
could
actually
add
that
piece
of
data
and
then
we've
been
working
on
adding
the
inheritance
model
itself.
The
work
that's
coming
up
is
we've
gone
ahead,
we're
going
to
have
to
actually
add
UI
for
these
pieces
and
leaper
has
been
working
on
and
to
end
mock-ups
of
what
that
what
those
workflows
will
look
like.
A
Ultimately,
it's
going
to
be
somewhat
straightforward
in
that
we
can
take
the
existing
UI
and
copy
it
up
to
the
group
level
and
copy
it
to
the
instance
level.
But
then
there
are
some
additional
pieces
of
functionality
to
work
right.
So
if
you've
got
something
into
google
level,
the
configuring
the
integration
may
look
about
the
same
with
a
few
additional
things
right.
We
have
the
option
for
allowing
overrides
or
not
and
then
allowing
the
end
user
to
see
the
fields
or
not
right.
A
A
So
there
are
a
few
modifications
to
what
that
template
looks
like,
but
rolling
out,
designing
those
workflows
and
then
rolling
out
those
workflows
or
the
big
pieces,
of
course
that
are
next
right.
Now
we're
rolling
out
that,
hopefully
this
milestone,
if
not
it'll,
be
a
fast
follow.
The
next
milestone
we're
nearing
completion
on
the
work,
for
instance,
level.
A
Integration
can
exist
just
to
keep
us
focused.
The
goal
is
when
we've
designed
this
in
such
a
way
that
these
will
effectively
apply
to
all
integrations.
The
endgame,
though,
is
getting
JIRA
integration
specifically
able
to
run
at
the
group
level
like
that
is.
That
is
the
target,
regardless
of
all
the
other
work
that
we
have
scoped
and
wider
than
that,
because
it
has
such
such
sweeping
impact
to
the
rest
of
the
integrations
that
exist.
A
A
And
then
a
fast
follow
to
JIRA
integration.
Is
we
also
it's
a
hugely
requested
feature
to
do
the
same
thing
slack?
We
also
have
instances
that
where
people
are
in
grading
slack
with
hundreds
of
thousands
of
projects
so
same
thing,
slacks
a
little
more
complicated,
because
when
you
integrate
JIRA
Jiri
integrates
at
the
instance
level
of
the
JIRA
instance
level
right.
So
you
just
kind
of
point.
Your
project,
at
the
entire
just
instance
slacks
a
little
bit
different
because
you'll
want
control
over
what
channel
each
thing
goes
into.
A
B
B
So
currently
this
this
work
here,
just
that
you're
showing
this
epic
just
entails
the
backstage
work,
basically
right
or
for
the
most
part,
yeah
yeah,
okay,
and
so
basically,
it's
targeting
milestone
12:10
at
the
moment.
Is
it
something
that
that's
still
valid
or
is
it
like?
Some
due
dates
are
not
correctly
there
and
it's
actually
for
see
that
it
will
be
later.
You
know,
13
132,
no
I,.
A
That
is
mostly
correct.
I
know,
I
have
been
called
out
on
this
few
times
there
there
have
been
so
there
has
been
so
much
backstage
work.
That
I
am
the
first
admit,
I,
don't
necessarily
understand
every
individual
piece
backstage
work
yeah.
So
there's
there's
a
bunch
of
stuff
that
the
engineers
have
have
added
issues
for
for
doing
that.
Backstage
work
I
know
not
all
of
them
have
the
right
milestones
now.
A
A
B
A
That
is
the
the
primary
track
at
work.
What
we've
been
doing
when
I,
when
I,
have
been
doing
planning
what
I've
been
trying
to
do
is
kind
of
follow.
A
parade,
I
would
just
say:
80%
of
the
work
is
gonna
be
around
mass
integration.
Whatever
that
means
great,
like
there
are
a
bunch
of
different
there's.
Mac
suits
work,
there's
some
design
work
there
bunch
pieces
and
then
20%
of
it
we've
been
trying
to
kind
of
keep
up.
There's
just
a
lot
of
we've
had
to
do.
A
B
Ok
good
to
know
good
to
know
young
ok,
interesting,
interesting,
I
mean
I
will
definitely
talk
to
Nick
and
to
the
engineers
about
details
this
week,
I've
just
set
up.
You
know
coffee,
chats
with
everyone
I'm
going
to
figure
out
some
questions
from
the
engineering
side.
You
know
want
to
also
answer
these
questions
about
front-end
foundation
in
GDK.
To
be
honest,
I
you
know
would
like
us
to
hold
off
a
bit
on
that
effort
until
we
actually
have
people
you
know
joining.
You
know
joining
the
group
with
these
joining
for
these
roles
in
these
efforts.
B
So
you
know
at
least
when
it
comes
out.
You
know
when
it
comes
down
to
the
details,
but
at
least
on
the
front
end
foundation
side
just
probably
stuff
that
I
or
can
do
together
of
a
few
X
and
figure
out.
You
know
what
what
is
the
the
thing
that's
needed:
yeah,
I,
I,
think
I
think
it
probably
will
start
with
a
little
bit
of
housekeeping
and
research
like
we
have.
Let
me
let
me
share
my
screen
for
for
a
change,
so
we
have
pajamas
right
and
we
have.
B
We
have
our
list
of
components
here,
and
you
know
each
component
has
like
a
status
next
to
them,
and
the
status
of
every
components
like
tracked
in
an
epoch
and
every
team
that
was
responsible
for
implementing
something
so
I
think
one.
One
thing
that
needs
to
be
done
is
like
the
very
boring
work
of
just
going
through
and
see
if
this
list
is
up
to
date
right
like
yeah,
because
it
could
be
that
you
know
some
some
integrations
already
have
been
built.
B
B
Yes,
so
if
we
have
button
components
right,
like
simple
buttons
and
for
some
reason
we
have
new
buttons,
so
somebody
has
we
have
somehow
it
ended
up
that
you
know
in
order
to
be
delivering
features,
we
ended
up
with
two
implementations
of
buttons
and
two
implementations
of
dropdowns,
so
this
is
really
something
that
we
need
to
check
out,
because
this
is
something
that
we
from
a
front-end
perspective.
Don't
want
right.
B
The
whole
purpose
of
this
design
system
is
that
you
know
our
component
system
is
that
it
aligns
with
the
design
system
and
sometimes
things-
and
this
is
also
where
conversations
with
reacts
need
to
be
heard.
Sometimes
it
is,
you
know
if
you
actually
look
I'm,
just
showing
you
if
you
into
the
use
cases
of
buttons
and
if
you
look
into
the
sketch
sketch
design
pattern
that
we
have
four
buttons
just
like
a
lot
going
on
right.
So
even
we
consider
all
of
these
things
buttons.
B
It
might
make
sense
from
an
implementation
perspective,
for
example,
and
I,
don't
know
if
this
is
true,
but
just
as
an
example,
it
makes
sense
to
differentiate
between
like
an
emoji
button
and
like
a
normal
button,
because
these
emoji
buttons,
you
know,
might
need
to
take
care
of.
How
does
an
emoji
look
in
different
circumstances
like
on
a
different
different
watch,
might
call
it
the
different
operating
systems.
You
know,
because
emojis
look
different,
and
these
kind
of
things
and
cramming
all
that
logic
into
one
button
might
not
be
the
best
thing.
B
A
A
There
was
an
alert
banner
design
yeah
that
had
been
that
was
in
pajamas,
but
hadn't
been
implemented
right,
so
I
know
Justin
three
milestones
ago,
picked
that
up
and
actually
went
and
implemented
it
rolled
it
out
so
yeah
stuff
like
that
I
think
if
we
can
create
actually
I
kind
of
wonder
if
we
can,
as
is
kind
of
a
the
beautifying,
our
UI
epic,
that
Christy
rolled
out
kind
of
in
a
similar
fashion.
Right,
like
me,
do
what
we
need
to
do
is
so
first
step.
Go
make
sure
that
the
list
is
correct.
A
Second,
step
go,
create
issues
for
all
the
things
that
need
to
get
done,
and
then
we
can
create
kind
of
in
a
similar
epoch
of
like
beautifying.
You
I
did
then
turn
it
into
I.
Don't
know
if
we
won't
actually
make
it
like
an
okay
are
right,
like
they
did,
but
turn
it
into
a
group
effort.
We
say:
okay,
we've
got
this
list,
PMS
break
off
two
percent
befriended
capacity
and
please
go
help
us
knock
this
out
and
I
think
that's
absolutely
valid.
Then
that
would
allow
us
to
ramp
up
very
quickly.
A
B
B
A
B
B
A
B
A
And
there
are
kind
of
next
steps
that
I've
added
to
the
dog
so
review.
What
components
are
being
built
or
need
to
be
built,
create
issues
for
those
that
need
to
be
built
and
then
socialize
that
work
yeah
so
happy
happy
to
help
drive
that
let's
just
get.
Let's
get
some
issues
built
and
we'll
go
we'll
walk
down.
B
B
A
B
A
B
A
A
So
we've
got
again
I've
made
some
changes
to
the
I,
just
made
a
bunch
of
changes
to
the
category
direction,
and
so
previously
our
Charter,
much
like
with
ap,
is
nine
months
ago.
Our
Charter
was
to
support
all
of
our
third-party
integrations,
so
there
are
currently
something
like
27
of
them,
30
30
plus.
Now
we
have
a
lot
of
different
integrations
and
they
are
all
wonderful
and
the
best,
but
there
are
some
that
are
more
important
to
enterprise
users
than
others,
so
our
focus
previously
had
been
support,
all
of
them.
What
I
am
proposing?
A
We
shift
to
right
at
this
point.
What
we
have
shifted
to
actually
I
can
say
now
is
that
we
should
be
focused
on
things
that
enable
enterprise
users,
so
the
goal
has
been
to
focus
on
JIRA
in
the
first
set
of
work.
What
I'd
like
to
see
us
do
once
we
get
the
group
level
JIRA
integration
shipped
is
start
looking
at
the
integrations
that
would
have
the
highest
impact
to
signing
up
enterprise
users.
I
think
that's
probably
service.
A
Now,
although
there's
still
some
investigation
to
be
done
around
service
now,
there
are
specifically
two
use
cases
that
we've
been
looking
at
so
hopefully
I,
don't
know
if
you're
familiar
service
now
and
again,
because
we're
recording,
let
me
give
you
a
brief
overview.
So
ServiceNow
is
a
workflow
management
tool,
so
I
think
it
was
like
an
ITSM
product
where
I
can
say:
I
have
an
IT
Help,
Desk
I
can
manage,
workflows
for
ticket
comes
in,
and
then
here
are
the
people
or
approvers.
It
needs
to
flow
through
to
get
to
a
final
state
right.
A
So
there
are
two
examples
that
have
come
up
with
how
you
may
use
this,
so
somebody
on
a
Nike
help
desk
gets
a
ticket
that
says
I
need
to
update
a
rule
enough
firewall,
for
example.
So
let's
say
that
firewall
is
configured
as
code
inside
of
gift
pack
right.
So
what
ends
up
happening
is
they
can
create
something
that
says:
ok,
I
need
to
make
a
change.
Some
Engineer
somewhere
needs
to
make
a
change,
and
then
that
opens
a
ticket
I'm.
Sorry,
the
service
name
ticket
opens
an
issue
inside
of
get
lab.
A
That
says,
please
go
make
this
change
in
this
repo.
It
would
refer
back
to
the
ServiceNow
ticket
and
say
here's
where
the
request
came
from,
but
ultimately
the
engineer
wouldn't
need
to
go
into
ServiceNow.
They
could
just
go
make
the
change
when
the
change
passes
the
pipeline's
gets
deployed
whatever,
then,
at
the
end
of
that
process
it
goes
and
updates
the
ServiceNow
ticket
to
say.
Ok,
the
the
ticket
has
been
updated.
A
The
viral
rule
has
been
added
whatever,
then
that
allows
the
the
ticket
to
continue
right
because
then,
maybe
that
help
desk
staff
needs
to
go
verify
or
do
whatever
there.
What
else
is
in
that
workflow
so
that
that
is
ServiceNow,
making
a
call
to
get
lab
and
then
get
updating
right?
So
that's
one
workflow,
the
other
workflow
is
the
visit.
So
in
get
lab,
let's
say:
I
am
especially.
A
Need
you
to
review
this
code.
I
need
you
to
put
it
on
the
release,
schedule
whatever
it
is
that
your
particular
place
does
these
changes
can
take?
It
could
be
a
24
hour
process
where,
if
somebody
goes
and
looks
at
it
reviews
it
within
24
hours
approves
it.
You
could
also
I
have
seen
processes
as
long
as
30
days
right
like
we
do
a
1
month
every
month,
we're
allowing
for
updates
to
roll
out
to
production.
So
you
have
to
wait
till
the
next
change
window
and
that
may
be.
A
If
one
just
happened,
it
may
be
30
days
from
and
then
we
queue
those
up.
So
it
has
to
wait
till
the
whatever
change
window
was
scheduled
when
that
thing
is
approved
and
ready
to
go,
it
allows
the
pipeline
to
continue
and
the
pipeline
deploys
all
right.
So
summarize,
we've
got
gitlab
changes
made,
ask
ServiceNow
for
permission
to
deploy,
ServiceNow
permission
is
approved
and
then
pipeline
can
actually
deploy
right.
A
So
we've
got
two
completely
opposite
workflows
that
allow
each
other
get
lab
and
ServiceNow
to
control
each
other
in
some
way,
so
I
think
that
is
gonna
get
back
to
it.
That's
what
we're
talking
about
with
ServiceNow
Rally
is
really
similar
to
JIRA
is
also
used
by
a
ton
of
enterprises.
We've
gotten
a
bunch
of
requests
for
it.
That
could
be
interesting
as
well.
Microsoft
teams
is
growing
like
gangbusters
from
what
we
can
tell
right
and
we're
getting
more
and
more
requests
for
Microsoft
teams.
We've
we've
been
seeing
it
grow
in
the
market.
A
I
know
Microsoft
is
this
is
reporting
a
ton
around
how
fast
it's
been
growing
in
the
marketplace.
So
that's
really
cool
each
peak,
you
see
I'll
admit
I,
know
comes
the
least
about
out
of
these
again
we've
seen
a
bunch
of
requests
from
enterprise
customers.
It
tends.
It
seems
to
be
pretty
interesting
to
federal
customers
right,
so
customers
seem
to
like
HP
qc4
for
some
needs.
Jama
is
similarly
like.
A
We
have
an
issue
open
for
requirements:
management
using
JAMA,
specifically
if
I
remember
correctly,
JAMA
is
used
quite
a
lot
around
the
health
space
right
so
like
healthcare
requirements
management,
so
those
are
I
think
ServiceNow
is
probably
going
to
be
top
priority
again
I'm,
looking
at
basically
prioritizing
based
on
business
impact,
so
I
don't
want
to
get
specifically
into
what
I'm
committing
to
us
to
next,
but
I
think
we're
looking
at
probably
ServiceNow
rally
teams
PTC,
that's
probably
the
order
in
which
it's
likely
to
happen.
But
again
it
needs
to
be
reviewed
first.
So.
B
Well,
one
of
the
one
of
the
thing
that's
interesting
from
an
engineering
perspective,
but
essentially
it's
also
product
management.
I
would
leave
or
falls
in
the
product
spaces
when
we
have
these
integrations.
What
do
we
support
because
I
mean
these
tools
are
always
involving,
so
how?
How
do
we
decide
what
support
and
how
long?
We
will
support
something.
So,
let's,
for
example,
I
don't
know,
for
example,
personally
I
don't
know
right
now
and
it's
something
I
need
to
research.
B
B
A
That
I
have
been
here
and
we
have
been
actively
working
on
the
JIRA
integration
for
it.
Maybe
four
months
now
I
have
not,
and
you
know
what
maybe
my
engineers
call
me
out
immediately,
but
I
have
not
seen
any
breaking
changes.
We
roll
out
from
JIRA
that
specifically
broke
something
we
did
now.
There
is
currently
a
bug,
we're
investigating
that
may
fall
under
that
category.
A
I
don't
know
because
we
haven't
actually
figured
out
what's
causing
it,
but
it
doesn't
seem
to
happen
very
often
I
think
there
are
kind
of
two
buckets
here,
though
one
is
integrations
that
are
of
high
priority
to
our
largest
customers.
I
think
the
answer
is
so
JIRA
is
an
example
of
that.
Now
the
answer
is
in
perpetuity
is
how
long
we're
going
to
support
it?
How
far
back
we'll
support
and
I
think
that's
a
little
different
right
and
there
are
jurors
complicated,
because
there
are
two
versions
of
JIRA.
A
One
is
your
cloud
which
I
think
we
say
we
will
support
100%,
accurate
cloud
because
there's
only
one
version
of
it
right
and
then,
as
far
as
backwards
compatibility
with
JIRA
server,
I,
don't
know
a
couple
of
versions:
I'm,
not
sure
again,
I
haven't
seen
a
ton
of
breaks
being
caused
by
old
versions
of
Jiri.
Yet
so
I
think
that's
one
of
those.
A
We
can't
really
answer
that
until
we've
got
a
little
more
experience
as
to
how
much
that
can
that
can
affect
us
and
but
as
far
as
how
how
long
will
we
support
anything
forever?
Anything
apps
below
that
line
thing
anything
that
is
a
lower
priority
to
large
customers,
no
interest
to
large
customers,
I
think
as
long
as
it
works,
that's
great.
If
it
starts
introducing
small
problems,
then
maybe
we'll
look
at
it.
If
it
starts
introducing
large
problems,
I
think
we
get
rid
of
it
right.
I
think
there's
a
few
steps
there.
A
That
may
be
a
little
more
nuanced,
for
example,
matter
most
is
very
interesting
to
the
matter
most
community
like
matter
most
integration,
is
very
interesting,
the
matter
of
its
community,
and
they
have
some
great
community
contributors
that
have
continued
to
help
us
update
that
and
support
it,
and
so
here's
how
it
kind
of
works
in
that
lens
right.
It's
not
super
important
to
our
enterprise
customers,
but
it's
not
causing
a
lot
of
problems
and
there's
an
active
community
who's
supporting
it.
A
That's
great
we'll
continue
to
support
that
great,
like
I'm,
not
definitely
not
going
to
remove
my
domestic,
but
I
think
there
are
a
couple
of
examples
that
we've
run
across
I
don't
know-
and
this
is
not
causing
problems
today,
but
we
do
not
have
an
active
community
around
Bugzilla
and
if
that
broke
tomorrow,
I
think
it
could
probably
be
reach
out
to
Latino
see
if
they
want
to
support
it.
If
they
don't
want
to
support
it.
A
B
Got
gotcha,
yeah
and
I
mean
I
think
this
is
probably
something
that
I
will
ask
engineering
and
quality
how
we
do
it
because
I
think
I
think
it's
probably
still
good.
If,
for
example,
on
the
JIRA
side,
we
say
we
can
uphold
some
promises
around
JIRA
server
right
or
we
run
like
our
I,
don't
know
how
we
run
tests,
for
example,
right
like
that
our
integrations
work
with
the
actual,
but.
B
Exactly
and
once
we
have
them,
it
probably
makes
sense
to
to
define
like
hey.
This
is
the
minimum
version
we
support,
and
once
we
see
that,
for
example,
at
lashing
itself
is
deprecated
like
a
certain
version,
we
can
say:
hey
the
next
major
release
we're
going
to
so
in
order
to
bring
in
some
stability,
because
we
don't
have
that
many
engineers
working
on
integrations
and
the
easier
we.
We
can
find
these
issues
right
or
find
out.
Oh
dang,
they
haven't
thought
about
JIRA
version
from
2005,
which
we
still
want
to
support,
because
big
customer
demand.
B
It's
probably
it's
probably
good
and
probably
an
interesting
effort
from
the
engineering
perspective
that
we
maybe
should
talk
to
the
quality
team.
Yeah
I'm,
a
big
fan
of
you
know
in
the
interim
tests,
and
we
have
run
into
problems
with
without
them
in
the
past,
at
gate
lab
and
in
previous
endeavors.
So
this
is
probably
something
that
we
also
might
want
to
look
into
yeah
and
you.
A
A
Where
I
know,
Anaya
was
looking
at
and
I
think
where
you
are
qe
support
is
gonna
change,
but
she
was
previously
looking
at
adding
and
and
testing
with
your
I.
Don't
know
if
any
progress
was
made
on
that
and
again
our
key
is
getting
shifted.
So
I
think
we'll
have
to
pick
that
up
with
our
new
support,
yeah
but
yeah
I
think
that's
absolutely
right
and
we
react
at
least
with
the
integration
as
well.
I
guess
with
all
of
them
it's
important,
but
it
particularly
with
the
ones
that
we're
focused
on.
B
A
If
you
were
look,
if
you've
never
worked
in
a
company,
that
is
that
big,
then
you
would
have
never
and
that's
really
all
it
is
it's
it's
the
same
thing
with
like
companies
that
use
or
a
goal
for
ERP.
You
write
like
there's
a
point
at
which
you
will
consider
one
of
like
Oracle
or
s
AP
or
ServiceNow
as
further
the
tread
in
that
space
rightly.
But
if
you've
worked
at
a
place
that
has
an
ERP,
then
you
know
what
an
ERP
is.
A
If
you've
never
worked
in
a
place,
that
is
near
a
P,
you
don't
know
it's
a
really
binary
and
I
think
it's
the
same
sort
of
it's
the
same
sort
of
product
right,
but
it's
it's
been
especially
like
I.
Historically,
just
in
past
endeavors
and
I've
worked
with
a
bunch
of
banks
and
banks
really
like
ServiceNow.
They
use
it
a
lot
for
the
change
management
process
that
I
described
in
there
yeah
and
it's
very
important
to
them.
When
you
have
that
kind
of
regulatory
regime
that
you
have
to
follow.
A
Change
management
is
a
very,
very
big
deal.
It's
interesting,
I
had
I
had
this
like
as
a
brief
tangent.
Like
remember
this
came
up
months
ago
now,
somebody
was
talking
about
change,
management
and
said
well,
really.
What
we
need
to
do
is
we
need
to
just
encourage
those
people
to
move
to
a
CI
CD
model
like
they
just
need
to
be
continuously
playing
and
what
I
told
them
was
you
don't
understand
like
just
take
it?
A
Take
a
bank
any
bank
doesn't
matter
and
that
banks
problem
is
not
that
they
don't
have
enough
money
to
hire
enough
engineers
to
move
them
to
a
CIC
frame.
That's
not
the
problem.
It's
not
that
they're,
not
smart
enough
or
they
don't
have
enough
time.
The
problem
is
that
their
lawyers
tell
them
they
can't
and
their
lawyers
are
telling
them
they
can't,
because
the
government's
that
they
serve
have
told
them.
A
They
can't
write
like
this
is
a
compliance
issue,
not
a
technology
issue,
and
so,
while
I
agree,
it
would
be
great
if
all
of
these
banks
would
move
to
a
CI
CD
framework
they're
not
going
to
because
they
can't
write
so
yeah.
We
have
to
support
change
management,
whether
we
do
that
maybe
someday
we
build
out
like
robust
change
management
tools
inside
of
get
Latin.
That
would
be
awesome.
A
B
No
I'm,
not
I'm,
probably
not
surprised
like
these
I'm,
not
going
to
say
anything
yeah.
You
know,
but
these
integrations
might
not
be
the
most
interesting
work
for
engineers
per
se
or
not
like,
for
example,
for
front-end
engineer.
It's
not
like
hey
we're
implementing
I,
don't
know
real-life
collaborative
editing
on
issues
which
might
be
interesting
from
a
technical
standpoint,
but
from
a
business
perspective
that
they
are
interesting
very
interesting.
This
probably
makes
sense
right,
yeah,
yeah,
yeah.
Definitely.
A
It's
and
it's
been
interesting
because
the
nine
months
ago,
when
we
first
started
digging
into
this,
there
wasn't
a
huge
amount
of
interest
in
an
appraisal
creation.
It's
like
it
was.
It
was
interesting.
It
was
kind
of
a
yeah,
maybe
some
day,
but
it
really
hasn't
been
high
priority
and
over
the
last
I
want
to
say
three
months.
A
Our
sales
force
has
started
to
shift
more
towards
looking
at
larger
deals
and
enterprise
deals
and
through
how
we
go
to
play
in
that
space
and
I
think
so
it's
become
more
and
more
of
an
interesting
priority
for
us
and
I
think
that,
just
from
past
experience,
this
is
has
nothing
to
do
with,
like
it
love
itself
for
past
experience
like
we're,
just
gonna
continue
to
go
in
that
direction.
I
think
over
time.
A
We
will
see
more
and
more
interest
in
those
spaces
and
it's
going
to
be
harder
and
harder
to
capture
those
those
customers
without
significant
investment
in
this.
In
this
space
and
the
example
I've
used
many
times,
and
this
is
not
our
wheelhouse.
This
is
somebody
else,
but
I
previously
worked
on
a
team
that
a
lot
of
what
we
did
was
add
access
integration
like
add
every
flavor
of
LDAP
right
there
product
and
what
you
see
is
like.
If
you
have
a
customer
who
comes
in
and
says
well,
I
had
15,000
employees.
A
This
is
the
access
control
system.
I
use
you
don't
get
a
say.
Well,
I,
don't
have
great
brain.
You
just
go.
Add
support
for
that
access,
control,
system,
yeah
and
I.
Think
it's
gonna
be
the
same
sort
of
thing
right,
like
I
use
rally
for
project
management.
Ok,
we're
gonna
use,
we're
gonna,
integrate
rally,
really
think.
That's
that's
generally.
What
we're
going
to
end
up
doing
for
at
least
with
some
line
snapped
like
I'm,
not
saying
we're.
Gonna
go
do
that
for
everything,
but
we
definitely
going
to
start
doing
yeah.
A
I
would
love
to
hear
your
feedback
I.
Don't
have
a
ton
to
contribute
to
this
conversation,
and
one
of
the
big
questions
that
that
I
have
not
had
enough
space
to
to
cycle
on
is
now
that
we've
kind
of
down
scope
API
is
a
little
bit.
Yes,
we
need
to
set
up.
We
need
to
refine
our
guidelines
and
our
really
we
need
to
do
some
handbook
updates.
That's
really
what
it
is.
We
use
some
handbook
updates
around.
How
do
you
develop
api's?
We
have
a
statement
in
the
engineering
handbook.
B
A
A
Talk
about,
we
did
a
really
interesting.
You
know
actually
here's
an
interesting
outcome
about
your
you're
talking
about
GDK
research,
so
I
had
a
bunch
of
interviews
with
with
engineers
in
organization.
I
was
actually
specifically
trying
to
learn
more
about
onboarding
and,
as
a
super
brief,
you
know
what
double
tangent
now
I
have
talked
to
a
bunch
of
companies
outside
of
get
lab
who
were
looking
to
integrate
with
get
lab,
and
a
common
theme
is
the
GDK.
It's
not
fun
to
use.
A
A
A
I
could
I
couldn't
even
find
the
GDK
at
first,
because
I
got
my
laptop
way
too
early
I
got
my
laptop
like
a
month
in
advance
of
of
getting
my
onboarding
issue,
for
whatever
reason
them
some
mix-up
or
whatever
got
his
laptop
way
too
early
trying
to
figure
I
have
this
out
the
GDK
couldn't
figure
it
out.
He
finally
found
the
template
for
the
engineering
onboarding
issue
and
he
just
started
following
the
onboarding
issue
said
after
that
everything
was
easy
and
I.
A
A
To
see
the
the
discussions,
I
have
a
really
interesting
for
people
who
are
worried
about
implementing
friend
for
friend
engineers,
specifically,
but
people
who
support
front-end
engineering
efforts.
They
all
seem
to
agree
graphic.
It
was
awesome,
it's
what's
next,
we
really
need
to
do
this.
It's
really
valuable
for
people
who
are
primarily
back
in
engineers.
It
was
really
interesting
cuz.
It
was
a
very
different
reaction.
It's
like
graph
QL
is
neat,
but
I
can't
guarantee
performance
on
it.
I
don't
know
what,
like
I,
have
no
ways
of
modeling.
A
What
that
performance
is
and
optimizing
my
database
to
support
that,
and
there
are
also
some
honestly
novel
for
me
like
very
interesting
security
concerns.
I
heard
two
or
three
people
who
specifically
said
like
the
beauty
of
rest,
is
that
it
has
decade's
worth
of
HTTPS
security
concerns,
build
into
it
right,
like
it
has
decades
of
security,
work,
where's,
graph,
QL,
I,
don't
know:
okay,
I,
don't
it's
novel
and
I,
don't
know
and
I,
don't
necessarily
trust
it
with
everything,
and
so
we've
got
this
kind
of
split
split
need
here.
A
What
we
see
today
is
we
have
a
bunch
of
API
clients
that
are
out
there
in
the
world
while
they're
like
sixteen
of
them.
People
have
built
native
libraries
for
the
gate,
lab
API.
Those
all
just
support
press
there's,
wrappers
Brown
rests
so
people
who
are
consuming
those
clients
are
not
able
to
leverage
graph
QL
data.
On
the
flip
side,
our
groups
are
adding
graph
QL
more
graph
QL
data
today,
and
they
are
trying
to
add
that
graph,
QL
first
all
right.
A
So
we've
got
this
very
split
ecosystem
that
we've
created
and
I
think
that
what
we
need
to
figure
out
and
I
to
be
perfectly
honest,
I
will
lean
very
much
on
you
to
help
me
understand
what
we
do
and
how
we
move
forward.
But
we
need
to
have
a
position
on
what
our
engineers
should
be
doing
and
then
what
a
product
manager
should
be
doing
as
far
as
prioritization
right
and
then
have
clear
guidance
in
the
handbook.
B
I
mean
I
mean
it's
not
all
milk
and
honey
right,
like
the
it.
Definitely
everything
like
these
definite
technologies.
From
my
perspective,
upsides
and
downsides,
one,
for
example,
one
downside
that
I
see
is
like
hey
beckoned
engineers
had,
like
especially
res
engineers,
had
years
of
training
on
how
what
you
described
like
how
to
get
stuff
performant
on
the
on
the
rail
side
of
things.
B
You
know
crying
the
database,
and
now
you
have
graph
QL,
which
feels
like
magic
and
sometimes
is
magic,
and-
and
so
you
know,
you're,
basically
moving
that
responsibility,
sometimes
to
write
efficient
queries
to
to
the
front-end
engineer,
while,
on
the
other
hand,
sometimes
with
those
generic
ap
is
that
we
have
is
like
hey.
You
know
we're
giving
all
this
data
and
all
this
data
might
be
pretty
expensive,
because
sometimes
you
know
fields
on
a
much
request.
B
Like
author
or
I,
don't
know
what
certain
fields
are
very
expensive
because
in
the
back
and
they
need
to
do
20,000
giddily
operations
in
order
to
retrieve
that
information.
Well,
hey
I
just
want
to
show
the
merge,
request,
title
and
offer
I
don't
want
to
show
the
last
commit.
It
was
based
on
off
master
or
something
like
that
right.
B
So
actually
you
know
it's
its
ups
and
down
sides
and
at
least
with
graphic.
Oh,
there
are
some
analysis
tools
and
you
can
also
jump
in
there.
I
don't
know
how
its
implemented
on
the
backhand
side,
but
fear
ethically.
You
could
also
see
what's
slow
and
improve
that
security
concern
I'm
with
you,
yeah
I,
don't
know
too
much
about
it,
and
it's
definitely
true,
but
one
of
the
things
that
I've
heard
you
know
that
is
actually
theoretically.
B
If
our
graphic
endpoint
is
up
to
snuff,
we
could
go
in
and
basically
be
our
existing
rest
and
points
just
being
unwrapped
are
about
around
the
graph
QL
endpoint
right
at.
In
the
background,
the
our
rest,
endpoint
just
does
the
graph
QL
query
that
leads
to
the
same
result.
Essentially
yeah.
It
would
be
very
interesting,
and
here
I
would
also
very
much
like
you
know.
One
of
the
frustrations
I
have
built
a
lot
of
things
with
get
labs.
B
Api
one
of
the
frustrations
is
that
it's
often
feels
very
Vesey,
so
you're
like
hey
I,
want
to
sort
stuff
and
you're
like
oh
cool
I,
can
thought
for
five
things,
but
I
actually
want
to
sort
for
a
new
thing.
I
know
that
needs
to
be
implemented.
It's
like
why
I
just
want
to
serve
I
have
a
date
field
in
here.
Like
I.
Don't
know,
I
want
to
select
merge,
request
after
the
merge
date,
but
I
can't
just
search
after
create
a
date
and
whatever
some
updated
date.
Why
can
I?
B
You
know,
there's
a
date
field
I
want
that
right.
So,
like
there's
a
lot
of
inconsistency
and
get
lab
always
had
the
spirit
like
oh
yeah,
we're
going
to
implement
that
API
field
or
that
search
when
it's
needed,
but
you
that's
also
just
similar
to
the
GDK
issue.
That's
it's
only
good
if
you're
in
get
lab,
because
I
can
just
code
that
up
assign
it
back
and
engineer,
get
it
merged.
But
someone
externally
is
like
oh
kid.
Let
doesn't
support
that.
Well,
I
can
create
an
issue.
B
B
But
I
read:
this
is
probably
something
where
we
and
I
think
I'm,
probably
not
too
happy
to
inherit
some
of
these
conversations,
because
some
of
these
conversations
will
be
very
exhausting
because,
as
you
might
imagine,
there's
like
a
lot
of
opinions
out
there
and
because
we
have
so
many
engineers,
there
might
be
a
lot
of
different
opinions
from
different
engineers,
and
so
it
will
be
very
interesting
where
we
land
and
I
agree
with
you
that
it
like
refu.
Our
first
thing
is
not
enough.
B
A
A
If
that's
what
we're
going
to
do,
but
we
have
to
define
that
clearly
and
then
communicate
that
out
clearly
exactly
because
otherwise
I
think
there
are
some
teams
who
are
straight
up
interpreting
and
it's
like
ok
graph,
you
only
and
like
there
is
a
bunch
of
functionality
that
has
been
developed
and
added
graph,
QL,
it's
not
in
the
rest,
and
then
we
have
all
of
this.
These
libraries
and
rests
that
are
being
used.
That
then
just
don't
have
access
to
any
of
that.
A
There
are
a
lot
of
endpoints
inside
I
get
lab
which
are
yeah
like
they
give
me
the
thing
that
you'd
expect
at
first,
but
then
I
can't
play
with
that
like
nowhere
in
our
API
is
and
I
say
this,
but
maybe
I'm
wrong,
but
like
we
don't
support
projections,
we
don't
support
or
green
by
anything
like
we
don't
support
sorting,
really.
Our
pagination
controls
are
minor
right,
like
I
I
as
a
developer,
who
loves
really
elegant
tight
solutions,
I
love
it
when
I
can
set.
My
word
ring,
set
my
sorting
or
set
roofing
better.
A
Yet
right,
I
can
also
project
only
the
fields
that
I
want
and
then
I
can
set
my
pagination,
sighs
max
right
and
then
I
just
get
a
data
set
back
that
I
want
and
like.
We
really
don't
have
the
ability
to
do
that
and
it's
actually
showing
what
we're
seeing
as
well
is
because
we
don't
have
those
controls.
We've
got
customers
who
are
grabbing
the
way
too
much
data
having
to
page
through
hundreds
of
queries
and
then
actually
is
a
huge
hit
on
our
system.
So
there
is
an
upside
from
performance
as
well.
B
A
Yes,
no
I
mean
so
here's
here's.
What
I'm
worried
about
so
I'll
show
you
how
my
brain
works
great.
So,
yes,
there
are,
there
are
a
bunch
of
native
clients
out
there.
I
have
significant
concerns
that
at
some
point
somebody
is
going
to
make
a
change
to
one
of
these
libraries
and
because
it's
poor
code
that
library
hits
a
race
condition
where
it
doesn't
know
the
end
state
of
the
call
it
just
made
so
because
it's
also
doesn't
have
any
logic
program.
A
Retries,
it
just
starts
retrying
interests
right
and
no
one
really
notices
it
and
it
goes
out.
Well,
it
turns
out
the
parole.
I,
don't
know,
I'm
making
it
up
the
parole
get
last
client
is
used
by
a
hundred
thousand
applications
and
then
that
thing
Otto
gets,
gets
Otto
updated
across
all
of
these
and
all
of
a
sudden
100,000
applications
out
in
the
wild
start
DDoS
and
get
slap
calm
right
like
that's
what
I'm
worried
about
yeah,
we
have
zero
insight
into
that.
A
We
have
no
ability
to
control
that
because
we
are
not
spending
time
on
our
SDKs
and
will
not
be
spending
time
on
our
SDKs.
We
don't
have
the
bandwidth
to
do
it
right
now.
So
that's
not
a
good
answer
in
that,
like
there's
a
space
that
we
should
be
worried
about,
that
we
have
no
control
over,
but
what
that
does.
B
A
Again,
we
need
really
tight
governance
and
guidance
on
our
API.
We
need
to
make
sure
that
things
were
being
set
up
in
a
way
that
that
will
not
allow
this
thing
to
happen
and
I
know.
We've
got
a
bunch
of
work
happening
right
now
around
application
limits
which
will
solve
some
of
that
right,
so
I
don't
know
but
yeah.
The
answer
is
yes.
I
have
concerns
about
it.
No,
we
don't
have
support
yeah.
B
No
I
just
remembered
because
I
contributed
upstream
to
some
JavaScript
gitlab
API
implementation
at
some
point
because
they
were
doing
like
stuff
wrong
right
and
it's
like
yeah
I
mean
the
interesting
interesting
thing,
for
example,
is
you
could
theoretically
use
it
for
dog
fooding
as
well?
I
could
use
it
as
a
good
entrant
test
mechanism.
B
So,
for
example,
if
we
actually
had
like
a
REST
API
implementation
of
our
of
our
gate,
lab
API,
we
could
theoretically
could
theoretically,
you
know,
use
it,
build
it
test
it,
and
if
we
accidentally
break
something
in
our
API
like
break
a
client,
we
would
see
it
automatically
right,
like
hey.
Suddenly,
just
integration
test
of
of
the
API
of
the
JavaScript
or
Ruby
API
client
doesn't
work
anymore.
Is
it
like
that?
What
happened
right
like
Jung,
okay,.
A
A
Whatever
reason
like
the
PHP
client
is
super
active
like
it's
a
pretty
active
community
that
works
they're,
a
bunch
of
PHP
sites
out
there,
integrating
this
gitlab,
that's
awesome,
great
yeah,
but
yeah,
and
there
and
I
think
part
of
the
problem
is
also
we
just
don't
have.
Our
engineering
organization
is
very
focused
on
Rails,
which
makes
sense
right
like
make
sense.
So
how
are
we
supposed
to
support
an
ecosystem
with
clients
in
closure
and
Python
and
laravel
and
dotnet
and
right
like
there's
so
many
different
libraries
out
there?
We
just
don't.
A
B
I
think
that's
fine
right,
the
thing
is
I
would
say
would
make
sense
for
us
to
to,
because
the
problem
is
what
we
have
seen
in
the
past
of
what
I've
seen
in
SDKs
in
the
past
is
like.
If
you
have
like
Java
engineer,
writing
JavaScript
API
libraries.
They
look
like
Java
code
right
there,
not
hydromatic,
so
to
speak,
so
it
well.
There's.
B
A
A
really
fair
point:
many
years
ago,
I
worked
in
developed
experience
at
Rackspace
and
we
actually
had
at
one
point.
We
had
a
developer
/
SDK.
That
was
an
expert
in
that
language,
and
that
was
the
only
way
to
support
that
because
you're
not
like
they
all
needed
to
be
idiomatic,
so
yeah,
we
we
didn't
use
Java
in
in
I
mean
in
where
we
were
in
recipes
in
that
part
of
engineering.
A
B
A
B
B
A
There's
definitely
I
know
there
are
some
teams
so
from
the
front
end
concerns
right.
Like
I
know,
there
are
some
teams
who
have
started
to
migrate
using
those
public
resources
to
power.
The
you
is
like
I
think
similarly,
like
I
know
we're
not.
We
are
not
an
API
first
company,
but
there's
definitely
some
shift
towards
like
yeah,
but
maybe
we're
API
somebody's
like
I.
Think
that's
positive
right,
like
I,
don't
think.
A
To
get
to
our
you
eyes,
only
consumer
a
be
eyes,
but
I
think
there
was
definitely
some
movement
in
that
direction
and
I
think
that
makes
sense
in
that.
You
know
you
know
about
the
thing
I.
Do
you
like
modern
front-end,
tooling,
is
heading
that
direction
and
kind
of
assumes
that
right
and
so
I
think
that
well
not
all.
A
A
And
then
we
talked
a
lot
about
the
work
being
done
with
and
foundations
by
the
way,
I
also
kind
of
I
shifted
it
in
that
MRF
e
/ux
foundations.
Tory
had
a
concern
that,
like
didn't
kind
of
capture
the
work
you
X
was
doing
so
feu
X
foundations.
We
did
a
good
job
talking
about
that.
We
didn't
talk
much
about
the
GDK,
but
I
think
that
the
GDK
in
general,
what
we've
discussed
so
far
has
been.
A
We've
got
someone
who
will
be
focused
on
GDK
I
know
that
there
is
a
GDK
working
group
which
I
should
probably
be
at
least
a
participant,
or
at
least
a
listener,
and
on
those
calls
to
make
sure
that
I
didn't
kind
of
keep
track
of
what's
being
talked
about
with
GDK,
but
I
think
the
GDK
is
pretty
sad
right.
We've
got
somebody
who's
gonna
be
focused
on
it.
A
We
do
already
have
a
working
group
discussing
it.
My
thinking
is
we'll
just
establish
I
just
need
somebody
to
come
to
me
and
say
these
are
the
issues
that
you
need
to
knock
out
this.
This
milestone
and
sounds
good
to
me.
So
I
think
those
two
are
pretty
set
I
dove
in
very
deep
on
integrations.
What
we're
talking
about
today,
we're
working
on
today
with
mass
integrations
where
we're
trying
to
head
with
JIRA
and
then
the
work
that
we're
probably
going
to
be
looking
at
over
the
next
year.
B
B
I
think
I
think
the
next
steps
for
me
would
be
diving
into
you
know
getting
to
know
the
people
more
diving
into
what
we've
done
on
the
integration
side.
You
know
trying
to
understand
like
especially
the
back
inside
of
it
I'm.
Actually
thinking
about
you
know,
maybe
maybe
picking
up
like
a
small
issue
like
what
we,
what
we
would
consider
an
onboarding
issue
for
an
engineer
for
myself.
B
You
know
so
just
that
I,
you
know
see
a
bit
more
about
the
codebase
and
see,
and
you
know
trying
to
understand
like
how
people,
because
you
said
we
don't
have
like
oh
yeah,
we
don't
have
like
good,
enter
and
testing
so
I'm
wondering
how
people
do
it
locally
right
so
do
do
they
need
to
install
Java
as
well.
That
sounds
like
fun.
We.
B
B
A
Name,
I
can't
is
completely
failing
me
right
now.
One
of
his
like
pie-in-the-sky
goals
would
be
he's
reached
out
a
couple
times.
We
talked
some
about.
He
wants
to
be
able
to
use
a
tool
that
he's
yes,
yes,
Jeff
Martin.
Thank
you
very
much.
Yeah
he's
building
a
tool
that
allows
kind
of
a
one
click
demo
set
where
you
can
say:
I
want
a
good
lab
installation
of
this
size
set
up
this
way,
click
and
it
spins
it
up
on
on
the
cloud.
A
So
a
sales
engineer,
sales
person
solution
architect,
whatever
can
just
have
that
demo
kind
of
readily
available.
One
of
the
goals
that
he
has
is
he'd
love
to
be
able
to
set
it
up
so
that
you
can
also
check
a
box.
It
says
and
agree
with
Gina
and
it
also
spins
up
Adria
instance,
for
you
at
the
same
time,
sets
up
an
appropriate
license
and
configures
the
integration
for
you
and
I
think
that
would
be
amazing.
That
would
be
super
cool,
yeah.
B
I
think
so
as
well.
It's
so
interesting
because
a
lot
of
these
efforts
I'm
wondering
how
we
are
able
to
do
it
efficiently,
because
a
lot
of
these
efforts
are
potentially
needed.
The
the
entry
and
testing
right.
A
lot
of
these
efforts
are
needed
for
local
development
like
and
sometimes
obviously
it
makes
sense,
because
hey
such
a
demon
environment
doesn't
need
to
have
the
same
things
as
the
developer
environment.
You
can,
for
example,
consumer
bills,
get
lab
in
favor
of
you
know,
having
the
actual
source
code
and
stuff
like
that,
so
yeah
I'm
very
interested.
B
If
there
could
be
collaboration,
efforts
there,
yeah
and
I
assume
that,
for
example,
from
a
GDK
perspective,
I
mean
it
would
be
cool
for
us
to
see.
How
could
we
do
a
thing
with
with
with
JIRA
and
getting
it
running
locally,
because
it's
part
of
our
daily
work
or
group
or
how?
But
probably
it
makes
from
from
an
company-wide
perspective,
it
makes
more
sense
to
look
and
how
can
I
get
a
good
lab
run
running
locally,
for
example,
because
that's
probably
something
that
more
people
need
then
JIRA.
A
Okay,
yeah
I
think
right
now,
we've
got
it's
a
totally
fair
point:
we've
got
a
couple
of
external
viewers,
I
think
we
have
like
three.
Whatever
we
have
a
couple
of
days:
external
JIRA
instances
that
we've
been
using
for
testing
and
to
your
point,
they
wrote
like
one
of
them
broke
at
one
point
and
Nick
had
to
go
in
and
try
to
get
things
right
hand,
but
that
broke
everybody
for
like
a
day
right,
so
yes
be
able
to
run
it
locally.
Asynchronously
from.
B
A
B
B
Still
a
good
engineer
and
I
can
understand
that
these
things,
but
my
fear,
for
example,
would
be,
and
it's
it's
good
that
we
I
don't
know
about
Andy,
but
Arturo
definitely
is
a
senior
engineer,
so
I
will
heavily
rely
on
him
yeah,
and
so
you
know
yeah,
it's
it's
just
it's
just
like
a
lot
of
new
things
that
I
need
to
consider,
and
you
know,
wrap
my
head
around
and
a
lot
of
new
people
to
work
with
trying
to
understand
the
product
politics
as
well.
You
know
what
is
important.
B
I
mean
you're
already
hinting
at
like
big
deals
and
stuff,
so
yeah
so
I
from
an
engineering
perspective.
You
know
I'm
probably
trying
need
to
try
to
balance
like
hey.
You
definitely
need
to
deliver
really
good
on
the
integrations
part
so
that
you
know
upper
management
keeps
us
alone
when
it
comes
to
other
things.
Yeah.
A
A
After
all
of
this
shift-
and
it's
like
oh
great
well
now
I'm
responsible
for
it
literally
how
everyone
makes
their
living
right,
we've
got
all
of
the
all
of
how
you
contribute
to
get
lab
comm
how
we
integrate
with
all
of
our
largest
customer,
selects,
all
of
our
you
Xers
all
of
our
software
engineers
and
all
of
our
integrating
partners
right.
So
it's
it's
a
really
big
scope.
I
am
super
excited
about
it.
I
think
it's
gonna
be
really
fun.
Yeah
I
think
that
you
know
full
transparency.
A
Like
I
think
we're
way
understaffed
for
today
today,
I
think
that
we'll
get
there
right
like
yes,
we
need
to
keep
the
lights
on
with
everything,
but
I
think
we
need
to
go
drives
for
revenue
to
go
build
some.
Some
great
integrations
with
large
enterprise
software
suites
like
ServiceNow
in
rally
right,
let's
go
build.
Those
things
out
prove
out
revenue
show
that
the
impact
there,
let's
also
go,
make
the
GDK
better.
Let's
go
fix
the
problems
that
we
have
with
pyjamas
parody,
with
get
lab
UI
all
right.
Let's
make
it
really
easy
to
contribute.
A
Let's
improve
our
API
is
to
make
it
easy
to
integrate.
If
you
don't
want
to
contribute
and
then
let's
go
grow,
the
community
right,
like
one
of
the
problems
that
we've
run
into,
is
that
we've
gotten
to
be
such
a
big
code
base
and
that
gtk
is
not
awesome.
It's
hard
to
use
for
external
people
who
aren't
getting
onboarding
right,
and
it's
such
a
large
code
base
that
it's
like
great
everyone
can
contribute
later
like
it's.
How
do
I
do
that,
like
that?
A
It's
pretty
straightforward
if
it's
just
like
editing
a
small
thing
in
the
UI,
but
if
it's
like,
adding
that
new
functionality
that
could
be
really
difficult,
so
I
think
that
what
I'd
like
to
see
from
the
you
know,
you
know
now
now
aforementioned
contributor
experience
things.
What
I
would
love
to
see
five
years
from
now.
Is
that
as
a
developer?
Who
is
interested
in
get
that
that
doesn't
work?
Forget
that
right
like
if
there
is
a
thing
I
want
to
go,
do
in
get
lab.