►
From YouTube: 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
Okay,
we're
live
hi
good
morning.
This
is
our
weekly
source
code
meeting
I.
Think
Dennis.
You
have
the
first
first,
yes,.
B
Thank
you.
The
first
one
is
not
like
not
very
exciting.
It's
the
the
the
it's
very
confusing
situation
we
have
now.
We
have
separate
channel
for
backend
and
some
general
source
code,
slack
Channel,
which
are
two
separate
things
which
doesn't
make
sense
to
me.
I
just
would
like
to
propose
to
merge.
Those
two
I
will
raise
this
with
the
with
the
engineering
managers,
but
I
think
it's
it's
a
bit
odd
to
have
separate.
B
Oh
yes,
we
have
Andre
here
and
I
think
it
would
make
sense
to
merge
those
into
one.
It's
just
just
an
idea
because,
like
monitoring,
one
channel
is
twice
as
easy
as
monitoring
two
channels.
C
Oh
then,
if
that
says,
we
still
have
a
third,
which
is
our
source
code
code
review,
yeah.
C
Yeah,
so
in
my
response
to
that
is
like
sometimes
there's
a
lot
of
topics
that
are
more
like
team
maintenance
discussions
that
require
a
little
bit
more
like
focused
discussions
on
the
people
that
are
targeted
in
that
thing.
So,
for
example,
if
we're
talking
about
stuff
that
relate
to
our
teams,
specifically
in
our
case
that
we
have
two
teams
so
I'm
talking
to
my
people,
my
people
I
will
flood
the
source
code
channel.
So
that's
why
we
have
separate
channels
historically
and
I.
C
Think
the
same
thing
happens
with
the
back
end,
so
I
think.
That's
the
reason
why
we
have
those
three
channels
like
one
for
products
and
I,
guess
the
group
one
one
for
the
group
and
then
one
for
each
report
of
the
engineering
manager,
specifically
so
yeah,
that's
yeah!
That's
how
you've
always
had
it,
but
I'm.
B
Just
wondering
probably
it's
just
my
my
problem
where
I
can,
where
I
monitor
all
of
the
channels
to
know
what's
going
on
in
the
group,
but
it's
it's
a
bit
confusing.
A
B
Can
even
take
it,
async
I
think
because
it's
sure
it's
not
the
most
exciting.
C
To
start
a
thread
start
a
thread
on
the
slack
Channel
on
the
source
code
main
one
and
then
we'll
go
from
there
thanks:
okay,
yep.
B
Yeah
so
I
have
the
next
question
the
next
point
and
that
one
is
much
more
exciting.
So
we
had
a
chat
with
the
torsion
earlier
this
week
about
some
some
interesting,
interesting
ideas
to
implement
in
in
the
group
and
in
particular,
three
three
points.
Three
things
three
ideas
were
were
were
interesting
to
discuss
and
would
involve
a
broader,
broader
group,
so
Michael
and
Anastasia
or
Jay,
we'll
we'll
see
how
it
goes.
How
soon
we
can
get
to
those
things.
B
So
so
I'll
just
go
one
by
one
into
those
things.
So
the
first
one
is
in
context
editing
files
in
Repose
screen.
There
is
an.
There
is
an
epic
here,
the
old
one,
from
from
old
days
when
Kai
was
product
manager
of
editor
group.
So
it's
been
really
long
ago
and
then
there
is
an
interesting
solution,
validation
created
by
Michael,
again
back
in
the
days
when
he
was
in
the
editor.
B
He
started
evaluating
this
I'm,
not
sure,
what's
the
state
of
that,
but
this
is
something
to
discuss,
and
then
there
is
the
very
current
POC
I've
spent
some
time
yesterday
create
throwing
the
POC
for
this.
For
this
effort
and
I
can
demonstrate
how
it
looks
like
at
the
moment,
it
doesn't
really
do
all,
but
we
can
briefly
take
a
look
at
at
the
at
the
this
thing
so
I
share.
You
apparently
see
some
see
my
screen
now
right.
B
It
throws
some
errors
which
are
not
supposed
to
be
here.
So
in
the
the
previously
there
was
a
POC
with
the
video
recorder
with
the
video
walkthrough
for
Snippets
and
I
showed
that
to
a
torsion
on
Monday,
but
all
right.
Okay,
that's
the
time
to
get
the
server
error,
and
let
me
just
restart
this
thing
technically.
B
The
idea
is,
there
are
two
different
things:
the
second
one
we'll
talk
about
a
bit
later
so
right
after
this
one,
but
the
first
one
is
in
context
editing
of
The
Blob
files,
and
then
there
is
inline
editing.
What's
the
difference,
the
con
in
context
allows
users
to
to
to
seamlessly
switch
between
viewing
a
blob
to
editing
a
blob.
B
This
is
in
context
in
line
is
when
a
user
wants
to
edit
a
particular
line
in
the
editor,
and
they
click
a
special
button
in
the
in
the
viewer's
gutter,
which
I
will
demonstrate
once
my
once.
My
jdk
is
back
and
healthy
and
then
all
right,
okay
seems
like
it's
not
gonna
happen.
Now
we
have
to
we'll
have
to
get
to
the
to
the
POC.
Apparently
I
didn't
record
the
video,
but
I
will
record
it
today.
As
I
said,
I
I
I
spent
some
time
yesterday.
B
Building
this
and
didn't
have
enough
time
to
to
tackle
this.
So
technically,
this
is,
as
I
said,
this
is
about
in
context,
editing.
We
we
actually
can
check
the
the
video
of
the
for
the
Snippets
and
it's
going
to
be
exactly
the
same
for
the
blobs,
except
for
one
simple
thing:
do
you
see
my
screen
now
the
video?
B
No
okay,
let
me
just
let's
see
it
is
yes,
no.
A
B
This
is
yeah.
This
is
the
this
is
the
POC
that
it
has
been
that
that
was
built
really
long
time
ago
for
for
Snippets,
but
the
idea
is
the
same.
So
here
we
begin
with
viewing
the
Snippets,
and
then
we
add
this
edit
button
for
every
individual
blob
in
the
snip
is
simply
because
we
didn't
have
this
button,
but
for
the
for
the
blobs
in
the
repository
it
will
be
that
blue
button
saying
edit.
So
it's
it's
working,
we
click.
We
are
right
there
without
reloading
the
page.
B
B
However,
the
safe
functionality
needs
to
be
thought
through
because
we
we
cannot
simply
Save
The
Blob
in
the
repository
we
have
to
go
through
the
commit
workflow
there,
so
the
one
of
the
ideas
is
just
to
put
the
commit
workflow
into
an
overlay.
So
when
a
user
clicks
save
changes,
we
get,
we
show
the
commit
overlay
user
types
in
the
commit
message.
Selects
the
branch
marks,
whether
it
has
to
be
a
new
merged
request
and
clicks,
confirms
the
saving
changes.
B
This
is
the
in
context.
Editing
do
we
have
questions
about
in
context,
editing
ADM,
because
this
one
will
have
will
need
a
lot
of
input
from
from
Michael
in
particular,
I
think
I,
I,
I
I
would
like?
Yes,
yes,
I'll.
B
Yes,
I
just
wanted
to
to
note
that,
since
we
don't
have
enough
that
that
much
time-
let's
let's
make
it
brief
and
I,
will
be
happy
to
answer
any
questions
in
async
manner
if
there
will
be
any
afterwards
the
poc's
link.
Now,
let's
get
to
the
questions
on
this.
A
One
yeah
so
because
you
have
specifically
questions
to
inter
context,
editing
my
impression
that
your
definition
of
what
it
is
is
very
technical
and
doesn't
put
in
the
center
of
the
user
problem.
I,
don't
exactly
know.
Here's
a
problem,
but
I
can
make
a
guess
that
there
are
certain
things.
Let's
say:
I've
discovered
that
I
want
to
change
something
then
I
want
to
change
that
and
with
at
least
least
amount
of
time
and
least
amount
of
clicks
to
make
that
happen.
A
I
want
to
probably
make
this
via
a
commit
commit.
It
should
still
be
git
after
all
and
I
want
to
understand.
You
know
where
I
do
these
things
and
probably
if
the
file
is
large
and
I
discover,
you
know
that
I
want
to
change
something
versus
the
bottom.
A
Yeah
interviews,
I'm.
A
Basically,
I
want
it
and
I
want
it
done
right,
so
I
want
right,
I
don't
want
to
have
to
do
others,
so,
of
course,
there
can
always
be
many
steps
to
do
it,
but
I
want,
as
least
steps
and
as
fast
and
as
little
and
to
use
your
word
as
little
as
possible
context.
Switching
you
know
context.
Switching
in
that
case
would
be
I
leave
the
line
that
I
want
to
change.
I
go
up,
I
select
edit
and
I
go
down
again,
but
that's
context.
Switching
I
got
it.
A
B
So
we
we
can,
we
can
base
it
on
user
needs.
Of
course,
however,
keep
in
mind
that
this
proposal
already
improves
the
distribution,
because
at
the
moment
the
contact
switch
is
not
only
losing
the
context
of
the
line,
but
also
getting
the
whole
page
reloaded.
So
this
is
much
more
dramatic
context
switched.
We
have
now
this
proposal
eliminates
One
Step
there,
so
you
you
remain
on
the
same
page.
You
instantly
switch
to
the
editing
interface.
You
have
the
file
in
front
of
your
RS.
B
B
B
I
actually
I,
as
as
discussed,
I,
didn't
I,
didn't
see
any
user
request
about
the
inline
editing,
except
for
except
from
you,
but
that's
already.
That
doesn't
mean
that
there
is
no
such
such
request
right.
This
just
means
that
we
don't
have
issues
from
the
from
the
customers
for
that
so
technically.
The
next
point
that
that
we
will
be
talking
about
is
actually
the
the
in
inline
editing
and.
D
I'm
just
going
to
jump
in
here
to
this
the
two
following
points:
I
have
no
issues
with
I
think
this
in
context
editing
one:
it's
like
I'm
confused,
whether
it's
our
responsibility
in
source
code
to
look
at
it
or
whether
it's
the
editors
group,
I,
don't
know
if
that
separation
is
clear
enough,
because
to
me
source
code
is
like
the
source
code.
Editor
is
a
component
I,
don't
know
if
the
whole
page.
D
So
for
me
personally,
I,
don't
know
I'm,
not
clear
on
which
group
that's
that
lies
on,
because
the
Epic
that
you
link
to
for
the
in
context
page
still
refers
to
the
editor
group.
So.
B
The
problem,
the
problem
is
that
this
is
this:
is
that
process
of
free
organization,
so
I,
don't
think
we
went
through
relabeling.
All
the
all
the
source
editor
related
initiatives
from
the
editor
group
to
label
them
to
source
code.
That's
that's
what
has
to
be
done.
C
So
Michael
one
thing
to
be
aware
is
that
the
source
editor
is
now
maintained
by
us
yep,
so
that
is,
that
would
be
a
source
code
project,
essentially.
A
D
B
Now
now
everything's,
technically
what
everything
we
talk
about
today,
it
doesn't
involve
any
cross-group
collaboration,
It's
all
under
our
control,
so
both
repository
editor
Source,
editor.
Those
these
things
are
under
our
control
and
we
can.
We
can
actually
do
whatever
we
want
with
those.
So.
C
You
go
sorry
before
I
go
forward.
I
was
trying
to
find
a
time
to
squeeze
in
so
when
we
started
to
do
the
refactoring
of
The
Blob
of
the
the
refactoring
of
the
repository
app
to
have
the
blob
incorporated
into
that.
C
The
idea
was
to
streamline
all
of
the
user
Journey
throughout
the
repository
and
make
it
as
seamless
as
possible.
This
is
the
End
bit
which
is
like
now.
We
have
the
blob
Incorporated
to
that,
so
you
can
navigate
between
the
blob
and
the
file
tree
much
easier,
much
smoother,
but
when
the
user
edits,
you
still
have
to
reload
the
thing.
This
is
like
the
final
step
in
the
user
Journey
that
wants
to
edit
a
file
to
make
that
seamless
and
smooth
loose
and
smooth,
essentially
a
performance,
Improvement
and
experience
enabler.
I.
D
That
makes
sense
to
me
so
at
the
moment,
I
feel
that
the
read
and
the
viewing
View
and
the
edit
view
look
very
different.
D
There's
ideas
of
that
I
propose
a
few
in
Epic
around
improving
this
single
just
the
viewing
of
it,
but
maybe
I
can
incorporate
thinking
about
how
this
may
swap
or
switch
into
edit
view
so
that
you
don't
need
to
reload
stuff,
or
you
know.
We
always
question
whether
that
well
of
information,
but
the
last
commit
is
actually
useful
on
the
page
or
maybe
there's
a
different
place
that
we
could
add
it
so
I
think
the
snippet
example
gives
me
a
good
idea
of
what's
possible,
but
I.
B
I'm
so
I'm,
so
sorry
I
cannot
demonstrate
the
the
POC
live
now
I'm
trying
to
reanimate
my
GDK.
While
we
are
talking
as
I'm
known
in
this
group
for
doing
things
while
on
the
call
so
but
technically
I
was
worrying
about
this
being
a
bit
too
harsh,
but
it
turned
out
to
be
really
smooth.
To
be
honest,
the
only
difference
that
that
even
even
the
difference
in
the
syntax
highlighting
you
can
highlight
GS
and
Source
editor
were
absolutely
negligible.
B
The
only
difference
that
was
a
bit
puzzling
was
it
was
surprisingly,
the
font
size
difference
between
the
viewer
and
the
editor,
so
the
editor
works
with
12
pixels
font,
size
and
viewer
with
13
pixel
size.
So
that's
the
only
disturbing
thing.
Otherwise
the
context
is
very
smooth.
Like
the
transition
happens,
you
click
the
blue
button
edit.
B
It
turn
it
turns
into
cancel
button
right
away
when
you,
so
we
swap
the
viewer
with
the
editor,
the
toolbar,
the
bar
Remains,
the
Same,
the
edit
bar
the
edit
Tool
button
swaps
into
the
cancel
so
that
you
could
cancel
editing
and
then,
if
you
make
the
changes,
these
cancel
button
swaps
into
the
save
changes.
So
the
transition
is
pretty
smooth,
but
yeah
I
cannot
demonstrate
this
I
will.
D
B
That's
that's
the
point
I
will
since
I
I
was
finishing
this
half
past
2
am,
and
it
was
like.
Videos
were
very
low
on
my
priority
list
at
that
moment.
So
I
will
do
it
today
and
yeah
for
all
for
all
three
ideas
we
have,
and
we
are
still
on
the
idea
number
one,
but
we
we
have
only
eight
minutes
left.
So,
let's
move
on.
Yes,
let's
move
on
so
the
in
line
editing.
This
is
the
idea
we
talked
about
with
the
torsional.
B
The
idea
is
so-
and
this
is
exactly
the
scenario
that
we
discussed
recently
so
user
looks
at
the
file
in
the
blob
viewer
and
then
find
something
that
has
to
be
changed.
So
what
what
happens?
Is
they
hover
over
that
line
and
the
same
way
we
show
the
a
line,
link,
icon
and
blame
icon
in
the
gutter
of
the
viewer?
The
next
to
the
blame
there
will
be
the
pencil
icon,
meaning
edit
user
clicks
that
edit
edit
link
and
now
the
ideal
situation.
B
Sort
of
the
Paramount
of
this
effort
to
me
would
be
that
this
particular
line
becomes
editable.
We
do
not
swap
the
whole
viewer
with
the
with
the
editor,
but
this
particular
line
becomes
editable
to
the
user
as
but
this
is
pretty
big
effort
like
it
sounds
simple,
but
it's
a
big
effort
because
we
are
attacking.
Why
would
you
want
to
limit
it.
B
You
can
write
more
lines,
but
that's
that's
exactly
the
the
context.
How
how
else
would
you
do
this
like
how.
A
Do
you
envision
I
would
just
make
I
would
just
you
know
and
I'm
just
speculating
now,
because
this
is
how
I
thought
about
it.
You
know
just
make
everything
editable
make
nothing
move
right,
so
right,
basically
going
from
read
only
to
right.
B
Right,
considering
considering
that
The
Blob
viewer
doesn't
have
height
limitation
and
the
source
editor
does
have,
we
have
to
make
sure
we
have
to
know
what
part
of
the
code
you
are
in.
We
can
introduce
a
complex
logic
in
order
to
detect
where
exactly
in
the
file.
You
are
like
scrolled
so
because
blobview
can
stretch
like
two
three
screens
right
while
Source
editor
is
only
on
the
top
screen
because
it's
limited
in
height.
So
what
will
happen?
Is
your
screen
will
jump?
No
matter
what
that's?
B
That's,
the
that's
I,
don't
see
this
technically
possible
to.
B
And
there
is
a
technical
reason
for
that.
First
is
the
editor
when
editor
is
defined,
it
has
to
have
the
the
parent
of
the
editor
has
to
have
the
defined
height
so
that
the
editoring
journals
would
know
how
many
lines
to
render
the
way
associator
works
in
order
to
be
performant.
B
Instead
of
creating
all
of
the
lines
like
two
three
thousand
lines,
it
creates
lines
only
for
the
visible
part
of
the
code
and
then,
when
user
Scrolls,
you
editor
reuses
those
already
rendered
lines
to
update
them
with
the
new
content
when
the
user
Scrolls,
otherwise
the
performance
of
the
editor
would
be
horrible
and
it
would
be
unusable.
The
the
reason
is.
B
They're,
a
completely
different
Technologies
right
viewer
is
just
rendering
the
HTML
lines.
Editor
is
about
run,
not
only
rendering
the
lines,
but
also
attaching
a
lot
a
lot
of
JavaScript
functionality
to
all
of
those
lines.
So
because
you,
you
have
to
have
a
lot
of
listeners
to
know
to
react
to
user
reaction
in
the
editor.
When
you
view
the
blob,
we
don't
need
to
do
this
because
it's
just
viewer,
so
there
is
a
technical
reason.
B
Why
why
in
particular,
why
the
editor
has
to
be
Limited
in
height
we
can,
we
can
adjust
the
height.
We
can
say
the
height
is
different
at
the
moment.
It's
500
pixels,
but
we
can
adjust
that
to
any
number
we
want.
We
just
have
to
know
that
we
cannot
make
it
unlimited
height.
B
Unfortunately,
so
again,
getting
back
to
your
question
like
swap
just
seamlessly
swapping
so
you're
viewing
at.
Let's,
let's
say,
do
I
have
yes,
so
let
me
just
share
my
screen.
I
did
I
still
don't
have
my
jdk
back,
but
we
can
and
we're
going
to
just
share
it
now.
B
Out
of
time
Dennis
so
yeah,
yeah,
I,
know
I
know,
I
will
I
will
probably
leave
the
third
point
for
for
the
next
meeting
then,
but
in
this,
in
this
case,
let's,
let's
go
to
some
Javascript
file.
When
we
talk
about
the
file
like
this
technically
we
can
like
44
lines.
We
will
be
able
to
more
or
less
seamlessly,
swap
the
things
and
make
the
whole
editor
editable.
B
Instead
of
just
one
line.
If
you
click
there
will
be
the
pants
like
in
here,
for
example,
next
to
the
blind.
But
if
we
talk
about
the
MVC,
this
is
what
we
discussed
as
well
as
the
MVC
like
we
can
discuss
the
end
goal
a
bit
later,
but
the
MVC
for
this
would
be.
We
show
the
pencil
icon,
we
click
it,
and
what
happens
is
that
we
get
to
the
editor
we
reload
the
page.
B
We
load
the
editor,
but
with
this
line
so
technically,
when
you
click
the
that
I
pencil
icon,
it
will
generate
URL
like
this.
Oh
come
on.
Okay,
right,
I
should
oh
man,
so
technically
you
will
have
to.
B
B
Let's
go
to
just
resolver,
so
let's
say
we
want
to
edit
the
line
six,
so
the
link
will
be
like
like
this,
and
then
we
get
to
the
editor
with
this
line
highlighted
right
away
and
then
the
user
has
the
context.
This
is
the
MVC.
B
This
is
what
we
can
do
right
now,
show
the
icon
user
clicks
and
then
gets
to
page
gets
reloaded
and
user
gets
to
this
line,
but
if
we
Implement
that
in
context
editing
from
the
first
part,
this
means
that
we
will
be
able
actually
to
get
closer
to
the
idea
that
Torsen
had
so
user
clicks,
the
edit
it
clicks
the
pencil
icon
and
instead
of
reloading
the
page.
B
We
swap
the
viewer
with
the
editor
with
that
line
placed
straight
in
the
middle
of
the
screen
and
that's
what
will
create
this
in
context
and
inline
consolidation
so
to
speak,
and
that
would
bring
as
close
solution
to
what
torson
described
as
possible.
What
will
be,
we
will
stay
on
the
same
page.
We
will
not
reload
the
page
and
we
will
get
to
the
exact
context
of
the
line
that
has
been
claimed.
This
is
sort
of
the
Paramount
of
this
whole
episode.
That
is.
C
Is
there
an
issue
for
this
proposal?
For
so
we
can
discuss
the
synchronous.
A
I,
don't
know,
for
you
know,
General
redesign
of
stuff,
and
there
was
a
at
least
a
comment
from
my
and
myself
and
maybe
also
a
discussion
I,
don't
know
where
we
have
that
Michael.
Do
you
remember
when
I
made
that
proposal
and
which
comment,
but.
B
I
will
I
will
get
the
links.
I
will
record
the
videos
for
these
things
and
we'll
take
it
asynchronously.
It's
just
I.
A
Wanted
one
last
sentence
about
the
topic:
I
think:
if
we
do
this
first,
before
the
income
tax
editing,
we
can
use
it
to
collect
some
data
and,
for
instance,
how
much
people
use
the
edit
button
at
the
top
versus
this
no
pencil
and
how
much
that
depends
on,
for
instance,
how
low
on
the
page.
They
are
I.
Think
that
might
give
us
some
insights
on
how
future
things
would
have
to
be
implemented.
As.
B
I
said
we
can
we
can
Implement
that
getting
to
the
to
the
line
with
the
page
reload
very,
very
fast,
it's
nearly
One
Max
to
weight
of
effort
this
this
can
be
done
now.
Then
we
can
start
gathering
information
and
in
the
background
we
will
be
working
on
the
in
context,
editing,
because
the
in
context
would
make
this
in
line
editing
much
much
better
experience.
If
we
combine
those.
A
C
The
last
two
things
just
an
announcement
of
a
new
working
group
and
we're
discussing
a
hackathon,
because
if
you
have
any
thoughts
or
questions,
raise
it
up
in
slack
and
discuss
asynchronously.