►
Description
This video should be kept as "Unlisted" because there are kids that appear in the call
A
A
You
know
waiting
to
make
an
action
before
creating
an
mr,
because
there
could
be
issues
with
ci
minutes
or,
like
you
know,
orphan
or
dangling
mrs
and
branches
all
over
the
place
so
and
the
other
thing
that
I
had
a
discussion
with
my
manager
about
this
was
that
the
idea
of
giving
users
control.
So
you
know,
if
we're
starting
to
create
mrs
for
people
automatically,
they
might
not
know,
and
then
they
have
to
manage
or
close
them.
A
So
that's
not
a
good
experience
that
we
want
to
introduce
so
with
the
spirit
of
one
branch,
one,
mr
I'm
just
gonna
jump
into
the
flow
and
then
I'll
feel
free
to
jump
in
at
any
time
to
leave
any
like
state.
Any
comments,
so
so
from
here
we're
gonna
test
out
this
new
like
contribute
to
this
page
flow
and
then
clicking
on
this
will
take
you
to
the
single
site
editor.
But
what
we're
just
going
to
test
today
is
the
stack
site
editor.
A
A
If
I
click
on
like
if
I
made
some
changes
here,
then
there'll
be
some
kind
of
signifier
that
says:
unsave
changes
so
here
it's
up
to
the
user
to
either
commit
via
save
or
publish
changes
which
would
create
the
with
which
would
commit
and
then
create
the
mr
as
well
so
here
I'll
click
save,
and
then
this
is
the
stage
where
I
propose
that
we
create
the
mr
and
the
branch
at
the
same
time
for
this
solution.
Validation
round
I'm.
A
This
is
a
question
that
I'll
open
to
you
guys
we're
not
gonna,
allow
them
to
change
the
name
of
the
branch
it'll
be
whatever
like
what
we
have
right
now
with
the
auto
generated
name
for
the
branch.
But
if
people
really
feel
the
need
to
change
change
the
name
of
the
branch,
then
that's
something
that
we
can
like
consider
adding
in
the
future.
But
essentially
this
is
our
current
flow
that
we
have
right
now,
but
it's
just
moved
up
forward
the
moment
when
you
create
a
mr.
B
So
I'm
just
having
a
look
at
this
and
if,
if
my
understanding
is
right,
we'll
we
won't
we'll
almost
be
hiding
the
branch
from
the
user,
you
know,
then
their
main
interaction
point
will
be
the
mr
and,
and
so
my
question
is:
does
it
even
matter
for
us
mentioning
what
the
branch
is
there,
especially
if
we're
not
going
to
allow
them
to
edit
it?
I
feel
like,
even
even
allowing
them
to
to
edit
the
branch
that
seems
like
a
really
advanced
use
case
and
probably
not
in
line
with
our
immediate
target
audience.
B
Sense-
and
I
I
kind
of
like
you
know
like
I-
I
like
seeing
it
there,
but
it
it
doesn't
really
make
sense
for
the
average
for
our
target
audience
and
that's
why
we
have
the
issue
to
create
a
new,
a
new
success
page.
So
in
that
same
vein,
I'm
I'm
questioning
you
know
like
this
might
actually
just
confuse
somebody.
B
If
one
of
our
pillars
is
to
abstract
away
the
complexity
of
git
and
the
git
workflow,
then
it's
probably
best.
We
just
don't
tell
them
about
this
branch
that
will
be
created
unless
there's
a
valid
reason
for
them.
To
know
about
this,
and-
and
I
I
I
looked
at
this
recording
from
the
issue
earlier
today
and
and
I
think
from
the
workflow
there's
no
real,
I
think
there's
an
opportunity
to
choose,
I
think
from
existing
mrs
down.
C
I
just
I
wanted
to
jump
in
and
just
just
to
explore
the
flip
side
of
that
argument.
If
we're
doing
one
branch
to
one.
Mr
I'm
I'm
curious
about
just
what
would
the
impact
be
if
we
expose
the
branch,
but
not
the
mr,
when
you're
selecting
multiple?
Mr,
so
if
you
think
about
the
saving
and
committing
workflow
prior
to
creation
of
an
mr,
you
might
create
a
new
branch
commit
some
edits,
come
back
to
it,
commit
some
more
edits
and
then
generate
an
mr.
C
So
if
the
workflow
we're
really
trying
to
achieve
is
the
ability
to
retrieve
some
work
in
progress,
draft
state
that
could
map
nicely
to
a
branch
name
rather
than
an
mr
object
and
then
having
you
presenting
a
way
to
switch
between
branches
to
to
set
the
state
of
the
editor
and
then
whether
that
branch
has
an
mr
or
not.
We
could
just
change
the
state
of
the
button,
whether
it's
publish
a
new,
mr
or
append
the
changes
to
an
existing.
Mr
because
we
would
know
if
that
branch
already
had
an
open.
Mr.
A
So
I
thought
about
like
starting
off
with
the
bread
like
I.
I
guess
that
was
the
thing
on
monday
when
I
was
like.
Oh
did
I
start
with
the
branch
or
with
the
mr
and
with
the
mr,
you
can
we
have
this
naming
convention
at
the
moment.
I
get
that
this
whole
work
in
progress
prefix
to
the
name
and
the
other
thing
was
like
from
our
branch.
A
So
let's
say
these
were
static
site
editor
changes
like
we
could
add
like
little
labels
on
the
back
end
of
this
to
like
help
surface
them
easier
and
the
complexity
of
linking
up
a
branch
to
mr
is
is
like
one
that
I
wanted
to
eliminate.
But
at
this
with
the
spirit
of
one
branch,
one,
mr
and
also
like
everything,
starts
off
as
a
merge
request.
So
that
was
my
kind
of
thinking
around
just
forcing
or
nudging
the
behavior
to
start
off
in
the
mri,
even
if
you're
working
on
and
like
draft
stuff.
A
B
C
C
C
C
B
A
But
with
that
with
commit
messages,
can't
is
it
possible
to
add,
like
an
extra
like
skip,
ci
comment
in
there
for
certain
commit
messages
so
that
it
doesn't
kick
off
the
pipeline?
So,
for
example,
save
would
do
a
commit,
but,
like
we
tag
on
inside
the
commit
message,
I
skipped
ci
or
something
and
that
wouldn't
trigger
the
ci
build.
A
A
A
Okay,
this
is
an
area
that,
like
I,
was
playing
around
with
yesterday.
I'm
not
100
happy
with
this
area
here
where
I
had
the
title,
the
mr
because
it
looks
a
little
bit
busy
to
me.
What
I'm
trying
to
convey
here
is
like
there's
still
stuff
for
you
to
do
within
the
mr
and
then
some
kind
of
time
stamp
to
show
that,
like
when
it
was
last
updated.
A
This
is
taking
kind
of
like
the
information
from
an
mr
here
like
zero.
Four
tests
completed
the
mr
number
itself
and
the
number
and
like
one
one
potential
thing
is
just
to
take
this
layout
and
then
just
apply
it
back
over
there
because
it
has
the
kind
of
key
information,
but
I
was
questioning
whether
it
is
useful
to
have
the
number
here,
because
we
kind
of
hide
it
everywhere
else,
so
that
was
the
rationale
of
changing
it.
It
looks
kind
of
messy
here
to
me
so.
B
Yes,
similar
to
exposing
the
branch
name,
I
don't
know
whether
exposing
the
mr
number
is
is
is
useful
or
needed.
Even
I
as
an
engineer
knowing
what
it
means
like.
I
I
fully
get
it,
but
I
don't
know
if
somebody's
going
to
know
what
exclamation
53426
means
who
who's
in
sales,
so
I'm
all
for
not
having
it
I'd
rather
have
users
tell
us
they're,
missing
information
yep
that
we
can
add,
then
provide
too
much
information
and
then
we're
confusing
people
or
make
giving
them
cognitive
ovarian
that
they
shouldn't
have
cool.
C
B
A
And
that's
correct
because
when
I
saw
these
zero
four
tasks
completed,
etc,
it
was
aligning
to
the
checklist
of
like
the
mr
template.
So
you
know
have
you
given
a
good
title?
Have
you
assigned
a
dri?
Have
you
added
description?
Have
you
used
the
right
template?
Those
were
like
the
four
tasks
in
the
book,
gitlab
handbook
pages.
So
when
I
go
to
publish
this
kind
of
idea
of
like
once,
I
add
a
description,
this
number
changes
to
three
or
four
tests.
That
was
where
this
was
coming
from.
A
Yes,
this
is
a
very
git
labs,
centric
solution
to
this,
but
it
was
kind
of
to
show
like
a
completeness,
so
we
could
abstract
it
away
from
like
the
handbook
stuff
and
just
have
it
as
like.
These
are
the
necessary
fields
that
you
need
to
complete
prior
and
then
maybe
that
might
change
where
I
do
that
progress
bar.
But
that
was
the
idea.
C
B
D
B
B
So
the
one
thing
I
wanted
to
say
about
this
is,
I
could
imagine
us
down
the
line,
long
way
down
the
line
where
there's
some
sort
of
configuration
option
where
they
might
be
specific
tasks
that
somebody
needs
to
to
do
before
they
can
submit
a
publish
or
change.
You
know
like
they
might
be
more
more
specific
fields
that
they
want
to
ask,
or
so
on.
B
So
my
the
one
thing
I
I
when
I
saw
that
the
passing
is
I'm
wondering
how
much
value
it
it
gives
and
whether
we
shouldn't
rather
have
other
queues
like,
for
instance,
the
publish
button
is
grayed
out
until
all
the
required
like
indicating
what
is
a
required
field.
For
instance,
I
think
you
mentioned
in
the
video
that
signee
wasn't
required.
B
Yeah,
so
so,
though,
so
like,
I
was
wondering
whether,
because
essentially
what
you
were,
what
I,
what
I'm
seeing
those
tasks
conveying
is
the
things
I
need
to
do
to
get
this
into
a
publishable,
and
I,
but
I
wasn't
making
the
connection
necessarily
with
what
the
tasks
are.
The
three
or
four
tasks
necessarily
like
I
can
see
now.
You
know
like
first
task
was,
I
guess,
make
a
change.
The
second
one
is
title
description
and
then
choosing
signing
publish
so
the
connection
between
what
the
tasks
were
wasn't
strong
enough
for
me,
gotcha.
C
B
Yeah
and
it
might
be
confusing
if
we
have
tasks
here
and
then
it
confuses
with
tasks
in
the
merge
request,
because
they're
not
the
same
thing,
so
we
yeah-
I
the
only
other
thing
I
could
think
of.
Is
you
know
how,
in
a
in
a
checkout
journey,
you
sometimes
have
step
one
two:
three,
yes,
potentially
having
some
sort
of
step
wizard
to
indicate
what
you
need
to
go
through,
but
even
that
might
not
be
necessary.
D
D
Perspective,
the
there's
only
one
task
that
actually
needs
to
occur
and
that's
an
approver
needs
to
be
set,
and
then
on
top
of
that,
if
we
do
in
fact
deem
it
very
important
to
have
a
title,
that'd
be
the
second
level
and
then,
if
a
description,
which
naturally
makes
sense
that
could
be
optional
or
then
be
required,
and
that
would
be
three
things,
but
ultimately
it's
if
going
through
this
flow
right.
It's
like
I
want
to
make
some
edits.
D
But
so
I
don't
know
if
there's
a
way
to,
I
guess
what
I'm
trying
to
say
if
there's
a
way
to
maybe
and
again
excuse
my
ignorance,
if
obviously
you're
kind
of
exploring
what
could
be
more
in
the
future.
Like
you
know
further
downstream,
but
I
don't
know
in
terms
of
immediate
needs,
it
might
just
be
the
approver,
and
that
might
be
a
good
first
iteration.
A
D
A
A
Use
existing
hammer
kind
of
flow,
so
you
choose
like
an
existing
merge
request
and
then
you
jump
into
that
and
then
this
is
what
I'm
proposing
for
like
editing
of
like
like
jumping
into
existing.
Mrs
at
that
moment,
when
you
choose
something:
that's
when
you
can
change
and
that's
when
you
can
select
the
mr.
A
B
B
A
A
I
have
other
designs
where
there's
like
a
search
where
you
could
search
for
them,
but
another
way
we
could
do
that
is
sorting
by
recency
so
like
that
surface
up
to
the
top,
so
it
would
be
similar
to
landing
on
this
page,
but
it's
kind
of
like
sorted
by
recency.
The
other
thing
is
that
we
could
do
is
potentially
have
labels
on
the
mrs
that
you
could
filter
by
so
let's
say
it's
just
static
site,
editor
stuff,
those
surface
to
the
top
yeah.
B
Because
I
I
would,
I
was
thinking
you
could
potentially
try
and
look
at
is.
Is
there
an
mr
with
this
page
already
on
it,
but
that
doesn't
really
work
for
the
multi
multi-page
edit
scenario?
Where
yeah
you
might?
You
might
have
edited
a
page,
and
this
is
a
different
one,
but
you
want
to
make
it
part
of
that,
mr,
so
it
it
and
also
it.
B
So
it's
a
really
difficult
one
to
to
provide,
I
guess
the
most
relevant
options
there
and
so
some
sort
of
search
like
I
think
we
have
to
try
as
our
best
to
have
some
sort
of
intelligence
to
limit
the
options
as
best
we
can,
but
some
sort
of
search
or
filtering
like
maybe
even
like
as
like,
like
the
search
we
you
have
there,
where
author
equals
this
user
or
something
like
that.
You
know
that
that
might
be
needed
to
to
help
get
to
the
right
image
that
you
want
to
do.
A
C
I
think
we
should
probably
take
more
cues
from
how
streamlined
that
process
is,
and
maybe,
okay,
so
I'll,
yeah
and
I'll.
Just
the
other
thing
is
I'm
a
little
concerned
about
the
performance
of
building
this
list
for
an
organization
like
ours
with
940
open,
merge
requests,
even
if
we
didn't
have
search.
B
So
I'm
I'm.
I
want
to
challenge
that
again
and
say:
is
our
target
persona
going
to
be
comfortable
or
no
about
you
know,
is
showing
them
a
list
of
branches
in
any
way
going
to
help
help
them
with
the
discoverability,
especially
if
we
ought
to
generate
branch
names
and
don't
allow
them
to
edit
it
like?
C
B
A
Yeah,
I
think
that
that's
a
good
way
to
start
and
then
over
time
over
time,
we'll
run
into
the
940
scenario,
because
everyone
would
love
to
use
the
static
site
editor,
which
is
good,
and
then
I
think
we
can
look
at
building
the
smartzone
like
sorting
like
yours,
first
or
most
recent
and
then
having
the
search.
I
think
to
confirm
this.
I
think
right
now
like
to
solve
the
problem
around
like
accidentally
choosing
the
wrong
one,
because
it's
like
a
little
bit
too
easy.
A
Maybe
there
should
be
a
second
step
after
this
to
confirm,
like
you
know,
you're
about
to
make
changes
on
this
thing,
and
then
this
is
where
I
list
like
the
branch
name
as
well
saying
so
that
it
gives
you
that
extra
bit
of
friction
to
say,
okay,
this
is
like
your
checkpoint
and
pay
attention
here.
Yeah
most
people
will
just
click,
click
click
click
but
like
at
least
there's
that
extra
speed
bump
before
jumping
into
the
wrong.
Mr,
where
I
the
screen
would
be
like
this
is
the
mr
you're
gonna
go
to.
C
A
D
One
yeah
we
have
I'm
curious,
do
we
have
data
on
so
I
just
did
a
quick
experiment
just
by
looking
at
the
current
mr's,
like
the
first
like
seven
or
eight
of
them,
and
then
just
quickly
looking
at
how
many
changes
were
done
in
each
of
them
and
of
the
first
seven
or
eight.
There
was
only.
I
think,
one
had
two
and
the
the
other
file
was
an
image
edition
and
then
the
another
one
had
three.
D
D
B
I
think
most,
mrs,
that
I've
seen
that
involved
multiple
pages
was
when,
when
you
introduced
a
new
page
and
you
needed
to
add
a
link
to
another
page
to
to
this
new
page
or
when
it
was
updating
a
specific
link
or
terminology
across
multiple
pages
sure
I
I
do
agree
that
that
80
of
the
cases
and-
and
this
is
just
some
sucking
based
on
what
I've
seen
it's
likely
single
page
updates
and
so
optimizing
for
that.
First,
as
our
first
iteration
is
not,
it
isn't
invalid.
A
D
Near
the
end
there
we
spent
a
a
chunk
of
time
thinking
about
how
we
could
filter
this
merge.
Mr
list,
now
that
we
know
probably
80
20
scenario
is
going
to
be
single
files.
I
guess
that's
not
totally
important.
I
guess
what
I'm
trying
to
get
at
is.
We
should
ping
the
sealy
or
chad
or
something
to
like,
basically
might
think,
there's
a
problem
right
now
in
terms
of
how
easy
it
is
to
filter
this
list.
D
I
have
an
assumption
that
it's
actually
going
to
be
very
simple
to
to
do
that
and
again
whether
I
know
we
propose
the
idea
we
have
a
special
label
if
it
was
edited
from
the
static
site.
Editor,
that's
one
way
again,
there's
going
to
be
multiple
ways,
but
I
imagine
it's
not
going
to
be
that
problematic
to
actually
filter
a
list
to
what
we
want.
A
Yeah
I
was
talking
to
pedro
from
within
the
create
group
and
they
ran
a
script
to
see
that
they
have
the
script
that
allows
you
to
see
how
many
files
and
chunks
and
line
changes
so
yeah
I'll.
Try
to
give
this
a
run,
see
how
that
goes.
If
it
doesn't
make
any
sense
to
me,
then
I'll
share
with
the
team
if
it
makes
sense
or
not,
but
then
yeah.
B
Yeah,
I'm
I'm
really
looking
forward
to
to
seeing
what
they
say.
This
for
me
is
kind
of
like
the
next
big
step
in
our
in
our
product,
offering
you
know
right
now
we're
just
focusing
on
the
content,
editing
experience,
but
the
workflow
is
such
a
big
part
of
of
making
that
experience
more
user
friendly
as
well.
So
I'd
be
really
interested
to
see
what
their
feedback
is
with
regards
to
whether
they
feel
this
will
make
it
easier
for
them
and
and
how
much
confidence
they
get
out
of
this.