►
From YouTube: CI/CD UX Weekly Meeting (APAC) 🔥 02-23-2022
Description
Recording of the CI/CD UX Weekly Meeting on 02-23-2022, APAC edition.
A
Hey
everyone:
this
is
the
st
icd
ux
weekly
meeting
the
apac
edition,
and
we
have
everyone
here
and
we'll
get
started
with
some
of
the
standing
items.
We
don't
have
that
many,
but
there's
one
standing
item
to
review
the
okr's
progress.
So
if
you're
working
on
some
okr
issues
like
the
s1
s2
bugs
and
things
like
that,
just
make
sure
that
things
are
on
track
and
if
you
do
complete
things,
don't
forget
to
check
them
off
in
the
kr
issues
and
yeah.
B
B
The
designs
are
quite
rough
at
the
moment,
but
if
anyone
has
a
time,
have
a
look
and
and
give
some
feedback-
and
the
second
thing
that
I
was
working
on
this
week
was
looking
into
a
competitor
and
the
reason
for
looking
into
the
competitor
was
in
some
research
sessions.
I
heard
customers
using
different
terminology
than
the
terminology
that
we're
using
maybe
having
slightly
different
mental
models
about
the
way
things
should
work.
B
So
I
took
the
time
to
really
dig
into
a
competitor,
and
I
made
a
literally
30
minute
long
video
about
my
experience,
which
is
fine,
but
not
that
consumable.
So
my
question
to
the
group
is:
does
anyone
have
any
tips
about
how
to
document
the
things
you
found
about
the
competitor
in
a
in
a
meaningful
way.
A
I'm
just
looking
sorry
I
I
was,
I
was
just
gonna
ask
if
you
used
the
competitor
evaluation
research
issue
for
this.
No,
I
don't
know
what
that
is.
Oh,
okay!
So
I'm
going
to
share
with
you,
so
we
have
kind
of
very
basic
guidelines
for
competitor
evaluation.
So
I
don't
know
if
it
actually
has
guidelines
for
how
to
document
things.
B
A
A
Oh
no,
not
recommendation!
Sorry!
I
I
think
it
makes
sense
to
put
it
in
dovetail
since
that's
the
source
of
truth
for
everything
and
since
we
don't
have,
I
think
we
don't
have
a
defined
format
for
that.
It's
probably
also
good
appreciate
you
to
see
if
we
can
put
some
basic
guidelines
in
place
for
that.
B
C
A
You
can
have
a
look
at
the
issue,
so
the
purpose
of
this
issue
is
to
create
visionary
mock-ups,
to
inform
the
proof-of-concept
work
that
our
engineers
are
currently
doing
so
the
way
we
want
to
approach
this
whole
project
is
that
first,
we'll
be
working
on
a
poc
that
will
be
used
only
internally.
We
want
to
first
create
a
ci
catalog
that
could
be
used,
perhaps
by
the
documentation
team.
Then
we
might
work
together
with
our
pipeline,
optimization
team,
where
I
think
they're
called
optimized
team
or
something
like
that
or
productivity.
A
So
the
idea
here
is
that
we're
kind
of
dreaming
big
but
at
the
same
time
it
has
to
be
very
realistic,
something
that
can
actually
inform
the
psc
work
and
drive
that
and
once
we
have
that
there
will
be
another
issue
to
refine
those
mock-ups
for
the
actual
nbc
that
we
will
start
working
towards
and
those
that
solution
will
go
into
solution
validation.
So
now
I'm
thinking
that
these
visionary
mock-ups
there's
no
point
in
doing
solution.
A
Validation
for
that,
because
the
scope
might
change
it's
just
to
drive
the
implementation
discussions
with
the
team
and
then
solution
validation
will
do
for
the
more
refined
proposal.
So
yeah-
I'm
very
excited
about
this,
because
I
get
to
kind
of
just
do
whatever
take
a
bunch
of
screenshots
of
the
competitors
and
we've
done.
We've
done
some
research,
so
we
have
lots
of
insights
that
we're
working
with
lots
of
discussions
with
our
customers
and
yeah.
A
I
started
with
some
sketches
and
wireframes
and
at
some
point
next
week
I
will
start
working
on
the
actual
actual
mockups
and
another
interesting
thing
about
this
project.
Is
that
I'm
not
necessarily
using
the
gitlab
component
for
this?
But
I
think
it
will
be
more
of
a
visual
language
that
we
use
on
the
docs
side
and
even
just
our
branding
or
marketing
sites,
so
yeah,
it's
very
refreshing,
something
that
doesn't
usually
happen
so
yeah.
C
D
B
D
D
B
A
A
So
clearly
it
can't
really
support
all
of
the
use
cases
or,
at
the
very
least,
some
guidelines
are
missing,
so
different
stage
groups
are
kind
of
doing
their
own
thing,
including
pipeline
authoring.
We
completely
butchered
the
drawer
component,
which
we're
now
fixing
so
there's
two
issues
that
I
will
be
working
on.
The
first
one
is
to
clarify
the
drawer
usage
guidelines
and
in
that
issue,
there's
like
like
a
wide
variety
of
questions
about
the
component
that
I
want
to
answer.
A
D
That's
all
on
my
end,
okay,
I
was
thinking
about
like
if
I
know
something
but
nothing
on
top
of
my
mind
right
now
and
yeah.
If
something
comes
up,
I'll
definitely
drop
it
here
and
in
the
meanwhile
katie.
I
also
found
the
template
that
we
have
for
competitor
evaluation
and
added
it
to
the
section
above.
D
Thank
you
yeah
and
coming
to
my
agenda
items,
the
first
one
is
so
there
was
a
daniel
and
I
were
working
on
some
changes,
two
pajamas
with
respect
to
the
reflow
and
responsive
design
behavior,
because
we
don't
have
any
of
that
like
outlined
in
our
design
system
today.
So
it
took
a
lot
of
mrs
a
lot
of
issues,
a
lot
of
discussions,
a
lot
of
to
and
fro.
But
finally,
it
looks
like
it's
going
to
get
merged
very
soon,
so
this
is
the
ever
and
I'll
share
it
in
the
slack
channel.
D
Right
now
and
other
pajama
issue
that
I
was
working
on
is
the
conceptual
model
for
pipelines,
so
nadia
just
finished
working
on
the
conceptual
model
for
jobs,
and
I
wanted
to
take
this
up
next
and
it
was
not
a
priority
yet,
but
we
recently
kind
of
ran
into
an
unfortunate
situation
with
one
of
our
implementations
feature
implementations
that
led
us
to
realize
that
internally
we
don't
have
sorry.
I
haven't
added
the
link
here.
There
you
go,
the
link
is
still
not
there.
D
D
D
Are
these
three
that
I've
just
highlighted
in
the
agenda
which
is
to
introduce
git
merge
and
they
want
to
reorganize
the
settings
to
decouple
fast
forward,
merge
and
merge
comment
and
then
they
want
to
introduce
optional,
merge
commit
settings,
but
from
pipeline
execution
side.
The
concerns
that
I
wanted
to
express
here
is
how
merge
strain
is
going
to
affect
these
options.
For
example,
you
cannot
have
a
fast
forward
option
with
merge
train
today
and
also
like
there's
also
some
sort
of
constraint
with
using
the
merge
commit
option.
D
So
how
are
we
establishing
that
relationship
in
the
ui,
because
we
have
to
make
sure
that
they
stay
in
close
proximity
on
the
ui,
and
it's
not
like
somewhere
far
apart
that
it's
very
difficult
to
understand
like?
How
is
this
item
impact
that
item
and
so
on
and
another
thing
that
I
really
feel
that
we
should
change
is
how
we
talk
about
like
enabling
more
strain.
So
today
it's
presented
as
a
cascading
setting.
You
have
to
first
enable
the
merchandise
pipeline.
Then
you
can
enable
the
most
train
so
both
have
their
own
valid
use.
D
Cases
like
there
could
be
a
situation
when
a
user
might
want
to
use
versus
a
pipeline
in
the
absence
of
moti
stream-
that's
totally
understandable,
but
when
I,
as
a
user,
I
I'm
going
to
the
settings
just
to
enable
more
streams,
and
this
is
how
I
find
the
settings
to
be
laid
out.
It
does
kind
of
trigger
some
sort
of.
D
It
affects
my
confidence
as
a
user,
because
I
have
to
like
look
at
so
much
more
to
understand
if
I'm
doing
the
right
thing
there.
So
I
think
we
should
tackle
that
as
well.
While
we
are
on
it,
we
might
not
be
taking
care
of
everything
that
I
just
mentioned
about
in
the
same
issue,
but
there
would
definitely
be
follow-ups.
A
Not
yet
yeah,
I
was
wondering
if
you
could
provide
like
we
still
have
some
time.
So
maybe
you
could
provide
a
brief
overview
of
water,
merge
trains
and
how
they're
used
like
how
do
you
set
them
up
and
how
do
you
use
them
and
what
are
the
personas
involved,
because
I
have
a
very
kind
of
basic
understanding.
D
So
in
get
club
when
you
have
a
pipeline
configured
for
merge
request,
so
what
happens
is
when
you
push
a
commit
to
your
merge
request?
The
pipeline
gets
triggered
and
it
runs,
but
this
pipeline
that
runs,
you
would
have
seen
the
label
detached
right
like
for
most
pipelines
that
that
label
comes.
That
means
that
the
pipeline
is
not
running
for
a
commit
against
the
target
branch.
D
It
is
detached
from
that
and
we
have
a
different
kind
of
pipeline
today,
which
is
merge
results
pipeline.
What
this
does
is
it
kind
of
simulates,
a
situation
where
it
makes
you
where
it
gives
you
the
result
of
what
the
pipeline
result
would
be
if
you
are
actually
running
against
the
target
branch,
so
it's
still
not
happening
in
reality.
It
creates
a
fake,
a
made-up
commit
from
the
target
branch
to
run
that
pipeline
and
what
merge
stream
does.
D
Is
it
leverages
that
pipeline
merge
result
pipeline
and
creates
a
whole
train,
so
what
it
does
is.
So
let's
say
if
I
have
five
merge
requests
which
are
queued
and
which
are
to
be
merged,
and
I
don't
want,
like
my
target-
is
progressing
at
a
very
high
speed.
My
main
branch
is
like
just
progressing
because
I
work
with
a
big
team
and
I
don't
want
the
branch
to
be
breaking
because
of
the
kind
of
change
that
I'm
making.
D
D
It
will
pick
like
it
kind
of
clubs,
all
the
changes
and
then
creates
a
fake,
commit,
runs
a
pipeline
and
then
matches
the
changes
that
you
have.
You
are
creating
with
your
commit
with
that
made
up,
commit
and
that's
why
the
result
that
you
get
from
that
pipeline
is
very
close
to
what
the
real
results
would
be.
So
it
does
it
for
each
of
the
commit
for
each
of
the
merge
requests.
D
Now
you
would
have
seen
that
when
something
is
dropped
from
a
train,
it
is
very
difficult
to
get
it
back.
Why
is
that?
So,
when
something
is
dropped
from
a
train,
that
means
that
made-up
commit
that
your
mercy
was
working
with
it
has
when
an
item
gets
dropped.
It
kind
of
re
like
imagines
a
different
chunk
of
changes,
and
it
creates
a
fake
commit
out
of
that.
Now
it's
not
very
easy
to
go
and
make
changes
to
it.
D
It's
not
very
easy
to
add
something
again
to
merge,
train
and
expect
it
to
like
just
catch
up,
because
that
would
involve
the
whole
commit
to
be
reconstructed
and
that's
a
lot
of
work
and
that's
the
reason
we
don't
have
those
retries
and
much
equal
in
more
strain
pipelines.
Yet
so
that's
some
work
that
we
still
need
to
do
there
to
make
it
more
efficient,
so
it
like
we
can
take
action
such
as
put
add
it
back
to
moisture
in
or
retry
this
moisture
in
pipeline,
but
we
are
a
little
far
away
from
that.
D
A
D
You
can
do
it
on
purpose,
but
that's
also
something
that
could
just
happen.
I
mean
something:
that's
not
in
your
control,
for
example,
something
can
go
wrong
with
the
normal
pipeline,
it
does
and
the
commit
drops
yeah
and
you
can
also
cancel
and
drop
it.
It
drops
if
the
pipeline
fails
or
I
wanted
to
say
yes,
but
I
don't
think
so.
I
think
there
are
other
reasons
as
well.
A
C
Yes
and
my
my
question
in
my
little
my
up
is
that
little
my
I
have
an
update
in
the
ux
research
thread,
but
basically
I've
just
been
running
users
through
the
survey
development
interviews,
which
is
basically
they
take
that
ops,
product
direction
survey
and
talk
out
loud
and
they
get
confused
anyway.
One
of
the
things
they
were
confused
about
is
what
was
a
merge
train,
so
I
just
was
trying
to
come
up
with
the
one
sentence
definition,
but,
but
I
was
wondering
is
that
only
a
get
lab
functionality
like?
Are
there
competitors
that
have
similar.
D
C
C
So
I
think
I'm
going
to
also
do
a
report
on
that
substantive
stuff
and
I
can
get
just
some
little
things
about
what
was
hard
or
why-
and
this
is
like
so
and
then
also
importantly,
to
point
out-
I
provided
a
90-day
feedback,
so
this
is
like
welcome.
My
90
days
are
up
for
onboarding,
so
like
now,
my
plan
is
to
get
further
embedded
and
develop
my
product
expertise
and
then
figure
out
how
to
like
better
stay
in
sync
with
each
of
our
lovely
teams.
C
But
so
this
is
like
me
dipping
my
toe,
which
I
think
is
good,
because
I'm
getting
a
little
bit
about
dependency
proxy
and
a
little
bit
about
merge
change
so
anyway,
there's
a
feedback
form
for
you
to
fill
out.
And
yes,
so
thank
you
for
talking
about
merge
trains
like,
I
think.
Let
me
know
the
best
way
to
involve
you
in
that
process,
because
I
don't
want
it.
You
guys
are
so
busy.
C
D
Sure
yeah
I'll
be
happy
to
help.
There's
also
some
work
that
we
did
around
like
simplifying
merchant
making
it
more
understandable.
So
I
can
share
that
with
you
as
well
and
there's
a
lot
of
good
discussion
there.
The
work
might
not
have
resulted
into
the
outcome
might
not
have
been
like
what
we
expected,
but
the
discussion
was
definitely
a
like.
It
was
really
great,
okay
cool
and
I
added
the
link
to
the
competitor
landscape
section
to
our
conversation
yeah.