►
From YouTube: CI/CD UX Meeting 2022-04-20(APAC)
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
Hello,
everyone
today
is
the
20th
of
april
and
we
are
meeting
for
the
ci
cd
qx
meeting
and
starting
off
with
the
general
announcement.
So
we
are
approaching
the
end
of
quarter
first
for
financial
year
21
22
23.
So
I
think
it's
a
good
time
to
go
back
and
review
our
ocr
progress
and
drop
a
note
if
we
are
apprehensive
of
kind
of
reaching
any
of
the
care
as
mentioned,
and
that's
it
that
there's
just
one
genuine
announcement
this
week,
all
right.
So
I
think
yeah
kitty
to
you.
B
Yeah,
I
don't
have
actually
that
much
to
report
on
this
week
because
it's
been
lots
of
holidays
and
and
whatnot,
but
this
week
I'll
be
doing
some
survey.
Development
interviews
in
preparation
for
releasing
a
survey.
So
erica
gave
me
this
idea.
So
what
I'm
going
to
do
is
have
some
customers
take
the
survey
kind
of
in
front
of
me
and
then
I
can
kind
of
prompt
them
with
questions
and
make
sure
that
the
survey
is
actually
asking
the
right
questions
and
covering
everything
we
want
to
know.
B
It
makes
sense
so
that'll
be
tomorrow
and
the
next
day,
and
I
just
put
a
small
request
for
design
feedback
that
just
occurred
today
in
a
slack
message.
B
We
have
this
case
where
we
have
to
put
an
alert
inside
of
a
table,
and
I
just
I
did
read
the
pajamas
guidelines
and
it
says
it's
acceptable
to
put
alerts
in
context,
but
I
haven't
actually
seen
them
in
a
table
and
I
just
wanted
to
check
with
the
ux
team
if
that's
acceptable
or
if
it's
weird-
and
my
last
point
was
just
asking
the
group
if
anyone's
leveraged
data,
to
make
design
decisions
and
what
the
process
was
like.
B
C
So
we
haven't
really
been
using
data,
a
lot
on
the
pipeline
authoring
team
to
measure
the
test
of
design
issues.
However,
in
the
past
couple
milestones,
I
started
it
really
strictly
using
our
complete
issue
template
for
the
designing
issues
and
all
of
them
have
a
section
for
metrics.
C
So
I
noticed
that
that's
been
a
good
kind
of
like
a
prompt
for
pm
and
I
about
it
and
to
try
to
set
some
metrics
that
we
will
be
tracking
for
the
speech
picture
and
now
we're
starting
just
to
instrument
new
metrics
wherever
we
need
them
and
so
on
so
we're
very
early
in
the
process.
But
yeah
we've
been
talking
about
it.
I
just
don't
have
any
historical
data
to
share
with
you
how
it
worked
out
for
us.
B
C
Yeah,
so
the
first
step
would
be
for
us
to
check
if
this
is
something
that
we
can
get
right
away
from
looking
at
our
dashboards.
Sometimes
we
can
get
that
data.
C
Otherwise
we
talk
to
our
engineers
and
we
might
have
to
open
an
issue
to
look
into
how
we
can
get
the
data
with
our
engineers
and,
if
necessary,
we
might
also
have
to
reach
out
to
our
data
team,
whatever
their
name
is,
but
we
have
like
a
team
responsible
for
for
that
cool
thanks.
A
So
I
know
from
like
I
was
also
trying
to
set
up
something
for
papine
execution
and
that's
when
I
went
back
to
a
ux
showcase
video
by
michael,
where
he
had
talked
about
how
he
made
certain
decisions
about
the
navigation
by
looking
at
the
data,
and
I
created
an
issue
for
piping
execution,
I'm
not
able
to
find
it
right
away,
but
we
haven't
worked
on
that.
A
Yet
we
haven't
set
up
the
tracking
or
instrumentation
yet,
because
even
for
that,
we
would
need
some
engineering
bandwidth
which
at
this
point
we
don't
have,
but
that
video
is
a
really
good
source.
I
think
you
should
watch
it
cool
we'll
do.
Thank
you.
C
All
right
so
this
week,
I'm
starting
to
refine
the
mvc
proposal
for
the
private
cicd
component,
catalog
we're
going
to
pursue
the
private
cicd
component,
catalog
first
rather
than
the
public
one.
This
is
just
a
business
decision
also
it
seems
easier
for
us
in
terms
of
implementation-
and
this
is
the
catalog
that
we
would
be
able
to
dock
food
more
easily
because
we
could
have
a
private
icd
catalog
for
the
gitlab
team.
So
our
idea
is
to
create
a
private
size
to
catalog
process.
C
So
it's
a
process
for
publishing
a
city
component
and
using
the
icd
component
that
some
of
our
team
could
use
and
we're
looking
at.
I
think
our
infrastructure
team,
maybe
the
productivity
team-
and
maybe
I
forgot
what
their
team
name
is,
but
the
team
that
managed
just
fast
and
death
scans
and
so
on.
I
think
the
cure,
maybe
something
like
that.
I
guess
yeah
yeah,
it
checks.
The
vulnerabilities
in
your
code,
so
must
be
secure,
yeah.
C
C
Okay,
so
we're
trying
to
reuse
the
existing
ui
as
much
as
possible
for
the
flow.
So
the
idea
here
is
that
to
publish
a
component
in
in
the
cicd
catalog,
you
will
be
using
the
projects,
ui,
documentation,
instructions
and
our
existing
ui
for
creating
branch
tags
and
making
a
release.
So
you
would
start
with
reading
through
the
instructions
for
like
step-by-step
instructions
for
creating
your
component
in
the
docs.
C
Then
you
would
have
to
create
a
new
project
and
we're
planning
to
utilize
the
template
function.
For
that,
so
you
can
create
a
project
from
a
template
and
there
would
be
a
template
to
create
a
csd
component.
C
Then
you
would
use
that
project
to
create
your
component
yaml
and
readme
files
component
yaml.
It's
where
the
actual
component,
like
pipeline
code
will
be
and
readme
file
will
contain
all
of
the
usage
instructions
for
that
component.
Once
that
component
is
published,
we
will
pull
this
information
into
the
cicd
catalog
page,
where
you
will
be
able
to
see
the
usage
guidelines
for
the
component
and
actually
use
the
component
like
on
the
developer
side.
C
So
once
you
yeah.
So
this
is
basically
just
the
usual
kind
of
merge
requests
flow.
You
review
the
files
with
your
team,
ensure
that
everything
looks
good
once
all
of
your
files
are
in
order,
and
you
think
that
the
component
is
ready
to
be
used
by
your
organization.
C
C
It
would
be
like
a
top
level
page
that
lives
inside
github,
but
it's
kind
of
like
it's
separate
from
your
project's
ui,
it's
kind
of
similar
in
its
location
to
the
project
that
projects
dashboard
that
you
have
so
it's
kind
of
like
yeah,
it's
project
agnostic,
so
the
component
would
become
available
in
the
component
catalog
and
you
can
access
the
catalog
either
by
going
to
github.com
ci
cd
component
or
you
can
just
access
from
the
ci
cd
navigation.
C
So
if
you
want
to
use
the
component
as
a
developer
of
a
project
in
an
organization,
so
your
platform
team
would
make
these
components
available
to
you
or
your
devops
engineers
and
then
as
a
developer.
If
you
need
to
use
it
for
your
application
project,
you
just
go
to
the
cicd
components
in
your
size,
navigation
or
you
can
access
the
catalog
directly.
C
C
All
of
that
all
of
the
component
info
will
be
pulled
from
the
project
component
project
has
been
created.
You
would
be
able
to
select
the
component
version
and
from
there
the
flow
is
to
copy
the
code
snippet
for
including
the
component
and
then
using
whatever
editor.
You
prefer.
You
have
to
paste
that
snippet
into
your
pipeline
and
do
some
customizations
from
from
there.
C
You
would
have
to
customize
variables
and
maybe
some
other
parameters
that
I'm
not
aware
of
yet
to
make
it
work,
but
all
of
that
information
would
be
inside
the
component
readme.
So
we
would
show
that
on
the
component
page
yeah,
so
these
are
like
the
two
major
flows
that
I
have
for
now
and
aside
from
that,
I'm
also
looking
into
the
discovery
like.
How
do
you
discover
this
feature
at
all
and
then
also?
How
do
you
discover
the
components
to
use
for
the
developer
implication
project?
We?
C
C
And
then
I
have
I'm
working
flows
for
releasing
a
new
version
of
the
component,
so
updating
a
component
and
how
how
it
will
work
with
developers
opting
into
the
updates
or
like
updating
the
version
and
then
it's
a
whole
new
story.
How
do
you
unpublish
the
component
and
make
sure
it
doesn't
break
anyone's
pipeline.
C
Yeah,
so
if
you
have
any
feedback
at
this
point,
let
me
know
we're
trying
to
reuse
the
existing
eye
as
much
as
possible
and
keep
it
super
simple.
But
I'm
also
trying
to
see
how
we
can
make
it
yeah
how
we
can
make
the
flow
more
natural,
because
you
have
to
jump
around
the
ui
a
lot.
It's
kind
of
very
disjointed.
A
Okay,
one
small
clarification
that
I
just
wanted
to
I
needed
from
you
was
a
complete
gitlab,
ci
yaml.
We
can
say
that
it
is
constituted
by
many
components.
C
So
aci
acid
component
is
any
part
of
the
pipeline
that
can
be
included
inside
of
your
pipeline.
So
the
difference
here
is
that,
instead
of
copy
and
pasting
the
whole
template
into
your
gitlab,
ci
yaml,
you
would
just
say,
include
a
sass
test
in
the
pipeline
and
it
just
it
just
gets
imported.
It
works
kind
of
the
same
as
importing
a
component
into
your
file.
A
Got
it
and
for
the
the
creation
part
is
very
clear,
but
I'm
just
trying
to
think
of
like
what
would
you
say
is
the
jobs
to
be
done,
which
is
associated
with
the
second
part
of
the
user
flow
that
you
had
showed,
which
is
using
the
component.
C
C
I
want
to
easily
find
or
like
I
want
to
easily
create
a
reliable
and
compliant
pipeline
for
my
project,
like
with
the
resources
provided
to
me,
the
the
main
theme
here
that
we
notice
that
developers
don't
want
to
learn
yaml,
they
don't
want
to
have
to
figure
out
what
they
need
to
use
for
their
project.
Ideally,
they
would
have
those
components
provided
to
them
and
there
are
some
guidelines
generally.
C
The
organization
provides
some
guidelines,
hey
if
you're
working
on
a
project
you
your
pipeline,
needs
to
have
this
kind
of
task
it
needs
to
include
this
include
that
for
compliance,
it
also
needs
to
run
those
kinds
of
scripts
and,
as
a
developer,
you
just
say
include
this
include
this
include
this
and
the
pipeline
just
run.
A
Okay-
and
I
think
it
would
still
mostly
be
used
by
devops
engineers
right
because
at
least
in
enterprises
developers
won't
have
the
access
to
editor
yaml
file.
C
So
what
we've
seen
it
really
varies
from
organization
to
organization
and
how
their
teams
are
set
up.
Sometimes
developers
are
also
maintaining
pipelines,
so
they
may
not
have
permissions
to
just
like
push
to
main,
but
usually
anyone
can
contribute
to
the
yaml
file.
So
it's
usually
kind
of
collaborative
effort.
C
The
platform,
team
or
infra
devops
team
provides
some
resources
and
guidelines,
and
ideally,
they
would
just
automatically
create
pipelines
for
everyone,
but
also
the
project
developers
typically
have
the
knowledge
about
the
project
that
also
the
platform
team
may
not
have
and
have
some
specific
special
needs
so
yeah,
so
they
do
create
pipelines,
but
there's
a
lot
of
new
ones
there.
It's
also
something
that
we
need
to
gather
more
insights
about
like
what
are
those
differences
and
how
they
collaborate.
B
B
A
one
comment
which
we
talked
about
briefly
in
our
sync,
which
is
the
the
user
flow,
feels
so
similar
to
the
packaging
container
registries
and
which
is
like
I
want
to
publish
a
thing,
maybe
more
as
like
a
devops
kind
of
person,
and
then
I
just
want
developers
to
consume
it
and
there's
kind
of
certain
permissions
and
one
of
the
problems
that
we're
trying
to
solve
in
package
or
something
that
we
need
to
research
on
is
like.
B
Currently,
all
of
our
things
are
tied
to
a
repository
and
that
may
not
make
sense
for
the
way
that
users
want
to
use
our
product,
and
this
feels
kind
of
similar
it
feels
kind
of
like
you
just
want
to
have
a
repository
of
components
that
everyone
can
access
without
too
much
dramas
that
aren't
necessarily
tied
to
a
repository.
So
yeah,
I'm
just
like
more
of
a
comment
and
not
a
question.
But
yes,
I
see
a
lot
of
overlap
and
like
yeah,
we
could
probably
learn
from
each
other's
research.
C
Yeah
we,
we
also
have
some
concerns
that
we
might
encounter
some
limitations
there
because
of
using
the
project
workflow
for
this
and
using
yeah
using
a
repo
for
each
component,
but
at
least
for
them.
We
see
it
gives
us
so
many
things
for
free
that
already
exists
that
yeah.
C
Okay,
so
the
rest
is
kind
of
read
only
but
I'll
quickly,
verbalize
in
15.0
I'll,
be
working
with
jeremy
and
the
tech
writing
team
to
define
the
guidelines
for
using
drawers
for
help
content
and
we'll
be
considering
such
things
as
the
drawer
stability.
The
content
guidelines,
how
we're
going
to
pull
in
information
from
our
documentation
into
the
drawer,
how
it's
going
to
work
with
markdown,
styling
and
whatnot,
and
what
are
some
additional
component
features
that
are
necessary
to
make
it
work.
C
For
example,
we're
considering
making
the
drawer
resizable
for
users
so
they're
able
to
consume
more
long-form
information
more
comfortably
in
the
drawer
and
then
there's
some
other
similar
considerations
that
we're
going
to
be
discussing.
And
another
thing
is
that
the
official
gitlab
brand
refresh
announcement
is
coming
soon
and
there's
a
lot
of
prep
work.
C
That's
happening
for
that
and
once
the
brand
refresh
guidelines
are
announced,
we're
going
to
update
the
github
illustrations
throughout
the
product
to
match
the
new
brand
guidelines
so
currently
we're
starting
to
work
on
an
audit
for
all
illustrations
in
the
product
to
see
what
illustrations
are
used.
How
are
they
used?
We
have
a
lot
of
lots
of
conversations
that
aren't
used
in
the
products
like
dozens
of
them
that
exist
in
the
library,
but
not
in
the
product.
C
A
A
All
right
moving
on
to
mine,
so
this
week
I
I
checked.
I
take
the
progress
that
I've
made
with
the
okrs
and
it
seems
that
I
do
not
have
much
control
over
the
s1
implementations,
because
our
team
has
limited
availability
of
developers
and
all
the
designs
for
s1
and
s2s
are
already
provided.
So
I'm
taking
this
feed
this
particular
milestone
kind
of
to
work
on
the
foundational
stuff
for
the
stage
group
and
that's
where
I
decided
to
revise
the
jobs
to
be
done.
A
Mapping
for
pipeline
execution,
that's
what
I'm
focusing
on
this
week.
At
least
I
am
going
to
apply
all
the
learnings
that
I've
had
from
all
of
our
experiences
and
I'll
try
to
do
it
differently
this
time,
and
also
I'm
also
looking
at
more
effective
methodologies.
A
So
if
anyone
knows
something
that
I
should
be
looking
at,
please
share
it
with
me
and
once
I'm
at
a
good
place
with
the
mapping
like
once,
I
have
all
the
primary
stuff
there
on
the
board
in
front
of
me
I'll,
be
sharing
it
with
the
larger
team,
with
all
of
you
to
understand
how
we
should
be
handling
the
overlapping
pieces
and
there's
a
very
interesting
challenge
that
I
have
kind
of
identified
that
we'll
be
facing
in
this
effort
and
that's
with
the
ci
scaling
category,
because
that
is
technically
a
non-marketable
category.
A
It's
the
work
that
falls
under
ci
scaling
is
mostly
what
we
are
doing
in
preparation
to
handle
a
huge
amount
of
like
to
handle
any
anything
that
relates
to
scaling
with
continuous
integration.
So,
for
example,
how
would
many
people
thousands
of
employees
in
let's
say
an
enterprise
would
be
working
with
the
pipelines?
Would
our
infrastructure
be
able
to
handle
all
the
tasks
that
they
would
be
performing?
A
So
there's
not
one
jobs
to
be
done
that
we
can
probably
zero
down
on
for
this,
because
it
applies
to
everything
that
users
would
be
doing
in
pipeline
execution.
So
we
do
have
a
maturity
plan
for
that,
and
it
will
be
interesting
to
kind
of
figure
out
how
we
are
going
to
assess
it.
So
I'm
starting
I'm
creating
an
async
issue
where
I'll
be
involving
the
backend
engineers,
the
product
manager,
to
understand
like
what
is
it
like?
A
What
are
we
considering
as
goals
for
ourselves
when
we
are
talking
about
maturity,
and
once
that
is
clear,
then
we'll
be
discussing
about
how
we
want
to
assess
the
maturity?
How
we
want
to
measure
it.
A
C
Exciting
I
wanted
to
ask
about
the
ci
scaling
category
because
it's,
I
think,
it's
something
that's
also
relevant
for
the
pipeline
authoring
team,
but
we
don't
really
think
about
it.
That
much
like
it's
actually
the
first
time
that
I
learned
about
the
sky
scaling
categories
during
our
one-on-one
this
week,
vithika
when
you
mentioned
it.
So
what
are
some
of
the
things
that
you're
looking
into
as
part
of
this
category
like?
Are
there
any
themes,
specifically
that
are
emerging
and
do
you
see
any
overlap
with
pipeline
authoring.
A
A
So
most
challenges
that
we
face
with
scaling
is
when
the
pipelines
are
running.
I
guess
when
the
runners
are
working,
so
I'm
going
to
share
the
category
page
with
you
here.
A
This
is
the
category
direction
we
have
for
continuous
integration
scaling.
So
if
you
see
the
vision
items,
it's
mostly
around
ci
cd
data
model
and
improving
printer
job
queuing,
then
it's
mostly
about
around
runner
and
what
we
are
doing
with
the
pipelines
are
running.
C
Yeah
makes
sense,
I
guess
for
us
ci
scaling
like
making
it
more
usable
for
very
large
teams
for
pipeline
authoring.
It
looks
like
making
the
process
of
enabling
developers
and
organizations
to
create
pipelines
easier,
more
effective,
so
the
ci
catalog
is
part
of
that,
but
yeah
we
haven't
really.
C
A
Yeah,
so
one
thing
that
I
have
proposed
proposed
as
a
part
of
my
growth
and
development
plan
is,
I
want
to
kind
of
start
an
effort
which
would
be
around
creating
frameworks
for
designing
for
scalability,
and
this
is
going
to
be
like
all
of
us
would
be
involved,
because
each
one
of
us
here
is
facing
challenges
when
it
comes
to
like
incorporating
scalability
in
our
respective
stage
group
features
so
yeah.
That's
that's
something.
That's
in
discussion
and
I'll
share
more.
As
I
hear
more.
A
And
that's
all
what
else
do
we
have
so
there
are
two
ux
research
threads
one
by
will
and
one
by
erica,
but
the
prioritization
issues
and
please
go
and
have
a
look
there.
If
you
want
to
check
like
what's
the
priority
for
this
quarter,
I
mean
for
the
upcoming
quarter
mostly
and
that's
it,
and
we
are
on
time
with
three
minutes
to
spare.
That's
great
all
right,
then.
Oh.