►
From YouTube: Workspace Weekly 2021-10-13
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
workspace,
weekly,
sorry,
again,
everyone.
This
is
using
my
zoom
and
I
totally
forgot
so
I
was
running
late
but
dosha
as
the
acting
em
for
workspace,
who
has
just
taken
over
this
project.
C
Yeah
I
a
short
status
update
for
the
phase
one.
We
do
have
basically
four
outstanding
tasks
remaining,
which
is
backfill
the
user
type
in
the
namespaces
table.
That's
in
review,
I
think
and
brett
is
taking
care
of
that
create
project
namespace,
which
has
a
couple
subtasks
and
filtering
out
the
project
namespaces
from
from
queries
throughout
the
code,
so
that
will
be
a
bit
challenging
but
again
we're
working
on
that.
C
Then
the
monitoring
part,
which
we
seem
to
have
skipped
it
up
until
now,
like
it
somehow
missed
everyone's
attention,
that
we
want
to
monitor
things
and
make
sure
that
we
don't
given
the
footprint
of
this
change
right,
we're
changing
things
in
main
spaces
table
that
is
basically
used
throughout
the
project.
So
we'd
love
to
be
able
to
see
if
we
are
affecting
anything
in
any
way
and
then
the
actual
backfilling.
C
Monitoring,
I
would
say,
are
the
two
main
things
that
will
then
allow
us
to
do
the
backfilling
itself.
C
I
think
the
backfilling
itself
is
not
super
hard,
but
we
should
do
it
very
carefully
and
the
plan
I
like
at
least
in
my
mind,
is
we
will
do
the
changes
and
deploy
them
to
staging
as
usual
and
and
watch
it
there
and
then
do
the
migration
for
a
sound,
specific
group
or
groups
and
watch
how
that
behaves
there
and
then
proceed
with
the
overall
migration
of
the
entire
table,
because
we
are
going
to
more
than
double
the
size
of
the
namespaces
table.
Basically,.
C
B
B
C
The
table
is
not
huge.
We
have
like
around,
I
don't
know
if
well
we'll
make
it
private,
then
around
12
million
records
in
the
name
spaces
table,
and
we
have
around
20
million
records
of
the
projects.
So
that's
just
to
give
it
perspective,
so
every
project
will
get
a
record
in
the
namespace,
so
we're
more
than
doubling
the
size.
C
So
I've
got
the
other
point
as
well
on
the
documentation
and
monitoring
which
kind
of
slipped
our
minds
in
a
way,
and
they
we
got
the
suggestion
from
aries
from
undocumenting
and
I've
started
a
couple
hours
ago
in
mr
to
do
so
so
please
come
in
and
yeah
leave
your
suggestions
and
then
for
monitoring.
C
Initially,
I
thought
that
we'd
want
a
dedicated
dashboard
for
for
the
specific
phase,
basically
for
the
phase
one,
it's
got
a
bit
of
pushback
so
to
say
and
like
because
we
have
a
lot
and
that
makes
sense,
because
we
we
do
have
a
lot
of
the
monitoring
in
place.
So
we
can
reuse
some
of
that.
It's
not
specifically
scoped
down
to
the
phase
one
work,
but
it
does
have
a
lot
of
the
monitoring.
C
So
maybe
there
is
too
much
overhead
to
just
do
this
specific
monitoring
for
the
for
the
face,
especially
given
that
the
footprint
is
super
large
affects
the
entire
application.
Maybe
maybe
just
doesn't
make
sense
to
narrow
it
down
to
to
couple
endpoints
and
things
like
that.
So
yeah,
then
the
kind
of
the
scope
of
the
monitoring
goes
into.
How
can
we
document
the
best
where
we
can
monitor
things
and
how
we
can
watch
things?
So
that's
kind
of
the
task
at
hand
right
now
for
the
monitoring
and
yeah.
C
B
I
believe
it's
looking
at
the
scope
of
the
changes
we're
having.
We
can
use
the
workspaces
dashboard
because
it
covers
a
lot
of
at
the
same
places.
And,
yes,
you
are
right.
We
are
changing
the
things
that
can
have
so
many
implications
for
the
application
that
we
probably
need
to
probably
need
to
monitor
the
application
as
a
whole,
especially
once
we
start
using
the
the
new
filtering.
The
news
after
the
backfill.
C
So
my
initial
idea
is
like
was
to
to
narrow
down
onto
specific
end
points
like
creation
of
groups,
creation
of
projects,
listing
groups
listing
projects
and
things
like
that,
but
in
essence
it
doesn't
defer
it
anyway
we
would
want.
We
would
want
to
watch
the
error
rates
on
these
specific
endpoints,
where
we
can
use
the
entire
fact
because,
like
I
think,
the
workspace
dashboard
doesn't
differ
from
pla
plan
stage
dashboard.
It's
pretty.
I
think
it's
following
the
same
template
and
it's
using
like
just
it.
C
It
dumps
there
every
single
action
that
we
know
off
or
that
we
track
data
on.
So
you
have
everything
there.
So
I
was
like
more
thinking
that
we
maybe
lose.
We
may
lose
some
information
just
because
we
are
covering
that
much
of
a
logging
kind
of
right.
If
you
have
a
lot
of
data,
you
may
lose
some
of
these
smaller
things
there.
Your
error
rate
will
be
small,
but
some
end
point,
maybe
creating
a
big.
A
big
issue
like
I
don't
know
how
to
solve
for
that.
C
Just
yet
because,
like
you
need
to
know
which
employee
creates
the
issue
in
first
place,
so
I
guess,
like
monitoring.
Everything
is
a
is
a
good
idea,
but
it
yeah.
In
essence,
it
doesn't
differ
from
from
what
we
have
right
now.
We
just
need
to
know
where
people
need
to
look
for
the
status
and
for
the
error
rates
and
for
the
response
times
and
so
on.
B
I
had
this
point,
I
just
want
to
ask
you
melissa
about
the
planning
for
workspaces.
I
started
to
add
issues
from
in
our
queries
project,
but
can
you
do
the
workspaces
part.
E
I
have
a
question
regarding
that,
so
a
lot
of
the
things
that
the
team
is
working
on
right
now
is
actually
bottom
up,
so
we're
starting
not
from
the
top
nay
space
but
from
the
lowest
level
project
level
and
which,
I
think
is
fine.
The
question
is,
as
our
poc
for
removing
the
first
features
from
plan
like
what
makes
the
most
sense
for
phase
two
so
that
the
planting
can
start
moving
stuff
over.
D
Yeah,
so
we
talked
about
that
last.
Speeding
and
essentially
is
the
team
needs
to
get
through
phase
one
and
some
of
phase
two
before
they
can
estimate
the
features
and
the
work
that
is
needed.
We
do
have
two
candidates,
one
being
labels
and
the
other
one
being
issues
as
the
first
things
to
be
migrated,
but
the
team
needs
more
time
to
build
the
foundations
before
they
can
like
estimate
and
start
that
work,
so
probably
after
next
milestone.
Maybe
is
when
we'd
be
looking
at
feature
stuff.
D
Okay,
so
then,
my
action
item
is
to
post
on
slack
to
see
how
we
wanted
the
refinement.
But
essentially,
what
you
know
next
milestone
will
be,
is
completing
phase
one
and
then
moving
on
to
the
phase
two
issues
that
are
already
in
that
epic,
basically
using
the
project
namespace,
now
that
it's
been
introduced.
F
Right,
I
was,
I
was
typing
and
I
can't
multitask
so
sorry
for
the
delay.
So
I've
kicked
off
work
on
the
on
the
label
stuff
that
was
just
mentioned
before
still
work
in
progress.
But
I
think
I
should
probably
have
a
a
good
stab
at
it
by
the
end
of
this
week
in
terms
of
like
the
full
analysis
and
like
recommendations
on
how
we
can
proceed
migrated
at
going
forward
from
a
ux
perspective.
F
I
in
the
issue,
have
started
in
the
description
to
outline
like
some
of
the
analysis
of
the
inconsistencies
between
how
labels
are
used
at
different
levels,
but
to
start
out
with
what
I'd
like
feedback
on
specifically
is
around
the
uml
type
diagram
or
the
conceptual
model
diagram
that
I've
posted
in
the
in
the
description
as
well.
And
you
don't
need
to
do
that
immediately.
F
But
basically,
this
is
a
tool
which
I
think
is
going
to
be
super
useful
for
helping
us
to
understand
how
how
like
the
functionality
and
properties
of
the
objects
in
the
current
state
and
how
they
start
to
to
to
to
look
when
we,
when
we
move
it
to
the
name
space.
F
So
what
I'd
be
interested
in
in
terms
of
feedback
here
is
the
specific
content
if
anyone
has
any
more
in-depth
knowledge
on
on,
like
the
properties
and
the
functionality
of
of
labels,
as
well
as
whether
this
is
a
useful
tool
to
collaborate
between
design
and
and
the
rest
of
engineering
as
well
again,
feedback,
not
necessarily
right
now,
but
feel
free
to
provide
it
in
the
issue
or
in
the
thread
here.
D
First
impression
is
I
like
to
diagram
current
state
future
state
kristin
would
be
a
great
person
to
loop
it
in
as
far
as
functionality
goes
and
completeness,
but
visually.
I
think
it
makes
a
lot
of
sense.
F
Cool-
and
this
is
like
the
conceptual
model-
I
don't
know
whether
it
maps
completely
to
how
the
back
end
works
and
so
on,
but
this
is
useful
for
at
least
mapping
what
the
functionality
is.
D
I
jumped
ahead,
and
I
look
I'm
looking
at
your
mock
ancestor
would
be
something
that
we
need
to
test
that
stood
out
to
me
as
like.
Is
that.
F
But
yeah
we
can
like
I
I
imagine
that
should
be
handled
rather
than
at
the
label
level.
We
should
like
start
to
think
about.
What's
the
terminology
and
stuff
that
we
use
in
in
a
separate
issue,.
D
F
Yeah
and
then
the
fact
that
the
relationship
here
is
between
projects
and
like
subscribing
at
the
project
level
at
group
level,
potentially,
would
we
want
to
go
beyond
just
the
immediate
parent
and
look
at
like
the
grandparent
or
the
great
grandparent?
That's
why
I
use
the
more
abstract
ancestor,
but
yeah
I'll
create
a
new
issue
for
that
in
terms
of
like
terminologies
that
start
to
come
up,
and
we
can.
We
can
further
the
conversation
there.
A
Okay,
like
I
said
earlier,
I'm
going
to
hand
this
call
and
zoom
link
off
to
gosha
for
next
week.
Are
there
any
other
things
that
we
want
to
cover
before
we
drop.
F
Yeah
well,
the
one
thing
that
came
up
for
me:
I
haven't
written
it
down,
I'll
put
it
after
michelle,
oh
wait,
so
what
I
was
thinking
is,
as
I've
been
working
through
a
little
bit
of
the
designs
here.
What
was
I
I've
completely
just
completely
slipped
my
mind
now
sorry.
F
I'm
such
an
airhead
today,
I've
lost
it
never
mind.
A
A
Okay,
let's
drop,
and
then
we
can
just
follow
up
in
slack
if
there's
other
stuff
have
a
good
one.