►
From YouTube: Source Code Weekly Meeting (2020-12-02)
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
A
A
That
would
be
great,
I
do
so
in
the
okrs
for
the
department,
and
actually
this
comes
from
the
very
highest
okrs.
I
think
it's
even
on
sids
okrs,
it's
something
that
is
coming
out
of
the
recent
months
of
like
having
a
bunch
of
reports
of
situations
in
the
emergency
grass
in
specific,
where
we
have
these
transient
bugs
or
things
that
happen,
but
doesn't
happen
all
the
time,
some
edge
cases.
A
Some
things
happen,
they're
not
easy
to
test
they're,
not
easy
to
fix,
sometimes
because
they're
hard
to
replicate
from
that
conversation
became
the.
There
was
formed
a
working
group
around
transient
bugs
and
the
idea
there
is
that
we'll
have
a
company-wide
attention
to
this
kind
of
box.
So
the
first.
The
first
step
here
was
to
create
a
bug
label.
So
we
have
a
bug,
colon,
coal
and
transient,
and
that
will
be
a
way
for
us
to
label
the
transient
bugs
that
we
find
now.
A
A
A
Okay,
you
can't,
I
can't
see
them
actually.
I
know
that
we
already
already
closed
one
on
the
code
review
side,
cool
yeah.
There
we
go
bug
transient,
I'm
going
to
put
the
link
to
the
issues
that
way
it's
easier
to
jump
to
them
and,
for
starters,
like
we
already
have
transient
bugs
on
secure
release,
so
there's
a
bunch
of
others
that
go
over
to
other
areas
as
well,
but
right
now
I
think
we're
at
the
at
this
stage.
A
At
this
stage
the
effort
is
majorly
identifying
these,
which
is
daniel's
question.
I
think
they
are
just
normal
bugs
and
they
just
they
might
just
be
higher
on
priority
because
of
this
attention
right,
but
we're
still
going
to
have
this
process
of
triaging.
Where
are
they
affecting
a
lot
of
people?
Are
they
just
a
very
very
bad
case?
Are
they
breaking
anything?
A
A
We
want
to
make
sure
that
this
goes
over
to
other
stages,
so
I
feel
like
at
this
stage,
is
more
about
identifying
them
and
then
creating
issues
for
these
labeling
them
properly
and
then
they'll
just
follow
the
regular
prioritization
and
scheduling
workflow,
not
particularly
special
anything
about
it.
What
I,
what
I
do
think
and
I'm
part
of
the
working
group
as
well,
I'm
a
member
one
of
the
things
we're
discussing.
B
Anyway,
with
the
with
these
ones,
it
might
be,
we
might
have
to
spend
more
time
on
actually
even
identifying
what
happened
right,
because
I
mean
all
we've
really
got
to
work
with
is
logs.
If
we
can't
easily,
if
we
can't
easily
replicate
it
ourselves,
then
we've
got
logs
and
then
from
the
logs
okay.
Now
we
can
create
a
you
know,
a
test
scenario
and
then,
of
course,.
A
A
The
issue
is
this:
applying
a
suggestion
on
the
merge
request
does
not
show
spinner
on
a
resolved
discussion,
so
what
was
happening
was
that
when
you
applied
a
suggestion
to
the
spinner
and
then
it
went
back
to
not
having
the
spinner
and
then
after
a
while,
it
came
through
the
result
right.
So
the
problem
that
we
identified
was
just
because
we
were
having
a
polling
request
coming
back
with
a
response,
while
he
was
applying
the
suggestion
right.
So
that
was
the
fix.
That
was
the
actual
fix.
A
A
So
we
are
looking
at
plug
connecting
the
the
merge
request
with
the
sidebar
making
sure
that
the
those
two
things
react
are
in
sync.
So
if
you
change
the
milestone
in
one
place
in
the
in
the
comments,
it
updates
the
mouse
on
the
sidebar.
Those
are
like
weird
behaviors
that
people
look
at
it
like.
This
is
not
right,
but
it's
a
ux.
It's
a
ux
gap.
It's
not
really
something
that
we've
built
code
to
address
that
it's
just
a
ux
cap.
A
B
A
A
Yeah,
that's
true
some
of
the
times
it's
just
like
a
loose,
and
I
think
this
started
as
a
one
of
those
like
a
loose.
I
don't
know
what's
happening,
like
suggestions
are
coming
back
in
the
is
this
known
channel.
It
happens.
A
lot
like
you
saw
you
see
a
recording
of
somebody
reporting
boom
grab
that
recording
put
it
in
an
issue:
okay,
ready
good
start
yeah,
and
that
would
be
a
that's
a
great
source
for
those
bugs
to
finding
these.
Because
people
complain
about
these
things
all
the
time.
A
It
would
be
great
if
they
complained
with
a
tag.
They
could
tag.
The
source
code,
group
and
we'd
know
immediately,
but
we'll
get
there
but
yeah,
that's
kind
of,
like
my
summarize
some
summary
of
the
transient
bugs
topic
in
terms
of
capacity
for
daniel.
Then
I
feel
like
it's
just
the
normal
capacity
of
bugs.
I
don't
think
they
will
eat
away
the
capacity
of
the
other
bugs
because
they're
like
coming
through
naturally,
but
we
are
going
to
prioritize
this
problem
a
bit
more
than
before.
I
think
that's
the
case.
A
A
C
B
Yeah,
I
was
going
to
say
I
guess,
with
capacity
there's
kind
of
two
ways
to
look
at
it.
One
is
that
they
might
take
longer
to
to
you,
know,
understand
and
resolve,
but
but
but
also,
maybe
we
also
put
a
cut
off
time
on
them.
Like
you
know,
if
it,
if
it
can't
be
replicated
or
then
it
has
at
some
point,
it
has
to
be
yeah
not
closed,
but
you
know
put
on
the
side
until
until
some
more
information
can
come
forward
about
this
particular
issue.
A
C
A
I
think
actively
trying
to
find
them,
because
so
one
of
the
things
that
we
that
we've
felt
with
source
code
in
particular
is
that,
since
he
was
part
of
the
the
now
code
review
domain,
we
were
always
a
little
bit
like
distracted
by
the
code
review
right.
So
even
though
we
were
getting
reports
on
the
source
code,
we
weren't
dedicating
our
sole
attention
to
this.
A
So
I
feel
like
there
might
be
a
lot
of
gaps
of
of
bugs
and
stuff
that
we
haven't
been
identified
and
we're
just
looking
to
improve
the
experience,
and
so
I
would
say
both
like
both
tagging.
The
ones
that
have
been
identified
and
actively
looking
for
them
might
be
useful
because
the
people
are
either
suffering
through
those
silently
not
mentioning
it
to
anyone
or
they
are
just
like
not
can't
be
bothered
to
open
an
issue.
I
don't
know
but
yeah
actively.
It
would
be
also
okay,.
B
A
A
A
B
B
A
A
A
I
would
say
closer
to
like
the
10th
10th
of
december,
something
we'll
probably
start
talking
about
capacity
of
the
team
giving
the
product
feedback
on.
What's
the
capacity
that
the
team
will
have,
the
reason
why
we
don't
do
it
earlier
is
because
deliverables
might
play
a
part
on
this.
Sorry,
the
slippages
might
play
a
part
on
the
capacity.
A
So,
if
there's
a
lot
of
slippage,
they
will
decrease
the
capacity
for
new
work.
That's
why
we
don't
do
it
too
early,
but
we
should
start
having
the
discussions
as
soon
as
we
can
now.
One
of
the
things
that
we're
already
doing-
and
this
is
for
mike-
is
that
pedro
is
already
scheduling
those
exercises
of
the
mural
and
I
think
he's
targeting
at.
I
can't
remember
exactly
when
he
was,
but
he
invited
me
so
I
know
it's
coming
soon
december
10th!
A
A
C
C
A
B
A
So
all
you
need
to
know
for
now
is
that
mike
will
schedule
a
session
for
us.
He'll
give
us
a
link
for
a
mural,
and
what
you
need
to
bring
to
the
meeting
is
five
issues
that
you
would
like
to
see
scheduled,
or
at
least
prioritized,
and
it's
not
always
so,
usually
the
ones
that
are
like
engineering
based
like
tech
debt.
We
don't
include
performance.
A
We
don't
include
because
those
are
going
to
have
to
schedule
them
anyway,
but
it's
kind
of
like
future
improvements,
bug
fixing
stuff
that
you
feel
like
it's
hurting
or
you
just
want
to
scratch
that
itch
or
something
sometimes
like
wishful
thinking.
I
would
love
to
see
this
fix,
or
I
would
love
to
have
this
feature
built.
A
A
B
A
A
A
This
is
what
the
session
will
look
like
right
and
if
this
is
the
issue,
oh
yeah,
okay
right,
so
you
bring
you
bring
five
issues:
okay
and
we
put
like
each
mine
bid
mike
sorry,
sean
who
put
hours
there,
including
daniel
then
we'll
put
his
here
we'll
go
through
a
bit
of
the
meeting.
I
think
takes
an
hour
that
we'll
go
through
each
one
of
these
presenting
them
to
the
team
so
that
we
have
a
brief
understanding
of
what
they
are.
A
Then
mike
will
kick
off
a
voting
session
first
on
importance
and
we
each
select
five
of
the
of
the
ones
that
we
have
here.
They're,
usually
20.
I
think
so
we
go
through
those
and
you
vote
for
five.
You
don't
have
to
add
scores
you're,
just
like
this
is
important.
This
is
important.
This
is
important.
A
This
is
important
and
then
we'll
just
add
them
up,
and
the
ones
that
have
more
votes
of
importance
will
rank
higher
on
the
important
scale
and
we'll
do
the
same
thing
for
feasibility
and
that's
the
other
axis
and
then
we'll
see
more
or
less
the
ones
that
are
higher
here
on
this
quadrant
here
and
those
will
be
the
the
more
important
ones,
but
also
feasible
and
usually
grab
those
take
a
screenshot.
That's
what
I
was
looking
for
and
put
it
on
the
asynchronous
issue
for
planning
and
that
will
just
guide
us
to
the
actual
scheduling.
A
B
A
A
Kind
of
it,
and
then
after
that,
we
usually
what
we
usually
do,
is
we
go
through
after
we
have
all
of
these
daniel
will
compile
like
a
spreadsheet
of
issues
that
we
would
like
to
consider
for
scheduling
and
then
we'll
just
have
to
play
the
the
the
chair
game
see
if
they
fit
or
not
the
capacity.
So
you
say
we
have
30
points
of
capacity
left
for
new
work.
You
have
like
50
points
of
new
issues,
just
have
to
postpone
them
find
a
good
cup,
and
that's
it.
We
usually
do
that
synchronously.
A
We
do
have
a
session
around
the
14
16
of
the
month,
where
we'll
go
through
the
final
list
and
final
short
list
fed
by
all
the
feedback
that
we've
gotten
from
the
prioritization
session.
From
the
discussions
we
have
issues
and
we'll
come
up
with
a
short
list
there.
What
I
recommend
is
having
a
look
earlier
at
like
bugs
and
issues
and
technical
debt
issues
that
we
might
want
to
schedule
from
our
own
side
of
engineering,
because
that
will
you'll
need
to
reserve
capacity
for
those
before
assigning
the
ones
from
the
product.
Okay,
we.
B
A
B
A
Had
cases
where,
after
one
when
milestone
assigned,
we
noticed
that
it
was
far
more
complex
than
we
expected
and
we
decided
to
put
it
in
the
back
burner
and
then
we
put
it
in
the
backlog.
I
think
that
happened
once
and
I've
scheduled,
I
think
I've
I've
planned
like
30,
somewhat
releases
by
now.
I
think
that
happened
once
really
yeah,
it's
very,
very
cool
yeah,
so
that
goes
to
show
that
it
doesn't
happen
a
lot.
A
So
what
I
usually
do-
and
actually
I
think,
the
issue
that
I
linked
there-
the
13.6
source
code
you
can
find
you
can
find
a
comment
that
I
used
to
do
back
then,
which
explains
exactly
my
thinking,
process,
which
I
can
always
we
have
two
minutes,
but
since
we're
chatting,
this
is
what
my
process
looks
for
looks
like.
First,
I
look
at
the
capacity
of
the
whole
team.
I
look
at
what
what's
the
slippage.
I
look
at
any
like
tech
there,
okay,
our
work,
that's
that
and
then
I
give
the
oops
right
yeah.
A
A
Yeah
and
then
out
of
this
three
23
points
of
capacity
we
start
counting
down,
which
is
where,
where
things
get
tricky,
so
we
had
at
the
time
we
had
17
points
of
new
features.
That
leaves
us
six
points
of
capacity,
then
in
support
of
slas
slos
and
okrs
there's
a
couple
of
other
issues
there.
We
wanted
to
consider
that
kept
this
at
-5.
A
C
A
Shortlist
of
tactical
issues
to
consider
that
was
sort
of
something
from
I
think
daniel
as
well.
He
can
he
suggested
these,
then
these
ones,
I
think,
was
mostly
me
coming
up
with
these,
because
one
of
the
things
I've
felt
in
the
past
milestones
is
that
if
we
don't
leave
time
for
smaller
bugs
the
product
feature,
work
will
just
trample
all
of
it
right,
yeah.
Of
course
we
won't.
It
won't
be
able
to
clean
up
the
bugs.
A
So
I
started
coming
up
with
these
lists
of
smaller
issues,
so
bugs
with
two
points
of
weight
bugs
with
one
points
away
just
to
have
them
available,
pre
pre-selected
and
then
out
of
this
whole
list.
We
have
a
discussion
and
we
have
a
discussion
with
with
daniel
and
that's
where
we
choose
right.
This
goes
to
the
next
release.
This
goes
two
releases
down
the
line,
we're
going
to
keep
this
one,
because
it's
important
we're
going
to
make
this
one
important.
You
know
what
I
mean.
A
A
Yeah
so
community
contributions,
mostly
they
come
in
through
the
code
review
capacity,
which
we
don't
really
schedule
for
that
unless
we're
continuing
one
that
already
started
and
shepherding
those
I
would
put
those
in
in
here
right
before
I
get
okay
before
I
give
that
to
product.
So
my
my
concern
is
always
to
give
to
product
the
visibility
all
right.
You
have
23
points
to
of
weights
to
play,
that's
it
and
then
they
and
then
daniel
will
kind
of
like
help
with
the
decisions
about
why
we
make
the
cut
or
not.
A
B
A
One
of
the
things
that
I've
asked
is
give
me
the
number
of
days.
I
don't
need
the
exact
number
of
days
now.
This
milestone
is
a
little
different,
because
I
want
to
make
sure
that
we
have
some
overlap
on
the
holiday.
We
have
make
sure
that
we
have
someone
around,
but
usually
I
don't
ask
which
days
right
up
front.
A
I
just
ask
how
many
days
in
this
period,
okay
and
that's
useful-
that's
easier
for
them
to
come
up
with
yeah
I'll,
take
a
week
and
that's
yeah
sure,
okay
and
they'll,
just
sometimes
they
take
all
in
one
batch.
Sometimes
they
take
it
in
small
batches
multiple
times,
so
that's
up
to
them
cool
cool,
all
right,
it's
a
time
anything
before
we
go
last
minute.