►
From YouTube: 2022-06-21 Code Review UX Sync
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).
B
Welcome
to
the
ux
thing
for
the
week
first,
one
up
that
I
wanted
to
put
on
the
list
is
that
I
I
had
slack
threads
for
both
of
these,
but
I
thought
it'd
be.
Maybe
we
could
sort
of
efficiently
get
through
them
here.
There's
been
some
feedback
about
automatic
assignment
and
merge
requests.
B
So
this
is
a
change
that
we,
the
genesis
of
the
change,
is
that
it
was
originally
done
on
the
create
merge,
request
button
back
when
that
button
automatically
created
a
merge
request
and
didn't
send
you
to
the
the
new
merge
request
form
and
we
talked
when
we
originally
did-
that
about
extending
it
everywhere,
but
sort
of
used
it
as
a
small
iteration
and
then
when
we
changed
the
create,
merge,
request
button
people
wanted
this
feature
back,
and
so
we
put
it
back
in
and
sort
of
turned
it
on
for
all
of
the
create,
merge,
request
form,
so
the
create
merge
request
form
basically
defaults
to
assigning
it
to
you.
B
If
you
create
a
merge
request
and
that's
the
behavior
that
we're
driving
now
but
link
to
the
slack
thread,
I
think
the
one
that
we
discussed
it.
It
might
be
a
customers,
actually
don't
remember,
and
then
the
feedback
is
sort
of
there
are
people
who
don't
don't
use
this
as
their
workflow.
B
If
you
look
at
the
issue-
and
so
I
think
we
need
to
make
a
decision
on,
I
guess
whether
or
not
we
want
to
keep
that
behavior
or
change
it
or
do
something
else.
I
think
I
just
I'll
start
with
my
preference.
My
preference
is
that
I
think
this
drives
behavior
for
how
we
want
the
review
flow
to
work
like
if
we
think
about
features
that
we're
building
around
review
flow.
B
They
revolve
around
those
people
being
in
the
reviewer's
slot,
like
if
you
think
about
re-request,
a
review,
which
was
the
feature
that
existed
before,
like
you
had
to
be
a
reviewer
to
see
the
re-request
review,
like
you,
couldn't
be
an
assignee
or
something
else,
even
though
other
groups,
you
know
other
people
who
hadn't
adopted
reviewers,
were
just
assigning
people,
so
I
think
it
drives
sort
of
the
right
behavior
in
terms
of
how
we
want
people
to
participate
in
the
merge
request.
B
It
is
weird
to
have
an
assignee
field
in
merge
requests
now
that
we
have
reviewers,
it
doesn't
really
make
sense
like
what
is
the
and
we've
always
sort
of
had
this
issue
of
like
it's
hard
to
distinguish
between
what
an
assignee
is
and
what
a
reviewer
is,
and
so
one
of
the
things
I
had
been
thinking
about,
and
just
maybe
this
is
a
catalyst
for
that
was
if
we
got
rid
of
assignee,
dramatic
change
and
relabeled
it
author,
which
I
think
more
correctly,
aligns
with
how
we
view
that
field
currently
by
automatically
assigning
the
person
we
view
it
sort
of
as
an
author
and
then
making
that
field
populated
based
on
actual
authors
of
the
merge
request,
so
people
who
are
get
authors
or
commit
or
do
other
things
right.
B
So
that
gives
you
sort
of
a
clear
indication
of
who
has
authored
parts
of
this
change.
So
that's
probably
a
more
dramatic
thing
that
we
need
to
think
through,
but
I
think
the
immediate
question
is
sort
of
do
we
want
to
do
anything
about
automatic
assignment
or
just
you
know,
continue
to
monitor
feedback.
C
C
Roles
that
people
are
trying
to
fit
with
the
current
attributes,
where
you
can
add
people
so
before
we
had
reviewers
and
we
just
had
assignees
different
teams,
would
treat
the
concept
of
an
assignee
differently
and
even
now
with
reviewers.
You
know.
There's
this
example
in
the
issue
where
someone
says
that
the
assignee
is
the
one
who
will
merge
will
have
the
final
decision
on
the
merge
and
the
reviewers
are
the
ones
who
might
be
interested
in
having
a
look
at
it,
but
are
not
responsible
for
reviewing
the
code
in
detail.
C
And
but
I
don't
have
a
strong
opinion
right
now
on
whether
we
should
revert
it
or
not.
Yeah,
that's
my
my
quick
take.
D
I
think
I
mentioned
this
in
the
thread
and
but
I
I'm
leaning
towards
reverting
it.
I
don't
mind
either
if
we
just
want
to
continue
monitoring
it,
but
it
does
feel
like
a
little.
I
mean
for
the
reasons
you
just
said:
we've
got
this
assignee
field
that
doesn't
necessarily
fit
into
the
workflow
anymore
and
by
automatically
assigning
the
author
it
feels
like
we
strongly
believe
that
the
author
and
the
assignee
should
both
exist
and
they
should
both
be
the
same
person
and
we're
not
sure
that
assignee
should
even
exist
in
its
current
state.
D
So
it
feels
like
we're
doubling
down
on
this
feature
that
we
don't
necessarily
plan
on
keeping
or
we
don't
necessarily
believe
in.
It
doesn't
really
work
for
our
workflow.
We
just
kind
of
do
it
and
it's
like
we
have
yeah.
We
just
have
these
these
two
things,
author
and
assignee,
they're
always
the
same,
and
it
doesn't
make
that
much
sense
and
then
we're
blocking
out
anybody
else
who
wants
to.
D
A
D
B
I
think
that's
I
wouldn't
expect
to
see
positivity
in
the
issues.
That's
typically
not
like.
When
somebody
you
know,
people
don't
come
to
the
issue
tracker
to
say,
like
oh
great
feature
that
you
just
released.
Thank
you
so
much
for
that.
Right,
like
they
come
to
sort
of
voice,
their
opinions
about
changes
or
other
things
they'd
like
to
see.
So
I
wouldn't
necessarily
expect
to
see
that
on
a
behavior
change.
B
B
I
don't
know
I
they
also
don't
they
don't
have
like
a
strong
number
of
upvotes,
but
I
think
if
that
is
your
workflow
right
like
which
it
is
a
git
lab,
then
this
is
like
a
net
benefit
positive
change,
and
if
it's
not
your
workflow,
it's
not
a
positive
change.
I
think
the
question
sort
of
is.
B
If
our
opinion
is
like,
if
the
long-term
opinion
that
we
might
take
is
that
assignees
and
authors
should
merge
and
eventually
become,
maybe
the
same
thing
then
like
this
sort
of
puts
us
on
a
path
to
that,
in
a
way
that,
like
that's,
sort
of
the
behavior
we're
driving
it's
not
complete
and
it
it
feels
not
great
to
people.
B
For
the
people
who
that
is
the
workflow
in
the
workflow
we
want
they
get
a
net
benefit
of
automatically
being
assigned.
They
don't
have
to
assign
themselves
for
people
who
don't
like
it.
They
have
to
unassign
themselves.
B
D
D
Yourself
was
like
an
additive
thing
that
you
did.
I
mean
you're
already
filling
out
the
mr
form
it
said
assigned
to
me.
You
clicked
that
if
you,
if
it's
automatically
assigned
to
you,
you
create
it
and
you're
like
oh,
I
need
to
understand
myself.
Then
it's
kind
of
it's
not
a
big
deal,
but
it's
in
the
log
then
like
it
just
looks
a
little
more
like
was
that
an
accident?
Okay,
I
also
don't
know
if
unassigning
yourself
is
as
one
clicky
as
assign
yourself
is,
so
it's
a
tiny
bit
more
annoying
it
just.
D
D
I
think
it
would
be
really
worthwhile
to
explore
that.
It's
something
that's
been
bugging
me
and
I
never
really
thought
about
it.
Why
do
we
have
this
thing?
It's
not
the
same
as
issues
where
you
create
an
issue,
and
then
someone
might
pick
it
up.
That
doesn't
really
happen.
It's
not
the
same
for
merge
requests,
and
yet
we
share
the
exact
same.
D
Maybe
that's
just
an
additional
section
like
final
reviewer
gets
their
own
little
area
icon
or
something
like
that.
But
now
I'm
just
blabbering
on.
I
don't
really
love
the
feature.
I'm
pro
revert
in
a
not
very
passionate
way.
So
if
you
want
to
continue
to
monitor
it,
that's
fine,
but
I'm
still
more
like
more
on
the
revert
side
of
things.
A
A
Your
your
code,
they
can
all
be
reviewers,
whoever
merges
it
that's
fluid
and
is
going
to
be
variant
within
teams
depending
you
know,
I
think
possibly
that's
enough
and
we
shouldn't
over
complicate
it
or
force
people
into
one
particular
designation
here
that
it
appears
it
doesn't
work
for
everyone.
I
think
just
having
reviewers
and
an
author
might
might
work
pretty
well,
but
that's
something
we
should
validate.
C
Yeah,
I
think
it's
interesting
that
I'm
reading
through
the
feedback-
and
it
seems
like
a
lot
of
the
use
cases-
were
relying
on
complete
an
assignment,
so
no
one
like
neither
they
didn't,
have
an
assignee
or
a
reviewer,
and
someone
even
says
that
the
lack
of
a
reviewer
is
hard
to
parse
from
the
mr
list,
so
they
they
understand
that
we're
pushing
people
to
use
the
reviewer
field
for
reviewers
and
okay.
So,
let's,
let's
have
the
assignee
with
the
author,
but
still
it's
hard
to
parse.
C
If
you're
looking
at
mr
list
to
understand,
is
this
an
assignee
or
is
this
person
a
reviewer,
because
we
don't
have
a
column
for
that?
You
have
to
hover
the
avatar
to
understand
if
it's
an
assignee
or
a
reviewer,
which
makes
it
harder
for
them
to
adapt
their
existing
workflow
to
use
this
auto
assignment
and
there's
also
feedback
of
it
seems
like
teams
that
don't
use
the
reviewer
field
until
today,
at
least.
C
That's
how
I
interpret
it
is
that
they
have
only
relied
on
the
assignee
field
for
everything
and
the
reviewer
field,
even
though
they
have
it,
they
don't
use
it.
That's
that's
how
I'm
seeing
it.
Maybe
I'm
misinterpreting
what
they're
saying
I
think,
with
the
amount
of
negative
feedback
that
we've
gotten
and
I
agree
with
you
kai.
C
But
I
think
that
the
amount
of
discussion
that
this
is
creating
and
backlash
compared
to
the
benefit
that
this
change
created
doesn't
seem.
You
know,
equal
doesn't
seem
like
it's
balanced
and
to
annabelle's
point
previously
and
even
today
like
if
no
one
is
assigned
to
a
merge
request,
you
can
easily
click
on
one
button
and
it
assigns
to
you
the
opposite.
C
One-Click
removal
is
not
there,
so
we
haven't
made
it
as
easy
to
remove
yourself
as
it
was
to
add
yourself
and
because
it's
not
a
dramatic
change
to
revert
it
yeah.
Now
I'm
a
bit
more
inclined
to
to
revert
it
and
because
it
seems
that
there
are
a
lot
of
different
things
at
play
here,
even
as
I
was
saying
in
the
beginning
tracking
your
workload,
it
seems
like
some
use
cases.
C
People
are
also
don't
want
to
assign
them
to
themselves
when
they're
not
working
on
it,
so
they're
using
the
assignee
field
as
a
like,
as
attention
requests
more
or
less.
You
know
so
like
I
am
assigned
myself
and
if
I'm
not
working
on
it
and
I
assign
who
you
know
so
I
think
there
are
maybe
too
many
interesting
things
at
play
here
that
we
weren't
aware
when
we
did
the
seemingly
small
change.
C
Yeah
thanks.
B
Yeah,
the
next
one
hesitant
to
bring
another
topic
up,
but
the
next
one
is
group
assignment
and
merge
requests
just
doesn't
bring
all
the
fire
today.
This
this
continues
to
come
up.
I
think
we
it
fueled
discussions.
B
More,
I
know
it
fueled
discussions
more
when
we,
what
I
will
continue
to
say
is
fixed
quick
actions
to
not
support
a
group
object
because
group
objects
don't
exist
in
reviewers,
and
so
it
sort
of
logically
makes
sense
that
you
can't
do
a
group
in
a
quick
action.
B
But
I
think
fundamentally
like
the
the
problem
everyone
is
solving
here
is
like
finding
the
right
reviewer
in
merge
requests
right.
That's
that's
why
everyone's
assigning
a
group,
everyone
assigns
10
people
because
they're,
like
someone
will
review.
This
is
sort
of
all
of
the
feedback.
I
think
boils
down
to
that,
like
that's
how
their
review
flow
works,
their
review
flows
work
that,
like
I
work
on
a
team
of
six
people
and
someone
from
the
team
of
six
people
will
review
it,
and
so
we
just
assign
everyone
as
a
reviewer.
B
I
think
we
have
long
built
code
review
as
a
modeled.
I
think
strongly
after
gitlab
values
around
like
dris
is
how
I
would
potentially
phrase
that
that,
like
we
think
that,
like
an
individual,
ultimately
has
to
be
the
one
that
reviews
and
merges
it,
and
then
you
know
we
have
concerns
about.
You
know
delay
in
people
responding
or
there's
a
fancy
term
for
like
bystander
effect,
which
is
another
piece
here
right
like
if
I
assign
six
people-
and
I
just
assume
someone
else
will
do
it.
B
You
know
it
doesn't
balance,
workloads
and
other
things,
and
so
we've
largely
done
this
around
individuals,
and
so
I
think
two
things
is
one
like.
I
know
we're
starting
suggested.
Reviewers
work
that
sort
of
aims
to
solve
this
problem.
I
think
this
is
a
problem
that
we
need
to
keep
like
focused
on,
I
guess
long
term.
B
Do
we
want
to
continue
to
take
the
stance
of
like
individuals
over
groups
like
a
suggested?
Reviewer
is
always
going
to
be
like
an
individual
based
feature
or
a
suggested.
Reviewer
is
one
day
going
to
say
like
assign
this
group
right.
I
think
that's
sort
of
the
question
and
if
that's
a
path
that
we
think
we
might
go
down
then
like,
maybe
we
need
to
somehow
think
about
what
that
user
experience
looks
like.
I
think,
if
it's
not
then,
like
you
know,
I'm
fine
to
continue
saying,
like
individuals,
not
groups,
here's
what
we're
doing.
C
Yeah,
I
was
gonna,
say
I
still
have
to
read
through
because
that
there's
that
huge
thread
in
slack
with
39
replies
of
people
talking
about
this-
and
so
I
haven't
had
a
chance
to
look
at
it.
Is
there
a
valid
so
first
question?
Is
it
to
assign
to
a
group
and
have
like
the
name
of
the
group
as
the
one
that
is
assigned
or
to
assign
to
the
people
that
are
members
of
a
group.
B
When
it
worked
before
when
you
could
use
a
quick
action
before
to
specify
a
group,
what
would
happen
is
if
I
specified
code
review,
backend
and
there's
six
members
of
that
group.
It
would
have
the
quick
action
would
have
made
all
six
of
those
members
a
reviewer.
It
wouldn't
have
made
the
group
a
review
or
it
would
have
made
all
six
of
those
people
a
reviewer
of
the
merch
request.
C
Have
you
seen
a
a
valid
use
case
for
that?
I
know
it's
not
aligned
with
what
we
think
would
be
ideal,
but
I'm
just
thinking
you
know
in
some
in
some
teams
they
might
be
workflows
where
a
certain.
C
B
B
It's
because
that's
how
their
team
works,
they
assign
it
to
the
group
so
that
someone
can
pick
it
up
and
then
internally,
the
team
sort
of
has
their
own
culture
and
way
to
do
that,
and
it's
not
that
the
tools
that
they
use
necessarily
does
that
if
that
makes
sense
so
like,
ultimately,
you
know
everyone
where
they
said:
they've
assigned
six
people,
all
of
them
have
come
back
and
said
yeah.
Well,
somebody
picks
it
up
on
the
team
and
you
ask
like
how
and
they're
like.
Oh
the
team,
just
like
it
just
happens.
B
B
So
yeah,
from
my
perspective,
like
what
that
confirms,
is
that
there's
still
an
individual
that
ultimately
has
to
do
something,
which
is,
I
think,
how
we've
looked
at
the
tool
right.
I
think
what
I
think
it's
a
symptom
of
is
like
it's
hard
for
people
to
know
who
do
I
ask
to
review
my
merch
request
and
the
answer
was
I
assign
10
people
and
hope
it
works.
D
But
it
was
also
like.
I
need
this
to
be
reviewed
by
the
back
end
team
and
we
don't
have
those
kind
of
groups
like
that
right
now.
I
think
in
some
design
I
saw
I
don't
know
if
I
made
it
actually
but
like
it
would
be
cool
if
code
owners
would
do
this
right.
If
you
changed
a
file
in
here,
it
would
tell
you
you
need
back
end
reviewers
and
it
would
show
up
in
the
sidebar
like
here's,
what
you
need
to
review.
It
wouldn't
suggest
a
person.
D
It
would
suggest
the
role
which
is
kind
of
what
this
sounds
like
this
person
is
assigning
a
group
of
back-end
engineers
because
it
needs
to
be
rude
by
the
back-end
developer
team
and
on
small
teams.
That
sounds
totally
feasible.
In
fact,
I
know
someone
who
worked
at
a
small
company
and
they
did
just
that.
They
never
signed
anything.
It
was
just
an
open
list
and
whoever
looked
at
the
open
list
would
just
assign
themselves
they
didn't,
assign
a
group,
but
they
didn't
assign
anyone.
B
Yeah,
I
would
agree,
I
think,
like
in
a
small
team,
it's
potentially
feasible.
I
think
code
owners,
if
I
were
to
like
logically
think
through
gitlab
and
how
we
would
want
to
drive
usage
and
people
into
features.
I
think
code
owners
is
the
way
we
would
want
you
to
do
this
right
like
we
would
want
you
to
have
your
entire
repo
sectioned
out
in
code
owners,
whether
or
not
you
used
approvals
and
then
everything
that
came
up
in
review.
B
We
would
want
to
suggest
someone
out
of
your
code
owners
list
to
like
review
that
file.
I
think
that's
like.
Ultimately,
that
is
where
we
would
want
to
be
with
like
how
we
do
reviewers.
The
question
I
guess
is
like
even
at
that
end
state,
if
you've
specified
a
group
in
code
owners
which
is
totally
possible,
you
can
say
code
review.
Backend
owns
this
group
of
files.
B
Where
we'd
say,
here's
two
people
from
code
review,
backend
that
you
know
only
have
one
mr
open
and
aren't
busy
in
get
lab
status
and
all
these
other
things
that,
like
continue
to
make
like
gitlab
the
tool
sort
of
the
the
way
we
drive
that
capacity,
because
if
you
look
at
danger,
which
would
be
like
the
you
know,
like
our
reviewer
roulette,
that
is
built
inside
of
danger,
it
is
very
much
individual
based,
despite
knowing
all
of
these
other
things
about
you,
it
knows
that
you're,
a
member
of
front-end
back-end
maintainer,
not
a
maintainer.
B
It
knows
when
you're
out
of
office.
It
knows
when
you're,
not
it
knows
sort
of
all
of
those
things,
and
I
think
that
would
be
like
in
my
mind.
That's
the
ultimate
experience
to
drive
like
somehow
in
product
right
like
how
do
we
drive
it?
So
you
get
the
five
people
or,
however
many
you
need
to
actually
get
that
merge.
Request,
merge,
not
pinging
huge
groups
of
teams.
D
D
B
I
am
of
the
opinion
that
we
should
we
should
build
a
tool
with
opinions
and
and
workflows
and
if
we
cover
80
percent,
I
think
I
think
most
people
say
that,
because
there's
not
an
experience
that
you
know
works
correctly
or
is
understood
right,
it
doesn't
exist
today.
Most
tools
do
not
assign
people
to
do
this,
and
so
it
doesn't
exist
or
work.
Today,
I
think
if
we
build
a
good
product
that
does
what
we
want
it
to
do.
B
B
If
we
want
to
make
100
of
people
happy,
I'm
gonna
have
a
settings
page
that
looks
10
times
worse
than
our
settings.
Page
already
looks
like.
If
you
look
at
like
you
know,
we
can
go
back
to
automatic
assignment
the
option.
People
literally
what
people
were
asking
for
is
like
give
us
options,
give
us
more
configuration
to
make
the
product
more
complicated,
so
we
can
do
whatever
we
want
and
in
my
opinion
I
think,
that's
that's
not
the
right
answer.
I
think
we
should.
B
We
should
have
a
viewpoint
in
a
workflow
that
we
we
want,
and
if,
if
that
doesn't
work,
then
we
can
optimize.
We
can
go
figure
out
how
to
like
what
changes
we
can
make
when
we
get
there
but,
like
I
don't
know
that
we
need
to
be
making
concessions
along
the
way.
B
Let
me
think
how
to
do
this.
There
are
there.
Are
there
were
some
bugs
in
the
existing
implementation
that
were
not
ideal,
so
part
of
it?
Was
that
and
then
part
of
it
was
like?
Well,
we
don't
necessarily
need
to
solve
for
that.
If
we
just
make
that
not
possible.
D
B
As
quick
action,
because
our
autocompletes
automatically
show
group
names
so
the
way
quick
actions
work,
is
it
part
like
it's
the
the
quick
action
and
then
it
completes
whatever's
after
it?
As
soon
as
you
put
an
at
symbol,
groups
show
up
because
the
autocomplete
actions
for
like
helping
you
complete
groups
or
individual
names
can
populate
groups.
A
I
mean
I
sort
of
like
that
idea
of
you
being
able
to
quickly
assign
a
group,
and
it
just
breaks
it
out
into
the
individuals
it
seems
like
it
doesn't
necessarily
go
against.
Our
idea
of
like
an
individual,
is
responsible
for
this
at
the
end
of
the
day,
but
it
does
allow
people
to
quickly
assign
a
group
of
people
to
an
mr,
which
is
what
they
want
to
do
and
just
be
able
to
do
it
faster.
C
Like
group
of
directors
that
you
want
to
regularly
assign
to
specific
issues
or
merge
requests,
you
have
to
always
add
them
manually.
C
I
want
to
assign
to
a
group
of
people,
because
someone
like
one
or
two
inside
of
that
group
will
eventually
pick
it
up
and
kai.
You
mentioned.
You
know,
building
a
great
experience
for
that,
and
you
know
we're
not
there
yet
and
I
think
in
to
the
customer's
eyes
and
users
eyes.
It
just
feels
much
a
much
smaller
step
instead
of
having
suggested
reviewers
and
other
smart
functionality.
Just
hey,
let
us
assign
to
a
group
which,
unfortunately,
for
all
purposes
it
we
inadvertently
had
that
functionality.
C
C
You
know
problems
with
you
know,
abuse
and,
for
example,
if
you
want
to
assign
a
group
that
not
all
people
have
access
to
the
project,
for
example,
but
I
think
we
can.
C
I
think
gabe
mentioned
that
in
the
in
the
issue,
the
internal
discussion
issue,
in
that
we
have
this
inconsistency
right
now,
where
you
can
bulk
notify
people
like
a
group
like
all
at
all
or
something
like
that,
but
you
can't
assign
them
and
it
kind
of
generates
the
same
frustration.
C
I
guess
so
I
don't
know
I'm
I'm
inclined
to
allowing
a
bulk
group
assignment,
but
yeah
it's
not
an
easy
issue.
I
I
do
think
that
we
should
encourage
individual
assignments
by
building
that
great
experience,
but
until
we
get
there
yeah.
I
just
think
that
people
are
trying
to
get
things
done
and
it
just
seems
like
an
easy
thing
to
do
and
we're
saying
hey,
no
we're
not
going
to
do
that.
C
We're
actually
going
to
build
this
amazing
experience
that
automatically
gives
you
someone,
but
we're
not
there
yet
yeah
I
have
to
to
run,
but
you
can
stick
around
and
I'll
read
the
agenda
later.
B
Okay
thanks
peter
yeah,
I
think
the
only
other
thought
would
be.
This
is
a
like
a
difference
of
parity
between
quick
actions
in
the
ui,
and
so
I
guess
the
question
is
is
like:
do
we
need
to
follow
up?
Are
we
comfortable
leaving
sort
of
a
difference
of
user
experience
between
quick
actions
and
the
ui,
because
the
ui
doesn't
has
does
not
and
has
not
ever
supported
that
behavior.
D
B
Cool,
I
have
to
run
thanks
everyone
we
could
skip,
for,
we
can
leave
it
as
read-only
or
I
can
the
tldrs
we're
going
to
turn
off
attention
requests
and
then
look
at
what
our
options
are.
B
B
We
just
didn't,
I
didn't
think
about
it,
necessarily
it
wasn't
intentional
to
like
not
record
it.
I
was
just
specifying
that
there
was
not
a
recording
in
case
someone
was
asking
for
it.
Sorry,
okay,.
D
Yeah
I
created
that
issue
to
follow
up
on
some
of
the
beautifying
ui
things
from
last
milestone
that
are
code
of
view
specific
well.
Most
of
them
are
quote
review
specific
because
that's
basically
all
we
did.
There
are
some
things
that
need
to
be
addressed
before
we
before
we
do
anything
really.
The
feature
flag
is
still
on
for
the
sidebar
and
both
the
marketing
website
and
the
gitlab
repo.
But
we
can't
do
anything
we
can't.
We
can't
do
anything
really
until
we
continue
to
iterate
on
it.
D
So
I
have
this
fixed
header
thing
and
a
sticky
header
kind
of
like
issues
finished
the
design
for
that,
and
I
just
pinged
phil
and
it
sounds
like
he
might
have
some
time
this
milestone
to
work
on
it.
The
other
thing
I
really
love
nice
to
have
is
to
feature
flag
on
fixing
the
top
nav.
I
talked
with
austin
about
that
a
little
bit
again.
This
would
be.
This
would
be
under
a
separate
feature
flag
because
I'm
adding
another
fixed
element.
D
I
realize
this
is
only
in
merge,
requests,
austin
and
sid
and
other
people,
I
think,
have
been
working
on
general
navigation
updates
and
one
of
the
things
that
I'm
curious
specifically,
is
why
we
still
have
that
top
now
fixed
and
what
purpose
it's
really
having
across
the
whole
experience.
It
turns
out
that
the
most
clicked
item
is
the
tenuki
or
the
home
button,
and
the
second
click
button,
I
think,
is
the
user
preferences.
D
I
don't
know
what
the
hierarchy
is
for
the
other
items,
but
I'm
not
sure
that
they
need
to
be
available
across
all
pages,
and
I
know
this
isn't
code
to
be
specific,
but
it'd
be
super
cool.
If
we
could
maybe
work
on
that,
this
milestone,
put
it
behind
a
future
flag
and
see
what
the
feedback
is.
B
You
mean
the
when
you
say
top
nav,
just
like,
like
the
one
that
contains
like
the
search
box
and
to
do's
and
issues
and
merge
request
drop
down.
Yeah,
okay,
yeah.
B
D
D
So
yeah,
first
of
all,
not
everyone
uses
to
do
so.
We've
already
got
like
the
split
between
people
who
use
notifications
and
then
they
were
upset
about
the
notification
control
being
moved
from
the
sidebar
to
the
drop
down,
and
we
have
people
who
use
to
do
is
who
don't
care
about
notifications,
but
if
we
unfix
the
top
nav,
maybe
you'll
be
angry.
I'm
assuming
we're
going
to
get
some
negative
feedback,
but
I'd
like
to
know
why,
like
knowing
that
you
use
to
do's
to
navigate,
is
super
valuable.
D
D
B
D
So
yeah,
I
know
I'm
going
to
add
another
fixed
thing
and-
and
I
just
didn't-
want
to
keep
on
adding
fixed
elements
again,
I
know
that's
that's
merger
quest
specific
and
now
I'm
making
a
global
change
for
my
own
personal
bias,
but
just
want
to
see
what
the
feedback
is
and
then
we
can
quickly
turn
it
off.
If
people
really
hate
it
and
figure
out
like
why
they
hate
it.
D
What
do
we
need
to
do,
and
also
I
I
came
up
with
this
one
merge
request,
which
was
not
it
kind
of
it
was
silly.
I'm
gonna
link
it
in
an
agenda,
but
I
made
the
the
to-do's
and
all
those
things
in
the
left
sidebar
that
would
be
present
across
all
pages
so
that
when
you
scrolled
you'd
still
have
your
to-do
smart
requests
and
issues
available.
D
I
don't
think
that
was
a
very
good
design
either,
but
it
was
there.
D
So
my
my
point
to
this
was
phil
said
he
already
has
some
time
to
work
on
the
sticking
the
sticky
header,
which
I
think
is
the
most
important
piece
to
to
getting
this
moving
along,
because
it'll
include
the
to
do
button
and
the
the
branch
which
has
come
up
a
hundred
times,
that'll
be
across
all
tabs
and
and
then
I
didn't
know
if,
if
anyone
else
like,
if
stanislav
or
thomas
had
some
time
this
milestone,
if
they
wanted
to
pick
up
anything,
if
I
should
add
that
to
tomorrow's
agenda
or
if
I
should
just
stick
it
in
the
slack
channel.
B
Yeah,
I
don't
know
about
the
unfix
at
the
top.
Now
I
think
the
sticky
header
one
just
tag
andre
and
I
in
the
issue,
and
we
can
figure
out
how
to
label
and
put
it
in
the
milestone.
I
think
the
unfixing
of
the
top
nav.