►
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
The
edge
cases
with
editing
and
how
I'm
not
fully
immersed
in
the
edge
cases
to
understand
how
to
deal
with
it.
So
some
of
these
examples
are
there
might
be
cross-group
dependencies,
such
as
security
for
security
rules
and
if
we
need
to
make
changes
there,
whether
we
have
to
coordinate
those
changes,
some
edge
cases
around
getting
the
flows
right
to
ensure
that
you
know
that
there's
a
one-to-one
mapping
between
rules
and
branches,
and
so
some
of
those
constraints
are
not
in
place
at
the
moment
and
so
every
every
like
week.
A
A
Existing
frame
like
areas
within
settings
to
change
those
it
may
seem
a
little
bit
convoluted
as
in
like
oh
now,
I
need
to
jump
around
more
places,
but
I
think
it
might
give
us
more
confidence
that
this
is
the
right
direction,
that
yeah
here's
all
your
branch
rules
grouped
in
branches
and
then
over
time.
We
can
like
look
into
the
details
of
how
we
restructured
the
data
models
and
everything
to
support
the
editing
experience.
B
I
show
you
I'll
show
you
concerns,
michael
because
in
fact
one
thing
that
seems
apparent
is
customers
are
using
some
of
these
features
in
ways
that
we
don't
that
weren't
originally
planned
and-
and
we
might
not
even
necessarily
understand
so
if
we,
if
we
go
ahead
and
take
away
that
functionality,
you
know
in
it
unintentionally,
you
know
we
might
have
might
have
pushed
back
and
then,
if
we
talk
about
you
know
at
gitlab
we
don't
have
this
option
of
having
a
b
testing
really
in
any
application,
which
is,
I
don't
know
something
we
should
look
at,
but
we
do.
B
We
do
our
feature
flags,
but
this
this
is
so
big.
It
actually
would
be
a
bit
difficult
to
feature
lag.
I
think
effectively
I
mean
we
could
we
could
try.
So
I
like
that
idea,
I
don't
know
what
the
effect
that
would
have
on
the
existing
development
to
date.
I
know
there's
been
a
lot
of
work
done
on
the
data
model,
but
I
mean
we
could.
A
Yep
that
makes
sense
to
me
because
I
think
our
end
goal
is
eventually
to
get
to
there
and
there
might
be
some
other
technical
issues.
We
don't
know
about
their
models,
so
it
might.
B
A
Good
to
continue
that
road
down
the
road
down
the
line,
I
also
think
there
might
be
some
updates
to
like
maybe
some
queries
to
capture,
to
get
all
the
data
from
both
the
current
data
model
and
the
future
data
model.
So
I
think
there
might
be
some
extra
work
that
I
am
not
aware
of,
so
maybe
that
could
be
something
that
we
put
into
consideration
but
yeah.
I
thought
I'd
bring
it
up.
The
discussion.
B
Yeah,
I
think
it's,
I
think
it's
a
really
great
point,
I'm
glad
you
brought
it
up
and
I
think
also
with
the
data
model
I
mean,
I
think,
the
work,
because
it
is
a
new
data
model.
What
they've
done
is
actually
created.
B
There
was
a
choice
made
between
extending
and
creating
a
new
one,
and
the
choice
was
made
to
just
create
something
completely
new
and
then
there
will
be
a
transfer
process,
so
so
that
actually
works
in
this
scenario,
because
that
work
can
just
continue
and
it
just
would
never
be
exposed
until
we
were
until
we
were
ready.
I
guess-
and
I
guess
the
next
step
would
be
to
work
on
the
visual
display
of
these
existing
rules
in
the
new
format.
C
I
I
really
super
like
this
idea,
because
I
think
it
will
reduce
the
scope
and
complexity
of
the
embassy
and
to
me
it
seems
that
maybe
all
this
information
that
we
need
for
your
new
proposal
is
maybe
already
available
in
the
back
end,
and
maybe
it's
just
that
the
front
end
needs
to
make
more
than
one
call
or
something
do
you
think
that
is
the
case
sean
that
yeah
I'll
make
this
a
simpler,
simple,
front-end
work.
B
Yeah,
I'm
not
sure
actually,
because
there
could,
it
could
be
a
bit
of
a
speed
bump
there
I
mean
we'd
have
to
ask
for
andre's
advice
on
this,
but
I
would
assume
that
the
new
you
know
we
built
part
of
the
part
of
what
we're
building
is
a
whole
lot
of
new
graphql
endpoints
for
consumption
by
the
front
end,
and
I
would
assume
that
they
had
planned
their
changes
around.
B
You
know
a
dependence
on
these
new
endpoints
so
and
those
end
points
depended
on
the
new
data
model
so
that
that
could
get
a
bit
tricky,
but
look
we
can
we
can.
We
can
talk
about
it,
andre
and
I
can
talk
about
it
offline.
All
the
engineers
can
talk
about
it
directly
and
and
see
whether
is
it
possible,
or
is
it
really
difficult
and
and
see
what
happens
there.
A
Okay
and
then
I'll
have
a
lot
of
then
I'll
focus
on
getting
like
the
solution,
validation
around
the
branch
display
and
detailed
views
of
it
sorted
sooner
than
later,
right.
C
The
next
one
is
me
so
sean
wiley
were
out,
we
defined
the
okrs
and
I
don't
know
where
they
had
a
chance
to
look
at
them,
and
two
of
the
okrs
were
defined
a
bit
more
openly.
So
one
of
these
more
open
ones
is
that
deliver
one
highly
demanded
feature
that
is
at
least
premium.
C
I'm
struggling
a
bit
to
find
the
right
issue
here,
but
I'll
continue
looking
into
that,
but
the
first
one,
which
is
in
the
documented
that
we're
looking
at,
is
around
delivering
a
highly
demanded
feature.
C
That
is
at
least
premium,
and
I
think
the
one
that
stands
out
in
terms
of
number
of
upwards
is
clearly
report.
The
number
of
lines
per
language
in
the
repository
charts
and
I've
been
starting
to
look
more
detailed
into
that,
and
unfortunately,
it's
a
very
because
if
you
have
so
many
requesters,
it's
also
a
very
big
mix
of
what
these
people
want
and
what
they
need
and
why
they
need
it,
and
it
goes
from
you
know.
C
Different
groups-
and
even
you
know,
on
gitlab
and
bitbucket,
and
you
name
it
right
so
that
they
have
something
that
tells
them
what's
the
distribution
of
code
that
they
have
in
terms
of
potentially
hiring
hiring
wasn't
mentioned,
but
I'm
I'm
thinking
that
may
be
the
case,
then
also
you
know
tooling,
and
risk
assessment
and
understanding
which
languages
grow
and
so
on.
C
So
I'm
I'm
planning
to
you
know,
detail
that
a
bit
and
then
openly
write
in
the
issue,
my
thoughts
and
ask
specifically
those
that
that
ask
for
that
why
they
need
it.
What
they're
trying
to
achieve,
because,
for
instance,
for
that
cio,
I
don't
see
why
it
wouldn't
be
important
to
know
the
exact
number
of
lines
of
code.
We
could
maybe
do
an
estimation
right,
so
we
just
do
some
statistics.
You
know.
Byte
size
of
java
is
translated
into
these
number
of
lines
of
code
and
python.
C
Is
that
and
so
on,
and
then
we
give
some
estimation
that
might
be
totally
enough
for
that
and
what
these
users
need
is
really.
They
need
it
on
the
group
level
and
they
don't
care
so
much
about
the
project
level
right
and
those
are
the
users
that
would
be
yeah.
We
could
definitely
consider
sort
of
premium
or
even
ultimate
tiering.
B
I
would
love
to
see
another
one
feature
for
source
code
management.
I
think
that
would
be.
That
would
be
the
ultimate.
C
Yeah,
do
you
sean
from
your
feeling?
Do
you
think
it's
reasonable
to
make
an
estimation
of
lines
of
code
based
on
the
byte
size?
So
for
your
background,
currently
we
report
languages
by
byte
size.
It's
reported
from
italy
and
we
show
that
in
the
analytics
for
the
project,
but
we
don't
bring
it
up
to
the
group
level.
B
I
think
that
could
be.
It
could
be
very
tricky.
I
mean
you
know.
Obviously
the
two
things
could
affect
it
is
you
know,
languages
can
can
vary
obviously
dramatically
within
themselves,
but
also
code
style.
You
know
the
way
in
which
people
code
can
also
affect
quite
a
lot
the
the
lines
of
code.
So
estimating
you
know
we
might
find
that
it's,
it's
even
exact,
which
which
might
then
be
contrary
to
the
goal
we're
trying
to
achieve
there
like.
B
If
we,
if
we
estimate
and
it's
actually
incorrect
or
you
know,
if
it's
out
by
a
lot,
then
that's
that's
tricky,
I'm
just
wondering
why
we
wouldn't
kind
of
just
actually
calculate
it.
I
mean
it
might
have
to
be
a
background
process
or
yeah.
C
So
there
was
one
comment
from
italy
developer
that
this
would
be
a
large
amount
of
work
right
and
it
would
come
with
performance,
potentially
performance
issues
and
to
avoid
those
it
would
be
a
significant
amount
of
work.
Therefore,
I'm
thinking
that
maybe
we
can
maybe
we
can
just
say
for
those
users
that
I
just
talked
about
those
admins.
It's
fine
to
have
the
bite
size,
the
problem
with
bite
size.
It
then,
is
not
comparable
to
bitbucket
or
github
that
might
report
the
lines
of
code
right,
yeah.
B
B
Yeah
I
mean
some
people,
you
know
they
write
their
code
in
all
different
ways.
You
know,
and
so
yeah
I
I
don't
know.
I
don't
know
how
much,
how
useful
that
would
be
in
terms
of
solving
the
giggly
problems.
I
mean,
I
think,
italy,
I
don't
know
if
italy
works
with
background
processes,
maybe
that's
something
they
would
consider
introducing,
because
this
would
not
need
to
be
anywhere
near
real
time.
It
also
also,
you
know,
depending
what
tier
it
is.
B
It
also
will
affect
a
small
group
of
customers,
a
smaller
group
of
customers
and
everyone,
so
maybe
that
maybe
that
could
ease
some
of
italy's
fears.
Look
it
could
even
it
could
even
be
some
type
of
ruby
job,
but
that
would
seem
to
be
it
would
make
more
sense
to
do
it.
In
italy
I
mean
we'd
have
to
call
italy
anyway,
going
back
to
the
estimation
aspect.
It
might
also
be
worth.
I
mean
we're
integrated
with
source
graph
and
and
source
graph.
B
C
B
It
might
be
worth,
I
don't
know
what
kind
of
relationship
we
have
the
saw
scope,
but
it
might
be
worth
just
seeing
if
that's
the
possibility
that
or
even
if,
actually
even
if
they
can
do
something,
I
mean
that's
a
separate,
actually
separate
database.
I
think
so
that
could
be
another
avenue.
C
And
help
me
able
to
understand
what
does
source
graph
do
and
how
could
that
help.
B
Well,
we're
integrated
with
source
graph
at
the
level,
I'm
not
really
entirely
sure,
but
they
you
know
they
kind
of
have
it.
They
have
like
a
a
database
of
of
the
code
itself
right,
so
they
have
it
like
a
queryable
structure.
B
Yeah
so
it
you
know
it
has.
It
has
awareness
of
the
code,
so
you
can
click
through
more
easily.
You
know
relationships
between
objects
in
the
code,
but
the
side
effect
of
that
is
they've.
Actually
you
know
they've
consumed
the
entire
repository.
B
B
I'm
also
not
sure
whether
we
have
some
type
of
formal
partnership
with
them,
or
it's
well
we're
just
using
their
open
source
version,
because
now
they
have
the
two
tiers.
Who
should
we.
C
B
I
don't
know,
actually
I
don't
know
who's
responsible.
I
guess
maybe
we
should
start
with
understanding
whether
we
are
just
consuming
the
open
source
version
and
and
then,
if
we
have
a
relationship
with
them,
it
would
be
the
relationship
manager.
B
But
just
take
a
step
back,
I
think
the
simplest
solution
would
be
to
just
count
them,
but
but
I
guess
we
would
need
to
work
with
good
leader
to
see
how
that
could
be
done
efficiently.
C
A
Not
sure
but.
A
You
know
this,
this
would
just
probably
look
at
one
branch
and
I
guess
people
would
care
about
the
whole
repository
like
all
the
different
branches
and
all
that.
So
there
was
another
comment
where
someone
suggested
that
this
could
happen
periodically.
So
that
idea
of
making
this
a
ruby
job
or
something
something
might
be
a
good
step
forward.
And
since
this
is
a
potentially
a
paid
feature,
then
this
could
justify.
A
C
How
do
we
deal
with
cost?
So
if
we
do
this
like
an
offline
icon
side,
job
that
needs
to
run.
B
Mean
we
have
visibility
over
over
runner
costs,
but
we
don't
have
very
good
visibility
over
just
general
background
jobs,
it's
a
bit
hard
for
us
to
estimate
how
much
a
specific
job
is
costing
us.
It
could
be
done
for
the
runner.
It
could
be
a
runner
job
where
you
know
they
pull
the
whole
repo
and
then
they
just
yeah.
They
use
something
like
clock
and
discount
it,
and
then
it
wouldn't
have
a
lot
of
strain
on
on
italy.
We
did
that,
but
it
would
be.
B
You
know
we
could
just
you
know
if
it's
a
runner
job,
then
we're
already
tracking
minutes
of
runner.
It
could
be
some
type
of
specialized
runner
job
and
then
we're
already
tracking
the
minutes,
and
so
you
know
we
know.
C
That
it
would
be
a
runner
in
the
customer's
namespace,
so
it
would
be
they
pay
for
it
right.
B
Yeah,
when
I
say
run
a
job
I
don't
mean
you
know
they
would
they
would
write
the
the
cio
themselves,
although
that
could
be
an
option,
but
it
could
be.
You
know
they
have
some
type
of
option
and
then
we
run
a
special
runner
in
the
background.
That's
you
know
a
bit
invisible
to
them
and
then
it
comes
back.
You
know
so
we'll
just
pull
the
repo
and
and
use
something
like
clock
to
to
do
the
accounting
and
then
store
that
in
back
in
the
database.
C
Okay,
all
right,
I
will
start
with
with
the
beginning,
which
is
you
know,
better,
understand
the.
Why
and
what
and
then
yep
and
then
cut
it
and
so
on.
B
One
point
is
it:
does
it
does
seem
like
a
something
we
should
have
it
also.
Does
I
mean
the
kind
of
out
the
couple
of
solutions
for
just
outline
all
same
they're
all
fairly
complicated
and
feels
complicated?
Well,
I
mean
there's
going
to
be
a
number
of
moving
parts
in
whatever
direction
you
take.
B
You
know,
and
probably
you
know
fairly,
you
know
a
big
development
effort,
possibly
across
teams,
and
so
I'm
just
wondering
you
know
do
we
have
a
feel
for
you
know
how
how
much
customers
really
want
this.
C
Yes,
so
there
are
18
customers.
B
B
C
Don't
have
metrics
on
you
know
whether
they
are
premium
ultimate
or
free,
but
given
the
I've
been
now
halfway
through
the
comments,
given
the
comments
it
looks
like
there
is
a
number
that
just
cares
about.
You
know.
I
know
this
from
github.
I
want
to
know
at
the
end
of
the
day
how
much
lines
of
code
and
yeah
and
I've
been
in
interviews
where
the
future
employer
asked
me
how
many
lines
of
code
have
you
written
whatever
right.
So
they
want
to
know
this.
B
So
it's
it's
mostly
an
aspect
of
achieving
feature.
Parity.
C
For
some
of
them,
yes
right
or
for
the
other
ones,
it's
more
like,
because
that
I
haven't
found
out
whether
there
is
some
kind
of
organizational
aggregation
at
github.
I
don't
know
yet.
I
have
to
check
it
out.
C
So
then,
going
back
to
your
the
beginning
of
your
comment
right,
so
any
of
the
solutions.
Look
big
in
terms
of
you
know
my
my
beginning
of
where
I
started.
You
know,
let's
find
a
highly
demanding
feature
that
is
at
least
premium
right
and
address
this
in
this
quarter
to
address
the
okr.
B
I
mean,
I
think
your
next
point
is
looks
amazing,
but
I
guess
you
don't
want
to
have
it
on
the
live
stream.
B
Okay,
I
think
the
next
point
would
be
a
great
ultimate
feature,
or
it
has
to
be
yes,.
C
B
I
had
a
couple
of
very,
very
quick
points,
so
one
is
that
we're
about
to
hire
well
we're
very
close
to
hiring
three
engineers
for
source
code
management,
so
offers
are
out
and
we're
just
waiting
for
feedback,
etc.
B
So
to
a
senior
and
one
is
intermediate,
and
if,
if
we
hire
all
these
all
these
engineers
two
are
in
emea
and
one's
in
north
america,
so
I
think
that'll
actually
be
awesome,
we'll
you
know,
we
will
of
course
have
to
up
up
on
ramp
them.
That'll
take
a
little
while,
but
I've
got
some
ideas
around
that.
So
that's
great
and
thank
you
very
much
to
product
for
getting
us.
The
head
count
really
really
appreciate
it.
C
B
C
B
Oh
yeah,
yeah,
absolutely
yeah,
and
so
because
contribute
was
cancelled.
There
are
now
you
may
be
aware,
there's
a
visiting
grant
and
so
there's
been
some
efforts
to
to
set
up
in
regional
meetups,
so
one
in
asia
pack,
one
in
north
america
and
one
in
emea
for
the
dev
organization.
B
So
it's
the
engineering
organization
and
there's
a
there's,
a
issue
in
the
document
there,
I'm
kind
of
thinking
why
restricted
to
dev,
it's
regional.
So
I'm
thinking
we
should
at
least
include
product,
you
know
or
anyone
anyone
who's
in
the
region-
and
I
guess
that
in
my
opinion,
that
should
apply
to
the
other
regions
as
well.
C
C
There
are
no
activities
around
product,
but
there
are
activities,
for
instance,
in
berlin,
to
come
up
with
something.
So
that
would
be
berlin,
regional
and
we
would
invite
people
from
whoever
wants
to
travel
to
berlin.
B
But
yeah
well
I'd
love
to
come
to
berlin.
Actually
that's
on
my
list
for
this
year
yeah.
So
I
think
the
the
general
criteria
was
that
it
should
be
a
hub
and
you
know
somewhere
interesting
to
go.