►
From YouTube: CI/CD UX Meeting - 2021-09-08
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
All
right,
so
this
is
the
cicd
box
meeting
for
september
8th.
I
have
a
couple
of
fyr
read-only
items
and
we
just
had
a
tour
of
danielle's
apartment,
we're
doing
some
icebreaker
activities,
they're
not
being
recorded,
but
it
has
been
fun
and
I
have
a
first
item.
I
actually
want
to
talk
about
code
review
guidelines,
so
I've
been
sharing
this
with
you
in
private.
A
We
also
have
been
having
a
couple
of
team
conversations,
mostly
in
verify,
but
I
want
to
open
this
space
to
answer
any
questions
that
you
might
have
about
code
review
guidelines.
A
Is
we
expected
from
you
how
we
should
be
doing
quad
reviews
or
any
questions
that
you
might
have
so
that
we
can
discuss
this
in
this
forum?
So
shoot
me.
B
I
feel
like
I
don't
have
any
questions.
I've
been
talking
about
it
so
much
and
like
reading
through
it.
So
much
as
we've
had
we've
been
having
these
discussions
on
the
pipeline
authoring
team
like
just
being
fully
transparent,
we're
kind
of
going
through
some
struggles
a
little
bit
in
our
team
in
terms
of
how
we
approach
uxmr
reviews,
but
I
think
we'll
be
just
yeah.
B
I
might
have
some
more
questions
as
as
we
start
as
I
started
doing
more
reviews,
because,
honestly,
lately,
I
haven't
had
to
do
a
lot
of
reviews
on
my
team,
because
I
don't
really
get
involved
in
the
mars.
That's
kind
of
the
problem
that
we're
trying
to
solve
yeah,
but
I
feel,
like
the
process,
is
quite
clear
from
documentation
to
me.
So
I
don't
have
any
questions
right
now.
A
B
I
need
to
read
this
documentation,
but
one
thing
I
caught
up
with
the
front-end
developer
for
package
yesterday
and
he
suggested
that
I
don't
review
things
on
the
gdk
and
that
he
can
send
me
screenshots
and
yeah.
I'm
curious
to
hear
other
people's
experience
with
this,
because
my
first
reaction
to
that
is
like
I
should
probably
actually
see
it.
Working.
C
So
yeah,
but
in
execution
we
have
been
doing
that
way
and
it
has
been
very
helpful.
So
it
saves
a
lot
of
time
also
because
we
are
working
on
so
many
different
things
and
gdk
is
a
little
moody
like
sometimes
it
works
very
well.
Sometimes
it
doesn't
so
those
gifs
those
recordings
or
screenshots
that
front-end
interiors
they
put
on
the
mr
description,
it
it's
very
helpful
and
I
think
it's
also
mandatory
for
them
to
do
that
because
it
comes
in
the
template
itself.
C
A
Cool
yeah,
I
think
the
last
part
of
vitica
added
is
really
important
right,
so
sometimes,
for
example,
you're
reviewing
something
that
it
is
a
white
change,
but
it's
just
copy.
So
you
don't
need
to
spin
up
jdk
to
review
that,
but,
as
as
you're
gonna
see
once
also
we,
we,
we
re-document
right.
That's
pedro's
kr
for
this
quarter.
A
The
code
review
guidelines
is
that
we
want
everyone
to
have
gdk
up
and
running
and
be
able
to
do
the
reviews
locally,
if
not
with
gdk,
with
git
pods
right,
so
that
we
are
testing
all
the
different
scenarios.
So,
for
example,
some
some
engineers
when
they
are
giving
you
that
information
in
the
issue
description
in
the
merger
class
description
through
a
video
or
a
screenshot
they're,
not
going
to
put
all
the
different
break
points
of
a
ui
for
you
right,
they're
just
going
to
show
what
they
see.
A
So
we
want
to
make
sure
that,
when
reviewing
the
changes
that
really
impact
the
the
experience
right
or
how
the
how
the
ui
behaves
that
you
test
that
locally,
so
jdk
or
git
pod-
and
that's
not
yeah-
that's
not
required.
If
the
scope
is
too
small,
but
everyone
should
be
doing
that
and
everyone
should
be
able
to
do
that
so
katie
yeah,
if
your
gut
feeling
says
I
need
to
review
this
locally,
then
do
it
yeah.
D
Yeah,
it's
good
that
you
mentioned
it
katie,
I'm
not
sure
if
you've
seen,
but
the
most
merge
requests
have
a
review
app
that
is
automatically
generated
with
that
change.
So
it's
kind
of
like
a
gdk
instance
for
that
merge
request
with
that
code
change
so
that
helps
you
see
the
code
live
already
in
some
instances.
The
review
app
either
won't
be
there
or
there
was
some
problem,
but
then
you
can
create
a
git
pod
instance
for
that
merge
request
at
any
time.
So
I
do
that
very
frequently,
even
smaller
ones.
A
To
know-
and
you
get
more
used
to
it,
katie
once
you
start
working
on
milestone
issues
and
you're
really
required
right
to
do
these
reviews.
A
But
one
of
the
things
I
also
want
to
talk
about
today
is
the
process
right
because
I
know
yes,
it's
a
very
long
documentation
page
about
code
review
guidelines,
but
I
just
want
to
touch
base
on
the
things
I
find.
I
think
the
most
relevant
for
us
not
only
now
that
we
have
merge
requests
as
a
key
performance
indicator,
but
so
that
we,
I
think
we
have
a
good
habit
of
reviewing
things
right.
A
So
first
off
always
have
yourself
assigned
as
a
reviewer
so
and
the
same
as
if
you
want
someone
to
review
something
assign
them
as
a
reviewer.
So
I
see
that's
different,
I
think
per
team,
but
the
code
review
guidelines
say
that
if
you're
working
on
something
keep
yourself
assigned
as
the
assignee
right
and
ask
people
to
review
and
if,
for
example,
you
don't
have
a
permission,
you
don't
have
a
maintainer
level
access
to
a
repo,
for
example
to
gitlab.com,
and
you
can
emerge
into
the
handbook.
A
Then
someone
that
is
a
reviewer
with
a
maintainer
access
level
will
ping
another
maintainer
or
will
merge
themselves
right.
So
that's
one
and
always
in
reviewing
something
hit.
The
approve
button,
if
you
approve
the
change
so
after
you
approve,
remove
yourself
from
your
viewer,
but
always
hit
the
approve
so
for
the
kpi
itself,
it's
going
to
be
important
that
we
are
following
this
process
that
you
are
assigned
to
things
that
you
are
reviewing
not
only
verbally
or
being
pinged
in
the
in
the
comments.
A
But
using
that
feature,
and
another
thing
is
that
if
you
ought
a
change,
I
think
then
you'll
talk
a
little
yesterday.
If
not
you
daniel,
maybe
austin.
Yesterday,
during
the
ux
call,
we
talked
a
bit
about
changes
that
come
from
the
back
end,
but
impact
the
ui.
D
Yeah,
it
was
a
form
that
we
we
no
longer
wanted
to
allow
users
to
change
one
field,
and
I
think
the
initial
plan
was
just
to
remove
it
and
or
they
already
had
the
plan
to
disable
it.
But
then
I
jumped
in
and
and
did
some
some
small
improvements
and
in
general
I
think
it's
worth
it
to
keep
an
eye
on
what
the
team
is
doing,
because
there
will
always
be
some
small
thing
that
should
have
some
level
of
ux
input
but
will
pass
through.
D
But
then
it
also
depends
on
the
on
the
dynamics
of
the
team
right
because
there's,
I
think,
there's
always
some
level
of
this
impression
that
oh
yeah,
involving
designers
in
the
mrr
will
slow
down
the
mr.
So
there's
always
this
friction
of
how
much
designer
should
be
involved,
depending
on
the
team.
A
Yeah
and
that's
a
very
good
point,
because
our
our
point
is
not
to
slow
down
the
mr,
but
spot
inconsistencies.
So
we
had
this
conversation.
Things
mostly
verify
that,
because
we
are
not
being
added,
designers
are
not
being
added
right
to
emerging
quest
reviews.
Then
we
are
not
tracking
wax
debt.
We
are
not
really
looking
at,
for
example,
if
the
component
are
following
the
pyjamas
guidelines
or
if
we
are
using
deprecated
patterns,
et
cetera,
et
cetera.
A
So
it's
it's
it's
about
unblocking
people,
but
at
the
same
time,
tracking
right
the
the
necessary
changes
that
will
need
to
be
addressed
that
we
need
to
be
prioritized
by
project
and
by
engineering.
So
that's
another
point
of
product
designers
being
the
key
reviewers
for
like
what
added
here
any
user
facing
changes.
A
So
this
is
what's
in
the
the
performance
in
the
not
not
in
the
code
review
guidelines
but
as
in
the
handbook
user
facing
changes
include
both
visual,
regardless
of
how
minor
and
changes
to
the
render
dom
that
impact
the
screen
screen
reader,
so
we're
honors.
So
we
are
responsible
for
it.
Please
read
the
code
of
your
guidelines
so
that
you
understand
how
to
perform
a
review.
What
is
your
responsibility,
what
you
need
to
do
after
reviewing
etc,
and
if
you
have
any
questions,
yeah,
let's
reach
out
and
we
can
continue
the
discussion.
B
I
just
had
a
quick
question
about
gitpod,
so
I
used
to
rely
mostly
on
the
digitdk
until
it
broke.
Then
I
started
relying
more
on
the
screenshots
and
having
to
fix
the
gdk
like
when
I
do
have
an
mr
that
really
requires
a
more
thorough
review
and
now
I'm
trying
to
figure
out
gitpod.
B
So
one
thing
I'm
struggling
with
is
that
when
I'm
just
spinning
up
a
new
gitpod
instance
and
it's
not
connected
to
a
specific
branch,
everything
works
until
I
switch
to
the
branch
that
I
want
to
review.
And
then
I
just
get
a
bunch
of
errors
and
I
wasn't
really
able
to
fix
it,
and
I
got
a
recommendation
to
instead
of
spinning
up
like
a
new
gitpod
instance.
Do
it
right
away
for
the
new
branch,
but
I
wasn't
able
to
get
git
pod
to
work
with
merge
requests
I'm
supposed
to
enable
it
in
settings.
B
C
Out
that
long
back
users
used
to
face
the
problem
with
that,
but
no
more
and
my
case
was
just
a
one-off
thing.
I
never
experienced
that
again,
but
if
it
is
happening
again,
I
suggest
you
again
post
it
in
the
get
pod
channel
on
slack.
B
C
Right
yeah,
some
branches
are
problematic.
I
there's
no
reason
why,
but
they
just
it's
very
difficult
to
be
a.
D
But
I
I
asked,
because
sometimes
I
can't
find
the
github
button
in
the
ui.
I
just
can't
find
it
and
then,
if
you
click
the
chrome
extension
from
a
commit
page
or
a
branch
page
or
an
mmr
page
gitpod
is
pretty
smart
and
it
will
know
to
create
a
pod
exactly
from
that
point
and
get
history
wherever
you
are.
So
that's
a
little
shortcut
if
whatever
just
click
there
and
it
goes
but
then
yeah
if
you're
having
problems
with
permission,
I'm
not
sure
you
did
add
git
pod
in
your
lab
settings.
Application
right.
B
B
Oh
on
git,
pod,
no,
that's
on
gitlab!
No!
When
I
go
to
gitlab
settings
and
I
enable
gitpod-
I
think
it's
in
user
settings-
it
doesn't
get
saved
but
yeah.
I
will
bring
it
up
in
the
gitpod
channel
and
see
if
anyone
can
advise
me
on
that,
but
also
I
will
try
the
extension.
That
sounds
like
a
good
hack.
A
Yes,
that
works.
I
had
the
very
same
issue
and
reach
out
to
george
marcel
can
also
help
you,
but
george
has
well.
He
now
works
at
github.
A
We
have
the
slack
channel
here,
and
I
know
that
george
is
always
looking
for
feedback
on
how
to
improve
the
user
experience
for
getpod
so
reach
out
to
him
in
the
channel
or
in
private.
I
think
he's
only
added
to
a
couple
of
channels
now,
yeah,
that's!
Okay!
Thank
you!
Yeah,
thanks
for
the
discussion
and
then
you're
you're
up
next.
D
Oh,
you
mean
the
stage
groups-
okay,
yes,
so
this
week
of
mine,
it's
kind
of
similar
to
the
last
one
right
before
I
went
on
holidays.
So
at
that
point
we
were
starting
up
the
environment
survey.
Now
we
are
ready
to
wrap
it
up,
there's
already
a
merge
request
to
remove
the
the
alert
from
the
ui.
Let
me
open
up
the
survey
to
make
sure
everyone
has
the
context
real,
quick.
D
So
we
added
this
alert
on
the
environments
page
to
add
a
callout
for
the
survey
the
survey
ran
for
about
two
weeks.
We
have
more
or
less
200
responses,
which
is
good.
Not
a
lot
of
them
are
from
large
customers,
which
is
not
so
good,
but
we
decided
to
wrap
it
up
anyways
and
go
deeper
with
interviews
in
the
future,
if
necessary.
D
So
now,
there's
another
merge
request
to
remove
it.
It
was
interesting
that
we
had
some
feedback
from
a
customer
saying
that
this
banner
was
disrupted
for
their
users
they're
a
large
enterprise
customer,
so
it
makes
sense
that
they're
kind
of
cagey
with
the
intrusion
and
they
asked
us
if
we
could
make
these
opt-in
so
at
a
settings
that
they
can
said
yes,
opt-out
of
of
end
product
surveys,
and
these
won't
show
up
for
them.
D
We
don't
have
tooling
for
that
right
now,
but
as
a
proposal
makes
a
lot
of
sense,
so
I
will
share
that
with
the
broader
design
team
as
well,
and
then
on
top
of
that,
what
I'll
keep
working
this
week
is
on
the
manual
deploy
approvals.
It
has
some
some
parallels
with
some
work.
Videos
doing
on
job
approvals,
but
it's
a
work
in
progress
and
basically
add
these
manual
deploy
approvals
to
the
environments
page
because
the
original
design
work
was
made
for
the
pipeline
graph.
B
B
D
Yeah,
absolutely,
I
don't
think
we
have
any
central
guidelines
for
that.
I
know
there
is
some
some
work
being
done
for
for
in
product
surveys
on
the
merge
request
page,
and
that
was
one
of
the
inspirations
for
me
to
add
this.
I
the
if
you
look
at
the
alert
I'll,
add
more
links
here,
because
there's
not
enough
links,
there's
a
dismiss
button
and
then
it
saves
your
option
with
a
cookie.
So
if
you
go
back
to
the
page,
the
alert
won't
be
there
anymore.
D
Even
so,
if
you
have
an
organization
with
1500
users
on
gitlab,
all
of
them
open
the
page,
all
of
them
will
see
it,
so
it
can
still
be
disruptive,
so
yeah
I'll
share
more
links
with
you.
Please
share
your
link
for
this
for
this
survey
nadia
and
we
can.
We
can
collaborate
on
this
and
share
with
more
people.
C
Okay,
my
question
was
around
if
you
and
your
pm
daniel
did
identify
any
large
customers
that
were
kind
of
specifically
concerned
about
this,
because,
like
the
last
time,
we
did
this
in
pipeline
execution,
which
was
long
back,
we
got
in
touch
with
the
times
and
essays.
They
are
very
helpful
in
such
situations.
So
I'm
just
wondering
if
you
kind
of
if
you
happen
to
leverage
these
channels.
D
So
not
really
well
to
give
a
bit
more
context.
The
reason
for
the
survey
was
that,
even
though
we
have
good
research
around
environments,
we
don't
have
specific
feedback
on
how
the
page
is
being
used
and
and
like
what
are
the
problems
with
the
page.
So
we
placed
the
the
feedback
link
for
the
survey
in
the
page
specifically
for
this.
That
was
a
definitive
choice
on
that.
But
then
we.
A
D
Know
that
environments
as
a
feature
doesn't
work
as
well
for
larger
organizations,
so
their
feedback
was
one
of
the
most
important,
but
since
most
of
them
are
on
self-managed
and
the
survey
only
went
to
sas,
then
we
didn't
get.
A
D
From
them,
so
what
we
did
to
mitigate
this
after
some
feedback
from
hayanna
was
to
share
it
with
our
research
coordinators,
and
then
they
shared
the
link
directly
with
larger
customers
in
in
the
first
look
and
on
social
media
as
well,
so
that
helped
scale
the
numbers
a
little
bit,
but
not
too
much
so
yeah
like
we
know
that
the
bigger
problems
for
environments
are
with
larger
customers,
but
this
survey
wasn't
really
the
best
format
to
reach
them.
D
B
Right,
I
tend
to
rely
on
dove
my
product
manager
to
connect
us
with
larger
customers
because,
as
vidiq
mentioned
like
he
will
get
in
touch
with
our
tams
and
through
them
he
will
get
in
touch
with
our
customers.
And
at
this
point
we
kind
of
have
like
a
set
of
a
few
large
customers
that
are
very
open
to
providing
feedback,
which
also
means
that,
like
we
need
to
get
outside
of
our
box,
sometimes
and
probably
talk
to
others
as
well.
But
still
it
provides
us
with
really
valuable
insights.
A
Yeah
and
then
I
think,
just
to
to
voice
what
we're
discussing
here.
Please
also
work
with
will
to
document
these
guidelines
right
from
a
research
perspective,
because
I
know
that
he's
working
now
on
improving
some
of
the
documentation
and
some
of
the
assets
for
research.
So
I
think
it's
a
good
opportunity
to
collaborate
with
him
and
bring
these
insights
so
that
everyone
across
the
board
knows
how
to
collect
this
in-app
feedback,
but
also
if
we
can
determine
when
to
use
this
type
of
surveys
and
show
these
use
cases.
C
A
We're
all
in
the
room
like
we
do.
We
know
what
this
is.
That's
just
good.
Let's
just
pretend
that
we
know,
thanks
for
asking
awesome.
Yeah,
then
feel
free
to
move
forward.
The
discussion.
B
Okay,
I
think
I'm
next
with
some
of
the
issues
that
I've
been
working
on.
I'm
just
gonna
share
my
screen.
B
Oh,
can
you
see
the
issue
yeah,
not
sure
which
window
is
sharing
yeah,
so
we
had
this
issue
to
retry
manual
drop
of
different
variables
and
I've
already
shared
it
during
the
last
last
meeting
that
we
had
and
my
proposal
was
to
add
an
action
to
the
pipeline
graph,
so
that's
kind
of
similar
to
daniel's
journey
with
the
manual
deployment
approvals
where
first
we
looked
at
adding
an
action
pipeline
graph
and
then
after
many
iterations
and
confusion
realized
that
it's
actually
not
the
right
way
to
go.
B
B
So
I
basically
misunderstood
the
problem.
The
main
problem
here,
as
it
turns
out,
is
that
maybe
I
can
show
I
don't
know.
What
can
I
show
to
better
illustrate
this?
So
this
is
what
a
manual
job
looks
like
a
manual.
Job
is
a
job
that
you
need
to
run
manually,
so,
instead
of
relying
on
some
predefined
conditions
like
when
the
previous
jump
job
is
finished,
running
a
new
job
starts
a
manual
job
requires
an
action
from
you,
so
you
would
have
to
actually
go
in
and
click
the
button
to
run
it.
B
So
when
you
do
run
your
manual
job
you
you
can
click
on
the
job
and
hold
on.
I
will
find
that
what
it
looks
like.
B
You
have
an
option
to
enter
manual
variables,
so
it's
it's
used
quite
frequently
by
our
users,
because
sometimes
you
may
want
to
override
the
variables
that
are
by
default
inherited
by
this
job,
and
the
problem
is
that
you
enter
these
variables
during
the
initial
job
run.
B
But
if
you
want
to
retry
the
job,
those
variables
are
not
used
anymore,
so
they're
basically
erased,
and
you
can
only
retry
the
job
with
the
default
variables,
which
has
been
a
really
big
blocker
for
for
your
workflow,
because
you
you're
not
able
to
properly
troubleshoot
the
job,
because
the
variables
that
you
used
are
basically
gone,
and
now
you
have
to
like
either
you
basically
have
to
rerun
the
job
from
zero.
You
can't
retry
it
with
the
variables,
so
I
didn't
really
understand
that
that
was
the
problem.
B
So
what
we
will
be
doing
is
we
will
basically
make
the
manual
jobs
retry
with
those
variables
we
will
make
the
manual
jobs
inherit
those
custom
variables,
and
the
next
problem
is
that
when
you
troubleshoot
the
manual
job,
you
want
to
override
those
variables
sometimes
to
see
if
it
helps
you
fix
the
problem.
So
that's
kind
of
one
of
the
steps
in
the
workflow.
B
So
initially,
what
I
was
proposing
was
this
very
complex
design,
where
we
would
add
an
action
to
a
manual
job
in
the
pipeline
graph
like
an
additional
option
to
retry
it
with
variables
and
not
just
do
like
a
basic
retry
and
then
that
would
open
up
a
model
where
you
would
be
able
to
override
those
variables.
B
But
again
there
was
lots
of
pushback
from
the
front
end
team
around
the
solution,
even
though
it
can
be
well
for
some
workflows.
It
can
be
easier
if
you're
using
the
pipeline
graph
to
stay
on
the
pipeline
graph,
but
it
would
make
it
difficult
for
the
page
to
kind
of
handle
these
actions,
because
the
pipeline
graph
is
already
very
complex,
we're
already
having
some
performance
issues
with
it.
B
So
we
need
to
be
very
careful
basically
when
adding
new
actions
to
the
pipeline
graph
and
unless
we,
unless
we
we
don't
have
any
other
way
to
do
it.
Then
of
course
we
can
or
if
it's
really
the
only
way
for
us
to
address
the
problem
and
really
fit
the
user's
workflow.
But
if
we
can
avoid
it,
we
should
avoid
it,
so
that
led
me
to
an
alternative
solution.
Also
after
I
investigated
all
of
the
different
versions
that
the
each
description
went
through.
B
So
I
got
a
better
understanding
of
the
problem.
So
now
what
I'm
proposing
is
that
instead
we
allow
you
to
override
variables
in
the
job
page.
So
when
you
run
the
manual
job
you're
able
to
enter
your
custom
variables
there
and
then
once
the
job
runs,
you
have
job
logs
in
the
job
page
and
what
I'm
proposing
is
that
we
have
different
tabs,
so
the
default
tab
would
be
job
logs.
B
So
the
default
view
of
the
job
page
will
not
change
basically,
except
that
there
will
be
an
additional
tab
and
then
we
would
have
a
variables
tab
where
we
can
surface
the
variables
that
are
being
used
as
an
mdc.
We
would
only
do
that
for
the
manual
job,
so
we
can
use
the
same
form
that
we
already
use
when
we
run
the
manual
job
with
custom
variables
and
we
would
surface
the
variables
that
were
entered
during
the
job
run
so
that
when
you,
when
you're
troubleshooting
your
manual
job,
you
will
see
okay.
B
So
it's
using
these
variables,
you
can
add
some
other
variables,
so
you
can
override
these
variables
and
retry
the
job
with
those
new
variables
and
in
the
future.
We
can
also
use
this
space
to
surface
other
variables
in
the
ui,
for
example,
we
could
surface
here
just
in
a
read-only
view
the
default
variables
that
are
being
used,
that
the
manual
job
inherits
from
the
rest
of
the
pipeline,
like
if
you
have
some
global
variables,
or
you
have
variables,
set
up
in
cd
settings,
for
example.
B
So
this
also
aligns
with
ditica's
findings
around
surfacing
the
variables
that
are
being
used
in
github
ui,
because
their
users
have
lots
of
confusion
around
how
the
variables
are
inherited.
So
here,
even
if
we
provided
just
a
view
only
like
something
in
view
view
only
mode
where
you
can
see
what
variables
are
being
used,
that
would
provide
some
clarity.
B
So
that's
where
I'm
at
right
now
with
this
issue
and
we've
gotten
some
feedback
from
customers
that
this
this
seems
like
a
good
direction.
But
if
you
have
any
any
comments
or
suggestions
around
how
to
make
it
work,
especially
vitica.
I
know
you
probably
have
opinions
since
you've
been
working
so
much
on
the
job
page.
So
I'm
curious
to
hear
what
you
think.
C
I'm
so
happy
to
see
this,
and
I
love
this
idea,
and
this
really
solves
so
many
different
problems,
because
I
know
this
mvc
is
specifically
for
the
manual
jobs,
but
they
would
also
be
so
useful
for
every
other
kind,
especially
for
upstream
and
down
stream,
because,
oh
my
god,
it's
so
confusing
to
just
understand,
what's
happening
with
the
variables
there.
C
So
if
you
users
are
able
to
see
that
these
are
the
variables
and
somehow
I
don't
know,
maybe
much
much
later
in
an
iteration
if
we
can
say
that
this
is
what
is
being
passed
from
that
pipeline
to
this
pipeline
or
it's.
This
is
what
is
going
from
this
pipeline
to
that
pipeline.
That
would
be
so
great
yeah
and
this
option.
C
B
Yeah,
so
it's
gonna
be
a
foundation
and
back
an
issue
for
sure
and
I'll
keep
you
posted
on
our
discussions
around
implementation,
because
right
now
I
I've
still
been
gathering
feedback
on
this
from
the
customers
and
the
issue,
and
now
I
think,
we'll
start
talking
about
how
we
will
actually
break
this
down
and
implement
it.
A
Sorry
but
yeah
we
have
a,
I
think,
six
seven
minutes
left
so
we
can
move
the
conversation
thanks
nadi
for
sharing
this
video
you're
up
next.
C
Amazing
yeah,
I
I
had
a
chance
to
work
on
something
that
I
have
been
wanting
to
work
on
since
a
long
time,
and
I
just
wanted
to
kind
of
share
that
the
progress
with
everyone.
So
there
was
this
issue
that
pedro
had
created
some
time
back
when
he
was
working
on
the
whole
redesign
of
mr
widgets,
and
it's
something
that
kind
of
came
up
in
his
conversations
with
other
stakeholders
in
the
process
but
and
it.
C
The
proposal
here
is
pretty
simple:
that
the
words
that
we're
using
the
buttons
today
they
are
very
verbose
and
they
kind
of
communicate
more
than
should
be
communicated,
which
kind
of
like
confuses
the
user
and
also
intimidates
them
to
a
level
and
like
how
about
changing
all
of
those
things.
Just
simple,
auto
merge
so
telling
users
that
do
you
want
to
auto
merge
it
which
is
like.
Do
you
want
to
use
the
strategies
that
you
have
selected
in
the
settings
page
or
do
you
want
to
do
it
manually
like
that
option?
C
But
when
I
started
to
dig
deeper
and
get
into
each
one
of
those
zendesk
comments
and
other
issues
that
were
in
picture?
I
figured
that
it's
probably
not
a
task.
That's
so
simple!
I
mean
it's
very
valuable.
Yes,
it's
going
to
like
help
us
improve
the
adaptation
adoption
of
our
merch
train
features
without
even
having
to
push
for
it,
because
we
can
just
I
mean
if
you
present
it
in
a
very
simple
way.
It
would
be
so
much
easier
for
users
to
start
using
this.
C
So
some
a
few
things
that
I
learned
learned
in
the
process
first
was
that
users
would
like
this
option.
Yes,
but
not
at
the
stage
where
they're
already
in
the
birch
request.
C
So
jumbled
up
in
the
settings
like
if
you
go
to
different
settings,
you'll
find
different
parts
of
this
scattered
all
around.
So,
for
example,
I
know
that
merge
stream
pipelines,
I
mean
merge,
result
pipelines
and
merge
train
pipelines.
They're
very
co-dependent,
like
you,
can
only
enable
merge
train
when
you
have
much
result
pipeline
enabled
but
merge
train
is
a
strategy
and
merge
result
pipeline
is
not
it's
like
a
merge
option.
C
It's
a
it
talks
about
like
what
your
pipeline
should
be
like
and
not
how
you
want
to
merge
your
mr,
so
those
things
have
to
be
separated.
We
cannot
keep
on
presenting
them
like
this
and
then
say
auto
merge
on
the
mr,
because
if
the
communication
doesn't
align,
it
just
creates
more
problem
for
us.
C
Then
there
has
to
be
an
emergency
exit,
because
users
would
definitely
not
want
to
be
trapped
into
this
and
feel
helpless
after
that,
if
they
want
to
revert
it
if
they
want
to
do
it
manually
after
setting
that
so
for
a
rough
proposal,
what
I've
proposed
is
that
maybe
a
design
for
like
when
you're
creating
a
new
mr
presented
an
option
for
auto,
merge
right
there
and
that
as
an
emergency
exit,
present,
merge
manually
option
and
also
an
option
to
go
and
take
a
look
like
what
are
the
strategies
which
are
in
place
and
policies
in
place
that
have
been
set
by
the
organization
then
show
the
auto
merge
process
through
the
merch
widget.
C
But
how
close
am
I
in
the
process
like
how
many
points
I've
already
been
through
and
what
am
I
waiting
for
now
so
to
very
clearly
communicate
the
progress
of
those
steps
in
the
widget,
and
this
could
be
done
using
the
design
that
pedro
has
already
worked
on,
so
maybe
just
making
small
little
changes
to
that.
C
And,
lastly,
going
back
to
the
settings
page
and
rearranging
everything
and
coming
communicating
very
clearly
what
are
the
policies
and
what
are
the
strategy
options
to
just
to
make
sure
that
everything
is
communicated
in
the
same
format
on
all
the
pages,
so
I
had
a
discussion
with
pedro
after
this
and
turns
out.
C
We
are
kind
of
on
the
same
page
and
so
I'll
be
creating
many
different
issues
that
will
be
working
on
iteratively
in
the
future
and
for
the
next
thing
that
I'm
doing
it's
just
like
it's
a
progress
on
what's
happening
with
the
redesign
of
the
table
that
I
was
sharing
about
in
the
last
two
meetings,
the
challenge
there
was
to
create
space
in
the
pipeline
index
page,
so
we
can
introduce
more
changes
and
currently
we
are
at
a
place
where
we
have
come
up
with
some
design,
which
has
like
substantially
reduce
the
space
consumption
in
the
table
and
nadia.
C
I
took
few
of
your
suggestions
from
other
issues
and
put
them
here.
So
we
have
just
one
column
now
which
says
pipeline
and
most
of
the
information
comes
under
that
yeah.
That's
it
and
we'll
be
doing
a
solution,
validation
for
this
very
soon
because
we
are
like,
even
if
it
is
just
like
ui
changes,
but
there's
a
lot
many
of
them.
So
we
need
to
validate
that
yeah.
That's
my
update.
A
Thanks
vitica
gina
has
a
feedback
question
here
and
I
saw
that
he
already
answered
vitica
on
runner
admin
view
she's
working
on
and
she's
gonna
start
working
on
some
more
visual
deliverables.
So
please
have
a
look
in
gina's
comment
and
answer
your
questions
or
leave
some
feedback
here
in
the
docs
or
in
slack
and
katie.
We
finally
made
it
to
you,
but
you
want
to
talk
to
us
a
little
bit
about
your
own
boarding
process.
B
Yes,
so
this
is,
I
think,
day,
seven
that
I've
worked
at
gitlab,
maybe
day
eight
getting
into
it.
Everything's
been
super
great.
So
far,
I'm
really
happy
to
be
here.
B
It's
been
awesome,
seeing
all
the
collaboration
happening
and
and
yeah
I'm
got
some
adjustments
to
to
work
with
with
gitlab
the
product
and
I've
never
worked
with
gitlab
before
and
even
some
of
the
terminology
like
merge
requests
is
new
to
me,
even
though
I've
been
using
like
git
based
tools
for
12
years,
and
but
I'm
sure
that
that
will
come
in
time
and
and
yeah.
It's
been
great
meeting
everyone
for
coffee,
ketchups,
I've
had
coffee
ketchups
with
all
of
you,
which
is
good
and
yeah.
B
My
biggest
struggle
at
the
moment
is
getting
a
bit
more
up
to
speed
on
the
package
area
and
I've
watched
many
many
youtube
videos
today
and
but
I
think,
once
I
get
stuck
into
it,
it
will
be
better.
I
remember
when
I
was
reading
about
git
before
I
used
git,
it
all
sounded
very
complex
and
then,
when
I
did
it
I
was
like.
Oh,
this
is
actually
very
straightforward
and
so
yeah
I
will
be
starting.
B
My
ux
scorecard
tomorrow
I've
got
some
time
set
aside
with
my
pm
tim
and
he's
been
on
holiday,
but
he's
back
now
so
hopefully
I
get
some
nice
hands-on
experience.
Then.
A
A
I
just
updated
something
in
your
onboarding
issue
and
documented
that
that
ux
scorecard
exercise
so
maybe
vta.
You
have
some
insights
also
in
this
process,
right
that
you're
going
through
with
it
with
gina.
So
please
connect
that'd,
be
awesome
and
we're
happy
hope
that
you're
here
katie
happy
to
be
here.
A
I
think
we
are
at
time
right
a
little
bit.
I
don't
know
anymore
one.
Second,
yes
a
bit
over
time.
Please
leave
some
feedback
for
gina.
I
think
I
think
that
I
know
that
she
would
appreciate,
and
anything
else
yeah
see
you
later
home
this
week.