►
From YouTube: 2022-10-26 Code Review Weekly 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).
A
Cool
welcome
to
the
code
review
weekly
sync.
The
first
item
is
async.
I
will
just
say:
it's
async
has
been
is
in
a
different
time
zone,
but
if
you
have
thoughts
and
feedback
here,
it'd
be
great
to
take
a
look
and
sort
of
provide
comments.
I
guess
we'll
sort
of
discuss
in
the
agenda
and
Ben
can
come
back
and
and
go
back
and
forth.
So
maybe
we'll
keep
an
eye
on
it,
but
yeah
I
I'll,
just
I
looked
at
it.
A
It's
a
list
of
like
support
tickets,
lots
of
like
approval
related
things,
so
it's
good
to
sort
of
get
feedback
on
where
people
are
running
into
challenges
with
this
overlaps
a
lot
with
source
code
but
like
actually
setting
up
and
configuring
and
the
approval
rules
more
so
than
consuming,
but
like
that
I
think,
as
organizations
have
gotten
more
complicated,
that
has
gotten
more
complicated
in
our
product.
So
if
there
are
things
we
can
do
to
make
that
more
apparent
when
it
gets
to
the
merge
request,
then
maybe
there's
opportunities
there.
B
Alrighty,
thank
you
so
much
so
yeah
I
was
just
wondering.
I
know
that
we
had
the
Q3
objective
during
the
ux
research.
With
these
the
last
point
in
the
agenda
through
the
structure
demo
that
I'm
really
curious
about,
but
I'm
wondering.
If
have
we
started
discussion
for
the
opr
quarter,
four
and
I
totally
missed
it
and
I
like
I'm
growing
old,
so
I
want
to
just
make
sure
that
I
didn't
miss
anything.
And
if
not,
should
we
started.
A
For
Q4
okrs
I,
actually
don't
know
I
need
to
go
look
product
like
it
feels
like
the
guidance
is
changing
and
shifting
again
around
quad
okrs
in
like
terms
of
like.
Maybe
we
don't
actually
have
to
have
them,
but
I
don't
know
because,
like
we
used
to
do
issues
on
the
products
like
inside,
basically
we
see
issues
on
the
product
side.
We're
like.
A
They
would
sort
of
lay
out
things
and
then
we
would
get
asked
to
do.
Roll-Ups
and
I.
Don't
know
if
we're
not
doing
that
this
time,
because
ux
has
also
moved
under
product
and
so
like.
Maybe
the
okrs
are
a
little
more
align
there
or,
if
we're
not
doing
them,
it
sounds
like
we're
also
moving
away
from
like
the
tool
we
used,
and
so
we
might
not
want
to
track
them
on
as
low
a
level
as
we
used
to
anymore,
and
so
that
is
maybe
another
contributing
factor.
A
I
will
try
and
ask
and
get
clarity
if
we
need
to
do
them
as
a
group
I.
Also
I,
guess
my
question
would
be:
do
you
think
they're
valuable
to
us
as
a
group
like
the
ones
we've
done?
Have
it
typically
been
things
we
would
do
anyway,
I
guess
I'm
curious,
like?
Are
they
valuable
in
terms
of
like?
Do
you
think
it
helps
us
stay
on
track
for
like
Q4
like
if
we
put
them
together
or
is
it
just
like
we're
gonna
do
those
things
anyway,.
B
It
helps
saying
no
to
distractions,
there's
a
couple
of
cases
in
the
past
where
some
pick
him
up
and
but
we
cannot
focus
on
that,
because
we're
focused
on
shipping
some
bands
I'm
not
sure
whether
we'll
be
able
to
do
that.
I'm,
not
sure
if
we
wouldn't
be
able
to
do
that.
If
we
didn't
have
Europe
yards
as
well
saying
that
anyway,
if
anything,
the
benefit
is
to
have
the
entire
team
focus
on
the
same
direction.
B
If
that
helps,
but
we
also
had
cases
where
it
ended
up
being
only
a
portion
of
working
on
that
engineering.
So
I,
don't
know.
My
question
is
more
like
we
have
a
couple
of
topics
lying
around
and
I
was
wondering
if
we
should
at
least
have
a
discussion
to
see
if
we
want
to
pick
something
up
as
a
group
objective,
because
what
I'm
going
to
get
from
the
engineering
side
are
going
to
be
like
Global
Engineering
it
goals.
B
But,
for
example,
we
started
working
on
real
time
for
the
merger
Quest
widget
or
we
are
starting
to
look
on
the
back
end.
Do
we
want
to
continue
rolling
out
real
time
step
to
the
local
review
part?
Are
we
focusing
all
efforts
on
the
restructuring
of
BMR
yeah,
that's
kind
of
like
what
I
was
curious
about
I,
wouldn't
I,
wasn't
necessarily
questioning
the
quad
objective.
More
like
a
joint
direction
would
be
useful
to
have
yeah.
B
A
B
That
sort
of
thing
so
I
expect
do
not
have
a
lot
of
time
to
do
major
work,
but
like
only
structuring,
I'm
sorry
full
rollout
of
the
restructuring
of
the
murder
case,
for
example,
I,
don't
think,
would
be
fitting
for
one
full
quarter.
You
can
start
to
roll
it
out,
but
I
wouldn't
expect
the
whole
thing
to
be
done
depending
on
the
scope,
so
yeah.
A
Is
engineering
still
doing
okrs
down
to
like
group
level
like
engineering
manager
level
like
do?
Are
you
being
like?
You
still
have
okrs
that
you
have
to
do.
B
A
B
We
do
okay,
but
that's
again,
that's
that's
well,
not
Global,
but
let
it
trickle-down
engineering,
okay,
ours,
I,
I,
I
from
my
perspective,
I
think
it's
always
fun
for
the
team
to
have
one
objective
that
drives
everybody
in
code
review
in
One,
Direction,
so
I
might
be
positively
biased
towards
and
the
part
okay
are
at
least
one
but
yeah.
If
we
don't
have
one,
we
shouldn't
force
it.
It's
just.
B
It
could
be
interesting
to
think
about
at
least
that
possibility.
Do
we
expect
the
roll
out
the
merger
Quest
widget
real
time
this
quarter
or
we
should.
We
just
consider
that
to
roll
over
to
the
next
one?
B
Okay,
then,
that's
probably
the
answer
be
natural.
Okay
would
be
that
under
the
back
integral
if
you
wanted
I'm
so
happy
with
part
of
the
integration
and
we're
talking
about
real
time
of
the
merge
request.
Widget
there's
actually
a
lot
of
stuff
in
there
right.
There's
a
couple
of
issues
to
tackle
in
a
couple
of
scenarios:
okay,.
B
All
right,
I
think
for
now
I
think
we
we'll
have
a
look.
Okay,
so
I'm
gonna
start
an
issue
all
right,
bye.
A
I'll
start
an
issue
like
we
do
every
quarter
and
put
the
ideas
in
it
and
then,
if
nothing
else,
we'll
just
at
least
build
out
issues
that
we
say
like
are:
okay,
ours,
I
I
linked
the
product
issue
where
product
is
not
using
I
guess
they
haven't
determined.
Yet
we're
going
to
be
using
the
tool.
A
My
understanding
and
now,
like
I,
don't
know,
never
mind
I'm,
not
even
gonna
get
into
it.
We
talk
about
it
afterwards.
B
B
C
Yeah
I
think
I.
What
Andre
is
saying
about
is
having
a
joint
Direction
and
objective
is
good,
whether
or
not
it's
an
okr
I'm
kind
of
indifferent,
but
knowing
what
the
the
main
goals
are
and
what
we're
shooting
for
I
think
that's
that's
important.
However,
we
capture
that.
B
B
If
anybody
has
anything
to
say
about
that,
okay,
so
sort
of
an
FYI
just
make
sure
that
everybody's.
On
the
aware
of
this,
we
had
a
proposal
recently
to
do
a
performance
Roundtable
for
code
review,
stuff
and
the
ideas
they
have
an
open
discussion,
but
with
some
certain
goals.
B
B
Now
this
there's
an
alignment
in
terms
of
time
with
the
restructuring
Mr.
If
we
are
to
restructure
the
UI
of
VMR,
we
make
piggyback
on
that
and
roll
out
some
performance
improvements
with
it.
But
for
that
we
need
to
have
conversations
about
it
in
an
engineering
side
and
from
a
full
stack
perspective.
So
the
idea
there
is
to
have
backing
in
front
and
Mingle,
but
it's
not
just
for
that.
If
you
have
ideas
about
it
feel
free
to
join.
B
Even
if
you're
not
an
engineer,
it's
everybody
can
contribute
for
a
reason
so
or
you
just
want
to
sit
on
the
sidelines
and
see
how
Engineers
talk.
So
it's
fun.
No,
but
seriously
it
would
be
great
to
have
anyone
who's
interested
in
the
topic.
There's
an
issue
to
start
conversations,
there's
always
going
to
be
an
issue
every
week
to
kind
of
capture,
synchronous
discussions
ahead
of
the
meeting
and
then
on
the
meeting
we'll
actually
have
more
informed
discussions.
B
I
mean
someone
alternating
time
slots
so
right
now
it's
more
convenient
for
some
part
of
the
world
and
the
next
week
will
be
more
convenient
for
APAC
for
yeah,
so
yeah.
Does
anybody
has
any
questions
about
this
initiative
or
comments.
B
I
wouldn't
distinguish,
but
I
mean
if
you
have
ideas
to
pursue
with
perceived
performance,
throw
them
in
there,
because,
if
they're
not
obvious
yet
to
us,
we
might
put
that
in
the
pipeline
for
working
on
it.
So
we're
looking
for
a
meaningful
like
rethinking
of
the
application
or
the
way
we
generate
dips.
The
way
we
handle
this
or
that,
but
any
ideas
about
performance
will
are
welcome
then
so
Pursuit
performance
are
also
part
of
it.
I'll
say
yes,
so
all
of
that
to
say
performance
is
included.
Yeah.
Oh
thanks.
B
Yeah
I
will
I
will
drop
a
note
on
across
engineering.
The
idea
is
to
get
the
ball
rolling
and
I.
Think
over
time
will
actually
be
sniping.
Certain
people
like
hey,
you
want
to
join
the
next
session.
We
have
might
have
something
for
you
to
Weighing
on
yeah
I'll
share
it
with
some
people
cool
Matt.
Have
you
heard?
Have
you
talked
about
this
with
your
engineers?
Are
they
aware
of
it?
Are
they
coming?
Do
you
have
any
any
thoughts.
D
C
Everyone
again
and
make
sure
her
okay,
they
know
it's
tomorrow,
I
think
I.
D
C
B
There's
already
a
thread
there
that
I
started
yesterday:
yeah
I
see
you
just
ping
them
she's
gonna
be
actually
a
discussion
between
Beckett
and
president,
so
you're
beautiful
to
have
at
least
one
of
the
members
of
the
team.
All
right,
I
hope
see
you
there
tomorrow,
Kai.
You
have
to
explain.
A
Yeah
I
thought
maybe
it'd
be
easier
to
talk
about
this,
like
sync,
first
and
then
go
from
there.
Matt
did
a
put
together
an
issue.
Thank
you,
Matt
for,
say
durations.
It
was
something
that
I
had
talked
to
Matt
about,
and
maybe
Andre
we've
talked
about
it
too.
Just
sort
of
some
milestones-
and
this
is
I-
will
preface
this.
This
is
not
like
a
knock
on
engineering
and
what's
being
delivered
and
not
how
I'm
approaching
this.
This
is
a
like.
A
Are
we
planning
too
ambitiously
and
like
not
getting
through
things?
What
we
think
which,
like
sort
of
interrupts
our
ability
to
like
understand
how
we're
gonna
deliver,
not
you
know
like
if,
if
the
reality
is,
is
that
like
we're
sort
of
overstating
capacity
and
under
delivering
on
our
consistent
basis
and
that
sort
of
like
a
conclusion
that
I
would
draw,
maybe
that
were
like
trying
to
to
plan
too
much
and
we
never
get
to
it
so
like
we
should
scale
that
back.
A
So
we
really
know
what
we're
what
we
can
deliver,
but
so
Matt
put
this
together
and
I,
like
my
questions,
were
sort
of
initially
on
the
charts.
Is
it
back
ended,
front
end
and
some
I
don't
know?
If
you
want
to
answer
the
questions
Matt
and
then
we
can
sure.
C
Yeah
so
right,
I
just
use
so
there's
a
Periscope
or
size
sense,
dashboard
that
is
super
slow,
so
I,
basically
just
chugged
through
a
bunch
of
old
milestones
to
to
pull
out
the
data.
But
it
is
both
it's
combined.
It's
for
the
whole
team,
though
it
is
possible
to
pull
out
the
the
back
and
in
front
of
which
is
your
next
question.
C
So
I
can
do
a
create
a
little
dashboard
that
does
that
parts
of
that
official
dashboard
have
have
it
at
least
not
broken
down,
but
listed
out
by
packing
and
front
end.
So
the
data
is
there.
We
just
have
to
report
on
it
in
a
better
way,
so
yeah
I,
you
started
that,
but
it
needs
a
little
bit
of
work.
It's
still
going
to
be
super
slow,
but
even
if
I,
maybe
if
I
just
filter
it
by
code
review
it'll
be
better.
A
Yeah
I
think
my
one
of
my
like,
like
the
following
of
that
is
like:
should
we
break
it
out
like
I?
Don't
because
we
plan
sort
of
independently
like
does
it
make
sense
to
look
at
this
and
again?
This
is
not
like
I.
Don't
want
to
penalize
a
team
so
I'm
trying
to
like
avoid
making
it
seem
blamey
like
do.
We
want
to
break
it
out
by
backing
in
front
end
to
know
like
which
like
if
it
is
a
specific
side
or
if
it's
like
General
like?
A
B
From
my
perspective,
I
think
we're
all
grown-ups,
and
we
know
that
this
is
from
the
perspective
like
I,
want
to
see.
I
see
that,
for
example,
on
1410
we
have
a
spike
of
little
issues
and
a
white,
so
it
seems
like
we
went
overboard
with
scheduling
there
and
the
yellow
line
does
come
down
on
both
issue
pound
and
weight.
So
that's
the
kind
of
lessons
we're
going
to
take
out
of
that.
B
It's
a
big
team,
so
individual
contributions
are
diluted
anyway,
but
I
think
it
will
be
more
useful
since
we
have
two
managers,
we're
splitting
it
by
manager,
not
necessarily
by
icing
so
I.
Think
it's
more
than
useful
to
have
that.
It's
a
doable
mat
when
yeah
I
would
say
yes.
C
Yeah
and
I
think
sir
I
I
totally
agree
and
I
also
I,
think
different
teams
might
have
different
responsibilities
outside
of
just
deliverables.
So
it
might
be
interesting
to
to
see
that
too
I
don't
know
if,
if
that
would
show
up
at
all,
but
I
think
it
would
make
sense
to
since
we
plan
slightly
differently
and
have
different
different
requirements
and
things,
for
example,
like
I,
don't
know,
1410.
C
That
time
frame
was
that
when
we
were
doing
like
security
allocation
stuff
or
some
engineering
allocation
back
then,
which
probably
impacted
back
end
a
little
bit
more
I
can't
really
remember
all
of
it.
C
A
Yeah,
okay
and
then
it's
like
my.
A
Like
what
do
we
do?
I
guess
is
really
what
this
last
question
is
like.
What
do
we
do
with
the
data,
because,
right
now,
if
I
look
at
this
and
I
I
think
I'm
interpreting
this
correctly,
it
looks
like
we
on
average,
somewhere,
like
60-ish
percent-
maybe
not
even
quite
60,
but,
like
average
of
averages
is
like
60
or
below,
like
somewhere
between
fifty
and
sixty
percent
of
the
time,
or
that's
how
much
we
deliver
of
what
we
said
we
were
going
to
deliver
each
Milestone.
B
Sorry
I
just
wanted
to
add
that
from
me,
looking
at
the
sale
ratio
like
I,
don't
think
the
goal
is
to
have
100
like
we
still
like.
B
There's
always
that
thing
about
for
delivering
100
without
being
ambitious
enough,
so
yeah
we're
all
a
little
more
than
that,
so
yeah
I
think
it's
a
matter
of
like
analyzing
the
cases
where
we
did
have
a
better
rate,
a
ratio
and
go
look
at
the
type
of
assignments
that
we
did
on
that
in
that
month,
because
I,
for
example,
know
that
certain
mountains,
I
did
I
signed
a
lot
more
smaller
regions
of
bugs,
like
example,
this
issue
this
Milestone.
B
We
have
more
such
issues
signed
than
usual
like
will
that
be
we're
yielding
a
better
sedu
Ratio
or
not.
So
it's
a
good
method
for
us
managers
to
see
going
for
yukai
to
see
whether
the
assignments
we
did
the
way
we
did
the
planning
this
month.
Was
it
a
successful
one
or
not?
Do
the
two
our
team's
way
of
working?
It's
more
like
bad
lessons
for
the
future,
because
try
to
do
more
of
trying
to
think.
A
Okay,
yeah
I,
think
that
makes
sense,
I
think
like
from
my
perspective,
what
I
want
to
know
is
like
yeah,
that's
an
interesting
like
types
of
issues
like
are:
do
we?
If
we
schedule
you
know
70
bugs,
do
we
not
get
through
them,
because
we
always
underestimate
them
or
if
we
like
you
know,
is
it
something
like
that
that,
like
maybe
if
there
is
a
balance
of
the
type
of
work
that
can
help
improve
it,
yeah
I,
agree:
I,
don't
want
to
be
at
100.
A
A
We
tend
to
have
like
long-running
work
streams
of
things
right
like
we
did
merge
ability
and
right
now
we're
working
on
a
lot
of
real
time
and
there's
15
issues
in
one
of
those
epics
to
sort
of
get
to
a
delivery,
and
so
it's
very
hard
to
communicate
when
we
will
get
to
that
delivery
because
we
say
oh
yeah,
we
can
do
two
or
three
of
these
every
milestone,
but
the
reality
is
is
like
that's
not
always
the
case
or
sometimes
something
slipped
or
something
else
slips
and
so
I
want
I,
don't
need
a
hundred
percent
confidence,
but
I
need
better
than
like
a
50
confidence.
A
I
guess
in
like
terms
of
being
able
to
say
that,
like
I
think
we
could
deliver
this
over
this
period
of
time
or
like
how
do
I
evaluate
you
know.
For
me,
it's
like
how
do
we
evaluate
relative
effort
right
if
we're
balancing
real
time
and
restructuring
and
both
of
those
like
have
let's
say
both
had
15
issues,
but
one
was
a
weight
of
10
or
well.
A
I
think
this
is
sort
of
I'd
say
from
my
perspective,
that's
what
I'm
trying
to
figure
out
from
this
is
like.
How
do
we?
How
do
we
get
a
higher
confidence
interval
of
like
yeah?
We,
we
know
how
much
work
we
have
to
do
for
this,
and
we
expect
it
to
take
this
amount
of
time
and
we're,
like
you
know,
80
sure.
A
Well,
I
appreciate
all
the
the
work
you've
done
already
Matt
and
yeah.
We
can.
We
can
keep
discussing
in
the
issue,
but
I
thought
it'd
be
good
to
like
sort
of
start.
This
conversation
here
and
then
figure
out
what
we
can
do
and
Annabelle
we
left
your
time.
D
Great
yeah
I
was
just
I
was
just
going
to
show
what
we're
kind
of
working
on
just
in
case
people
haven't
seen
and
I
was.
You
know,
working
to
make
this
more
realistic,
with
an
actual
merge
request
and
I
I've
gotten
it
into
a
pretty
good
place
where
I
now
know
how
things
are
going
to
work,
and
you
know
it
does
work
which
is
exciting.
So,
let's
see
if
I
know
how
to
share
a
screen.
D
Okay,
that's
not
it!
Okay.
What
I
did
was
I
took
this
merge
request,
which
was
a
collaboration
between
mostly
Phil
and
like
five
different
developers,
so
it
went
through
many
rounds
of
reviews.
It's
got.
A
billion
comments
label
changes
all
this
mess,
so
the
idea
was
okay.
What's
the
worst
one
we
can
fix,
or
we
can.
D
You
know,
put
into
our
new
framework
and
you
can
see
here
how
many
different
times
different
system
nodes
are
added,
and
it's
all
these
urging
on
useless
pieces
of
information
that
we're
hoping
to
kind
of
streamline
a
little
bit.
So
the
Prototype
has
been
two
parts
because
figma
hates
me.
This
is
what
we've
already
seen:
here's
the
activity.
D
This
is
the
one
that
doesn't
work
so
all
of
that
all
that
entire
list
of
things
has
been
condensed
into
just
this
section,
which
is
just
by
default,
show
comments
and
review,
requests
and
reviews,
and
then
everything
would
be
a
link
so
from
here.
If
you
wanted
to
look
at
the
comments-
and
this
would
be
all
the
comments
you
can
see
the
filter
here-
this
is
every
comment
that
you'd
see
if
you
haven't
selected
one.
It's
a
bit
like
slack
where
you
pick
one
from
the
left
and
it'll
show
up
on
the
right.
D
If
you
haven't
selected
one
we
might
show
you
know
just
a
big
version
of
the
comment,
input
which
you
can
also
access
from
here
and
if
you
wanted
to
filter
it
by
one
person,
you
can
do
that
either
using
that
filter
or
you
see
that
kushal
was
the
final
reviewer.
So
if
you
click
on
five
comments,
you'll
see
all
the
comments
that
he's
added
to
that
merge,
request
and
they're
grouped.
So
this
was
his
review
and
then
you
can
click
through
each
part
of
the
review.
D
D
I
guess
that's
kind
of
it
actually,
but
everything
all
the
questions
that
were
brought
up
in
the
initial
round
of
testing
with
our
really
basic
prototype.
That
was
kind
of
a
perfect
scenario.
It
does
work
pretty
well
right
here,
so
I
think
that
we're
ready
to
use
this
prototype
if
I
need
to
you
know,
fix
some
things,
but
we're
we're
ready
to
kind
of
do
more
research
on
it.
I
think
internal
and
external
will
need
to
do,
but
it
does
work.
So
that's
exciting!
D
That's
I
was
just
kind
of
letting
everyone
know
this
is
kind
of
what
we're
potentially
going
for,
and
this
also
in
a
way
kind
of
takes
some
inspiration
from
the
review
rounds
that
we've
been
looking
at,
in
that
it
is
grouped.
So
if
you
look
at
this
review,
it's
grouped
into
one
kind
of
piece:
it
doesn't
look
like
it,
we
could.
We
can
fix
the
styling
and
everything,
but
I
wanted
to
be
able
to
group
things
by
either
comments
or
reviews.
So
it
kind
of
takes
things
from
there.
D
B
A
My
question
for
like
Andre
and
Matt
prior
to
like
sending
this
through,
like
a
round
of
research
validation.
Do
you
think
it
would
make
sense
for,
like
Andre
and
Matt,
to
have
an
engineer?
Look
at
this
and
sort
of
say
like
I,
want
to
say
like
engineer,
everything
is
possible,
so,
like
engineering
is
fine,
they
can
be
on
the
hook
for
all
of
it,
but
also
like
look
at
it
and
sort
of
go.
A
A
Don't
know
like
I
want
to
know
like
how
do
we
bridge
that
Gap
to
make
sure
that,
like
we
don't
end
up
with
something
that
like
we
feel
really
good
about
from
a
design
and
usability
perspective,
and
then
engineering
looks
at
it
and
goes
like
I,
don't
even
like
couldn't
even
begin
to
Fathom
how
we
would
like
put
this
together.
I,
don't
know
if
this
is
the
right
time
or
not
so
sort
of
a.
A
B
My
my
question
goes
to
Annabelle,
so
the
idea
that
we
had
was
to
have
studies
live
available
for
discussion
and,
if
I'm
not
mistaken,
Gary
did
any
of
this
was
run
by
them.
Did
they
were
they
involved
in
the
discussion
that
led
to
this
or
not
much,
participation.
D
Not
that
I
know
of
they
might
have
seen
the
Prototype
at
some
point
when
Pedro
was
commenting.
While
he
was
doing
all
this,
he
was
posting
videos
of
the
initial
prototype.
He
came
up
with
kind
of
in
the
Skeleton
version.
He
was
posting
it
a
lot,
so
I
don't
know
if
they
saw
it
or
not.
Yeah.
B
That's
fine,
so
that'll
be
my
answer.
Okay
is
the
thing
those
folks
take
a
look
at
this
and
spell
our
way
in
any
kind
of
feasibility.
I
mean
if
we
just
think
about
what
we
have
today,
like
it's
repurposing
the
UI,
to
show
what,
like
the
filtering,
for
example,
like
that's
the
UI
filter
that
we
can
build,
and
this
would.
This
would
be
a
new
perspective
on
the
data
that
we
already
have.
I,
don't
see
anything.
B
B
Sure
that
liberates
a
little
bit
so
then
okay
create
a
different
app
to
work
with
what
we
want,
which
it's
a
nice
segue
for
my
point
in
the
agenda.
First
slash
me:
I
got
all
giddy
when
I
saw
the
fields
going
per
author,
that's
really
when
we're
you
want
to
go
in
and
look
at
the
review
that
simply
just
sent
that's
exactly
what
I
went
with
so
kudos
for
your
for
your
foot
for
this
exercise.
Really.
B
We
appreciate
that
second
part
is
that
there's
an
ongoing
discussion
or
an
actual
proposal
of
a
different
architecture,
front-end
applications
at
gitlab
that
Tim
puts
forward
and
it's
being
discussed-
and
this
could
be
an
opportunity
to
kind
of
like
try
out
to
build
a
prototype
of
that
application.
Using
this
as
a
guidance
to
see
how
how
fast
it
will
be,
how
how
efficient
that
sort
of
UI
would
be
if
we
build
it
that
way
so,.
B
So
yeah,
that's
my
word.
My
mind
is:
if
you
look
at
the
the
links
that
that
I
put
there
I
think
links
in
there
in
the
screenshots
and
stuff,
so
it's
still
being
discussed
how
we're
going
to
roll
it
out.
It's
a
lot
about
our
architecture-wise,
how
we're
going
to
be
doing
this,
but
to
have
caching
on
the
client
and
all
that
stuff.
B
So
there's
a
bunch
of
technical
stuff,
but
this
UI
proposal
could
help
us
understand
what
we're
building
all
of
that
technological
jargon
for
if
that
makes
sense,
it's
good.
B
D
A
Thanks
yeah
I
appreciate
that
that
covers
off
my
concern.
I
just
want
to
make
sure
that
we're
giving
which
I
wrote
like
engineering
options
to
see
it
early
versus
feeling,
like
they're
surprised
later
on.
B
Yeah
and
if
you
want
to
preemptively,
try
something
put
something
together
to
try
something
out
before
all
of
that
architecture
is
put
in
place,
that's
possible
too.
It's
just
that.
It
helps
us
more
or
less
know
how
to
build
these,
whether
it's
an
iteration
of
the
current
application,
whether
it's
a
new
application
on
the
side,
I,
want
to
try
something
new.
All
of
that
plays
into
this
rolling
something
like
this
out
yeah,
because
here's.