►
From YouTube: Discussion: Tech Debt work for Source Code FE 13.4
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
Right
welcome
everyone
today
we're
having
the
call
to
discuss
the
initiatives
for
tech,
debt
in
1304,
1305
and
eventually
136.
Basically,
this
this
quarter
and
the
idea
for
us
on
this
call
is
to
discuss
the
already
pre-discussed
concepts
and
theories
and
ideas
so
that
we
can
prioritize
them
and
see
which
ones
we
should
tackle
first
prioritizing
impact,
but
also
predictability.
A
You
want
to
make
sure
that
we
go
in
them
with
some
sort
of
game
plan
so
that
we're
not
tackling
something
that
it's
uncertain
and
it
will
slip
slip,
slip
slip
and
not
have
any
impact
on
this
quarter.
So
keep
this
in
mind,
impact
and
predictability.
While
we're
discussing
these
things
so
going
into
the
document,
you
have
the
first
point:
justin
you
wanna
get
started.
B
A
True
true,
that
kind
of
that
kind
of
is
connected
to
one
of
the
issues
we
have
so
I'm
going
to
share
my
screen,
so
we
can
have
a
discussion
on
video
sure
right.
So
one
of
the
issues
we
created
out
of
our
discussion
is
this:
one
decreased,
dom
note
dom
node
and
component
count
of
murdoch's
diff
zap,
and
this
is
something
that
we've
been
discussing
for
a
while.
We've
had
already
taken
some
stabs.
A
I
know
that
phil
took
a
stab
at
this
once
justin
you
opened
another,
mr
to
refactor
the
roads
and
everything
we
never
got
to
the
bottom
of
it
all,
but
it
might
be
worth
us
doing
that.
The
one
thing
that
I
put
here
is
tearing
down.
While
updating
ui
is
kind
of
what
you
were
just
talking
about.
It
feels
like
whatever
we
can
do
to
make
that
process
less
costly.
A
It
will
benefit
that
particular
part.
So
the
idea
here
was
just
to
go
in
there,
especially
about
the
div
file
rows.
So
I
said
remember
that
any
reduction
on
diff
file
rows
compound
immensely
across
the
page.
So
if
you
remove
say
like
10
of
the
of
components
or
just
weight
on
a
particular
row,
we
have
thousands
of
rows
throughout
the
page
that
will
compound
the
impact
of
this.
So
my
my
my
idea
was
first
for
this
particular
effort
for
us
to
focus
on
the
file
rows
themselves.
What
do
you
think
about
it?
A
B
A
B
C
A
Okay,
so
I
feel
like
that
could
definitely
be
beneficial
in
the
overall,
because
I
the
thing
that
you
mentioned
here
about
the
common
bubble
hovers.
We
already
know
that
that's
from
the
moment,
we
can
start
putting
that
on
css
first
in
some
some
way,
just
the
hiding
and
displaying
you
can
probably
get
far
better
performance
on
that,
but
for
us
to
be
able
to
do
that,
we
have
to
effect
to
this
to
be
more
lean.
So
that's
so
you
talked
about
the
markup,
the
table
markup,
which
is
definitely
important.
B
B
So
in
particular
I
pick
on
a
pick
on
the
diff
table
row:
components
a
lot
because
there's
a
lot
of
duplication
in
there
and
they
in
particular
they
use
a
component
called
diff
table
cell
twice.
It's
put
in
there
twice
and
I
think
if
all
we
did
for
a
first
iteration
was
extract.
What
diff
table
cell
is
doing
and
put
it
directly
into
diff
table
rows
that
reduces.
B
Yeah,
I
was
doing
a
bunch
of
performance
profiling
this
month
and
the
number
one
thing
that
it
waits
on
is
actually
just
garbage
collection
when
it's
done
in
knitting,
a
component
being
created
so
yeah
like
the
really
it
was.
It
was
amazing,
like
the
garbage
collection,
is
like
70
of
the
the
time,
the
blocking
time
in
the
script.
B
B
The
diff,
the
diff
table
cell
component,
so
it's
the,
I
believe
it's
diff
under
bar
table
under
marcel
dot
view
stop
using
that
component
and
use
the
things
it's
doing
directly.
Inside
of
the
two
diff
table
row
view
components,
it'll
create
a
lot
of
duplicate
code,
but
I
think
it's
better
than
the
performance
that
we're
having
right
now,
plus
there's
a
handful
of
logic
inside
of
div
table
cell,
where
it
has
to
try
and
maintain
its
own
context,
like,
I
believe,
there's
a
couple
of
properties.
B
B
B
Of
context,
local
state
maintenance
that
is
unnecessary
because
it's
unaware
of
its
context
as
a
child
component
should
be,
but
I
really
don't
think
this
should
be
a
child
component.
I
understand
the
idea
of
trying
to
move
some
of
this
out
of
just
having
one
giant
component,
but
this
is
that
example.
I've
mentioned
before,
where
I
believe
this
section
of
the
code
was
built
correctly,
as
per
like
the
view,
docs
would
state
but
hurts
us
just
because
we
have
such
large
data
dumps
from
time
to
time.
B
So
I
think
personally,
if
it
was
me,
I
would
elevate
this
code
up
into
the
table,
row,
components
and
stop
using
table
cell,
and
then
that
would
be
my
first
step.
I
think
we'll
get
a
performance
gain
just
from
not
bootstrapping
two
components
per
row
anymore
and
it'll
set
us
up
for
less
refactoring
down
the
line
to
pull
this
into
a
non
table.
Markup.
C
A
B
B
Yeah
like
for,
for
example,
the
things
like
just
like
that
this
is
context
line
and
whatnot.
I
think
we
could
bake
a
lot
of
that
into
the
array
of
data
themselves
so
that
it's
now
a
property
on
the
line
object
itself.
So
you're,
not
just
trying
to
say.
Oh
this
type,
you
could
actually
turn
its
context,
light
line
into
a
boolean
flag
on
the
line
type
itself.
So
now
you
have
a
property
available
and
you
don't
need
to
have
this
computed
value
anymore.
A
So
that
brings
us
to
another
conversation
we've
been
having,
which
is
the
following:
oops
a
lot
of
the
calculations
we
do.
We
do
them
every
time
we
need
them
like
these
ones
is
context
line
is
metal
line,
and
then
we
have
to
keep
on
doing
them
through.
You
know,
computer
properties
or
getters
to
get
the
actual
data
in
the
shape
we
want.
A
C
B
B
B
A
Yeah,
because
that
makes
sense
to
me
one
one
thing
that
I
we
have
to
be
vigilant
of
is
even
though
it's
a
computer
property
vue
does
catch
the
computer
properties
right.
So
even
though
it
might
be
accessed
a
bunch
of
times
we
do
cache
it
might
I'm
not
sure
if
by
if
we
are
moving
things
in
and
out
of
the
dom,
if
every
time
we
put
them
on
the
dom,
if,
if
he
reuses
the
catch
from
before,
I'm,
not
I'm
not
fully
aware
of
that.
A
A
After
because
as
much
as
we
have
problems
with
performance,
I
think
most
of
the
things
we're
detecting
is,
while
the
user
interacts
with
the
application
rather
than
bootstrapping
it,
which
trapping.
It
has
been
very
optimized
to
a
point
that
we're
already
batch
diffing
that
the
server
has
some
optimistic
optimizations
to
do
as
well,
but
by
putting
stuff
on
the
state,
I
don't
think
that's
where
it
hurts
us
it's
putting
things
on
the
page,
removing
things
from
the
page.
That
sort
of
thing
is
what
hurts
us
right.
B
A
A
I
feel
from
the
feedback
I
got
from
you
all
is
that
it's
not
very
easy
to
work
with
how
we
identify
a
line
on
a
file
on
a
version
right
and
there's
probably
some
context
that
I'm
missing.
So
this
one
here
is
kind
of
to
be
able
to
identify,
but
that
plays
into
that
out
of
the
other
issue,
which
is
improving
the
way
the
discussions
are
attached
to
diffs
and
forget
the
across
versions.
I
think
that
part
is
is
on
the
attached
to
diff
lines.
A
I
think
I
removed
it
from
the
top
yeah
from
the
title
so
and
this
effort
here
is
the
thing
we
talked
about
where
right
now,
the
way
we
structured
it
is
that
the
highlighted
diff
lines,
which
is
we
all
know,
is
the
inline.
We
could
also
rename
them
by
the
way.
If
you
want
in
the
middle
of
all
this,
but
we.
B
C
C
B
A
C
C
B
On
a
scale
of
one
to
all
of
the
pain,
all
of
the
pain
seriously,
it's
a
it's
a
problem
like
that
different
data
structure.
There
is
a
ton
of
logical
branches
that
are
unnecessary
because
maybe
in
this
context
it's
in
the
left
property
or
not
that
that
happens
a
lot.
We
have
a
lot
of
code
that
handles
just
whether
or
not
it
has
a
left
and
right
value
or
not.
A
Yeah,
I'm
already
thinking
about
how
we
can
do
this
refactor
without
disturbing
the
stability
of
the
application
and
I'm
thinking
can
we
derive
if
we
just
get.
If
we
work
based
off
the
highlighted
diff
lines
or
the
inline
diff
lines,
we
could
try
to
generate
the
parallel
left
and
right
structure
from
that
information
right.
Theoretically,
that's
possible,
yep,
okay,
because
what
I'm
thinking
is
we
create.
A
So,
basically
making
two
changes
in
one
one
would
be
the
inline
and
parallel
split
would
be
merged
into
one
representation
and
then
also
we
change
the
way
we
do
things.
So
basically,
this
would
be
the
fork
in
the
state
for
the
refactor,
where
we
put
all
the
new
stuff
in
this
fork
by
the
time
that
we're
done,
we
can
just
drop
the
old
ones.
How
does
this
sound
dangerous.
A
A
B
A
C
B
B
Oh
man,
it
was
brilliant
I'll,
never
be
able
to
repeat
that,
so
I
was
just
saying
that
so,
okay,
so
it
sounds
like
we
should
treat
the
inline
version
as
the
single
source
of
truth
and
so
you're
saying
we
data
transformed
somewhere
to
manipulate
that
into
parallels
into
the
the
parallel
structure,
and
I
was
basically
saying
I
I
disagree
with
that.
I
don't
think
we
should
change
the
state
at
all.
I
think
we
should
change
the
way.
The
front
end
is
interacting
with
the
state
so.
A
B
A
C
A
A
A
Are
you
a
removal,
or
are
you
in
addition,
and
doing
that
as
we're
rendering
the
component
that's
going
to
move
all
the
logic
to
the
edges
of
the
component
tree,
but
we
could
have
closer
to
what
we
have
right
now,
where
we
have
the
inline
in
the
state
and
through
getters,
you
have
a
getter
that
will
give
you
the
structure
prepared
for
pella
parallel.
Would
that
put
us
in
the
same
place.
B
There
might
be
a
third
option
here,
so
maybe
if
we
attack
the
getting
rid
of
the
table
structure
first
in
my
in
the
proof
of
concept
I
built
where
I
was
using
a
css
grid
instead
of
tables,
I
did
all
of
that
using,
I
believe,
the
inline
version
of
the
data-
and
I
got
you
know
not
counting
for
edge
cases.
It
was
done.
I
got
it
working,
so
maybe
that's
the
approach.
Is
we
back
off
using
tables
at
all
so
that
it's
simply
a
css
change
between
how
it
looks?
B
A
A
A
A
A
Can
we,
in
the
module
of
the
diffs
have
an
id
here
where
the
discussions
would
just
be
an
array
of
ids,
and
then
we
would
reference
the
that
that
id
would
allow
us
to
fetch
the
right
discussion
from
the
notes,
module,
which
is
basically
just
going
into
the
notes,
module
discussions
and
instead
of
being
an
array,
it
would
be
a
hash
where
the
key
of
the
hash
is
the
id
of
the
discussion
and
we
just
grab
it.
We
don't
even
have
to
filter
it
out
from
the
array.
C
So
we
can-
and
I'm
pretty
sure
we
used
to
like
that.
Okay,
the
problem
is
the
more
discussions
you
have,
the
more
getters
it's
going
to
end
up,
adding
onto
each
line
and
every
time
the
discussion's
already
changed
together
then
links
for
every
single
one
and
then
filter
through
it
to
get
the
one
that
you
need,
and
it
was
the
same
for
the
web
id
as
well.
C
So
always
so,
if
the
guess
of
references,
whatever
you
references,
it
had
to
get
it.
So
if
the
getter
references
the
array
every
time,
you
then
access
that
getting
it
then
adds
another
getter
onto
the
array.
So
if
you
access
that
gif
at
once,
you
have
won't
get
the
access
situation,
two
guesses
and
so
on.
C
The
way
we
do
it
right
now
or
the
way
view
does
it
makes
sense.
So
if
you
have
do
we
have
the
discussions
array
in
the
notes
if
we
have
to
get
in
the
diffs
whenever
the
discussions
changes
any
object
in
that
array
changes
well,
because
it
should
update
and
tell
the
component
whatever
is
accessed.
That
gets
its
update.
So
right.
B
I
know
thomas
had
an
idea
of
creating
a
a
dictionary
object
for
the
discussions
keyed
by
discussion.
Id
is
where
he
was
going
with
this.
So
I'm
wondering
if
it's
not
as
much
of
a
performance
problem
if,
because
it's
no
longer
an
array
that
it
has
to
iterate
over
and
update
the
whole
thing,
if
it,
if
it's
a
dictionary
object
and
the
computed
value
inside
of
the
row,
is
just
grabbing
that
particular
property
off
the
object.
B
No
he's
talking
about
if
you
transform
the
array
into
into
a
dictionary
object
where
each
discussion
is
keyed
by
its
discussion
id,
and
then
you
have
just
the
array
of
discussion
ids
on
the
diff,
the
diff
line,
so
that
when
you
go
when
the
diff
line
is
rendered,
it's
doing
a
just
a
straight
lookup
off
of
the
object
itself
based
on
the
id.
So
it's
not
doing
any
filter
or
find
or
anything
like
that,
it's
just
here's
a
computed
value.
B
C
B
A
Yeah
because
that
that
idea
of
having
the
map
state
directly
to
it,
I
feel
like
that,
would
help
the
rendering.
So
when
we're
iterating
over
the
the
list,
we
will
be
iterating
over
the
ids
and
then
we'd
be
passing
as
a
prop
to
the
component,
or
something
would
be
something
that
we
get
from
the
states.
A
So
we
would
have
another
state
and
would
just
pass
the
id
to
that
and
we'll
get
the
actual
object
that
will
be
passed
as
a
prop
to
the
component
right.
You
wouldn't
be
through
getters,
but
there
might
be
situations
where
we
do
need
to
get
the
discussions
on
the
getters
world
and
that
will
itself
generate
more
getters
because
they
will
still
also
gonna
have
to
be
we're
still.
Gonna
have
to
work
with
discussions
on
the
getters
at
a
certain
point.
So
it's
not
just
about
the
rendering.
A
B
A
B
They
do
so
and
that's
another
good
point
to
bring
up
it
might
be
that
accessing
the
notes
store
directly
from
diffs
is
a
bad
idea.
There's
enough
differences
in
what
those
things
are
trying
to
do
that,
maybe
it's
a
mistake,
maybe
the
maybe
discs
should
have
its
own
notes,
property
inside
of
its
own
store
that
is
derived
from
or
hydrated
from
the
note
store,
I
don't
know.
I
ran
into
that
a
lot
with
the
the
change
line
issue
for
this
whole
milestone.
B
A
A
We
solve
that
by
making
those
initial
data
more
complete
in
the
first
place.
By
making
the
notes
on
the
discussion,
tab
be
more
complete
to
all
the
information
we
need
to
provide
different
the
features
we
want
sure
you
have
a
point,
though
there
might
be
maybe
some
hurdles
there,
but
in
terms
of
to
the
discussion
that
we're
having
earlier
just
now
about
the
feature
flag,
some
of
these
things
will
have
to
be
shipped
right
away
for
the
sake
of
our
sanity.
A
We
just
have
to
test
them
very
extensively,
not
just
manually
but
also
automatically,
but
the
other
thing
if
we
say
if
it's
an
exploration
like
this
one,
like
we
don't
know
until
we
get
started,
I
think
the
safest
would
be
to
have
one
flag
for
every
refactor
approach
and
every
time
we
want
to
move
it
out
of
the
of
them
of
the
testing
experience.
We
move
them
out
from
us
from
behind
the
feature
flag.
A
B
A
No,
no,
no,
actually,
I
wouldn't
have
a
separating
individual
flag.
I
would
just
have
one
for
all
one
for
all,
so
that
that
fly
would
always
be
off,
except
in
our
environment,
in
our
projects.
Okay,
I
wouldn't
see
us
turning
that
default
to
true
it's
just
a
safeguard
for
us
to
be
able
to
ship
code
into
all
the
way
into
production.
If
we
need
to.
A
But
the
thing
is,
we
would
always
have
one
master
flag
for
the
refactor
experiments,
but
by
default
we
would
ship
things
in
front
of
users
without
any
feature
flag
by
default.
The
because
some
of
these
changes
we
will
have
to
be
confident
enough
to
ship
them
without
putting
them
behind
a
feature
flag.
Others
like
this
one
about
the
discussions,
the
hash
is
it
feasible?
Is
it
not
feasible?
Those
are
explorations
and
we
would
put
those
behind
the
feature
flag,
but
by
default
no
feature
flag.
B
A
It
does
come
with
a
responsibility,
because
what
we
saw
on
the
initial
refactor
to
view,
which
was
done
in
a
completely
different
way,
was
that
we
had
no
safety
net
and
when
things
were
shipped,
we
kind
of
lost
the
previous
way
of
doing
things.
So
we
have
to
be
very
responsible
about
shipping
these
things,
but
it's
like
a
band-aid.
We
have
to
rip
them
out
quickly,
otherwise
we'll
just
be
forever
trying
to
rip
this
slowly
so,
but
we
have
to
be.
A
A
B
A
A
A
A
Okay,
I
guess
we'll
start
seeing
it's
important
for
ever
for
every
time
we
start
picking
something
up
to
keep
in
mind
about
checking
the
tests
that
are
recovered
and,
if
not
adding
that's
going
to
be
a
constant
good.
It's
a
good
call-out
right,
we're
running
out
of
time.
So
the
one
thing
that
I
wanted
to
see.
I
feel,
like
this
discussion
thing,
it's
a
worthwhile
exploration
to
see
if
it's
worthwhile,
but
then
sure,
if
we
do
a
refactor,
we
render
it
from
the
united
states.
A
A
A
A
B
B
A
Let
me
let
me
let
me
clarify
what
I'm
what
I'm
thinking
of
writing
here
is
basically
exploration
of
moving
the
discussion
objects
out
of
the
lines
and
just
keeping
the
ids
and
being
able
to
reference
that
list
of
discussions
elsewhere.
So
that's
kind
of
like
assessing
whether
this
is
a
good
or
a
bad
idea.
Sure
that's
the
first
part.
The
flattening
of
the
state
is
probably
another
effort
that
we
have
to
talk
yet
about
what
parts
should
be
flattened
this
could
so
this
could
be
one
of
the
flattened.
A
B
B
So
when
we
do
the
the
discussions
flattening
thing,
for
example,
if
we
still
have
inline
and
parallel
data
structures,
then
we
need
to
write
quote
code
to
handle
both
of
those
right.
So
that's
that's
two
sets
of
that's
that's
twice
the
work
every
single
time.
So
I
think
if
we
can
extract
ourselves
from
inline
versus
parallel
data
earlier,
it
will
speed
up
everything
that
comes
behind
it.
A
B
B
B
The
two
efforts,
I
think
so
yeah
yeah
we
should
be
able
to
because
the
promoting
the
the
div
table
cell
can
be
done
one
side
at
a
time.
So,
for
example,
we
could
have
a
first
round
that
stops
using
div
table
cell
on
the
inline
version
and
because
that
data
structure
isn't
changing
at
all,
it
would
free
up
somebody
else
to
work
on
the
rendering
of
parallel
off
of
diff
lines
for
the
parallel
version
and
both
of
those
could
work
in
tandem.
A
C
A
A
A
Is
it
more
performance
probably
hard
to
measure
this?
I
guess,
but
if
we
do
have
a
a
branch
with
this,
we
can
always
do
some
profiling
on
the
the
master
and
the
branch
and
compare
the
timings
on
it.
And
if
we
have
a
very
large
mr,
it
should
be
substantial
difference,
because
if
it's
not,
then
we
could
potentially
consider
it.
A
So
this
won't
this
won't
this
effort
kind
of
demand
us
to
do
this
of
being
able
to
identify
things.
Actually,
we
just
need
to
identify
the
discussion,
but
the
discussion
already
has
an
id,
so
that's
kind
of
not
the
same
thing.
It's
a
different
comp,
a
different
concept
yeah,
because
this
one
is
about
the
line.
The
way
we
identify
the
lines
right
should
we?
What
are
your
thoughts
here
about
this
effort
of
putting
things
more
easily
to
identify
across
all
this
situations?.
B
A
That's
for
the
end
point.
The
question
here
is:
if
you
think
about
discussions,
they
are
attached
to
diff
lines
using
a
code
right
sure
and
that
code
is
fallible,
because
there
are
some
situations
that
it
doesn't
hold
up
and
but
it
does,
it
is
implemented
at
this
point
on
the
back
end
and
on
the
front
and
using
that
position
so
to
speak.
C
A
C
C
C
A
B
A
C
A
C
I
mean
it's
worked
since
it
was
just
waving
before
we
used
them
here.
It
was
this
way
within
jquery.
So
right
and
the
thing
is
you
change
out
to
a
uid
or
whatever
you're
still
into
in
the
same
situation
you
just
instead
of
accessing
the
line
code,
your
access
is
id
instead,
but
we're
already
upgrading
to
my
code.
A
C
A
Well,
I
would,
I
would
tell
you
that,
there's
a
couple
of
ideas
that
we
have
in
the
future
to
be
able
to,
for
example,
comment
on
the
commit
message
and
some
of
the
ideas
was
to
create
a
virtual
file
in
there.
But
then
we
wouldn't
have
a
line
code
for
that
it's
kind
of
like
it
goes
a
little
bit
beyond
the
sim
link.
But
at
this
particular
point
in
time
everything
else
is
working.
A
So,
while
we're
refactoring
these
things,
if
you
can
make
these
easier
to
work
with
the
better,
but
but
here's
the
thing
we
might
by
doing
some
of
the
other
stuff,
we
might
have
the
benefits
of
having
it
simpler
to
work
with,
rather
than
just
changing
the
way
we
id
things
the
actual
id,
and
that's
not
to
say
that
the
line
code
itself
can't
be
improved.
I
mean
it
might.
C
C
C
A
So
there's
yeah
there's
multiple
things
that
can
attach
to
a
line.
Let's
start
there,
you
can
have
a
note,
a
discussion.
You
can
have
a
batch
comment
right,
a
draft
comment
and
you
can
have
you
can
start
having
stuff
like
the
things
we
have
somewhere
like
the
line
coverage
and
more
and
more
things
are
going
to
want
to
attach
to
lines.
A
So
if
you-
okay,
let's
see
let's
talk
about
this,
imagine
one
day
you
want
to
expand
the
multiline
comments
to
inline
multiline
comments.
You'll
be
want
to
be
able
to
select
a
piece
of
text
and
then
start
commenting
from
the
first
word
from
the
fifth
word
of
the
line
to
the
third
word
of
the
third
line
below
you
know
what
I
mean
like
select
text
actually
a
span,
we
won't
be
able
to
do
it
with
this
way
we
would
have
to.
A
A
If
anything,
we
could
have
a
line
code
with
three
three
numbers,
which
would
be
the
start
so
yeah.
You
always
have
the
position.
Sorry
give
me
a
second,
you
always
have
the
position
and
then
the
line
range.
So
basically
here,
instead
of
just
a
line
code
with
two
numbers,
if
you
had
a
line
code
with
a
third
number,
that
would
be
the
initial
column.
So
we
can
always
expand
the
line
code
later
yeah,
I'm
kind
of.
C
A
Yeah
yeah
I
at
this
point
the
thing
is,
it
might
make
sense
to
do
this
in
some
scenario,
but
right
now,
the
the
case
I
don't
see,
is
as
strong
as
others
just
because
it
is
hard
to
handle.
I
guess
at
certain
point,
but
it
has
been
working
since
before
the
refactor,
and
it
is
so
much
some
of
the
cases
that
are
not
supported.
A
A
C
A
A
C
B
C
C
C
B
Sure,
but
there's
also,
but
there's
also,
I
want
to
say
when
you
have
deep
objects,
that
the
payoff
is
way
less.
You
know,
unless
you
do
some
sort
of
deep
object.
Freeze,
it's
not
it's
not
as
easy
as
just
saying:
object-free
is
in
the
top
level
and
calling
it
a
day
because
right
I
did.
I
did
that
it
was
very
easy
to
implement
and
it
didn't.
C
A
C
C
A
A
What
else
we
had
here
on
the
list?
Simplified
default
header
component
yeah,
it
does
seem
like
the
the
one
we
were
talking
about.
The
div
table
cell
is
a
little
bit
more
urgent
in
terms
of
the
impact
we
want
to
have,
but
I
would
probably
put
this
on
the
third-ish
iteration
as
well
to
take
a
look.
Well,
what
do
you?
What
do
you
think.
B
Sure
I
know
that
it
honestly,
I
don't
know
if
it's
as
important
as
it
used
to
be.
We've
done
a
lot
of
optimizations
between
that
first
discussion
and
now,
and
so
when
I
was
doing
the
performance
testing
most
recently,
the
diff
headers
weren't
nearly
the
problem
they
used
to
be.
But
having
said
all
that,
there's.
C
A
So
that
you
so
that
you're
fully
aware
why
this
is
on
our
list
is
because
we've
changed
this
file
a
lot
right.
Oh
that's,
right,
yeah!
That
was.
That
was
the
reason
why
it
was
highlighted,
but
I
from
our
discussion
it
feels
like
we
have
other
components
that
would
be
more
in
fact
impactful.
So
I'm
totally
okay
and
putting
this
on
hold
so
right
now,
I'm
just
gonna
be
putting
this
as
not
urgent.
For
now,
that's
good
okay
in
the
decreased,
dom
node
count.
A
That
sort
of
thing
is
already
kind
of
into
this
whole
thing.
I'm
gonna
put
the
rewrite
comment
bubble
to
css
into
three
so
that
we
can
split
this
out
from
the
that
second
effort
to
not
have
too
many
things
happen
at
the
same
time
sure
looking
at
this
list.
It
does
feel
that
if
you
accomplish
this
over
the
next
three
milestones,
we
would
be
in
a
better
position
right.
That's
at
least
given
there's
a
lot
of
uncertainty.
There
there's
a
lot
of
in
terms
of
like
we're
touching
central
parts.
A
That
would
be
touching,
there's
also
the
other,
the
other
problem
which
is
alongside
with
these
changes.
We
will
be
doing
feature,
work,
we'll
be
doing
bug,
fixing
and
shipping
features
and
stuff.
So
it's
important
to
keep
a
constant
communication
across
everyone
and
I'll
try
to
do
my
best
when
scheduling
the
issues
to
identify
overlaps
and
stuff
and
try
to
put
you
as
a
heads
up
and
give
you
a
heads
up
and
stuff,
but
I
feel
like
we
already
have
good
enough
planning.
A
A
A
Having
said
that,
on
those
18
points,
there's
also
your
work
fill
for
the
emergicals
widget,
so
I
am
mindful
that
it
might
be
a
little
bit
tight.
So
the
one
thing
that
we
have
to
keep
in
mind
is
predictability.
Here
is
key
like
we
talked
in
the
beginning,
so
once
we
tackle
these
things,
it's
important
to
be
very.
A
A
A
A
Capacity
for
these
things,
where
I
won't
put
any
product
on
each
any
of
the
person
who
are
working
on
these
things,
but
we'll
see
any
any
more
thoughts,
but
before
we
go
okay,
I
will
I'll
transform
these
into
issues.
Whether
I
use
these
issues
that
I
already
created
and
change
them
or
not
I'll,
look
into
it,
but
I'll
put
this
into
13
4
and
then
these
ones
will
come
on
the
next
milestones,
but
these
ones
at
least
I'll
I'll
document
them
and
assign
them.
A
A
B
A
Right,
thank
you
so
much.
This
has
been
exhilarating
to
do
and
scary
at
the
same
time,
but
I
think
we'll
definitely
be
in
a
better
position
than
where
we
are
right
now
and
at
least
we'll
be
looking
into
this
thing
and
we
have
the
time
to
work
on
it.
So,
let's,
let's
make
sure
that
we're
that
we're
deserving
of
this
trust
that
the
product
is
put
on
us
by
allowing
us
to
play
with
this
and
yeah.
That's
it
for
now
man,
anything
else.