►
From YouTube: UX Showcase: Shifting to an Integration Platform
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Hello,
everyone
Libor
here
senior
product
designer
for
the
Integrations
group
and
it's
been
a
while
since
I've
shared,
what's
happening
in
our
group,
so
I'll
start
with
a
little
quick
update
here.
So
first
of
all,
our
Integrations
group
is
no
longer
under
the
ecosystem
stage.
It's
now
under
manage,
and
so
some
of
you
may
have
known
that.
A
I
was
surprised
by
that
when
I
got
back
from
my
parental
lead,
it's
kind
of
good
and
secondly,
our
group's
direction
is
Shifting
to
be
more
platform
focused,
and
so
our
groups
PM
Grant,
made
an
excellent
video
about
this
already
about
this
shift,
and
he
includes
a
lot
of
different
metrics
that
support
the
rationale
and
the
reasoning
behind
this
shift.
So
I
encourage
you
all
to
watch
it
if
your
team's
thinking
about
integrating
with
any
other
third-party
services
I
think
the
videos
his
is
internal.
A
So
it's
linked
right
here
and
so
for
today.
I
just
want
to
talk
about
this
shift
to
an
integration
platform
and
more
what
it
means
from
a
design
standpoint.
A
So
why
the
shift
so
historically
that
integration,
the
group,
has
operated
as
like
a
streamlined
team
being
the
creators
of
the
majority
of
Integrations.
A
So
our
group's
Focus
has,
you
know
been
to
you
know:
build
Integrations
and
add
user
value
as
quickly
and
independently
as
possible,
without
requiring
us
to
hand
it
off
to
other
teams,
but
in
reality
you
know,
we
spent
a
lot
more
effort
on
bug,
fixing
security
and
maintenance.
You
know
rather
than
delivering
on
newer
features,
so
this
approach
hasn't
been
scaling
well
and
plus.
We
found
that
there's
a
greater
opportunity
for
us
to
support
gitlab
product
teams,
Partners
contributors
and
customers.
A
By
focusing
our
efforts
on
providing,
you
know
more
self-service
tools
for
building
Integrations,
so
as
a
platform
team,
we'll
shift
our
Focus
to
more
internal
Services,
that's
that
other
streamlined
teams
can
use.
A
A
So
what
are
we
doing
differently
today?
Grant,
RPM
and
I
are
have
this
ongoing
discussions
about
this
topic
during
our
weekly
one-on-ones
and
during
Milestone
planning.
The
goal
is
to
kind
of
schedule
at
least
one
piece
of
work
that
supports
this
shift,
so
we're
consistently
working
towards
this
effort
and
and
so
I
see
this
effort
being
Loosely
broken
down
into
these
three
following
themes,
which
is
Focus
and
so
focus
on
existing
commonly
used,
Integrations
empowering
others
and
making
it
easy
for
internal
and
external
developers
to
contribute
and
to
standardize.
A
So
we
want
to
do
less
custom
work
and
more
standardization
and
I'll
go
through
each
one
of
these
in
a
little
bit
more
detail
and
show
some
examples
so
Focus
to
so
to
focus.
That
generally
means
to
say
no
to
things
so
we'll
be
saying
we're
going
to
stop
working
on
any
new
Integrations
and
instead
prioritize
improving
our
existing
Integrations
and
prioritizing
the
work
around
our
apis
and
web
hooks.
A
So
that's
a
little
bit
of
a
challenge
today
through
making
a
searchable
catalog
and
a
dedicated
integration
landing
pages.
So
I
have
one
example
here
of
a
integration
landing
page
that
we
recently
launched
for
the
git
lab
for
slack
application.
A
So
if,
for
example,
if
a
partner
wanted
to
come
along
and
create
a
new
integration,
you
know
they
could
automatically
have
this
kind
of
a
landing
page
created,
but
that's
further
down
the
line,
not
there.
Yet,
let's
see
so
next,
we
want
to
empower
others.
So
we
want
to
make
it
easier
for
internal
and
external
developers
to
contribute
and
manage
their
own
Integrations.
So
we
don't
so
we're
not
the
bottleneck
having
to
do
that.
A
So
our
team
should
try
to
become
again
domain
experts
in
all
these
different
in
the
different
product
stages
that
we
have
currently
at
gitlab,
and
so
instead
we
want
to
provide
those
tools
and
support
others,
so
they
could
do
that
on
their
end,
and
so,
in
order
to
do
that,
we
really
need
to
have
better
sample
Integrations
and
offer
more
code
samples
and
and
show
different
demos
of
how
that's,
how
that,
how
that's
done
and
how
to
get
started.
A
So
we
do
have
some
integration
examples
today
that
I
found
they
all
kind
of
link
to
different
issues,
and
some
of
them
are
two
years
old
or
older.
So
it's
hard
to
tell
first
of
all,
if
they're
up
to
date,
the
structure
of
the
different
issues
is
inconsistent
and
the
format
is
inconsistent,
so
it
makes
it
a
little
bit
harder
to
follow.
A
So
you
could
improve
our
efforts
there
or
should
improve
our
efforts
there
and,
let's
see
going
back
here,
and
we
also
need
to
continue
our
ongoing
efforts
to
just
keep
our
documentation
clear
and
make
sure
the
documentation
is
up
to
date.
A
Next,
you
know
Stan
to
stand.
We
want
to
standardize.
We
basically
don't
want
to
do
custom
work
and
want
to
move
faster.
So
the
same
way,
we
use
our
pajamas
our
design
system
today
to
help
us
move
fast
and
reduce
the
need
for
Reinventing
the
wheel.
Every
time
we
want
to
be
working
on
so
we'll
be
working
towards
that
and
we'll.
We
also
want
to
work
on
standardizing
different
interaction
patterns
and
extending
upon
our
existing
product
configuration
principles,
but
next
integration
categorization.
A
A
So
we
have
some
of
that
happening
more
underneath
the
hood
of
how
we
Define
the
different
classes
more
of
the
code,
but
not
so
much
on
the
on
the
front
end
and
the
user
facing
categories
so
and
then
next,
which
is
this
integration
static.
Dsl,
is
an
exciting
new
effort.
I
have
an
issue.
We
have
an
issue
for
that
here.
Let's
see-
and
this
is
really
interesting
because
we
have
an
integration
guide
today,
which
is
the
beginning
of
this
doc
here,
but.
A
The
developer
experience
just
needs
more
refining
here.
So,
even
though
we
have
this
guide,
gitlab
still
ends
up
having
to
guide
a
lot
of
the
development
and
there's
basically
it's
to
write
an
integration
today,
there's
a
lot
of
different
things
that
need
to
be
written
and
a
lot
of
different
settings
that
are
similar
and
in
multiple
different
places
that
need
to
be
kept
in
sync,
so
this
static,
DSL
d,
yeah,
a
cell,
should
solve
this
problem.
My
understanding
is
it's
kind
of
similar
to
writing.
A
A
single
configuration
yaml
file
that,
instead
of
having
code
and
configuration
in
different
places
of
the
application,
next
I'm
going
to
go
through
a
few
examples,
focusing
more
around
the
need
for
establishing
patterns
around
our
Integrations
So.
A
Let's
see
for
instant
instant
Incident
Management
here's
another
example
of
what
this
integration
would
do
here.
A
To
our
to
our
Integrations,
to
be
able
to
extend
them
and
also
would
be
nice
if
you
know
another
chat
provider
then
comes
along
and
then
decides
to
to
build
a
chat
integration
with
gitlab.
They
should
automatically
have
access
to
that
new
trigger.
Sorry,
let
me
go
back
here.
A
So,
ideally,
you
know
there's
some
set
of
patterns
that
we
establish
that
make
it
easy
to
extend
upon.
You
know
these.
These
triggers
here.
A
A
Oops
made
it
too
small,
and
this
was
focusing
on
extending
the
jira
integration
and
adding
this
section
here.
A
So
at
the
time
this
required
both
again
both
teams
to
create
Spike
issues
to
understand
how
this
would
work
and
understanding
just
all
the
technical
constraints
so
again
having
some
sort
of
generic
pattern
for
or
how
to
extend
an
extend
integration
for
issue
tracker
category
would
save
us
a
lot
of
time
and
next
here
last
example,
I
have
is
around
just
establishing
some
guiding
principles,
so
we
have
a
set
of
those
right
now
which
are
really
great
and
I.
A
So,
for
example,
let's
see
right
here,
for
example,
so
imagine
that
you're
a
project
maintainer
and
you
have
you-
know
three
different
Pro
integration
set
up
for
your
project
and
one
of
them
being
in
the
git
lab
for
slack
app.
So
imagine
that
you
now
want
to
change
some
settings
for
the
gitlab
slack
app.
So
imagine
you
have
the
both
set
up.
So
where
do
you
go
to
change
that?
Do
you
go
to
your
gitlab
app
to
find
those
settings?
A
So
we
need
to
establish
some
kind
of
guiding
principles
even
just
around
where
these
settings
should
live
and
for
now
for
the
thought
is
for
at
least
to
get
in
this
case
for
the
git
lab
for
slack,
we
want
to
establish
that
all
the
settings
are
primarily
first
in
git
lab
and
then
we
could
extend
those
out
to
the
other
clients.
A
So
that's
one
example
of
you
know
we're
having
some
guiding
principles
here
will
help
in
the
long
term.
That's
it
all.
That's
all
I
have
for
now
for
the
Showcase
thanks.
Thank
you
all
for
listening
and
let
me
know
if
you
have
any
questions.
B
I
just
started
adding
a
question:
I'm
finished,
but
I'm
I
was
curious.
If
the
team
has
started
discussing
like
a
central
location
for
all
of
the
guidance.
One
example
is
we
have
the
gitlab
developer
portal
that
has
like
apis
I,
think
we
have
web
web
hooks
on
there
and
then
maybe
native
Integrations,
or
something
like
that.
So
is
that
going
to
be
included
as
part
of
this
effort?
Are
we
thinking
about
creating
something
else.
A
Yeah
good
questions
right:
this
is
still
kind
of
up
in
the
air
a
little
bit
where
this
is
some
things,
we're
still
discussing
a
grant.
Definitely
the
the
developer
portal
is
probably
a
good
place
to
start
putting
some
of
these
things
so
we'll
see.
I
know
we
have
multiple
guides
too
I
think
so
then
being
able
to
consolidate
some
of
these
would
be
helpful.
A
I
think
we
have
like
this
this
page
as
well,
integrate
with
gitlab
and
then
yeah,
trying
to
figure
out
how
this
all
ties
together
is
would
definitely
be
one
of
the
efforts
that
we
need
to
figure
out.