►
From YouTube: CI/CD UX meeting APAC 2022-03-09
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
welcome
to
the
apec
addiction
edition
of
the
cicd
ux
meeting
for
the
9th
of
march
2022,
and
we've
got
pretty
full
agenda
today.
I'll
start
with
the
general
announcements
and
there's
an
upcoming
family
and
friends
day
on
march
25th
and
next
up
reviewing
the
okr
progress.
So
it
looks
like
we've
closed
4
out
of
10
s1
and
10
out
of
10
10
out
of
16
s2
issues.
A
A
So
we've
all
reviewed
the
engagement
survey
results
and
we're
taking
this
week
to
identify
team
level
focus,
and
so
the
ask
is,
in
the
tracking
issue,
discuss
opportunities
about
how
we
might
approach
growth
and
development
in
fy
23,
the
deadline
being
march
11th
and
for
the
growth
and
development
faq
we'll
be
using
march
to
do
weekly,
check-ins
and
work
on
your
individual
growth
plans
and
make
it
measurable
and
formalize
at
a
time
in
a
gitlab
issue
and
from
april
onwards,
we'll
be
doing
monthly
check-ins
career
development
is
a
lifelong
process
of
managing
learning,
work,
leisure
and
transitions
to
move
towards
personally
determined
and
evolving
prefer
future.
A
You
are
the
owner
of
your
career
plan
and
your
manager
is
available
to
facilitate
your
discovery
process
and
discuss
aspirations
and
opportunities
for
developments
within
gitlab
and
hayana
has
linked
what
is
career
development
and
last
little
bit
of
the
general
announcement.
Is
everyone?
Please
read
the
overview
of
the
fy
22
q4
survey
results
and
the
ux
department,
f123
directions?
A
A
A
Product
management
is
the
dri
for
prioritization.
Only.
You
know
how
much
you
can
commit
to
in
a
given
milestone.
You
set
the
tone
for
your
work.
However,
any
change
in
the
ux
priority
or
commitment
to
your
milestone
needs
to
be
discussed
with
your
pm
first
and
high
on
the
links.
Product
design,
priorities
and
saying,
though,
is
an
important
skill
for
managers
of
one
and
product
designers.
It
enables
you
to
define
bad
boundaries
and
make
better
use
of
your
time
and
gives
you
confidence.
A
A
Cool
I'll
just
quickly
touch
on.
What's
in
the
emea
america's
thread,
and
maybe
we
can
go
through
that
async
and
then
we'll
get
into
these
things
up
for
the
apac.
So
hayana
is
doing
some
problem
validations
on
the
environments
page,
we
design
to
understand
if
it
improves
the
overall
usability.
A
Gina
is
working
on
some
design
proposal
for
the
artifacts
page,
and
I
was
asking
for
some
feedback
on
that
and
provided
some
background
and
gina
also
mentioned
that
there
was
an
incident
with
runner
registration
tokens
and
it
spurred
a
conversation
of
the
redesign
for
the
registration
process
and
gina
is
also
looking
for
design
feedback
on
communication
of
outdated
moments.
A
A
There's
actually
heaps
of
designers
that
have
worked
on
this
and
a
lot
of
past
stuff
that
I
can
build
upon,
and
the
original
impetus
is
that
package
settings
don't
fit
nicely
in
the
architecture
of
the
current
gitlab
settings
and-
and
I
made
some
smaller
issues
just
to
kind
of
make
things
work
for
package
and
torrey
pointed
out
that
this
could
be
an
opportunity
to
re-architect
settings
and
and
the
problems
that
I'm
trying
to
solve
are
already
well
defined
in
herald
and
michael's
work.
A
But
there's
just
some
general
usability,
such
as
consistency,
wording
and
specifically
for
my
purpose,
sustainably.
Housing
very
complex
settings,
which
is
what
package
is
going
to
be
dealing
with.
There's
discoverability
issues
of
settings
both
within
the
gitlab
product
itself,
like
people
are
looking
in
the
future
for
the
settings,
but
also
within
the
settings,
there's
some
discoverability
issues
and,
lastly,
understanding
group
versus
project
settings.
When
do
we
use
each
one,
how
do
they
interact
with
each
other
and
how
is
that
communicated
with
the
user?
A
A
I
think
at
the
moment
the
scope
is
probably
too
broad,
but
I'm
still
kind
of
in
discovery
mode
before
I'm
gonna
start
narrowing
it,
and
also,
if
you
have
any
particular
vision
for
the
settings
of
your
area
or
insights,
about
how
settings
are
used
or
any
pain,
points
and
I'd,
love
to
chat
or
feel
free.
To
link
me
like
dovetail
or
anything
like
that,
because
I'm
just
collecting
a
lot
of
information
at
the
moment.
B
So
what
I'll
do
is
there
was
an
effort
by
the
technical
writers
in
pipeline
execution
marshall.
I
think
he
took
up
a
huge
epic,
where
he
made
a
lot
of
changes
to
at
least
the
copy,
so
how
that
can
help.
You
is
understand
how
what
kind
of
communication
you
want
to
put
forward.
That's
it
I
mean
that's
the
only
scope
in
which
that
could
be
of
help
to
you,
but
I'll
find
the
epic
and
I'll
link
it
here.
A
Yeah,
so
if
either
of
you
have
any
research
that
you've
done
or
anecdotally,
if
you
have
a
vision
for
your
areas
of
the
settings,
yeah
I'd
love
to
I'd
love
to
chat
more
about
that
as
well.
A
All
right
so
there's
one
issue
that
I'm
working
on
for
differentiating
trigger
jobs
in
gitlab
ui,
so
differentiating
trigger
jobs,
the
trigger
downstream
pipeline
from
the
regular
jobs.
So
you
can
have
a
look
at
the
proposal
in
the
issue
and
if
you
have
any
feedback,
I
would
love
to
hear
that
so
feel
free
to
just
have
a
look
at
that.
Async.
A
Another
thing
I
wanted
to
share
is
that
there
is
an
effort
right
now
that
jeremy
is
leading.
I
think
he
shared
an
issue
in
the
ux
weekly
yesterday
for
finding
like
one
standardized
way,
to
organize
stigma:
files
within
stage
groups,
so
I
started
an
issue
to
look
into
an
approach
that
we
could
maybe
pilot
as
the
cicd
ux
team.
So
you
know
just
so.
A
We
can
start
small
and
kind
of
see
what
works
for
us,
so
we
can
iterate
in
our
process
more
easily,
as
opposed
to
trying
to
right
away,
create
a
pilot
for
the
whole
company
so
yeah.
So
I
think
you
can
just
have
a
look
at
this
approach.
They
suggested
in
the
issue
that
I
linked
and
let
me
know
what
you
think
we
can
have
a
discussion
there
in
the
issue,
but
also
we
should
contribute
to
the
discussion
in
the
jeremy's
issue.
A
I
will
find
it
and
link
in
our
agenda
as
well,
so
it's
there.
I
think,
once
we
pilot
an
approach
and
iterate
on
it
and
find
what
works
for
us,
then
we
can
make
a
more
like
educated
proposal
to
the
rest
of
the
ux
department.
Right.
B
I
had
just
very
small
concern
here,
so
I
like
that
you
talked
about
like
using
one
file,
a
file
for
the
area
and
putting
all
the
design
in
there.
B
I
have
tried
this
in
the
past,
but
it
made
me
feel
as
if
the
file
itself
was
not
able
to
take
the
load
of
all
the
many
designs
being
hosted
at
this
one
place.
So
if
there
could
be
a
clarity
around
that,
I
think
that
that
that's
a
method
that
can
really
work
sorting
the
designs
by
areas
and
not
necessarily
by
issues.
A
Yeah,
I
think
this
also
scope
of
the
files
can
vary
so
depending
on
what
your
stage
group
is
working
on.
Maybe
you
you
can
get
away
with
having
like
one
two
or
three
files,
but
if
you
have
many
different
areas,
for
example,
for
pipeline
offspring,
I
can
see
us
having
maybe
like
six
file.
Seven
files
varied
in
scope.
I
think
it's
totally
okay.
The
goal
is
just
to
kind
of
organize
them.
Logically,
so
someone
looking
at
the
structure
can
more
easily
browse
it,
because
the
categories
are
more
logical.
A
Like
okay,
I
know
that
pipeline
authoring
team
works
in
the
pipeline
editor
and
then
they
also
have
the
ci
catalog.
You
know
for
someone
outside
the
team.
It
makes
more
sense
rather
than
seeing
a
bunch
of
issues
that
don't
necessarily
like
you
can't
necessarily
understand
exactly
what
the
team
is
working
on,
sometimes
from
just
having
a
bunch
of
different
issues
but
yeah,
I
don't
know
we'll
see
what
works
for
us.
So
that's
kind
of
the
point
of
the
pilot.
We
can
see
what
are
the
problems
with
it.
A
I
thought
they
had
something
else,
but
oh
yeah,
I
haven't
noticed
it
yeah.
So
there's
a
an
active
discussion
right
now
in
the
issue
that
I
linked
here.
You
can
see
it
highlighted
around
using
drawers
for
help
content
in
the
product.
So
currently
we
mostly
use
papers
and
models
to
provide
help.
Content
and
models
are
used
for
critical
information
as
you're
going
through
the
flow.
A
If
we
need
to
elicit
a
certain
action
from
the
user,
a
model
is
better
and
if
we
want
to
provide
some
tiny
piece
of
supplemental
information
and
maybe
a
link
to
the
docs,
we
use
popovers
and
then
drawers
it's
kind
of
like
a
new
addition
to
our
help
stack
where
we
can
show
more
supplemental
information.
That
is
more
like
reference
information,
so
something
that
you
refer
to
as
you're
going
through,
perhaps
a
more
complex
and
boarding
flow.
A
And,
of
course
we
see
a
lot
of
value
in
that
for
pipeline
authoring,
because
creating
a
ci
pipeline
generally
requires
you
to
work
with
documentation
a
lot,
but
there
are
other
areas
of
the
product
that
could
use
that
kind
of
help
as
well.
So
there
are
some
questions
that
we're
trying
to
answer
around.
A
How
like
what
guidelines
do
we
have
to
put
in
place
to
make
drawers
work
for
health
information
across
the
product
in
a
standardized
way,
and
how
can
we
also
standardize
the
content
inside
the
drawers?
So
it's
still
in
the
very
early
stages
of
the
discussion,
but
if
you
have
any
thoughts
or
questions
around,
it
feel
free
to
drop
them
in
the
issue.
A
B
I
also
see
a
scope
of
us
being
able
to
recycle
drawers
for
situations
where,
when
you
made
a
lot
of
changes
to
a
page-
and
I
mean
we
don't
have
a
current
mechanism
to
like-
highlight
those
changes
and
run
users
through
everything
that
has
been
changed
and
if
there
could
be
these
one-off
instances
of
allowing
like
nudging
through
a
jar
and
when
they
open
it,
then
just
running
them
through
the
changes
that
we
have
made,
and
maybe
we're
not
showing
that
again.
B
So
just
for
an
alternate
behavior
of
the
drawer,
I
mean
I
know
that
in
pipeline
authoring,
it's
like
it.
It's
gonna
stay
it's
going
to
be
there
whenever
the
user
demands,
but
I'm
just
thinking
like
because
I
had
a
discussion
with
erica
around
how
we
do
not
have
enough
scope
for
users
within
the
product
to
kind
of
localize
their
feedback
and
also
make
them
aware
of
why
we
made
certain
change
to
the
product.
So
if
this
can
be
used
for
that
purpose,.
B
A
B
A
Yeah,
I
think
we
use
the
powers
for
this
and
I
think
they're
called
banners
honestly.
The
other
day
I
saw
yeah
a
little
it's
kind
of
like
a
popover,
but
it
doesn't
look.
Sorry
like
a
four
kind
of
looks
like
an
alert
but
behaves
like
a
before.
A
I'm
not
sure
if
it's
a
special,
very
special
use
case
just
that
the
growth
team
used
it,
but
it's
something
to
sync
up
on
with
the
growth
team,
because
they're
doing
a
lot
of
exploration
and
research
around
it
so
yeah
and
we
we
have
now
an
an
issue
open
around
documenting
the
usage
of
performers
for
highlighting
premium
features,
for
example.
So
that's
somewhat
related,
I
guess
it's.
A
You
know
if
we
introduce
a
feature,
but
it's
not
visible
to
free
users,
it's
a
way
to
get
their
attention
and
on
board
them
if
they
want
like
in
a
non-disruptive
way,
I'll
find
a
link
to
that
and
drop
it
in
the
agenda
as
well.
B
I'll
start
with
my
items:
okay,
so,
first
of
all,
I
just
wanted
to
like
share
this
issue
here,
which
is
still
a
draft
for
setting
up
tracking
data
tracking
for
a
few
actions
of
the
piper
index
page
I'm
doing
this
with
snow
flow.
For
the
first
time
I
used
to
I
mean
I
had
some
experience,
but
with
a
different
tool,
so
the
table,
the
information
that
you
see
on
the
table,
it's
still
not
very
accurate,
I'm
still
struggling
to
find
out
how
to
best
populate
it.
B
So
I'm
seeking
help
within
the
team,
but
this
is
the
general
draft
issue
and
we'll
be
going
this
path
and
why
we
need
this
data.
So
our
plan
is
to
pair
this
data
with
our
qualitative
findings
so
that
we
are
able
to
generate
more
robust
and
actionable
insights
without
much
of
ambiguity
in
our
head
regarding
the
direction
that
we
should
be
taking
yeah
any
thoughts
around
this
what's
notepad
snowplow
is
a
so
we
use
this
tool
for
setting
up
tracking
and
I
took
a
little
help.
B
I
mean
I
asked
for
the
issue
that
michael
lee
created
for
setting
up
the
tracking
for
the
navigation
items,
and
then
I
saw
we
have
a
template
for
a
snowplow
and
I
just
started
using
it
and
I'll
keep
everyone
updated.
Regarding,
like
the
progress
I
make
for
this.
B
So
it's
like
quick,
quick,
tracking,
no
yeah
so
like
who's
clicking
where,
where
are
users
coming
from
to
that
page?
Where
are
they
going
to
like
tracking
the
path,
the
actions
the
clicks
got
it,
and
how
is
it
to
you
so
far,
I'm
still
struggling.
A
Yeah
cool,
let
us
know
how
you
go,
because
I
have
need
for
this
and
package
as
well,
and
I
assumed
that
I'd
have
to
engage
with
an
engineer.
But
if
it's
something
I
could
set
up
myself,
that
would
be
awesome.
B
And
the
other
item
is
we're
in
the
process
of
creating
a
conceptual
design
for
project
level
overview.
So
in
the
past
I
had
created
something
a
graph
like
feature,
but
for
the
pipeline
overview
page,
I
think
nadia
would
remember
for
katie.
I
will
find
the
link
and
share
so
it
was
a
graph
that
used
to
show
how
much
duration
your
jobs
are
consuming.
B
What
is
going
wrong
with
your
pipeline
and
out
of
that,
but
with
more
research
with
more
talking
with
the
customers
and
users,
we
figured
that
that's
not
a
very
like
a
lot
of
use.
What
we
really
need
instead,
is
something
which
is
more
at
the
project
level,
not
at
the
pipeline
level.
So
project
level
overview
for
the
pipeline
performance
is
what
we'll
be
working
on
now,
because
I
think
that's
going
to
provide
a
lot
of
value
to
our
users
and
might
even
help
us
with
the
conversions.
B
So
that's
our
focus
this
week,
because
I
am
a
little
ahead
of
my
planning
for
14
point
now,
so
I
had
a
week
to
spare
and
I
am
using
that
for
collating
all
the
discussions
that
happen
on
different
issues.
For
the
same
purpose,
creating
a
new
doctor
project
and
like
generating
fresh
insights
and
also
a
fresh
design
so
after
that
me
and
james
will
take
it
forward
like
how
to
validate
this
and
how
to
break
this
into
nbc's
and
all
of
that,
the
personas
we
are
targeting.
B
B
So,
let's
start
with
something,
that's
most
demanded
and
that's
why
we
are
still
going
with
a
software
developer
and
tech
lead.
So
I
think
the
major
persona
for
us
is
the
tech
lead
and
devops
engineer,
but
it
should.
It
should
still
be
usable
by
software
developers.
A
Yeah,
so
I
see
there
there's
probably
going
to
be
some
opportunities
there
to
connect
the
workflows
between
the
dashboard
and
the
pipeline
editor
because
devops
engineers
or
developers
who
use
the
pipeline
editor,
they
would
be
interested
in
all
of
this
information
performance
of
pipelines
because
then
they
use
the
pipeline
editor
to
actually
optimize
their
pipeline.
Configuration
so
yeah
very
excited
to
see
this
developing.
A
Yeah
I
can
share
I
I
will
look
into
the
existing
pipeline
authority
research.
There
wasn't.
There
was
no
research
that
was
specifically
focusing
on
that,
but
it
kind
of
keeps
coming
up
in
our
general
research
around
pipeline
authoring,
because
identifying
inefficiencies
in
your
pipeline
is
part
of
the
pipeline
authoring
like
pipeline
optimization
process.
A
So,
okay,
also,
I
really
recommend,
if
you
haven't
done
it
yet
talk
to
our
productivity
team.
We
have
engineers
at
gitlab
who
focus
specifically
on
optimizing
gitlab
pipelines.
So
it's
like
they're
a
full-time
job
to
to
do
that.
So
we
talked
to
them
a
lot.
To
kind
of
you
know,
demo
popular
authoring
features
and
they
talk
a
lot
about
pipeline
performance,
pipeline
efficiency
and
they
actually
have,
I
think,
their
own
documentation
and
their
own
charts,
and
things
like
that.
So
that
can
be
really
useful
to
you
for
the
dashboard
work.
B
Yeah
and
lastly,
we
are
bringing
back
the
moisture
in
visualization,
so
I
once
gave
you
actual
case
presentation
on
this,
and
then
the
entire
effort
went
to
a
halt
because
we
had
other
things
of
a
higher
priority
on
our
plate,
but
with
the
increasing
request
for
this
and
demand
for
this,
we
are
going
to
bring
back
this
effort
and
we
also
floated
this
on
twitter
and
linkedin
last
week,
but
it
did
not
gain
much
traction
because
it's
a
premium
feature
and
not
many
people
use
it.
A
And
the
last
things
in
the
agenda
is,
will
and
erica
have
both
like
their
prioritization
issue.
I
think
their
issues
span
about
like
three
months
or
something
like
that,
and
I
mean
take
a
look
at
that.
A
Does
anyone
have
any
final
comments
before
we
wrap
up
cool
thanks?
Everyone.