►
From YouTube: 2023-07-12 Source Code Weekly Meeting [REC]
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
Welcome
everybody
to
the
weekly
call
of
the
source
code
group
and
I'll
go
straight
to
the
agenda,
so
the
first
one
was
for
Joe,
so
we
can
skip
it.
I
can
talk
to
him
asynchronously
about
six
and
three
planning.
A
A
So
essentially,
we've
been
running
into
performance
problems
on
the
merger,
crests
and
the
disc
generation.
For
a
long
time,
we've
had
epics
to
break
it
down
iterations
and
bring
TBT
down
iterations
to
par,
to
break
the
requests
into
multiple
batches,
a
bunch
of
things
right
for
performance
reasons.
A
What
we've
realized
is
what
is
that,
with
the
current
approach
of
having
everything
via
view
app
we're
always
going
to
get
so
far
right,
so
we've
been
discussing
and
trying
out
some
crazy
ideas,
one
of
them
that
we're
currently
exploring
is
server
side,
rendering
try
to
see
where
that
I'm
trying
to
find
a
nation
for
it
that
we
have
opened
it's
not
as
love
is
investigating
an
approach,
but
the
topic
was
beyond
that.
So
what
we?
What
I?
A
Basically
want
to
like
just
disclose
here
is
that
the
way
we
see
this
going
forward
is
the
code
review
diffs
and
the
source
code
diffs?
They
are
different
to
a
point
because
one's
merged
one
is
just
browsing.
The
repository,
the
other
is
in
the
merger
cast
context,
but
the
render
of
the
diff
itself
should
be
easily
made
consistent
if
we
use
the
same
code
base.
A
So
that's
going
to
be
our
Target
is
whatever
comes
next
for
code
review
will
span
the
source
code
as
well
right,
so
this
isn't
necessarily
like
a
product
change.
It's
more
like
an
engineering
based
change,
because
the
the
outcome
of
it
will
just
be
a
consistent,
consistent
experience
of
diffs
across
source
code
and
code
review.
Now
what
this
entails
is
a
lot
of
technical
hurdles
in
the
back,
but
the
idea
is
to
make
the
code
much
more
maintainable
and
much
more
easier
to
work
with
and
much
more
performance
from
the
get-go.
A
Given
all
the
lessons
we've
been
taking
in
technical
terms,
what
this
will
mean
is
front.
End
will
have
to
be
reworked,
but
the
backend
will
also
have
to
be
reworked.
Essentially
right
now
we're
using
custom
end
points
on
the
code
review
side
of
things.
We
have
an
info,
that's
not
even
API
that
public
API
is
like
an
internal
endpoint
that
we're
using.
So
it's
not
ideal,
so
we
definitely
want
to
make
all
of
these
things
be
repurposed
into
a
much
more
performant
perspective
and
yeah.
A
So
from
the
front
end,
that's
going
to
be
reworked.
We
have
a
bunch
of
ideas
on
how
we
can
potentially
go
about
that
from
the
back
end,
I'm
a
little
bit
blind
on
what
needs
to
be
reworked
to
make
diffs
work
both
for
source
code
and
code
review,
because
they're
different
in
the
representation
of
the
back
end
I
know
that
at
least
the
code
review
there's
a
cache
in
the
table
of
the
div
itself.
A
I,
don't
think
that
happens
in
the
repository,
so
it
would
be
interesting
to
eventually
we
want
to
start
to
have
conversations
around
ideas.
Idealizing,
an
architecture
for
this,
so
I
do
expect
these
topics
to
come
into
our
pawns
very
soon
and
yeah.
The
that's.
That's
pretty
much
like
the
pitch
right
there,
where
we
are
right
now
we're
evaluating
the
front
end
architecture,
including
some
Ruby
rendered
server-side
render
templates,
which
would
then
go
over
to
right.
How
do
we
cache
these?
How
do
we
make
these
fast?
A
How
can
we
make
these
cached
in
a
way
that
doesn't
burst
the
radius
cluster
and
all
that
stuff?
So
it's
going
to
be
a
lot
of
crosstalking
back
in
the
front
end
and
between
starts
putting
code
review
so
I'll
leave
it
at
that.
Does
that
sound
good
to
everybody,
like
you,
have
any
questions
or
ideas
that
spark
any
ideas.
B
Sorry
I
was
kind
of
late,
so
I
missed
the
first
off,
but
it's
already
issues
you
could
link
to,
but
we
could
read
through.
A
Yeah,
so
that's
what
I
was
trying
to
find
I
I
with
this
very
last
minute.
As
you
know,
the
agenda
I'll
add
something
so
right
now
we
have
an
ongoing
Spike
that
stand
is
live
on.
The
preview
side
of
things
is
investigating
server-side,
rendering
of
diffs
you're,
doing
some
front-end
techniques
and
just
move
this
try
to
find
the
issue
that
he
has
assigned.
So
this
should
make
it
easy.
B
A
A
A
If
you
have
some
changes
here,
just
to
make
things
available
he's
using
he's
using
the
Hamel
templates
that
we're
using
in
the
source
code
side
of
things
just
to
test
it
just
to
get
it
started,
but
it's
definitely
going
to
be
like
a
major
change
in
how
we
serve
the
data,
and
this
is
not
going
to
be
the
code
we
ship,
it's
just
an
exploration,
yeah.
A
But
I
find
an
epic
that
I
think
we
have
an
epic
for
these
things.
There's
no
epic,
yet
I
know
we
have
an
epic
for
their
performance
because
I
created
some
of
these.
A
A
Yeah,
there's,
not
a
lot
of
stuff
in
here,
but
I'll
show
you
either
way
in
case.
We
want
to
start
talking
about
things,
but
I
just
want
to
like
to
at
least
get
this
on
your
minds
in
the
backhand
side
of
things
and
there's,
potentially
a
lot
of
questions
between
code
review
and
source
code
that
we
need
to
clarify
how
we're
going
to
do
that,
but
especially
given
that
Georgetown
is,
is
stepping
out
of
the
scope
after
this
Milestone
planning
I.
A
Think
it's
important
for
us
to
understand
that,
even
without
a
lot
of
work
coming
from
products,
there's
a
lot
of
stuff,
we
can
clean
the
house
from
the
engineering
perspective.
So
I
wanted
to
share
that
with
you
too,
with
you
three
here
on
the
top
but
everybody's
watching
the
report
of
that
how
to
be
positive.
A
That's
that's
it.
Nobody
has
any
other
comments
or
questions
I'd
hand
it
off
to
Amy.
C
Okay,
sorry
I
was
typing
so
as
far
as
I
know,
Joe
is
still
speaking
to
me.
So
thank
you.
The
reason
I
wanted
to
bring.
C
Kind
of
tutorials
they
want
to
my
managerial
team
wants
to
see
us
write.
They
span
multiple
groups,
they
span
multiple
stages
and
I
realize,
since
I
represented
source
code
and
code
review,
I
have
an
opportunity
to
write
tutorials
on
the
really
really
early
part
of
the
adoption
process
and
then
I
realized
nobody
had
written
up
okay.
So
how
do
you
set
up
groups?
How
do
you
set
up
protections
on
a
new
project
and
I
handed
over
an
MR
to
Joe?
That
literally
said
things
like
I
know.
C
So
we
got
it
dealt
with.
We
know
what
we've
I
know,
what
I
have
to
do
in
the
next
round
of
reviews
or
next
round
of
improvements,
but
I
wanted
to
call
that
out
here,
because
I
know
this
was
a
pain
in
the
butt
to
review
and
I
also
know
that
it
required
him
to
look
up
stuff
that
he
wasn't
super
familiar
with.
So
thank.
C
There's
probably
going
to
be
more
of
this
I,
don't
know
what
exactly
I
need
to
focus
on
I've
I'll
deal
with
that
next
quarter,
I
just
got
to
get
this
one
published
first.
So
from
time
to
time,
big
Mrs
like
that
are
going
to
show
up
I'll,
try
to
split
them.
Between
Coke,
review
and
source
code,
but
source
code
got
this
one
for
reason.
C
It
was
mostly
because
of
all
the
the
changes
to
code
donors
I
wanted
to
make
sure
that
the
person
who
had
been
working
on
them
could
look
at
what
I
wrote
and
said.
Yes,
that
that
knowledge
is
based
in
how
this
worked
a
year
ago,
nice
try
so
so.
That's
that
the
other
is
is
a
little
bit
of
knowledge
that
I
mostly
poked
a
code
review
with
yesterday,
but
I'm
going
to
bring
it
up
here.
C
A
Yes,
so
one
of
the
things
that
we
already
already
discussed
we're
also
very
mindful
that
accessibility
is
very
horrible.
I
remember
when
we
were
in
Cape
Town
and
contributed.
We
had
a
session
where
we
used
like
a
blind
like
a
opaque
pair
of
glasses
I
mean
we
have
several
front-end
Engineers,
try
to
use
the
platforms,
it
wasn't
good,
then
it's
not
better.
Now
yeah,
we
don't
have
that
as
concerned,
I
know
that
some
people
are
really
invested
and
have
made
a
lot
of
changes.
A
So
we
definitely
want
to
make
sure
that
this
is
part
of
like
the
direction
of
where
we're
going
with
the
refactor
of
the
diffs
like
easier
to
navigate
easy
to
work
with
easy
to
stick
to
context,
but
also
to
not
just
not
just
assistive
technology
that
reads
the
screen:
the
screen,
readers,
but
also
there's
a
lot
of
stuff
that
we
can
do
to
benefit
the
accessibility
of
motor
impaired
users,
but
also
that
benefits
everybody
like
the
size
of
the
controls.
A
The
way
that
we
have
provided
a
way
to
navigate
on
the
page,
so
a
lot
of
that
stuff
will
run
up
there.
So
we'll
have
those
discussions
on
with
the
designers
and
all
that
stuff,
but
that'll
be
part
of
the
project
for
sure
and
of
course
I.
Don't
know
it
won't
impact
the
Vlog
page
I
think
so
we're
still
going
to
have
to
probably
like
do
some
new
revisions
there.
So
what
I
would
say
is
especially
the
repository
in
the
blog
page.
A
I
would
definitely
encourage
creating
issues
around
improvements
that
we
can
ship,
the
other
Pages
they're,
so
they're,
so
behind
that
they're,
probably
going
to
pick
up
by
every
factor
and
the
refactor
will
take
care
of
those,
but
for
the
other
ones,
issues
are
easy
issue.
Galore.
A
D
C
B
D
Yeah,
this
to
know
actually
I
hadn't
I've,
never
worked
with
with
with
the
diffs
so
far
is
to
know.
Actually
what
you
think
is
gonna
be
needed.
Do
you
think
we
we
need
to
so
we
could.
We
need
to
create
a
public
API,
you
think,
and
it
should
work
for
both
or
the
current
API
just
work,
for
we
get
two
apis
for
two
type
of
divs.
Somehow,
like
I
I.
A
Don't
know
I
can
share
some
ideas
of
what
we
know
so
far.
One
of
the
things
that
has
helped
the
front-end
apps
as
a
whole
is
the
ability
to
requests
different
things
at
different
times
in
different
shapes,
so
I
can
give
you
an
example
on
the
merge
request.
You
can
request
the
div
solid
ones.
We.
A
Have
a
file
by
file
navigation,
so
the
API
being
extensible
being
adaptable.
Definitely
it's
a
hint
for
graphql
that
we
can
have
an
endpoint
that
we
can
request
things
on
our
own
and
we
can
specify
exactly
how
we
want
the
data
to
come
through.
That's
definitely
going
to
be
part
of
the
equation,
I
think
I,
don't
think
we
can
get
around
that,
but
more
than
that,
one
of
the
things
we've
noticed
is
if
we
want
something
performant.
A
If
you
want
something
performance,
I'm
going
to
just
drop
the
wallet
there
once
a
big
performant,
we
need
to
have
something
built
for
purpose.
So
one
of
the
things
we're
talking
about
having
is
a
priority
of
constituents.
A
What's
going
to
be
like
the
most
important
things
on
that
project
and
a
lot
of
the
times,
it
won't
be
as
consistent
as
the
other
typical
apps
when
we're
talking
about
diffs
we're
talking
about
lots
of
data
to
the
to
the
page,
lots
of
interactivity,
lots
of
memory
usage
on
the
front-end
browser
respective
things,
so
we
might
cut
some
Corners
that
are
not
obvious
for
the
rest
of
the
applications.
That's
why
I
want
to
advise
an
architecture
around
this
thing,
but
I
do
expect
some
form
of
API
attention
to
graphql
for
getting
dips.
A
Now,
in
the
repository
side
of
things,
it
will
be
the
diffs
on
a
branch
or
this
on
a
commit
or
diffs
comparing
two
branches
on
the
compare
page,
for
example,
and
then
on
the
merge
request,
it
will
be
essentially
comparing
one
branch
with
the
other,
which
is
kind
of
like
the
compare.
So,
as
you
can
see,
there's
already
differences
here
is
it?
Is
it
a
commit?
That
is
where
you
have
it
in
gits,
or
is
it
a
comparison
of
two
branches
and
in
the
case
of
merge
requests?
A
What
we're
doing
is
comparing
your
branch
with
the
head
of
the
target
Branch,
it's
constantly
moving,
so
just
on
the
back
end,
there's
going
to
be
an
engine
around
this
sorting
out
and
abstracting
a
lot
of
this
complexity.
To
give
this
is
important.
The
same
response
to
the
front
end,
the
same
format,
the
same
payload,
the
same
verbiage,
all
of
that
consistently
across
all
these
scenarios.
Right
now
we
don't
have
that.
A
A
Perhaps
some
parts
of
these
will
come
pre-server
side
rendered
from
the
back
end:
okay,
okay,
but
they
have
to
come
consistent
in
a
way
that
the
front-end
can
hydrate
the
UI
and
add
functionality
as
it
needs.
So,
for
example,
the
way
we're
thinking
about
this.
If
you
can
find
a
way
to
render
the
HTML
of
a
diff
consistently
on
the
back
end,
he
gets
the
front
end
and
then
we
can
just
attach
things
to
that
UI
depending
on
the
use
case.
A
That's
one
way
to
go,
but
we
need
to
make
sure
that
it's
super
fast,
regardless
of
whether
the
caches
are
warm
or
the
casts
are
not
worn.
So
yeah,
there's
gonna
be
a
lot
of
conversations
around
this
yeah.
A
A
We
have
talked
about
doing
something
like
a
try
inside
cache
or
that
the
back
end
talks
to
that
cache
and
then
the
front
end
always
renders
from
cash
on
the
client
side,
but
then
that
what
that
will
do
is
like
we
will
start
spreading.
The
data
through
the
client
side
on
every
merch
request
you
visit
is
that
sustainable.
A
You
need
to
check
so
there's
a
bunch
of
like
questions
around
that,
but
what
we
want
to
do
so
one
of
the
one
of
the
things
we
want
to
question
is
whether
rendering
getting
a
line
by
line
from
the
server
is
the
most
effective
way
to
getting
the
diffs
right.
Now
we
get
a
structure
of
we've,
got
a
structure
of
like
diff,
div
files
and
four
and
there's
an
array
of
lines,
and
each
line
has
a
bunch
of
structure
right.
A
It's
such
a
heavy
payload
to
repurpose
that
into
a
front-end
compared
to
getting
a
blob
of
text
and
dumping
it
on
a
div
right
now
we
have
a
Blog
of
text.
We
don't
have
lines
breaking
broke
up.
How
can
we
reconcile
these
two
scenarios
here
and
having
the
front
end
talk
to
the
back
end
in
a
way
that
hey
I,
wonder
if
that's
a
common
to
this
line,
so
there's
a
bunch
of
like
stuff
that
we're
still
going
through
in
trying
to
identify.
A
We
already
have
some
clues
about
what
works
and
what
doesn't
work
from
the
code
review
side
of
things,
we're
not
ready
to
set
an
architecture
plan.
Yet
that's
what
I'm
talking
about
to
you
right
now
is
so
that
when
we
start
those
conversations
source
code
will
need
to
be
part
of
that
to
make
sure
that
we're
consistent
again,
then
we
serve
both
purposes.
Okay,.
D
A
I
heard
about
HTML
over
the
wire
right,
yeah
yeah.
So
what
are
my
Engineers
talk
to
me
about
that?
He
mentioned
that
the
I
think
I've
seen
that
the
way
that
I
usually
see
these
things
is
like
they're,
very
basic
to
how
they
got
to
how
they
get
to
I.
Remember
triple
links
having
a
bunch
of
like
benefit
benefits,
but
then
he
fell
short
once
we
had
already
like
a
complex
front
and
app
to
build
upon
it.
A
Yeah
we
can
look
at.
We
look
at
all
the
and
all
those
things
to
me.
A
The
the
way
that
we
get
the
HTML
to
the
browser
is
the
least
critical
one
to
me,
the
harder
part
is:
how
do
we
get
the
data
from
Italy
to
HTML
rendered
like
that
Journey
To
Me
is
much
more
critical
because
it
needs
to
be
super
fast
needs
to
be
super
efficient
and
again,
if
you
think
about
server-side
rendering
remember
if
the
the
user
has
opted
for
parallel
view
or
inline
server-side
render
divs
need
to
be
accounted
for
that
so
we're
probably
gonna
need
two
different
versions
for
each
div
right.
A
Idea
is
Jared
on
the
on
the
Epic
that
I
that
I
gave
you
and
then
I
LinkedIn
the
agenda,
and
we
can
start
from
there
and
eventually
we're
gonna
start
having
conversations
more
formally
about
architecture
about
this
around
around
these
things.
Yes,
at
the
moment,
just
the
hints
of
what's
potentially
coming
in
the
next
months,
I.
D
A
B
A
C
A
A
B
A
Right
and
it's
especially
important
when
we're
talking
about
motor
motor
impairments
like
if
you
have
a
hand,
yeah
yeah,
we've
all
been
there,
RSI
yeah
I.
Have
that
too.
So
a
lot
of
the
times
like
we,
we
feel
it,
and
then
we
became
aware
of
that.
So
it's
important
for
us
to
have
that
empathy
about
the
the
disabilities.
We
don't
have
right
now.
We
could
have
one,
so
you
know
might
as
well
just
prepare
the
future
for
everybody.
A
It
is
important
to
distinguish
two
things,
though.
There's
the
screen
reader
accessibility,
which
can
benefit
from
a
very
careful
markup,
but
a
lot
of
like
visual
users,
don't
benefit
from
that.
So
the
effort
in
the
market
isn't
the
whole
thing.
A
A
So
yeah
yeah
we're
very
big
supporters
of
accessibility
at
this
point,
so
sometimes
you
just
don't
do
it
because
the
the
code
base
is
so
convolutely
broken
and
so
Legacy
that
it's
just
it
will
be
a
huge
effort,
but
sometimes
it
isn't
I'm
just
into
scheduling
work,
so
issues
are
helpful
and
then
on.
The
refactory
was
therefore
play
pay
attention
to
that
yeah
thanks
for
bringing
it
up,
Amy
and
all
right
we're
at
time
any
last
minute,
thanks
Joe
since
I
have
you
here.
A
Should
we
get
a
poll
scheduled
for
the
next
couple
days
or
so
to
go
to
the
16th
Street
planning?
How
do
you
want
to
do
that.
B
A
For
tomorrow,
all
right
I'll
take
a
look
at
your
calendars
and
see
where
we
can
get
something,
because
usually
what
we
do
is
this,
like
back
in
hezekobby
Thurston
trumpet
has
a
call
with
Kirsten
back
in
front
end.
Don't
really
have
one,
but
in
the
case,
like
you're,
doing
you're
sitting
in
for
Sean.
If
I
can
help
in
any
way,
I
can
sit
in
on
that
call
with
Thurston,
and
then
we
can.