►
From YouTube: Plan | 2021-07-07 Weekly Team Meeting
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
So
on
like,
for
instance,
a
big,
a
big,
a
big
thing
would
be
well.
We
cannot
do
this
because
this
will
block
sharding
we
we
will
not
be
able
to
shut
it.
This
way,
then
further
down
the
line
or
something
like
that,
then
you
kind
of
know
that
you
cannot
go
that
way
anymore
and
I'm
like
more
like
things
like
that
is
what
I'm
looking
for,
but
yeah.
B
A
Today,
so
just
to,
as
we
started,
recording
later
I'll
vocalize
mine,
so
first
congrats
to
all
the
promotions
this
week
it
was
a
busy
one
I'd
seen
and
it
was
nice
to
see
so
yep
congrats
to
everyone.
A
And
then
the
next
one
is
on
custom,
work,
item
types
and
custom
widgets
and
all
that
fun
stuff.
I
was
trying
to
do
some
pocs
on
the
data
structure
and
testing
out
how
it
would
perform
with
some
amount
of
data.
So
basically
I
was
looking
at
two
main
directions:
basically
like
eav
and
json
b
options
and
I've
laid
it
down
in
the
in
the
issue,
being,
I
think,
ping
p
back-end
plan
and
database
teams
not
sure
if
database
team
will
be
coming
in
soon
because
they
have
a
lot
of
their
play.
A
But
it
will
definitely
be
something
that
I
would
look
for,
because
that
is
what
is
affecting
the
the
most.
I
guess
the
database
scalability
and
performance
so
yeah
feel
free
to
leave
your
feedback.
A
So
but
yeah
like
I
mentioned,
I
think
there
might
be
a
couple
things
that
can
be
already
taken
out
of
that
pocs,
something
that
we
can
move
on
with
like
defining
these
metadata
for
the
widgets
and
defining
like
which
widget
belongs
or
will
be
displayed
on
which
issue
type
and
stuff
like
that.
So
even
even
before
we
start
adding
custom,
widgets,
defining
or
customizing
the
work
item.
Types
with
the
current
widgets
is
still
a
problem
that
we
would
need
to
solve
sooner
rather
than
when
we
get
to
the
custom
custom
widgets.
A
C
B
C
A
A
B
I
think
the
pocs
are
awesome
because
it
helps
teach
out
the
data
model
and
I
was
just
going
to
say
I
think
at
least
for
a
while.
The
majority
of
widgets
will
be
fine
to
be
defined
by
us
and
have
a
schema
like
we
can
define-
and
I
think,
follow
up
on
john
what
you
said.
It
feels
like
we're
trying
to
solve
too
many
things
right
now.
B
I
personally
like
that,
we're
thinking
in
terms
of
idealized
design
working
backwards,
and
then
I
also
just
wanted
to
reiterate
that
we
aren't
doing
custom
fields
attributes
until
further
down
the
road.
I
think
the
most
important
thing
to
get
right
now
is
a
data
model
behind
the
widget
work
item,
associations
and
a
perfect
example
is
we
want
to
launch
default
issue
types
or
work
item
types,
the
monitor
team
implemented
the
severity
widget.
I
would
want
the
severity
widget
to
be
on
a
bug.
B
For
example,
the
bug
issue
type
right,
but
we
wouldn't
want
it
to
necessarily
be
like
on
a
feature
or
something
else,
because
a
feature
is
not
going
to
have
the
severity,
but
a
a
bug
will
so
I
don't
know
how
they
implemented,
that
I
think
they
tied
it
to
the
issuable
model.
B
That's
also
something
to
consider
too,
when
we
think
about
widgets,
and
things
like
that
is,
there
are
other
teams
that
have
built
issue
types
on
top
of
the
issuable
and
on
top
of
the
issue,
I
think
vulnerabilities
is
an
example
too
and
sort
of
like
how
can
we
take
sort
of
par
part
of
why
we're
trying
to
solve?
B
This,
too,
is
for
our
own
use
cases
where
another
team
might
want
to
quickly
build
a
type
of
issue
that
has
certain
types
of
widgets
right
and
we
want
to
be
able
to
reuse
those
widgets
other
places
like
I
wish
that
the
mr
reviewers
was
a
widget
that
was
built
to
the
issue
against
issuable,
so
he
could
order
automatically
use
it
easily
on
issue
right,
but
it's
not
so
I
think
that's
like
that's
a
foundation
we'll
look
for,
and
then
after
that,
we'll
think
about
like
custom
things
right
to
me,
like
it's
an
issue
or
a
work
item,
type
name,
that
someone
can
customize
they're,
just
changing
the
name
like
right
and
then
eventually,
maybe
they
can
turn
widgets
on
and
off.
B
D
So
are
we,
are
we
still
working
on
work,
item
types
or
issue
types,
or
has
that
been
chilled
or.
B
Yeah,
it's
it's
still
the
found
foundation,
I
think,
of
what
we're
doing
for
the
whole
like
initiative
of
having
a
feature
right,
we
still
need
to
have
types
of
work
items,
so
I
think
that's
where,
like
that,
is
an
opportunity
to
add
some
incremental
value
as
we
work
towards
a
bigger
goal:
okay,
cool.
D
E
I
think
some
of
the
concern
from
the
database
team
was
around
the
idea
that
what
we're
doing
looks
an
awful
lot
like
single
table
inheritance,
which
is
discouraged
but
well,
we
use
a
column
called
issue
type
like
had
it
been
called
anything
else.
It
might
not
have
rung
such
alarm
bells,
and
it's
really
just
a
coincidence.
These
are
really
just
work.
Items
are
really
just
what
we
now
call
issues
with
different
labeling
attached
right
I
mean.
A
E
Have
different
like
features
or
widgets
or
whatever
you
want
to
call
them,
but
they
all
broadly
share
broadly
share
these.
E
These
widgets,
like
you
know,
yeah
like
this
one
might
not
have
a
due
date,
but
it
could
have
a
due
date
right
like
it's,
it's
just
hidden
in
the
interface
or
or
maybe
it
may
be
deeper
down,
but
it's
nevertheless
just
hidden,
and
so,
if
you
think
about
it,
that
way,
it
doesn't
seem
so
bad
like
it
doesn't
seem
like
such
a
contravention
of
our
documentation
that
we
would
have
it
in
the
issues
table.
A
A
If
you
model
it
in
a
way
that
it
stores
very
different
objects,
and
then
you
need
them
to
be
referenced
in
a
different
table,
then
you
cannot
do
that
and
and
what
we
are
doing
with
the
issues
table
in
this
case
is
not
really
that
it's
like
you
can
reference
it,
and
because
this
issue
type
is
not
a
hard
corded
thing,
it
can
change
from
one
type
to
another.
You
can
actually
reference
the
id
of
an
of
a
bug
to
a
requirement
because
it
can
later
on
become
a
sub
requirement,
or
something
like
that.
A
So
it's
not
really
a
single
table
inheritance.
In
this
case,
I
don't
think
but
yeah
it's
good
to
get
feedback
to
get
them
aligned
just
to
make
sure
we
don't
create
any
issues
further
down
the
line,
but
I
think
we
should
be
fine.
E
E
Why
not
keep
these
things
in
separate
tables
since
we're
already
having
problems
with
the
size
of
tables
the
amount
of
things
being
stored
in
the
table?
But
but
that's
the
thing
like
we're,
not
just
moving
the
data
in
there
for
the
fun
of
it,
we're
actually
in
the
interface
and
in
the
application,
and
then
every
way
you
can
think
about
it,
we're
consolidating
what
these
items
are
and
how
they
work.
And
so
it's
not
it's
not
a
bad
architectural
choice,
and
that,
in
this
case,
is
probably
a
good
one.
A
Like
I
don't
think
we
are
conflicting
with
sharding
like
I
don't,
I
don't
think
we
have
a
decision
on
how
we're
going
to
chart
yet.
I
think
there
is
a
ongoing
effort
to
vertically
shine
first
and
then
we'll
see
if
we
can
do
like
by
name
space
and
shock
horizontally,
but
this
also
can
align
fairly
well
with
them
partitioning
the
issues
table
by
the
issue,
type
for
the
like
you
shot
it
by
namespace
id,
for
instance,
and
then
partition
it
by
issue
type.
A
I
I
don't
know
how
this
will
break
out,
but
I
don't
think
we're
blocking
in
that
regard,
but
again,
just
because
this
is
such
a
huge
effort.
It
is,
it
will
be
nice
to
to
get
the
database
and
maybe
the
sharding
team
aligned
on
what
we
are
going
to
do,
what
we
plan
on
doing
from
the
high
level
perspective
and
then
they
can
chime
in
and
sorry,
that's,
that's,
okay
from
their
perspective
or
not
really.
Okay,.
D
I
I
like
that
we've
kind
of
laid
out
the
tables
a
little
bit
or
got
a
got,
an
idea
of
that,
because,
particularly
from
from
a
non-optimization
point,
and
now
we
can
take
smaller
pieces
of
it
and
start
figuring
out
how
to
optimize
that
with
the
database.
It's
one
thing
to
lay
out.
You
know,
okay,
this
is
ideally
what
we
want.
This
is
the
kind
of
interaction
we
want
the
kind
of
data
we
want.
Now.
How
do
we
actually
store
that
performantly?
D
How
do
we
access
that
is
it?
Maybe
it
really
is
many
many
smaller
tables,
or
maybe
it
is
one
giant
table,
but
I
think
what
you
put
together
is
a
good
step
in
terms
of
understanding
overall,
what
we
really
need
in
this
and
all
the
problems.
A
D
C
Step
always
mine-
I
just
wanted
to,
as
we
were
just
talking
through
this,
and
we
will
need
more
ideation
on
this
as
well.
Do
we
need
to
create
different
types
of
widgets
that
some
may
be
for
data
entry,
so
a
lot
of
like
health
status
and
some
of
the
others
where
you're
actually
putting
data
in
or
it's
giving
you
options
like
a
a
small
app
and
then
the
other
ones
which
would
do
roll-ups
or
calculations
on
the
data?
C
C
A
I
I
briefly
looked
and
looked
at
notions,
interface
or
how
they
are
going.
A
I
don't
have
a
solution
for
that,
but
I
think
that's
something
that
we
can
tackle
once
we
get
into
widgets
themselves,
implementing,
widgets
and
and
doing
stuff.
It
should
not
be
too
different
from
a
simple
field
sort
of
thing.
It
will
have
some
logic
behind
it,
but
in
terms
of
data
structure
and
so
on,
I
don't
think
that
influences
our
decision
on
how
we're
going
to
design
the
data
structure
to
hold
the
different
widgets.
A
Now
it
will
be
specific
to
every
widget's
implementations
of
the
sort
of
thing,
but
yeah,
I
think
notion,
only
does
roll
ups
for
a
single
level
or
something
like
that.
You
can
pick
a
relation
and
then
do
the
sum,
but
you
cannot
use
that
calculated
field
now
in
the
next
level
kind.
C
Yeah,
it's
flexible
in
that
it
lets.
You
add
relations
to
a
multitude
of
things.
If
you
want
to
but
you're
right
when
it
does
a
calculation
on
a
column
that
doesn't
live
in
the
db,
that's
kind
of
in
real
time.
You
can't
go
reference
and
pull
the
calculated
value
again,
so
it
would
be
cool
if
our
fields
could
handle
that
yeah.
A
C
B
Yeah
in
the
extensible
issues,
epic,
that
I
kind
of
put
together
a
while
ago,
I
kind
of
split
out
the
two
two
different
kinds
of
widgets.
One
would
just
be
like
fields
that
kind
of
hold
data
right
and
then
others
that
were
like
apps,
which
were
like
more
complex
widgets
that
maybe
tie
into
other
parts
of
the
product
would
be
roll-ups
or
calculations
or
that
sort
of
thing.
B
I
also
did
some
research
on
notion
and,
if
supposedly
they're
using
postgresql,
which
is
like
from
mongodb,
it
has
great
support
for
calculated
fields
for
rollups,
like
that.
So
I
think
it'll
be
harder
to
support
its
scale
with
our
current
stack
based
on
my
limited
understanding.
But
I
do
think
that
if
we
basically
as
we
go
through
this
process
of
converting
each
basically
field
or
that
we
have
a
widget
that
we
have
on
the
current
issue
view
into
this
new
format
like
there
will
be
some
good
patterns
that
are
merged.
B
And
we
can
start
applying
some
basic
rules
so
like
to
how
things
do
roll
up
and
and
whatnot
and
so
like.
If
we
have
the
right
data
model,
at
least
how
we're
storing
the
widgets
related
to
work
items,
I
think
we
can
tackle
that
like
once
time
as
we
as
we
work
on
each
widget
and
then
eventually
like.
If
we
need
to
have
a
different
type
of
widget,
we
can
design
that
from
the
ground
up
and
tie
it
into
the
same
framework.
A
Yeah
at
least
yeah-
I
I
I'm
not
sure
how
this
is
going
to
be
implemented
or,
but
it
may
very
well
be
that
the
calculated
bridges
are
going
to
be
a
totally
different
data
structure,
separate
from
what
we
are
thinking
right
now
in
terms
of
custom
widgets
that
basically
just
display
data
that
can
be
changed
updated.
But
you
don't
do
any
calculations
on
that.
So
I
don't
think
that
affects
us
in
this
case,
but
yeah
aware
of
things
that
we
want
to.
C
C
C
I
just
linked
our
main
mvc,
which
everyone
is
aware
of.
We
did
add
some
shells
of
the
and
other
mvcs,
as
we've
talked
through
them
in
the
spreadsheets
as
of
just
yesterday,
so
everyone
could
see
that
we
added
one
for
the
back
end
architecture
that
might
need
its
own
issues
before
we
get
into
actually
displaying
the
feature
so
feel
free
as
a
team
to
start
populating.
C
These
the
spike
should
pull
in
here,
maybe
in
the
architecture,
would
be
a
good
spot
and
we'll
fill
out
the
different
work
item
fields
the
hierarchy
stories,
all
of
it
as
we
go,
but
it's
we're
in
planning
breakdown
and
design
for
all
this.
So
make
sure
like
that,
if
you
see
something,
that's
missing
that
you
added
that
you
change
things
that
you.
This
is
all
work
in
progress,
so
don't
feel
you
can't
add
new
nbc's,
add
new
issues
and
make
this
work
so
that
we
get
all
of
it
in
here.
B
B
Confusing
but
I'm
going
to
create
some
sort
of
reference
there,
so
we
know,
like
that's
part
of
the
effort,
and
I
think
we're
also
going
to
do
the
same
thing
for
requirements
figuring
out
some
way
to
reference
it
in
that
epic
as
well.
So
we
can
kind
of
see
all
these
different
work
streams
in
one
place,
at
least.
C
B
I
had
the
next
point:
do
we
have
an
engineering
dri
that
will
convert
like
the
outcomes
from
the
engineering
discussions
into
an
architecture
blueprint
largely
because
I
think
it
will
be
helpful
to
coordinate
everyone
who
maybe
can
work
on
parallel,
nvcs
and
things
like
that,
but
also
help
other
teams
follow
behind
and
implement?
B
You
know
a
type
of
work
item
and
widgets
that
they
want
just
in
terms
of
like
documenting
the
system
as
we're
designing
it.
I
don't
know
if
you
all
have
any
thoughts
about.
B
E
C
E
Yeah
well,
the
issue
describes
the
outcome
as
to
be
able
to
draw
an
architecture
blueprint
so
yeah,
like
I
don't
know
if
we
have
a
dri
specifically
for
that
yet,
but
there
are
a
couple
of
things
going
on.
I
guess
that
would
that
also
tie
into
this.
So
there
are
members
of
the
team
involved
in
that.
The
one
that
comes
most
readily
to
mind
is
that
jan
is
currently
working
on
a
proof
of
concept
for
group
and
project
consolidation.
There
are
two
proof
of
concepts
being
produced.
E
The
timeline
is
around
two
weeks
and
the
reason
like
I'm
bringing
that
up
is
that
it
would
also
have
an
impact
on
this,
because
one
of
them
is
to
move
issues
to
the
group
level.
I
believe
I
think
that's
the
one
that's
been
done
by
emory
so
depending
on
the
outcome
of
that,
then
it
would
also
feed
into
this
issue
because
guess
what
it's
the
issues
table.
So,
yes,
I
don't
have
an
answer
for
the
question.
E
If
we
have
a
dri
like
if
anyone
would
like
to
volunteer
before
they're
volunteered,
yeah
like
we
could
use
a
dri
just
even
for
not
to
necessarily
write
the
architecture
blueprint,
but
just
to
be
responsible
for
seeing
it
through
otherwise
we'll
look
into
where
we
are
probably
in
a
week.
I
would
imagine
when
those
pocs
start
bearing
through
for
the
group
and
project
consolidation
and
take
it
from
there.
B
Cool,
I
think
we
have
the
next
one
as
we
think
about
playing
breakdown
with
this.
B
The
other
thing
I
was
thinking
about
is
like
we
have
a
lot
of
engineers
and
plan
and
if
we're
sort
of
making
this
the
shared
initiative
that
we're
going
to
be
focusing
on
for
the
next
several
releases,
one
of
the
things
that
I
learned
from
you
john-
and
you
taught
me
very
well
a
long
time
ago-
was
creating
parallel
like
work
streams
or
npcs,
and
I
was
wondering,
as
we
think
through
this,
how
can
we
create
those
parallel
npcs,
because
some
of
them
can
happen?
B
Don't
need
to
be
blocked
by
each
other,
like
refactoring
discussions
to
use
subscriptions-
and
you
know
our
modern
front
end
and
there's
like
destruction
layout
of
the
new
york
item
view.
There's
parenting
there's
like
a
lot
of
things
that
can
sort
of
happen
simultaneously.
Once
we
have
like
an
architecture
blueprint,
I
think
and
then
like
being
able
to
assign
a
couple
back-end
and
front-end
engineers
to
each
mvc.
So
that
way,
like
you,
have
a
clear
work
stream,
basically
that
people
are
responsible
for,
but
they
can
also
act
sort
of
autonomously.
B
E
The
what's
interesting,
I
think
at
the
minute,
is
that
the
requirements
work
that
charlie
is
doing.
Is
it
stops
at
the
api
layer,
so
there's
no
front
end
work
as
far
as
I'm
aware,
anyway,
donald
you
can
correct
me,
but
everything
from
the
api
up
is
going
to
look
the
exact
same,
we're
just
moving
requirements
into
the
issues
table
and
have
them
act
underneath
the
api,
as
as
work
items
will,
but
you'll
still
interact
with
them
through
the
regular
api,
and
nothing
should
change.
E
That's
a
good
example
of
things
that,
like
that
would
be
parallelizable.
If
we
had
the
architecture
blueprint,
we
could
do
that
for
many
types
of
objects
at
once,
because
nothing
changes
for
anyone
else
besides
yeah.
Besides
for
us
on
the
back
end
where,
where
we
change
the
architecture,
I'm
trying
to
think
like
there
will
be
things,
though
that
are
that
have
to
be
done
linearly.
E
I
would
imagine
like
you
can't
you
have
to
wait
for
something
to
be
widgetized
before
you
can
move
all
the
objects
that
will
use
that
widget
to
to
use
it
right.
Does
that
make
sense
like
if
we
wanted
to
add
due
date
to
test
cases
and
requirements,
we
would
have
to
wait
that
would
be
blocked
by
creating
a
widget
for
due
dates.
I
guess.
F
E
Yeah,
so
a
better
example
might
be
like
the
actual
deciding
the
actual
architecture
of
the
first
widget
like
or
I
will
decide
an
issue
type
knows
which
widgets
it
has
and
so
on,
but
that
should
be
covered
by
the
architecture
blueprint
anyway.
I
think.
D
But
I
mean
due
date
is
already
something
we
show
in
the
ui
so
and
it
already
accesses
the
data's
already
stored.
It's
not
like
this
is
something
new
coming
in,
so
for
that
that
doesn't
actually
need
to
be
in
a
widget
table
per
se.
Those
things
I
think
signees,
all
that
stuff
is
still
will
get
migrated
over
eventually
into
this
new
thing,
but
those
things
just
keep
moving
forward.
Can't
they.
B
Dates
is
an
interesting
one
because
once
we
add
parenting
to
work
items
or
issues
like
we
need
to
support,
start
and
end
dates,
and
then
I
was
talking
with
chris
and
also
about
the
idea
of
having
an
issue
or
a
work
item
be
able
to
have
both
like
a
fixed
date
as
well
as
an
inherited
date.
At
the
same
time.
So,
like
you,
can
actually
plan
something
in
and
see
the
drift
where
things
below
it
actually
get
scheduled
out
so
like
the
behavior
of
date,
will
change
by
nature
of
introducing
parenting.
B
A
And
the
widgeting
part,
even
on
other
widgets
or
attributes,
is
more
like
deciding
on
which
type
which
work
item
type.
This
specific
widget
is
being
displayed
or
not.
So
that's
another
part
of
widgetizing
the
attributes
I
think
which
is
not
currently
limelight
right
now
we
would
if
we
would
move
requirements
as
an
issue
type
right
now
and
display
it.
A
A
G
I
do
I
was
thinking
about
sharding
and
single
tables
and
stuff
still
yeah.
I
opened
an
epic
around
just
feedback
and
discussion
for
these
weekly
syncs
that
that's
helpful,
maybe
different
time
zones
could
better
bring
things
up.
Async,
I'm
not
sure
I'm
just
kind
of
highlighting
it
out.
G
So
what
I
did
was
just
created
a
discussion
issue
for
every
week
and
I'm
thinking
at
least
it
can
be
kind
of
like
a
single
source
of
truth
interested
in
y'all's
participation
or,
if
you
think,
it's
a
good
or
bad
idea.
I'd
love
to
know
what
do
y'all
think.
C
I
think
it's
a
great
idea
to
document
this
for
sure
and
to
track
seeing
each
meeting
as
meeting
notes,
that's
great,
because
that
will
give
us
a
lot
more
formality
just
around
where
we're
at.
I
would
like
to
make
sure
that
those
decisions
get
translated
up
into
that
topic
initiative
as
well,
so
anything
that
we
discover
uncover
walkers
decisions
that
those
keep
rolling
up
to
top
level
artifacts.
So
everybody's
aware.
G
But
things
like
dri,
like
we
just
discussed
like
things
like
that,
maybe
having
people
on
aipac
chime
in
here
and
then
moving
it
to
some
of
those
other
places.
Would
that
make
sense?
I'm
just
wondering
how
do
we
get
you
know?
How
do
we
allow
for
other
time
zones,
especially
to
have
more
say
in
some
of
these
discussions
we
have,
or
maybe
they
you
know.
Maybe
they
are.
I
don't.
I
don't
see
all
of
the
collaboration
here.
So
what.
D
D
G
D
C
C
I
wouldn't
want
to
gate
us
moving
forward
with
like
waiting
for
aipac
to
put
theirs
in.
Similarly,
if
they
move
forward
with
something
I
wouldn't
want
them
to
gate
off
our
getting
our
consensus,
because
we
don't
really
wait
for
consensus,
but
I
do
think
it
would
be
valuable
to
surface
more
of
the
tldr
discussions
that
they
should
get
into,
or
maybe
go
back
and
watch
a
section
of
this
video,
because
we
highlight
this
was
a
great
disc
part
of
the
discussion.
This
three
minutes
is
really
important.
A
I
think
it
will
be
nice
during
the
meeting
to
decide
what
are
the
questions
that
need
more
feedback
like
the
dri
and
so
on
and
just
move
those
into
a
separate
issue
and
so
on,
and
then
it's
just
easier
to
to
track
it
there,
because
you
can
ping
everyone
and
so
on,
rather
than
come
back
to
the
agenda
and
similarly
to
what
we
did
with
the
technical
discussions
I
think
like
it.
A
It
was
sort
of
obvious
that
we
need
to
discuss
things
there
and
then
we
made
it
and-
and
we
are
having
the
conversations
in
the
issue-
I
don't
find
it
too
easy
to
to
track
progress
in
the
dock.
To
be
honest,
I
don't
think
I've
ever
looked
back
at
a
lot
of
the
discussions
that
happened
in
the
dark
and
commented
or
or
stuff
like
that.
I'm
not
sure
that
anyone
does
that,
but
yeah
moving
it
to
issue
makes
sense.
A
So
to
me,
it's
a
lot
of
work
for
someone
to
go
through
the
discussion
and
move
things
to
the
issue.
That's
that's
a
nice
amount
of
work
to
be
done.
So
maybe
if
we
can
decide
during
the
meeting
that
these
are
the
action
items
and
people
can
take
them
out
into
issues
that
will
be
the
way
to
go,
I
don't
know.
G
And
I
don't
know
this
is
just
me,
I
I
don't
think
I
was
envisioning
moving
like
the
entire
agenda,
for
example
too,
but
more
just
like
hey.
This
was
something
interesting
that
you
know
alex.
You
know
that
you
brought
up
and
I
want
to
discuss
it
further,
but
I
wasn't
on
the
call
like
where
do
I
do
that
right?
E
Yeah,
no,
I
agree
with
with
brett
and
alex
like
if
we
could
have
the
issue,
maybe
in
advance
of
the
meeting,
and
we
can
just
add
stuff
in
real
time
it
doesn't
have
to
be
james
joyce,
preferably
we
wouldn't
be
james
choice
actually,
but
yeah
like
the
thing
is
like
we
just
had
that
conversation
about
dri,
but
I
didn't
actually
make
any
commitment
to
it
and
I
didn't
give
any
timeline,
and
so
I
can't
be
held
accountable
for
it.
So
I'll
add
something
to
this.
E
I
like
the
idea
of
referencing
specific
parts
of
the
call
that
may
be
interesting
to
people
on
apac
as
well.
That,
unfortunately,
will
end
my
two-year
streak
of
never
watching
myself
back
on
youtube,
but
yeah
I
mean
gotta
bite
the
bullets
someday.
I
suppose.
G
C
I
did
just
add
a
little
section
at
the
bottom.
Anyone
if
you
have
a
d,
an
item,
an
action
item
or
a
summary
just
add
it
there
and
see
just
so.
We
have
the
items
coming
out
of
this
week.
I
do
want
to
say,
like
we
need
to
really
consolidate
because
there's
so
much
going
on.
We
got
to
get
them
all
under
the
initiative
and
have
things
roll
up
to
the
top
of
that.
So
it's
not
just
our
team
who
sees
it.
C
It's
everyone
else
at
gitlab,
so
alexis
if
you
want
to
drive
the
note-taking
of
it
and
the
rallying
of
the
team,
that's
okay,
but
I
just
want
to
make
sure
that
it
does
add
value
and
not
like
a
lot
of
overhead
so
that
everyone
knows
where
to
go
and
keep
things.
G
H
G
C
D
C
E
E
If
somebody
it's
easy,
people
could
miss
things,
so
I
don't
think
it's
a
terrible
idea
that
we'd
have
like
at
least
the
takeaways
and
the
commitments
in
a
in
some
some
medium,
where
we
could
be
held
accountable
for
them,
in
particular
like
probably
ems
and
bms,
but
everybody.
A
H
My
concern
with
that
is
just
that:
there's
more
places
where
important
pieces
of
information
can
be
right,
so
my
concern
would
be
that
something
important
gets
lost
and
one
of
those
issues,
and
we
should
try
to
find
the
source
of
truth
of
for
that
question
right
and
post
a
question
there.
Instead,
I
don't
know
if
that's
realistic
or
if
that
makes
sense.
A
I
don't
think
current
situation
is
is
better
in
any
way
like
I
like
right
now
we
have
the
videos
and
we
have
this
document,
but
then,
if
no
one
comes
back
or
no
one
uses
it
to
collaborate
on
a
specific
item,
I
I'm
not
sure
that's
helpful
either
unless
we
really
take
out
the
important
stuff
and
make
them
the
single
source
of
truth
issue
or
epic
or
whatever,
and
then
everyone
can
keep
it's
there.
A
D
D
For
that.
So
you
know
might
be
copying
that
over
into
that
weekly
issue
and
and
then
conversation
can
go
on
from
there
or
is
that
too
much
work.
C
H
H
So
that's
like
a
capability.
We
could
explore
right
that
at
the
end
of
this
meeting
it
just
gets
posted
to
slack.
That's
just
like
an
additional
kind
of
like
paying
to
for
people
to
go,
look
if
they're
interested
and
then
if
they
have
questions
they
could
raise
them
in
slack,
it's
something
that's
temporary
and
from
there
we
could
decide.
Okay.
This
goes
in
this
issue
or
this
other
place,
but
that
could
be
something
that
would
help.
F
Yeah
we
kind
of
do
that
manually
after
every
after
every
week
we
just
post
it
on
the
on
the
plan
channel,
but
we
can
we
can
figure
out.
I
think
we
could
probably
figure
out
a
way
to
automate
that
just
to
make
sure
we
don't
miss
it,
I'm
I'm
still
so.
The
main
problem
we're
trying
to
solve
here
is
to
encourage
feedback
from
the
people
that
can't
attend
this
meeting
because
of
either
time
zones
or
or
whatnot
right
exactly.
G
F
Yeah,
so
I
I
do
think
that's
a
good
idea
whenever
we
do
have
like
decisions
made
in
this
meeting
to
somehow
highlight
that
with
the
rest
of
the
team,
and
maybe
that's
just
even
sending
out
a
slack
saying
that
hey.
You
should
definitely
watch
this
meeting,
because
decisions
were
made
but
to
encourage
feedback.
F
I
think
we
should
try
going
the
other
way
in
that
we
try
to
fill
the
agenda
a
little
bit
earlier
than
we
have
been,
and
that
way
everyone
else
that
isn't
going
to
be
able
to
attend,
can
kind
of
look
at
the
agenda
and
comment,
and
then
we
can
just
read
through
it
in
the
in
the
sync
meeting,
because
yeah
right
now,
we've
kind
of
been
filling
it
like
on
the
on
the
fly,
which
doesn't
give
a
whole
lot
of
opportunity
for
other
people
to
to
comment
or
to
discuss.
H
D
C
Maybe
a
year
out
of
date,
melissa
did
it
more
recently,
but
he
has
these
massive
50
page
things
that
he
maintains
in
google
because
there's
so
many
references
so
like
he
doesn't
just
run
off
issues,
it's
kind
of
the
other
way
around,
but
anything
where
it
goes
to
like
it
needs
collaboration,
gets
a
note
with
the
action
item,
which
is
this
issue
is
going
to
be
updated.
This
comment
is
going
to
be
updated
and
that's
linked
as
a
bullet.
C
So
it's
not
so
you
can
then
go
to
the
actual
work
product,
but
he
has
an
intense
table
of
contents
for
every
executive,
like
an
executive's.
One-On-One
document
is
like
50
pages
long
and
it's
all
in
flight,
so
but
the
single
source
of
truth
stays
in
google,
which
is
the
meetings.
What
was
said
the
action
items,
but
it's
always
linking
out
from
there.
B
C
One
of
the
things
he
does
obviously
is
hold
everyone's
feet
to
the
fire,
so
we
don't
necessarily
come
back
like
john
you're
gonna
get
the
dri
by
next
week,
but
that
would
be
top
of
the
agenda
every
week
until
john
executed
on
it
with
sid.
So
that's
just
things
don't
slip
ever
because
he's
always
seeing
them
in
there.
So
that's
something
we
could
think
about
too
is
just
having
team
accountability
when
we're
in
these
sync
spaces,
but
making
sure
that
works
in
the
and
actually
get
lab.
A
C
Yeah
we
could
start
the
agenda
for
the
next
meeting
right
now
yeah
and
have
follow-ups
at
the
very
top
that
we're
committed
to
from
the
last
one.
And
just
so.
We
keep
a
loose
list
of
what
needs
to
be
checked
in
on
that
should
get
transferred
over
probably
into
the
main
initiative
as
well.
But
I
think
that's
a
great
idea
would
that
be.
C
G
So
if
we
wanted
to,
I
guess
kind
of
like
discuss
something
that
was
brought
up
in
a
meeting
in
one
of
these
weekly
sinks.
Then
would
it
be
added
like
a
question
about
something?
Would
it
be
added
to
the
agenda
for
next
time
then
like?
If
it
wasn't,
let's
say,
necessarily
issue
specific?
G
G
E
Yeah,
I
do
this
on
my
one-to-one
agendas
like
if
you,
if
you
put
your
own
email,
you
get
an
email
from
it
and
then
I'll
yeah
grep
my
inbox
from
time
to
time
to
make
sure
that
I'm
meeting
everything,
but
I'm
trying
to
work
more
from
two
news,
which
is
what
I
was
talking
about
earlier
in
the
slack
channel
and
dangerously
close
to
having
zero
two
days,
and
then
I'm
gonna
put
a
to-do
slo
on,
so
that,
if
I
don't
get
back
to
you
within
two
weeks,
I
don't
know
what
happens
something
bad
happens.
E
A
D
I
I
I
didn't
agree
with
you
alex
it's.
The
problem
is,
is
for
me,
I'm
not
going
to
really
know
if
you've
made
a
comment
later
today
on
something
or
someone
from
apac
has
added
additional
details
under
this
discussion
or
something
and
it's
come
on.
I
won't
necessarily
be
notified
about
that.
I
guess
I
could
be
notified
of
every
change
in
the
document,
but
I
think
that
might
drive
me
or
everybody
else,
crazy,
so
yeah,
I'm
usually
that's
why
I
thought
that's
why
I
thought
copying
what
the
contents
were
of
this
into
the
issue.
D
A
Yeah,
if
there
is
a
way
to
move
this
to
the
issue,
I'm
all
for
it
because,
like
me
as
well,
I'm
not
checking
on
these
talks
too
often,
and
it's
awkward
for
me
to
go
to
the
google
doc
to
check
it
rather
than
looking
into
into
the
issues
or
follow
an
issue
or
or
stuff
like
that,
but
yeah.
If
we
cannot
do
it
or
if
it
doesn't
work
for
the
other
people,
I
I'll
try
to
do
my
best
to
follow
this.
One.
D
G
So
what
if,
and
we
also
wouldn't
want
to
wait
for
like
apac,
let's
say
right
if
we
so
using
for,
like
the
the
dri
as
an
example,
if
we
put
that
in
the
agenda
for
next
time,
what
would
be,
I
guess
the
like
ideal
scenario
for
the
that
discussion,
that
kind
of
rolls
over
kristin
you're
unmuted.
Do
you
want
to
talk
about
it.
C
Oh,
I
was
just
going
to
say:
hopefully
the
action
would
happen
sooner
than
the
next
meeting
so
like
whenever
john
does
it,
he
knows
we're
all
talking
about
it.
He
could
even
vocalize
it
into
slack
just
with
wherever
his
comment
is
in
gitlab
and
say:
hey
it's
handled
it's
done
and
we
could
just
tick
that
box
for
next
time.
But
if
it's
something
that's
ongoing,
maybe
it's
like
a
decision
that
we
have
to
revisit
the
next
meeting.
E
The
dri
one's
a
good
example
right
because,
like
jake's
not
on
the
call
and
we
sort
of
share
the
responsibility
for
the
back
end
of
of
work
items,
so
the
fact
that,
like
and
yeah
other
engineers
involved,
aren't
on
the
call,
so
it's
classic
decisions
that
should
be
made
like
not
synchronously,
on
the
call,
but
it
does
have
a
pretty
clear
criteria
like
completion
criteria,
which
is
there's
a
pr
but
yeah
and
also
yeah
during
the
apac
calls,
as
donald
said,
like
I'm
just
default
dri
for
everything
which
has
worked
out
pretty
well
so
far,
one
one
time
that
happened
so
anyway,
where
was
it
going
with
that
yeah
like,
I
think,
even
those
things
that
go
on
for
a
while
like
we
can
still,
we
can
still
find
something
to
do
in
the
week
timeline.
E
You
know
we
can
still
say,
like
you
know,
we
want
to
like
this
decision
about
whether
to
use
the
work
items
table.
I
would
hope
that,
like
we
can
resolve
it
pretty
quickly.
My
worst
fear
would
be
that
it
goes
on
for
a
very
long
time,
but
by
next
week
we
should
be
able
to
accomplish
something
on
that
like
whether
it's
having
had
a
sinkhole
or
some
other
kind
of
call
with
the
database
team.
That
is
going
to
move
that
decision
forward
and
that's
something
we
can
absolutely
definitely
do
by
next.