►
From YouTube: 2019 11 19 Memory Team Retro
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).
C
D
A
B
All
right
cool
thanks
everybody
for
joining
and
putting
information
on
the
retro
here.
So
I
really
do
it
real,
quick
and
there
are
about
ten
topics
on
here
number.
Only
two
of
them
got
voted
on,
so
we'll
just
go
top
down
rather
than
bouncing
around.
So
first
topic
is
grooming
sessions.
I
was
one
that
brought
it
up.
Basically
are
just
suggestion.
Setup
grooming
sessions
or
use
office
hours
spend
some
more
time
on
grooming,
individual
issues.
C
Some
I
just
only
know
occurred,
I
mean
a
crack.
It
already
basically
said
the
same
thing
a
month
ago,
yeah.
So
these
sessions
I
act
like
I'm,
really
useful,
because
you
get
different
angles
on
the
same
topic
from
people
with
different
backgrounds
and
yeah,
like
you
said
already,
sometimes
the
issues
are
varying
like
terse,
so
it's
sometimes
yeah
difficult
to
understand
what
the
scope
of
it
is
and
it.
C
F
C
C
D
C
Mean
I
would
say
like
it
needs
to
be
clear,
because
if
you
schedule
something,
you
kind
of
need
to
have
a
vague
idea
at
least
of
how
long
it's
gonna
take
how
much
effort
it
is
so
I
think
grooming
should
help
in
making
it
like
actionable
of
a
story
so
that
anyone
could
actually
pick
it
up.
You
know
just
like
ready
for
development
and,
and
it
should
be
roughly
clear
like
what
the
effort
is,
and
it
can
be
things
as
well
like.
C
C
G
D
So
like
like,
at
least
like
my
perspective
about
like
how
little
Papa
rights
right,
you
don't
think,
oh
when
it's
needed
no,
but
no
by
default
and
technically,
if
it's
unclean
for
you
that
right
there
is
ambiguous.
The
idea
needs
to
be
like
the
comment
in
the
issue
question
to
the
specific
person
if
it's
unclear
further.
D
This
is
when,
like
we
jump
on
the
cone
and
try
to
like
piss
off
that
as
quickly
as
possible,
but
like
the
course
should
be
like
the
last
resort,
you
start
with
the
commenter
synchronously,
then
I
kind
of
go
on
the
swag
and,
as
the
last
resort,
you
kind
of
pull
a
call,
because
Co
is
such
for
you,
like
the
most
interactive
for
everyone's
work
that
you
like.
For
example,
we
we
have
the
import-export
car
scheduled
like
two
days
from
now,
because
we
have
to
align
everyone
to
jump
on
the
car.
D
So
I
would
say
if
Africa
is
clear,
it's
maybe
good
enough
to
write
a
comment
as
the
title
description
of
the
of
like
having
received
that
and
right
saying.
I
am
doing
that.
Okay,
if
someone
disagrees,
is
negative,
three
disagree
so
kind
of
not
looking
for
the
approval,
but
rather
looking
for
a
bad
thing
that
some
of
these
I
did.
Those
disagree
right
with
your
approach
of
solving
that.
So
this
is
it
so
this
is
kind
of
like
money,
perception
of
a
sink
work.
B
Yeah,
it
seems
like
everybody
agrees.
We
want
to
spend
a
little
more
time
on
grooming
issues.
I
think
it's
now
in
can
they'll
kind
of
switch
the
direction
into
how
right.
So,
how
would
we
implement
grooming
so
the
way
I've
done
in
the
past
with
more
synchronous
companies?
Is
you
know?
However?
Often
we
have
a
scheduled
some
companies.
We
did
it
weekly
to
just
make
sure
that
we
had
enough
information
flowing
about
the
work
that
was
upcoming
as
we
would
have
an
agenda
and
say:
hey
we're
gonna
talk
about
these
issues.
B
D
D
So
we
can
ask
her
some
of
the
questions,
so
that
may
be
like
someone
could
spend
ahead
of
the
time
quite
amount
of
the
time
on
trying
to
understand
that
and
us
having
on
the
call
I
think
or
if
it's
needed
when
we
have
me
someone
that
is
like
very
knowledgeable
in
that
space.
So
can
answer
our
questions
and
like
that,
our
proposed
also
make
how
this
could
be
done.
So
maybe
like
starting
with
this,
like
the
bear
of
POC.
It's
like
the
one
of
the
good
ways
to
do
it.
C
So
would
we
say
that
office
hours
is
not
the
time
and
place
to
talk
about
any
of
these
things,
because
I
do
have
mixed
feelings
about
it,
I
mean
because
it's
also
supposed
to
encourage,
like
you
know,
not
strictly
work,
specific
topics
and
it's
difficult
to
tune
out
if
you
are
under
call
a
lot
of
people
who
might
not
want
to
be
involved,
but
I
yeah
I,
understand
that
you
know,
setting
up
more
calls
might
be
more
destructive
in
our
setup.
No
I
think
you
can
still
use
office
hours
for
it.
I.
H
C
Yeah,
it's
actually
not
so
the
way.
So,
on
the
last,
what
sickness
team
I
was
on?
It
was
actually
similar
in
the
sense
that
we
did
have
like
this,
like
standing
meeting
I
think
was
every
Monday
or
so,
but
it
was
like
open
agenda
and
it
was
optional
like
there
was.
It
was
an
optional
invite,
so
you
didn't
have
to
attend
it,
but
anyone
could
put
points
on
the
agenda
to
talk
about
it.
So
the
only
thing
we
asked
team
members
was
to
have
a
look
at
the
have
a
look
at
the
agenda.
C
Is
there
something
you
have
an
opinion
on
that
you
can
have
up
with
and
then
those
people
would
use
that
time
slot
to
talk
about
it.
So
it's
actually
not
not.
Unlike
the
office
hours
we
have
and
that
work
reasonably
well,
because
then
don't
people,
people
don't
feel
forced
to
attend
a
topic
where
maybe
they
don't
have
as
much
insight
into
you
know,
and
it's
not
as
doesn't.
C
B
G
C
What
how
it
was
not
clear
so
and
when
people
said
well,
I
really
need
to
get
my
hands
on
it
and
like
research
it
so
then
we
would
create
these
spike
stories
and
then,
which
is
to
work
over
the
bar
in
the
same
way.
Other
stories
do,
but
the
outcome
was
really
just
a
decision.
Okay,
now
we
have
confidence
on
how
we
want
to
build,
and
then
we
actually
build
it.
So
there
was
something
we've
done.
Yeah.
G
Think
that
it's
important
that
the
result
of
such
meetings
should
be
always
some
kind
of
comment
on
the
issue
right
mm-hmm,
so
to
keep
this
synchronously
like
everyone
who
is
posting,
the
bit
of
agenda
should
be
responsible
for
posting,
some
kind
of
like
result
of
the
meeting
and
appropriate
issue.
We
are
not
going
to
record
it
right
on
do
we
do
we
record
such
meetings
by
the
way,
usually
in
github.
B
B
C
Yeah
I
mean
hey.
This
is
how
we
need
to
be
specific
right.
It's
just
something
you
know
being
new
and
just
came
up
and
I
noticed
some
other
people
had
like
similar
struggles.
So
some
of
these
things,
I
kind
of
learned
by
trial
and
error
in
the
end,
which
is
which
is
good
but
I,
felt
like
the
actual
engineering
onboarding
is
pretty
light.
Like
I
felt,
like
most
of
the
two
weeks,
I
spent
on
kind
of
like
office
work.
You
know
like
very.
E
C
Something
for
like
outside
of
this
group
to
bring
up
also
like
it,
should
soon
mentioned
that
in
the
last
he
pointed
us
to
the
engineering
weekly
review
that
there
was
a
point
around
there's,
also
a
bunch
of
people
who
don't
feel
comfortable
around
Prometheus.
Yet
so
so,
there's
a
couple
like
areas
where
I
think
that
could
be
more
like
knowledge
sharing
be
done,
especially
for
new
joiners.
You
know.
Otherwise
it's
just
you
have
this
overwhelming
mass
of
information
and
it's
very
hard
to
decide
what
to
look
at
next.
C
C
G
C
G
Maybe
we
should
like
big
issues
for
new
team
members
more
precisely
to
control
like,
for
example,
to
pick
some
issues
that
would
be
would
give
a
nice
observation
of
our
product.
I
know,
I
know
it's
something
that
isn't
we
don't
always
have
such
issues,
but
maybe
we
could
help
they
struggle
by
picking
first
issues
very
carefully
planning
to
number
and
trying
to
check.
How
was
it
done?
G
Cruising
yeah
because
I
understand
the
struggle
and
I
would
also
love
to
have
like
some
time
to
have
overall
observation
of
parameters
and
all
this
kind
of
stuff,
but
I
can't
I
can't
see
how
this
could
fit
our
like
company
boarding
home
testing,
especially
since
we
started
in
the
team
already.
So
in
my
previous
eminent
company,
we
had
the
bootcamp,
it
was
like
months.
It
was
very
lonely
and
we
didn't
work
on
a
special
team.
We
worked
with
some
special
mentors.
They
called
boot
camp
members.
F
C
E
C
So
so,
there's
like
any
number
of
ways
yeah,
but
it
could
be
just
by
pairing
up
more
with
someone
who
has
done
all
these
things
before
so
so,
I
guess
the
the
biggest
area.
For
me,
it
sounds
pretty
broad,
but
it's
like
the
current
onboarding.
It's
not
very,
like
workflow
oriented,
there's
a
lot
of
like
different
topics
like
here's,
a
section
about
monitoring
and
here's
a
section
about
merge
requests,
and
but
but
none
of
these
are
really
there's
like
no
workflow
narrative
to
them
right.
C
So
what
I
want
to
see
is
more
something
like
okay,
so
you
know
to
get
wrap.
You
want
to
contribute
something
to
get
that
here.
Are
the
steps
from
A
to
Z.
You
know
from
like
you
know:
it's
setting
up
GDK
through
you
know,
making
a
change,
opening
and
mr
getting
it
into
production,
went
through
staging
and
explained
along
the
way
and
then
monitoring
in
the
end
as
well.
Basically,
all
the
DevOps
stages
right.
So
so
there's
no
yeah.
It's
kind
of
like
ironic
because,
like
that's
probably
and.
H
H
Agree
gate
on
this
one
with
Matias,
because
the
handbook
is
really
detailed
and
there
a
lot
a
lot
of
information,
but
you
cannot
find
the
actual
workflow,
for
example,
from
all
onboarding
things
that
I
read
about
engineering
and
developing
stuff.
The
thing
that
helped
me
the
most
is
the
memory
team
one
on
one
video
we're
like.
Oh
the
whole
process
like
we
were
debugging
we
were
searching
the
logs,
the
merge
request
was
merged
and
Camille
explained.
Like
old
environments.
H
A
D
G
D
Like
that
is
interesting
and
I
believe
quite
unexplored,
fingering
it
dropped
it
because
of
our
remote
nature.
We
don't
really
serve
our
development
like
tricks
that
we
do
how
we
kind
of
like
I,
don't
know
around
Paris
or
like
how
we
even
like
program
things
and
like
how
how
we
test
them
and
I
believe.
But
this
is
my
Samson
like
every
goes
like
those
all
of
that
kind
of
in
their
own
way.
D
We
have
like
setup
and
things
like
that.
So
it's
very
it's
very
hard
to
translate
that.
But
it's
also
kind
of
like
I
guess
inefficient
because,
like
not,
everyone
is
fully
focus
on
like
making
big
workflows
are
efficient,
but
I
would
assume
the
discourse
about
inefficient
in
a
way
how
you
develop
stuff.
D
C
So
okay,
I
mean
that's
a
fair
point,
but
it
is.
There
are
certain
things
that
don't
change
right.
I
mean
how
it
changes
being
deployed,
how
deployment
pipelines
work,
I,
think
it's
just
something
that
should
be
part
of
one
wording.
It
blinks,
you
know
getting
your
contributions
deployed
I
how
to
monitor
them.
That's
kind
of
the
same
for
everyone
right.
It's
a
pretty
streamlined
process.
You
just
need
to
figure.
D
I
mean
the
question
is
like:
do
we
have,
or
did
we
track
if,
like
our
drivers,
description
of
like
the
workflow?
It's
well
documented
because,
technically,
like
everyone
should
be
using
Wartrol
like
worst,
to
indicate
like
the
status
of
the
magic
by
status
of
the
issue
and
whether
turns
are
merged?
It
should
be
automatically
provided
to
you
by
about
changing
the
raipur,
so
maybe
like.
D
We
have
but
more
care
about
the
die,
spec
workflow
staging
happening
on
your
issue,
and
you
can
actually
validate
that
yeah
because,
like
it's
kind
of
like
the
moving
target
like
today,
we
have
staging
like
product,
qunari
and
production,
but
tomorrow
we
have
something
different,
but
like
single
source
of
truth,
my
workflow
labels
is
probably
like
what
we
should
be
optimizing
for.
It's.
C
A
really
interesting
point:
it's
just
like
okay,
I'm,
just
speaking
for
myself
here,
I,
would
find
this
like
extremely
unsatisfying,
because
I
want
to
understand
how
things
work
you
know,
especially
if
something
doesn't
work
you
know
like
if,
for
some
reason
it
doesn't
move
from
like
one
stage
to
the
next
I,
just
kind
of
want
to
look
at
stuff.
You
know.
C
D
You
don't
it
doesn't
really
defy
but
like
having
like
the
starting
point,
just
follow
work
from
labor
strike.
If
you
like
to
get
your
things
vetted
by
marriage
party,
data,
yeah
and
I
assure
it's
like
kind
of
a
good
first
night,
because
they're
like
you,
can
correct
what
is
happening
behind
these
fourth
floor
Labor's.
D
Who
is
assigning
them
well
on
what
circumstances
but
like
having
like
kind
of
a
some
beach
process
for
like
the
newcomers
which
is
kind
of
it
seems
like
this
is
the
trouble
right
now
like
because
so
many
different
stuff
happening
in
the
background
that
is
kind
of
like
hard
to
understand,
at
least
from
what
I
see
hard
to
understand.
Yeah.
G
C
C
Basically
is
we
have
the
handbook,
then
we
have
duct
circuit
lab
calm,
which
is
more
like
a
manual
of
source
right,
forget
that
and
then
we
have
all
sorts
of
documentation
sitting
in
MD
files
in
individual
repositories,
but
they're
not
really
linked
from
anywhere
I
had
a
really
hard
time
like
reconciling
all
that
stuff.
It
wasn't
really
clear
to
me
like
what
what
like
kind
of
documentation,
because.
C
Should
I
turn
to
it
for
what?
Because
the
like
dogs
are
good
like
a
calm,
they
often
cover
things
like
about
configurations,
so
I
think.
Ok,
that
sounds
right.
I
want
to
know
how
to
whatever
like
change
the
number
of
Puma
threads,
but
then
is
written
in
like
very
much
like
an
end-user
way,
and
often
it
only
applies
to
omnibus
and
oh
yes,
super
confusing
quickly,
because
it's
not
clear
like
who
the
audiences
is
I'm
as
a
developer
or
contributor.
C
D
C
D
C
D
B
One
so
I
will
ask
other
managers
if
they've
run
into
the
same
issue
and
how
what
did
they
do?
You
know
that
they
continue
to
focus
on
their
own
teams
onboarding
or
do
they
have
a
list
of
onboarding
templates
I'll
see
what
other
information
we
can
get
and
then
maybe
I'll
ask
on
the
engineering
weekend
review
as
well
see
if
people
are
willing
to
link
out
or
share
their
onboarding
templates.
B
B
Seen
like
most
Nicola
and
Matthias
added
stuff,
I
think
everybody's
added
stuff
to
the
memory
team
onboarding.
So
thank
you
and
we've
actually
I've
had
people
from
other
teams
see
our
onboarding
but
and
appreciate
the
contributions
there
so
yeah
just
making
it
better
for
the
next
person.
The
next
person
might
not
even
be
on
our
team
so
and
it
might
be,
you
know.
Maybe
it's
something
that
comes
out
of
this.
Is
an
entry
in
the
handbook
says:
hey
here's
a
list
of
onboarding
templates.
You
may
find
something
useful,
even
though
it's
not
your
team.
H
C
D
So
this
component,
like
seems
like
at
least
four
years
I,
was
thinking
like
when
I
still
like
manager
of
the
team
of
like
implementing
that
stuff
having
to
make
some
free
time
to
do.
But
it
was
always
a
challenge
like
to
get
it
done
and
like
it
didn't
kind
of
work
out.
In
the
end,
I
I
brought
my
opinion
about
that.
I'm
I'm,
like
in
the
hand
side.
It
seems
like
it's
a
great
idea,
but
like
I
didn't
yet
CD
started
working
like
very
well
in
my
career,
so
I
don't
know.
D
I
would
say
that,
like
the
manger
issue
that
that
people
asked
for
doing,
that
explicitly
is
like
that.
You
are
oversubscribed
and
stuff.
If
you
have
more
free
freedom,
more
time
like
you
always
should
be
able
to
like
to
start
something
on
the
side
like
my
dck
I
started,
disick
a
well
because
I
bet
the
time
because
I
you
for
doing
that,
improve
my
workflow
and
in
my
case,
but
this
is
my
opinion.
D
If
I
would
have
liked
one
three
there
you
like
to
do
whatever
I
want
food,
it
actually
make
me
do
this
kind
of
research
stuff.
He
doesn't
at
least
work
for
me
that
way.
It's
not
like
I
can
say
that
on
that
day,
I
am
doing
this
particular
stuff.
Doing
research,
it's
gonna,
look
more
like
I
have
a
dice.
It's
like
a
three
dice
were
to
do
something,
a
problem
that
is
fun
but
then
I
get
back
to
my
regular
work.
D
It's
not
something
that
is
very
structured,
but
maybe
for
some
other
people
who
do
work
better,
but
always
I
I
find
a
time
to
do
that
when
my
felt
that
I
had
a
little
free
time
in
my
schedule
to
do
stuff
and
every
time
when
I
was
struggling
from
the
getting
my
things
known
watching
it
felt
miserable
and
I
was
not
able
to
do
anything
else
like
that,
because
I
wanted
to
get
my
things
down.
So
at
this.
From
my
perspective,
it's
peace
to
me
more
like
that.
D
C
I
really
like
that
answer,
actually
because
I
also
noticed
that
if
you
have
these
set
kind
of
allocated
time
slots
for
this,
it's
like
yeah
yeah.
It
cuts
into
people's
schedules
right.
So
then
they
kind
of
maybe
even
feel
like.
Oh
I
should
I
be
hid.
Should
I
come
up
with
an
idea
know
you
know
that
you
know
it's
just
to
feel
at
that
time.
That
probably
also
doesn't
ruins.
C
The
opposite,
because
people
they
are,
they
are
different
right
and
I've,
also
seen
the
problem
where,
if
you
make
it
like
to
undefined
like
how
about
these
things
and
people
would
just
never
do
it
because
they
always
feel
guilty
about
it
right.
So
they
always
think
when
I
should
be
working
on
this,
because
that's
more
important
as
a
company
priority.
So
that's
also,
then,
the
potential
that
you
miss
out
on
interesting
ideas,
if
people
just
don't
if
guilty
about
pursuing
them
and
I
think
that's
possible
to
the
other
extreme.
C
So
what
a
good
in-between
as
between
the
two
but
I,
like
the
idea
of
being
generally
open
to
the
idea
that
if
someone
has
a
great
like
gck,
is
such
a
good
example
for
this,
it's
so
useful
and
I
think
it
would
be
good,
as
I
would
like,
as
a
team
to
then
be
able
to
say,
I.
Think
that's
a
great
idea.
I
think
we
should
allow
folks
to
pursue
that
idea
unless
it
interferes
with
project
priorities.
D
C
D
D
D
B
That's
actually
a
topic
for
later
too
there's,
there's
a
topic
about
scheduling
and
pre
assigning,
and
it's
a
follow-up
from
our
previous
stretcho.
So
the
one
thing
I
would
say
about
this
and
it's
gonna
sound
kind
of
wishy-washy,
a
non-committal,
but
as
a
manager,
I'm,
absolutely
supportive
of
innovation
time,
and
it
scares
me
to
death
when
I
hear
specific
numbers
called
out,
because
I've
seen
it
weaponized
in
good
ways
and
bad
ways
that
other
companies
like
nope.
B
This
is
my
20%
time
just
to
use
your
example
Matias,
absolutely
not
picking
on
you,
but
I,
don't
need
to
work
on
this
priority.
Somebody
else
can
because
they
are
to
use
their
innovation
time
and
it's
just
it's
not
healthy
and
I've
seen
it
used
in
other
way.
It's
like
well
I
only
need
to
spend
30%
of
my
time
and
support
and
everything
else
they
do
feature
so
I
would
I'm
in
support
of
this
I'm
struggling
to
find
a
way
to
say
other
than
that.
You
know
be
flexible.
B
C
B
B
No
feedback,
so
it
kind
of
falls
in
line
with
the
asynchronous
planning
grooming.
Try
to
throw
them
out
there
with
themes.
Here's
the
things
we're
gonna
be
working
on
for
the
upcoming
milestone
and
then
fill
in
as
the
current
milestone.
So
planning
is
from
milestone,
plus
one
well
curtain
wall
in
current
milestone,
I,
try
and
throw
in
issues
in
there.
Here's
here's
team,
two
working
on
here's
specific
issues
that
we
should
prioritize
so
that
people
can
discuss
gotten
good
comments
and
feedback
on
them.
B
C
C
B
So
dev
support
rotations.
We've
talked
about
this
a
little
bit,
trying
to
think
of
actionable
ways
that
we
can
do
this
because
right
now
we're
kind
of
in
the
middle
of
you
know:
Alexian
Nicola,
focusing
on
import
and
export
and
continue
and
Mattias
focusing
on
sidekick,
so
how
we
would
balance
that
with
incoming
bugs
and
we're
a
little
different
as
the
memory
team
bugs
aren't,
gonna
come
in
as
frequently
I
would
think
as
a
feature
team
right.
It's
going
to
be
they're.
B
Gonna
kind
of
ramble
in
it's
gonna
be
less
of
a
direct
line
to
the
memory
team.
So
looking
for
ideas
or
thoughts
on
how
or
if
we
should
even
do
this,
there
was
one
jobs
up
thanks,
40s
any
ideas
or
any
thoughts
on.
If
we
should
formalize
this
or
are
we
okay
with
continuing
on
with
having
general
themes
and
folks
assigned
to
it
and
taking.
B
G
First
of
all,
I
don't
think
it.
We
are
ready
to
formalize
it
at
our
current
point,
because
we
are
still
still
not
clear
about
our
like
expletives
fields
of
everything
number
and
our
goals
are
still
aligning.
We
just
recently
started
import/export,
so
I
feel
like
it's
better
to
apply
our
best
judgment
in
place
when,
when
some
issue
comes
up,
we
probably
know
who
will
be
the
best
fit
to
to
start
working
on
at
least
maybe
put
more
resources
from
team
members.
So
I
I
don't
feel
like
I
need
formalization
process.
The
person
yeah.
C
C
B
B
See
so
from
our
last
retro,
the
feedback
was,
we
were
almost
over
subscribing
by
assigning
prior
to
the
milestone
signing
as
much
as
we
thought
the
team
could
take.
An
individuals
could
take
from
a
capacity
standpoint,
so
I
think
it
was
twelve
five
tried
to
assign
a
50%
right
and
I
just
want
to
get
some
feedback
on
that.
The
the
reason
I
put
this
into
here
is
there
were
a
couple
times
where
folks
were
saying
what
do
I
work
on
next,
so
it's
an
indicator
that
our
workflow
is
not
very
well
defined
at
the
moment.
G
The
only
point
I
have
like,
usually
when
I'm
creating
an
issue
like
follow
ups
and
stuff
I
usually
assigned
to
myself,
which
is
not
correct,
I
believe,
but
it
happens
automatically
for
now.
I
just
notice
that
I
just
feel
that
it's
not
easy
to
understand
it.
So
I
give
you
a
scent
already,
so
I'm
I'd
rather
say
it's
better,
not
to
assign
everything
up
front
because,
like
probabilities,
could
change
and
you
feel
like
you-
could
even
block
the
issue
for
someone
else.
G
For
example,
I
have
a
number
of
issues
and
for
import/export,
but
then,
for
example,
some
bugs
popped
up
that
I
should
fix
and
new
team
member
could
overlook
the
issue
assigned
to
me
thinking
that
I'm
working
on
that
or
we
need
additional
synchronization
for
that.
So
I'd
say
it's
better:
to
assign
only
items
you're
going
to
work
very
soon.
They
so.
D
C
Fell
into
the
same
trap,
where
I
created
a
couple
issues
that
came
up
because
they
were
problems,
you
know
related
to
psychic
or
something,
and
then
they
shown
up
shop
in
your
lane
as
well
on
the
board,
and
it
gives
you
this
bias
as
well
that
oh,
it's
assigned
to
me
I
should
be
working,
but
it's
kind
of
like
just
something.
You
know
you
broke
up
yourself
from
another
story
and
never
actually
went
through
the
planning.
Yes,.
E
C
And
yeah,
it's
really
hard
to
get
out
of
this,
so
I
actually
agree.
So
I
fell
into
his
trap.
Myself.
I
think
we
shouldn't
probably
do
that,
and
just
just
it's
good
to
capture
these
issues,
but
then
I
should
go
in
the
backlog
first,
so
they
go
through
the
whole
coming
process
so
that
you
focus
on
the
stuff
that
actually
needs
to
be
done.
I
also.
G
Feel,
like
sorry,
I
also
feel
like
this
sidebar
Tobar
would
happen.
Give
up
with
our
issues.
To
do
sense,
not
request
is
actually
a
really
useful
tool
for
your
workflow.
That's
why
I
would
like
to
keep
it
minimal
to
not
have
too
many
most
requests
and
too
many
issues,
and
one
of
these
ones
I
need
to
take
action.
So
it's
like
my
to-do
list,
injury,
which
is
fine.
D
If
there
is,
there
is
also
another
truck
which
is
the
milestone,
because,
like
a
lot
of
stuff,
we
assign
mice
on
the
current
milestone
or
the
future.
My
son's
alright
I,
don't
know
what
is
the
answer
for
that,
but
probably
like
some
of
these
items
could
still
be
like
faculty,
big,
hairy
paw,
but
some
of
them
kind
of
light
blue.
So
are
the
importance
when
you
saw
that
like
issue.
C
I
think
unless
it
really
blocks
you,
if
neither
immediate
progress,
I,
don't
think
we
should
actually
add
it
to
the
current
milestone.
I
know
I've
done
it
myself,
and
but
that
was
probably
not
a
good
idea,
because
I
also
noticed
that
some
of
those
issues
that
I
broke
out
from
existing
ones,
but
they
didn't
really
need
to
eat
it,
to
be
working
right
away.
So
they
had
me
a
sign
on
it.
C
G
I
usually
assign
it
to
come
as
soon
as
well,
which
is
not
good,
I
agree
with
Mattias,
because
all
just
like
missed
issues
are
important
to
understand
like
that.
The
over
plant
that
we
had
some
issues
mid-cycle
sunburn
chart
is
not
working
well,
but
we
shouldn't
assign
it
on
the
card.
So
I
guess
unless,
like
it's
bug,
fixed
or
immediate,
if
I
think
you're
going
to
follow
up
closely
after
acquisition,
humans.
B
Maybe
we
could
add
that
to
the
agenda
meeting
agenda
new
issues
that
have
come
in
then
there
are
some
upcoming
features
right
about
issue
dependency.
That
may
help
us
to
better
understand,
because,
right
now
we
can't
it's
it's
hard
to
link
issues
together
and
say
that
this
one
is
blocking
that
one.
All
we
really
have
is
a
related
feature,
something
that
would
helpless
help
us
to
understand
dependencies,
how
much
we're
adding
to
the
issue.
Sorry,
how
much
we're
heading
to
the
milestone
when
we're
oversubscribed
so
I
think
some
of
those
new
features
will
help.
H
Yeah
I
agree
with
Camille
about
like
assigning
yourself
to
the
issue
should
mean
like
that
you're
working
on
because,
for
example,
alexei
now
has
issues
for
import-export
and
all
sub-issues
assigned
to
himself
and
now.
I
am
also
signed
to
some
of
them
and
I.
Guess
it's
not
really
clear
who
is
working
on
what
so?
Yes,.
B
Yeah
I
think
it's
okay
to
unassign
yourself
and
if
you
know
something
not
going
to
make
it
in
the
milestone,
kick
it
out
all
right.
So
we
don't
get
those
missed,
deliverable
labels,
which
you
know
other
companies
I've
worked
at
where
they
follow
strict
from
being
you
have
discussions
about
velocity
and
why
things
were
missed,
and
that's
just
that's
not
a
thing
here.
So
don't
feel
bad
about
moving
issues
around
all
right
and
I've.
Already
added
to
the
weekly
meeting
template
bullet
point
to
talk
about
in
New
York
created
for
the
week.
C
I'm,
sorry,
to
remind
myself,
please
yep
yeah,
you
know
what
we
would
kind
of
cover
this
I
think
by
just
talking
about
how
we
go
about
planning
because
yeah
yeah.
It's
like
these
smaller
things
that
we
find
while
working
on
something
else.
We
break
out
a
bunch
of
new
ones,
but
maybe
they're
like
not
super
important
straightaway,
right
and
so
yeah
I
think.
We've
basically
said
what
we
would
do
right.
We
put
it
in
a
future
milestone
and
then
we
can
just
reprioritized
again
she'll
be
coming.
B
They
have
gone
to
more
of
a
weekly
cadence
and
following
a
little
more,
the
Kanban
workflow.
So
if
folks
haven't
read
this
now
or
folks,
I'm
read
this
prior
to
I
talked
about
it's
just
something:
to
read
different
way
to
look
at
things.
It's
I'd
say
we're
trending
a
little
more
closely
to
this,
because
I
do
have
weekly
meetings
with
Josh,
where
we
talk
about
prioritization,
make
sure
if
anything
new
is
coming
in
memory
team
and
the
other
team
that
works
with
the
were
aware
of
it.
B
C
Yeah
I
mean
this
kind
of
goes
hand
in
hand
with
the
discussion
made
earlier
about
grooming
as
well
right
I
mean
it's
not
the
same
thing:
I
guess
yeah,
so
so,
maybe
maybe
to
make
this
distinction
clear,
grooming
from
me,
or
actually
an
issue
description.
The
original
issue
description.
It
shouldn't
actually,
in
my
opinion,
describe
exactly
how
we
gonna
resolve
it,
but
only
what
the
goal
is
like
what
should
be
done?
What
should
the
outcome
be?
C
E
C
A
C
C
D
So
like
what?
What
did
work
for
me
in
the
past
mm-hm
is
like
the
tissue
description.
Had
the
problem
to
solve,
had
the
proposal,
how
to
solve
the
problem
and
had
assumptions
behind
like
the
proposal,
because,
usually
that
you
eat
and
I
quit
purpose
a
design
of
something
based
on
like
some
assumptions
of
the
design,
and
this
is
what
he
was
like
good
enough
and
I
for
implementation
was
very
part
of
their
magic
waste
description
like
because
he
was
implementing
the
specific
design
based
on
the
specific
assumptions.
D
But
it
seems
that,
like
also
today,
like
a
lot
of
time,
there
is
like
discussion
about
like,
like
the
implementation
on
the
issue,
but
more
into
the
comments
of
the
issue,
but
not
really
in
the
description
of
the
issue.
Description
like
usually
seems
to
indicate
like
the
single
source
of
truth,
what
we
are
implementing
for
who
and
for
what
purpose
and
like
what
is
our
design,
but
doesn't
like
go
to
detail
exactly
about
like
implementation,
because
this
is
very
like
that
it.
What
is
part
of
them
at
cheapest,
sure.
C
D
So
like-
and
this
is
a
tricky
part,
because
what
happens
very
often
today
is
that
you
start
might
request.
The
description
of
the
of
memory
has
become
master,
because
a
lot
of
the
good
like
discussion
is
on
the
comments.
So
you
don't
update,
request
description
and
you
also
don't
update
the
issue
description
exactly
on
what
is
implemented
so
technically
like
for
the
sake
of
completeness.
D
That
kind
of
fork
from
this
one
documenting
like
specific
aspects
that
were
not
covered
by
the
original
issue,
so
there
ISA
I
think
a
lot
of
housekeeping
the
like
we
are
not
doing
is
like
and
sharing
it
that,
like
the
description
of
the
night
requests
in
the
description
of
the
issue,
actually
reflects
the
truth.
I
just
wanna
say
a
single
source
of
truth
of
what
is
actually
being
done,
because
then
it's
much
easier
for
everyone
to
understand.
From
the
p.m.
perspective
from
the
high
level.
It
looks
like
the
issue
from
the
engineer.
F
C
D
Don't
know
the
answer
for
that,
but
it
really
depends
on
like
what
level
is
that,
usually,
like
you,
have
some
rough
idea
how
it
can
be
implemented,
so
you
can
kind
of
read
different
approaches
for
implementing
that
on
the
on
the
issue
as
part
of
the
comment
and
kind
of
like
documenting
based
on
these
sort
of
the
assumptions.
For
example,
if
we
look
at
the
memory
killer's
IQ
molecular,
one
of
the
assumptions
would
be
interest
are
the
separate
thread.
It
doesn't
look
at
the
middleware.
D
C
I
think
we
should
be
able
to
challenge
these
assumptions
like
because
so
I'm
just
worried
that
someone
will
pick
up
this
issue.
Let's
say:
I
brought
this
issue
and
eyebright
the
assumption
is,
it
runs
on
a
separate
thread.
Someone
else
might
pick
it
up
and
take
this
as
that's
how
they
should
be
doing
it.
Maybe
that's
not
the
best
way
yeah
so
because,
well,
it's
not
the
goal.
For
this
thing
to
run
its
own
thread.
The
goal
is
to
be
reliable
and
kill
another
process
that
runs
out
of
memory
right.
It.
D
Really
depends
on
how
you
look
at
that
because,
like
each
of
these,
things
can
be
solved
in
different
ways.
Now,
if
you
propose
a
design
of
something
that
is
solves,
that
particular
problem,
he
also
kind
of
make
some
design
choices
and
you
build
it
or
some
assumptions.
You
cannot
say
that
if
you
remove
this
assumption,
this
design
gonna
be
Steve
audit.
You
need
to
reevaluate
the
design.
That's.
D
So
I
guess
like
the
issues
and
minesweepers
they
are
not
set
in
the
storm.
So
if
someone
wrote
that
in
the
past
he
doesn't
have
to
apply
in
some
one
piece
that
so
it
has
to
be
like
this
one.
He
would
ask
like
person
peeking
that
to
like
to
revisit
that
and
ensure
that
is
clear,
that
it
still
sound
in
the
Koreans
like
architecture
and,
if
he's
not,
it
does
change
the
design
and
change
their
Samsung.
It's
about
setting
this
tone
yeah.
C
C
B
C
All
read
earlier:
if
we
find
that
that
assumption
we
had
made
or
proposal
we
had
made.
If
we,
if
we
want
a
child
I,
think
everyone
should
be
able
to
challenge
that's
right,
and
then
we
can
maybe
even
before
we
start
developing
and
make
sure
that
once
it
leaves
this
column,
you
know
problem
and
solution,
validation
that
we're
really
on
the
same
page
about
okay.
So
we
know
how
we
want
to
build
this
and
surely
I
will
always
be
more
questions
that
come
up,
but
at
least
the
general
there
would
feed
the
fun
yeah.
B
I,
like
cameos,
this
suggestion
is
something
we've
talked
about
before
making
sure
the
description
stays
up-to-date.
The
one
thing
that
I
find
a
bit
frustrating
is
when
you
update
the
description,
there's
no
notification
that
the
description
is
updated,
so
people
won't
notice.
So
if
you
really
want
folks
to
read
like,
if
you
add
some
assumptions-
and
you
want
some
validation
on
you're
gonna
have
to
add
a
comment
to
the
issue,
so
that
folks
will
know
that
the
description
is
changed.
If
you
want,
you
want
people
take
a
look
at
it.
D
D
B
D
Like
probably
like
some
some
point
in
the
future
is
gonna
probably
would
be,
but
at
least
you
can
now
see
like
what
was
the
change
historically,
that's
great,
because
this
is
because
this
was
kind
of
like
the
missing
piece,
but
like
years
what
he
was
editing,
we're
moving
or
content
I'm
losing
these
sort
of
content,
which
is
kind
of
not
nice,
but
now
there
seems
to
be
some
feature
that
you
can
actually
and
maybe
III.
Don't
know
how
useful
is
that,
but
it's
really
like
the
first
step.
I
think
like
this
verse
one.
D
B
Our
image
that
feature
from
JIRA
being
able
to
see
what
change
in
the
description,
so
even
on
things
that
I
changed
I,
maybe
forgot,
they
changed
yeah.
That's
awesome!
Okay,
any
of
anything
else
to
talk
about
on
that
topic,
so
I
agree
a
general
concept
story,
kick-outs
I!
Think
the
next
big
one
that
we'll
have
that's
been
talked
about
recently
is
probably
the
web
hooks
WebSockets.
Sorry,
once
we
get
to
that
project,
because
we
still
have
quite
a
bit
more
work
to
do
with
important
export,
but
we
should
have
an
asynchronous
story.
B
Kick
off
on
WebSockets,
say:
hey
we're
going
to
start
working
on
this.
There's
the
goals
and
folks
can
ask
questions
prior
to
being
expected
to
work
on
it.
Right
need
to
have
a
better
understanding
and
some
slow
on-ramp
in
the
new
storage,
rather
than
here
shooting
story
and
start
working
on
it
today.
I
think
gin.
You
can
tell
us
some
horror
stories
about
some
of
the
omnibus
work
that
you
did.
Yeah.
B
All
right,
if
there's
nothing
else
through
a
line
item
in
here
about
training,
your
conferences
really
just
add.
If
you
have
anything
you
want
to
go
to
it's,
not
a
commitment,
it's
not
it's
not
going
to
be
approved
or
denied
on
when
you
put
it
in,
which
is
for
budgeting
purposes.
You
need
to
know
what
conferences,
what
what
trips
people
want
to
attend
so
that
we
can
have
a
rough
idea
for
the
year.
B
This
is
pretty
empty
right
now,
the
to
answer
your
question,
the
tsum,
Postgres
sequel,
is
still
going
to
be
available
for
everybody
once
I,
actually
land
on
a
vendor.
We
decide
on
the
vendor.
I've
gotten
feedback
from
one
I
reached
out
to
a
bunch
I've
only
gotten
detailed
feedback
for
one.
It's
pretty
good.
We
may
end
up
with
them,
but
I
need
to
ping
some
more
people,
I'm
trying
to
nail
that
went
down
for
December
that'll
be
available.
B
C
Today,
to
my
to
my
dismay
that
they
used
to
be
this
website
called
lanyard,
which
was
it
was
great.
It
was
like
this
kind
of
social
network
for
conferences
so
that
people
could
put
like
list
of
conferences
they
go
to
and
stuff.
That
was
great
for
discovering
interesting
purposes
and
it's
down
like
it's
been
shut
down.
Oh.
H
D
D
Is
that,
like
you,
can
use
that
in
this
month
and
you
can
Expensify
if
you
have
they
received
for
this
month,
you
can
ask
for
like
using
that
in
the
next
month,
but
you
should
send
information
on
my
request
to
some
email
address
that
is
in
our
handbook.
So
technically,
if
you,
if
you
know
that
regular
than
I
use
the
dinner
this
month,
you
can
still
use
that
in
the
December,
but
you
need
to
just
send
it
format
or
email,
so
I
think
it's
a
PID
cupboard
comb,
but
I.
Think
thanks.
B
You
have
until
the
22nd,
if
you
want
to
request
a
one
roll
over
to
you
to
Camille's
point,
you
can
roll
it
over
once.
So
you
can
accumulate
two
months
right.
I
think
you
can't
wait
a
year
and
then
go
spend
$1,200
on
the
dinner.
They're,
not
gonna
support
that.
But
if
you
feel
you
can't
make
it
for
the
month
then,
prior
to
the
22nd,
you
can
submit
a
request
to
say:
I
went
all
over
and
the
rest
of
the
details
are
in
there.
So.
A
D
Number
submitting
the
meal
like
no
like
22nd
is
like
that
date.
It
was
like
you
have
to
send
the
information
that
you
want
to
run
over
that
yes,
yeah,
like
yeah
like
you
can
you
can
use
that
like
food
and
Hamas
or
like
it
can
be
like
really
31st
but
like
in
the
past,
I
was
able
like
to
my
quickness
in
the
31st,
because
I
know
that
I
don't
can
I
use
that
all.
B
G
A
bit
related
question
to
labels
and
posted
that
another
issue
where
what
went
well,
what
didn't
end
well,
the
question
is:
how
do
you
sleep
rebels
because
for
me
it's
still
like
very
random
process.
I
know
like
group
memory
and
devotes
enablement
are
essential
for
us,
but
what
about
other
way
was
like
which
describes
official
I
should
I
put
boss
project
important
project
expert
when
I'm
fixing
import
like
it's
not
clear,
do
we
have
some
guidelines
who
might
be?
Are
we
going
to
improve
the
process
of
selecting
labels
for
the
issue?
G
B
Answer
for
them
and
other
companies
that
we
just
use
it
for
search
ability
right
in
categorization.
The
only
thing
that
I
would
be
aware
of
is
the
group
labels
right
because
that's
going
to
dictate
the
which
teams
working
on
them
and
probably
affect
their
board.
So
like
group
memory
that
drives
all
of
our
boards
and
if
you
put
a
group
memory
label
on
there
and
don't
put
the
DevOps
label
eventually,
the
the
get
bottom
will
add
that
DevOps
label
to
it
as
well.
So
in
those
work
section
you're
in
yeah.
G
My
ideas
that
have
have
builds
sociability
is
worse
than
no
sociability
at
all,
I
mean,
if
you
put
on
the
labels
randomly
and
you
will
not
be
able
to
rely
on
that
search.
So
we
should
eyes
are
like
set
I
would
say,
epoch
some
more
importance
and
labels
in
our
case,
I'm
willing
to
exist.
Our
epics
are
good
for
discoverability
of
similar
issues
and
supports
for
labels.
B
G
G
Yeah,
just
just
a
small
note:
I
noticed
that
we
don't
usually
feed
our
like
so
two
minutes
on
Monday
I
know
that
ideally
we
want
to,
but
maybe
we
want
to
risk
the
process.
Maybe
we
want
to
I.
Don't
know
like
goes
through
agenda,
not
issue
by
issue
because
we're
usually
not
covering
them,
and
since
we
are
going
in
like
created
order
created
by
order
it
doesn't
it,
we
could
easily
miss
something
important.
So
maybe
we
should
go
by
epics
first
and
then
by
issues.