►
From YouTube: UX Showcase - CI/CD Templates Vision
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
Hi
everyone-
this
is
nadia
and
today
I'll
be
sharing
a
story
with
you,
and
I
will
use
our
issues
and
epics
to
tell
it
so
I'm
trying
a
new
approach
where
I
don't
create
presentations,
because
that
just
I
get
down
the
rabbit
hole
and
create
like
50
slides.
So
this
is
a
story
of
my
product
manager
dove
and
I
really
quickly
over
two
milestones:
creating
north
star
vision
for
the
gitlab
cic
template
experience.
A
So
we
were
very
short
on
time
and
we
knew
very
little
about
like
the
current
problems
around
the
cic
templates
experience,
and
one
day
we
just
saw
nmr
that
one
of
our
engineers
made
that
proposed
lots
of
changes
to
the
templates
experience
and
lots
of
it's
a
really
really
great
proposal,
and
this
by
the
way
is
a
new,
mr.
That
was
already
broken
off
from
that
other
much
bigger
bar.
A
So
it
wasn't
clear
to
us
whether
it's
like
solving
the
right
or
the
highest
priority
user
problems
with
the
whole
experience
or
not,
because
we
ourselves
didn't
fully
understand
the
problems
and
we
didn't
really
have
a
vision
defined.
So
we
were
really
struggling
with
driving
this,
mr
basically
into
like
some
direction
that
is
more
rooted
in
the
problems
based
on
user
research
and
so
on.
So
we
decided
to
very
quickly
wrap
our
heads
around
the
problems
and
create
some
kind
of
vision,
communicate
a
vision
around
cic
templates
experience
using
visionary
mock-ups.
A
A
What
we
tested
was
how
how
gitlab
users
would
sort
the
cic
templates
into
different
groups
to
make
them
easier
to
search
in
the
existing
github
ui
like
inside
the
templates
drop
down
so
like
in
retrospect,
we
should
have
started
just
with
problem
validation,
honestly,
because
there
were
many
gaps
in
my
understanding
about
the
problem
and
those
as
well.
But
still
now
this
comes
in
handy,
because
now
we
have
this
more
granular
information
around
how
the
different
templates
can
be
sorted
into
different
categories,
and
things
like
that.
A
We
also
ran
a
category
maturity
scorecard
recently,
which
was
not
directly
related
specifically
to
the
csu
templates
experience.
But
we
looked
at
the
pipeline
authoring
experience
and,
as
part
of
this
study,
we
tested
how
our
own
gitlab
srs
engineers
would
approach
creating
a
pipeline
a
new
pipeline
for
a
project.
A
So
of
course,
templates
were
part
of
that
experience
because
templates
are
sassy.
Templates
is
usually
how
you
start
a
pipeline.
You
copy
some
kind
of
example,
or
you
use
a
template
inside
gitlab
and
that's
how
you
start
customizing
your
pipeline,
but
we
still
had
lots
of
open
questions
like
we
kind
of
had
some
bits
and
pieces
of
understanding
just
like
giving
us
enough
information
that
okay.
This
is
a
really
important
problem,
but
we
we
still
don't
really
have
a
clear
direction.
A
So
we
started
a
problem.
Validation
issue
specifically
to
understand
the
template
management
pain
points
like
template,
management
and
usage
pain
points
for
large
enterprise
companies.
So
we
wanted
to
talk
specifically
to
our
customers
to
understand
what
are
those
specific
problems
that
large
organizations
are
facing
when
using
csd
templates
and
using
cica
templates
for
them
often
really
means
maintaining
libraries
of
custom
templates
that
they
create
and
they
want
to
distribute
those
across
the
organization
to
enable
cic
practices
to
ensure
compliance
and
things
like
that.
Basically,
anything
that
gets
enabled
using
csd
pipelines.
A
That's
what
templates
can
help
with
so
through
these
calls
with
customers
that
don't
very
skillfully
rent,
because
it's
not
easy
to
get
a
hold
of
those
those
people.
So
we
were
looking
specifically
for
people
who
authored
their
pipelines
like
so
it's
devon,
priyanka
those
kinds
of
personas-
and
I
just
listened
to
the
recordings,
but
it
was
very,
very
insightful.
A
We
together
collaborated
on
analyzing
the
research,
so
we
together
tagged
and
created
insights,
which
was
really
really
helpful
for
us
to
very
quickly
create
create
a
lot
of
shared
understanding,
because
we
would
just
discuss
the
research
sessions
and
yeah.
It
was
like
a
very
kind
of
natural
flaw,
so
that
was
great.
So,
based
on
all
of
these
insights,
we
started
to
get
a
better
understanding
of
what
are
the
current
problems
and
opportunities
that
exist.
So
first
off
github
templates
aren't
discoverable.
A
How
can
we
make
them
more
discoverable,
it's
difficult
to
find
the
right
template
to
solve
most
of
your
needs,
so
it's
just
difficult
to
search
it's
difficult
to,
because
we
don't
have
a
search
that
like
looks
for
certain
categories
of
templates,
you
need
to
really
type
in
the
name
of
the
template,
which,
right
now,
it's
like
very
kind
of
based
on
github
features,
rather
than
the
purpose
of
the
template,
then
also
improving.
The
templates
would
make
github
features
more
discoverable.
A
Also,
another
big
problem
is
that
our
cic
templates
are
used
in
many
different
web
base,
so
you
can
just
copy
and
paste
a
template
into
your
pipeline
configuration
and
then
manipulate
it
there
or
you
can
insert
complete
pipelines
or
like
separate
pipeline
files
into
your
main
pipeline
using
various
keywords.
A
So
some
templates
are
designed
specifically
to
be
a
workflow
template.
That
is
just
your
onboarding
template
that
you
use
to
create
the
backbone
of
the
pipeline,
while
other
templates,
like
many
of
the
templates,
our
security
team
has
all
the
sas
scans
and
things
like
that.
They're
meant
to
be
used
with
an
include,
so
it's
completely
different
way
to
use
a
template
and
we
need
to
differentiate
how
we
treat
those
different
use,
cases
in
the
ui
and
in
the
templates
themselves
and
yeah.
A
We
also
wanted
to
help
organizations
maintain
libraries
of
templates,
make
them
easier
to
share
across
the
organization
and
ensure
that
the
projects
inside
the
organization
have
easy
access
to
all
those
templates
and
it's
easy
to
get
started
with
their
pipeline
in
a
way
that
is
compliant
and
according
to
the
company's
standards.
A
A
So
these
are
all
of
the
different
problems
and
it's
a
lot
so
based
on
all
of
these
things,
we
started
also
documenting
how
do
our
customers
currently
solve
these
problems
so
clearly
they're,
somehow
operating
and
they're
solving
these
problems
in
their
own
ways
with
like
custom
scripts
and
things
like
that.
A
So
the
main
thing
I'm
not
gonna
like
go
into
detail
into
this,
but
the
main
thing
is
that
organizations
often
have
a
library
of
templates
in
a
project
or
a
group,
and
they
simply
link
to
this
project
or
a
group
and
tell
their
developers
hey
use
all
of
these
templates.
These
are
the
required
templates
for
you
to
include.
This
is
what
you
need
to
run
in
your
pipeline
for
compliance
and
some
organizations
have
custom
scripts
that
go
into
projects
and
check
if
you're
running
the
right
pipeline
or
not,
and
things
like
that.
A
Other
organizations
don't
do
that.
So
it's
really
trust
based
and
because
of
that
not
very
efficient,
and
the
next
question
we
asked
is:
how
do
our
competitors
currently
solving
for
these
problems
that
we've
uncovered?
A
So
it
was
perfect
timing
to
try
out
the
competitor
evaluation
process,
where
I
analyzed
the
experience
for
creating
a
library
of
custom
templates
and
like
how
does
it
show
up
in
the
ui?
What
is
the
experience
for
the
developer,
creating
the
pipeline
with
those
templates
using
github
actions
and
circle
ci?
A
So,
if
you're
curious,
you
can
check
out
this
issue
which
I
haven't
linked
yet,
but
I
will
to
our
agenda
so
based
on
all
of
these
insights,
we
decided
to
create
visionary
mock-ups,
so
we
can
actually
communicate
that
vision
in
some
kind
of
visual
way
to
our
engineers
and
specifically
to
shinya
who's,
been
working
on
this
big
proposal
to
see
like
where
it's
aligned,
where
it's
misaligned
and
it
turned
out,
actually
that
it's
aligned
pretty
much
all
of
it
is
aligned,
but
we
just
need
to
kind
of
prioritize
and
make
sure
that
we
focus
on
the
highest
priority
features.
A
First,
so
probably
the
initial
proposal
will
be
broken
up
further
to
focus
on
some
more
specific
parts
of
the
experience,
but
we're
still
discussing
that.
So
I
don't
want
to
dive
into
the
mock-ups
too
much
because
my
dove
and
I
will
be
recording
a
proper
walkthrough
tomorrow
and
sharing
with
everyone,
and
also
not
everyone
from
my
team
have
seen
this
yet
so
it
would
be
unfair.
I
feel
like
to
share
it
here.
First,
I
want
to
make
sure
they
see
it,
but
just
as
a
little
sneak
peek.
A
This
is
what
we're
thinking
of
for
the
experience
of
creating
a
pipeline
for
a
project
as
a
developer,
an
organization
that
created
a
custom
library
of
templates
for
you.
So
we
would
pull
in
those
templates
into
the
ui
and
the
templates
will
have
tags
and
all
kinds
of
additional
useful
metadata
attached
to
them,
which
is
what
genius
proposal
is
all
about,
adding
all
of
that
useful
metadata
and
we
will
differentiate
between
workflow
templates
and
templates
that
are
meant
to
be
included
in
your
pipeline.
A
So
as
part
of
your
initial
onboarding,
this
is
the
empty
state
for
cicd.
Basically,
in
gitlab,
you
will
only
see
the
workflow
templates
and
if
you
have
organization
templates,
which
are
like
group
level
templates,
csc
templates
for
your
organization,
you
will
see
them
by
default
here
and
you
can
still
have
access
to
gitlab
workflows
coming
into
workflows.
A
Partner
integrations
things
like
that.
Hopefully,
we
can
also
use
some
kind
of
intelligence
to
recommend
a
template
based
on
your
project
type.
So
if
you
have
a
note
project
and
we
should
be
able
to
have
the
information,
I
think
we
show
it
like
the
major
language
of
the
repo
in
the
repo
page
as
well.
We
can
recommend
a
template
for
that.
So
in
this
case
the
bluespark
team
created
this
template
for
their
bluespark
project
and
as
a
developer,
creating
a
pipeline.
A
You
can
easily
just
get
started
with
the
right
template
that
already
has
all
of
the
things
necessary
built
in,
so
you
can
just
like
customize.
It
run
it
and
you're
done
yeah,
and
these
are
some
of
the
thoughts
we're
having
around
the
pipeline
editor
experience
as
well,
so
we
want
to
start
moving
closer
towards
what
our
web
id
looks,
like,
I
suppose,
and
creating
a
more
unified
experience.
A
This
is
just
by
the
way
I
should
have
said
this
is
super
visionary,
so
I
this
is
like
the
only
option
that
I've
explored
for
the
pipeline.
B
A
Ui,
it's
not
gonna,
look
like
this,
but
this
is
the
direction
kind
of
that
I
have
in
my
head
and
you
would
be
able
to
again
along
the
lines
of
separating
two
different
types
of
templates
usage.
You
would
be
able
to
select
a
different
workflow
template
or
you
would
be
able
to
add
a
workflow
extension
which
is
currently
the
best
word.
We've
come
up
with
for
defining
a
pipeline
or
a
job
that
can
be
included
in
your
pipeline,
so
it
could
be
included
using
the
include
keyword
or
extend
or
like
a
child
pipeline.
A
For
many
of
you,
probably
it's
very
confusing
like
what
child
pipelines
extends
and
it's
that's
how
confusing
it
is.
I
think
for
new
users
as
well,
so
the
idea
is
to
provide
two
options
at
first,
which
makes
it
easier
and
then
once
you
get
to
the
workflow
extension
and
you
need
more,
you
can
start
digging
into
all
of
the
nuances
that
we
have
for
adding
your
workflow
extension
using
different
keywords
and
we
might
add,
like
customizable,
onboarding
information
to
the
pipeline
editor.
A
A
So
maybe
we
could
allow
them
to
add
custom
links
and
steps,
and
things
like
that
into
the
pipeline-
editor
sidebar
onboarding,
so
their
team
can
follow
custom
steps
based
on
what
the
organization
pipeline
should
look
like
yeah,
so
I'll
be
sharing
more
about
it
tomorrow,
so
stay
tuned
for
that,
but
that
was
a
an
overview
of
the
process
of
how
we
got
here
and
the
next
steps
are
sharing
this
with
our
team,
continuing
discussions
and
iterating
together
virginia
on
his
mr,
which
seems
like
it
supports
90
of
what
we
want
to
do
here.
B
This
is
awesome.
Thank
you,
nadia,
I'm
biased,
because
we've
seen
this
last
week
during
the
the
icd-ux,
we
have
a
couple
questions
in
the
in
the
agenda.
Do
you
want
to
voice
yours.
C
Yeah
sure
so
it
you
have
kind
of
answered
this
already,
but
I
was
just
wondering
like
how
does
the
new
findings
they
could
be
tied
back
to
sheena's.
Mr,
I
know
it's
like
in
a
very
different.
It's
a
whole
new
problem
space
now.
A
Well,
shiny
smr
supports
what
we
want
to
do
with
the
ui
quite
a
bit,
because
ksmr
is
about
adding
different
types
of
metadata
to
the
templates,
for
example,
adding
different
template
categories
and
things
like
description
and
authors,
and
things
like
that.
So
it
means
we
will
be
able
to
pull
the
information
into
the
ui
which
the
mock-ups
are.
You
know
a
lot
of
it
is
about
having
that
metadata
and
allowing
you
to
search
for
your
template
using
tags,
and
things
like
that.
So
shiny's
proposal
actually
addresses
that.
A
But
his
proposal
is,
I
would
say,
bigger
in
scope
than
what
we
ended
up
defining
in
the
mock-ups
I
forgot
to
mention
like.
Why
did
we
focus
on
boarding
in
with
the
mock-ups?
A
And
it's
because
we
see
that
as
a
big
selling
point
for
large
organizations,
if
you
have,
if
you're
a
very
large
enterprise
and
you
have
lots
of
projects,
all
of
them
need
to
be
onboarded
onto
ci
and
you're
hiring
new
engineers
that
need
to
be
on
board
and
onto
your
ci
cd
practices,
you're
very
interested
in
making
the
onboarding
as
smooth
as
possible
following
your
csc
practices
and
creating
these
mock-ups
would
hopefully
help
advertise
this,
and
a
lot
of
them
currently
have
already
libraries
of
csv
templates.
A
C
And
do
you
feel
that
this
new,
the
new
proposals
could
they
have
like
they
could
potentially
alter
the
architecture
that
china
has
proposed,
or
everything
is
in
tandem
already
or
has
this
conversation
happened
yet.
A
So
we're
still
discussing
this,
but
it's
more
or
less
aligned
like
we
just
had
a
meeting
today
and
it's
more
or
less
lined
it's
more
about.
Maybe
some
of
the
things
in
his
architecture
will
not
surface
in
the
ui.
Maybe
we
will
default
to
a
smaller
like
more
narrow
set
of
options
in
the
ui
and
then
allow
you
to
use
more
advanced
features
like
by
taking
to
the
documentation
to
read
about
it,
but
yeah
at
this
point,
it's
hard
to
say
it
might
shape
into
something
entirely
different.
A
D
I
think
I
got
the
next
one.
I've
tried
out
github
actions
quite
a
bit
over
the
last
couple
of
weeks
for
a
small
side
project,
because
I
really
wanted
to
see
how
it
feels
and
how
it
differs
from
our
own
solution,
and
one
of
the
things
I
noticed
when
using
templates,
especially
from
the
community,
is
that
it's
really
tough
to
understand.
What's
going
on
inside
these
templates.
D
So
especially
when
there
are
community
contributions
where
you
have
no
direct
association
with
these
users
who
have
contributed
them.
You're
not
only
concerned
about
the
stability
but
also
about
islam,
maybe
any
kind
of
malicious
code
hidden
inside
that
could
like
steal.
My
content
that
could
like
put
something
bad
into
my
code.
Is
that
something
that
has
already
come
up
for
you
and
your
team
as
a
challenge.
And
how
are
you
thinking
about
this
currently.
A
We
haven't
really
uncovered
this
problem,
yet
I
think,
because
we
haven't
really
gone
deeper
down
the
rabbit
hole
of
the
community
templates,
because
currently
we
don't
really
have
that
right.
But
it's
it's
like
a
a
huge
piece
of
an
even
bigger
vision.
So,
but
that's,
I
think,
that's
a
really
good
concern
and
generally
the
current
proposal
that
chenia
has
around
adding
all
of
these
different
types
of
metadata.
A
I
think
one
of
the
drivers
behind
this
is
to
make
the
template
easier
to
consume
and
easier
to
see,
what's
happening
there
and
then
some
other
things
yeah.
So
we
don't
know
what
fields
will
be
mandatory
or
and
what
not
like.
We
don't
know
those
details,
but
it
might
help
with
that
as
well.
But
I'll
get
back
to
you.
Definitely
when
we
start
asking
more
questions
around
the
community
templates.
B
Okay,
I
want
to
keep
us
on
time,
but
I
have
a
question
related
to
ulta,
devops
and
configure
nadia.
Can
you
tell
us
a
little
bit
about
how
your
collaborate
or
how
these
the
templates
relate
to
the
other
devops
adoption.
A
So
well,
part
of
our
vision
is
to
use
the
shared
workflows
or
these
workflow
extensions
to
promote
such
features
as
autodevops.
So
autodevops
is
currently.
A
A
They
were
aware
of
the
overall
vision
kind
of
that
we
have
for
pipeline
authoring
through
collaboration
on
autodop's
vision,
the
design
sprint
that
we
did
together,
but
we're
gonna
share
it
with
them
and
have
discussions,
because
I
don't
know
we'll
have
to
we'll
have
to
collaborate.
That's
the
answer.
B
Thank
you
better.
Do
you
want
to
ask
your
questions?
Maybe
one
of
them
and
then,
when
we
move
the
conversation
we
sync,
so
we
leave
room
for
vitica.
E
That's
okay,
I'm
gonna
ask
the
one
I'm
most
interested
in,
which
is
the
second
one,
but
first
of
all
thank
you
nadia.
It
was
great
seeing
you
do
a
presentation
without
slides.
That's
that's
perfectly
fine!
Don't
worry
about
that.
It
was
as
informative
and
as
engaging
as
it
was.
This
slide
presentation.
So
don't
worry
and
also
thank
you
and
I'm
very
happy
to
see
the
effort
you
put
into
the
research.
A
Yeah,
so
we
want
to,
we
want
to
have
a
unified
experience
for
editing
in
gitlab
period.
I
think
we
definitely
have
way
too
many
ways
to
edit,
but
the
problem
is
that
the
current
pipeline
editor
is
built
on
top
of
a
single
single
file
editor,
basically
so
we're
in
tricky
position.
We
we
have
this
thing
that
is
still
kind
of
like
single
file
editor
and
we
want
to
take
it
more
towards
being
like
web
id,
but
eventually
that's
where
I
want
to
go.
A
One
thing:
definitely
that
we'll
be
looking
at
sooner
rather
than
later
is
changing
the
navigation
and
looking
at
the
commit
flow,
I
think
there's
an
issue
for
for
us
all
to
collaborate
on
the
commit
flow
inside
github
editors.
So
have
one
pattern
for
committing
inside
all
of
the
different
editors
that
we
have,
but
we
haven't
really
made
any
like
specific
design
or
research
effort
in
that
direction.
Yet.
E
Yeah
thanks
for
explaining,
I
would
encourage
you
to
he's
not
in
on
this
call,
but
too
I
don't
know
if
he
will
see
it
but
to
reach
out
to
mike
nichols,
because
he
was
heavily
involved
in
the
editor
experience
to
see,
if
there's
anything
that
you
can
do
to
bridge
that
gap
and
avoid
creating
a
third
editing
experience.