►
From YouTube: Plan | Weekly Sync 2022-10-26
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).
B
All
right,
so
it's
just
it's!
It's
me
randomly
because
I
remembered
to
put
it
please
welcome
Danica.
She
is
going
to
be
the
new
ux
or
senior
ux
researcher
for
plan.
The
Nikon.
Would
you
like
to
say
hi.
C
Yeah
hi
everyone
I'll,
keep
it
short
and
sweet.
I'm
Danika
I'm
excited
to
be
here.
I
know:
I
haven't
reached
out
to
all
of
you
yet
but
I'm
hoping
to
set
up
some
coffee
chats
and
get
to
know
everybody,
but
very
excited.
I
was
working
as
a
US
researcher
at
aquea.
Prior
to
this
doing
some
web
hosting
and
marketing
automation,
tool,
work
so
excited
to
switch
over
to
gitlab
and
yeah.
I
am
open
to
any
questions.
C
I
can
share
a
little
bit
more
about
me
if
you
want,
but
yeah
you
can
find
me
on
Zuck
come
around
I'm
I'm
in
Boston,
so
Eastern
Standard
Time
typically
works
for
me.
Yeah
I,
don't
know
if
there's
anything
else,
I
should
add,
but
I'll
leave
it.
There.
C
B
All
right
great
thanks,
then
you
come
so
Jones
is
read
only
and
then
it's
me
again
so
I
said
it's
an
FYI,
but
I
can
vocalize
it.
B
So
someone
someone
showed
with
the
technical
writers
that
we
as
the
company
or
it's
a
specific
group,
I
guess,
is
working
on
open,
API
V2,
which
so
this
antique
has
specific
issues
or
sub
epics
for
for
different
groups
or
stages
and
plan,
or
at
least
or
specifically,
project
management.
Is
there
with
like
18
issues,
so
I
just
wanted
to
share
it.
B
In
case
you,
you
haven't
been
aware
that
there
is
some
kind
of
that
November
deadline,
so
I
don't
know
like
how
are
we
approaching
it
for
like
from
my
end,
you
know
for
API
descriptions.
We're
not
Tech
writers
are
not
pressed
to
be
creative
with
the
descriptions.
So
if
you
don't
do
it
in
a
merger,
class
I
would
probably
be
suggesting
just
using
the
same
descriptions
that
we
have
in
the
rest.
Api.
B
A
A
Yeah
you're
right
there
was
18.
There
were
18
issues
for
project
management,
I
moved
forward
them
into
product
planning,
but
that
still
leaves
quite
a
lot
of
work
for
project
management,
so
regular,
two
things
I
think
we
can
do.
One
of
them
is
if
the
weight,
if
it's
truly
like
a
one
to
two
buyer
job
per
issue,
then
like
let's
put
a
weight
of
one
on
them
and
put
the
good
for
new
contributors
label
on
and
see.
A
If
we
can
rally
some
Community
input
because
they're
kind
of
good
issues
for
somebody
who
wants
to
contribute
for
the
first
time
and
then
second
of
all
like
if
we
could
move
some
of
them
around
the
different
groups,
optimize
already
has
four
I
think
as
well.
Brandon
is
that
right,
I
think
it's
four
anyway,
like
four
is
probably
enough
for
anybody,
so
maybe
that
just
leaves
certify.
So
we
could
look
if
certified
could
take
a
few
as
well.
A
And
seeking
Community
contributions
as
well
you're
right
marching.
We
should
have
that
cool
if
there
are
no
other
comments
on
that
Heinrich,
you
have
a
demo
for
us
right.
D
Yeah
so
yeah
that
wasn't
a
really
exciting
demo,
because
but
yeah
John
mentioned
it
might
be
worth
sharing
so
that
you
know
what
we're
working
on
next.
So
let
me
just
share.
D
So
right
now
it's
back
end
only,
and
this
allows
us
to
add
this
parameter
or
an
argument
or
argument
similar
to
what
we
do
with
not
and
currently
it
supports
assignee
usernames
or
author
user
names
and
yeah.
It
returns
you
the
issues
that
are
assigned
to
this
user
or
this
user.
It's
a
highly
requested
feature
and
we
started
work
on
this
before
but
got
stalled
by
The
View
issue
list
refactor
and
now
the
view
is
now
in
our
issue.
List
is
now
in
view.
D
We
can
work
on
the
front-end
component
to
add
this
type
of
filtering
I
think
Kong
is
working
on
it,
so
yeah
and
yeah
just
for
the
info
of
everyone.
So
how
the
all
works
is
it's
a
per
field,
type
of
ore
or
is
basically
a
union
where,
if
I
say,
assign
a
usernames
this
and
this
and
if
I
do
another
one
like
author
user
names
is
you
know
another
set
of
users,
it's
basically
only
an
or
within
the
field,
so
it's
still
an
and
so
it's
assign
username.
D
E
I
think
that's
really
cool
I'm
actually
ran
into
a
use
case
where
I
really
wanted
to
use
all,
but
it
wasn't
available.
It
wasn't
on
issues,
though
so
I'm
just
curious.
How
much
work
was
it
to
get
all
working
in
graphql,
four
issues
or
four
specific
Fields,
because
I
know
you
mentioned
it's
per
field
I'm
assuming
you
have
to
do
work
per
field
to
have
it
enabled.
D
Right
so
yeah,
so
the
MRI
have
right
now
that
I
Linked
In.
The
agenda
is
just
for
adding
the
argument
to
the
graphql,
because
the
finder
worked
for
assignee
and
others.
I
already
did
like
I,
don't
know
how
many
months
ago,
but
basically
the
work.
D
It
is
a
bit
easier
than
did
not
or
yeah,
because
active
record
relations
basically
already
support
on
or
by.
If
you
pass
an
array
to
the
where
it's
like
it
generates
an
in
where
column
in
this.
You
know
this
array
that
you
give
right.
So
it's
very
similar
to
an
end.
You
just
pass
in
an
array
instead
of
the
single
value
and
for
yeah.
Just
let
me
show
you
an
example
for
labels
that
I
added.
D
Yeah,
so
basically,
what
I
did
here
is
that
for
an
and
for
labels,
we
already
support
passing
in
multiple
label
names
right
for
an
end.
If
you,
if
you
supply
a
list
of
labels,
then
we
basically
do
an
end
and
for
the
logic
for
end
it's
here.
D
What
we
do
is
for
every
label
name,
we
iterate
over
them
and
call
the
relation
dot.
Where
you
know,
label
name
is
this
and
for
another
label
name
we
do
another
where
so
that
active
record
doesn't
end
right
so
for
the
or
it's
actually
simpler,
because
it's
just
a
single
wear
and
you
pass
in
the
array
into
the
relation
and
then
active
record.
D
D
So
we
have
this
pyrams
class
that
handles
finding
of
assignese
finding
of
authors,
finding
everything,
basically
turning
these
params
like
names
or
into
IDs,
and
then
there's
the
part
where
we
do
the
actual
filtering
and
all
that,
so
it's
grouped
by
function
right
and
it's
so
every
file
is
very
long
because
the
parent
handling,
it's
still
handling
all
the
filters
right.
D
So
it's
still
very
long,
so
the
actual
filtering
is
still
very
long
because
it
has
all
this
params
that
we
support
so
right
now,
I'm
trying
to
split
this
out
into
separate
classes
per
function.
So
this
is
the
label
filter
class
and
it
has
the
actual
filtering
here.
It
has
the
code
for
querying.
Where
was
it
querying
the
actual
labels
from
the
names
that
you
provide
and
turn
them
into
IDs
so
that
we
can
pass
through
the
query
and
stuff
like
that
so
yeah?
D
Our
issue
update
service
is
very
huge
and
very
long
because
it's
also
split
into
methods
like
filter
parents.
Does
the
param
filtering
and
permission
checks,
then
there's
the
the
actual
updates
and
then
there's
the
function
for
creating
the
system
notes
after
the
updates.
So
it's
still
split
like
horizontally
per
function
and
it's
easier
to
understand
and
it's
just
the
code
is
easier
to
follow.
Should
we
split
it
vertically
into
like
this?
Is
the
assignee
update
handling
code,
where
first
it
filters
the
parents
by
permission?
D
It
feels
it
does
the
actual
update
and
does
the
system
node
for
assignees
in
this
one
file,
and
then
this
other
file
does
the
same
thing
for
the
other
feature
and
I
think
it
also
improves
Security
in
a
way,
because
when
the
code
is
easier
to
follow,
and
then
you
know
less
transfer
bugs
and
all
that,
because
yeah
we've
had
some
instances
where
things
happen,
just
because
it's
just
so
hard
to
follow.
E
Yeah
I
think
I
call
that
Charlie
inside,
but
thanks
just
another
question
regarding
that,
so
in
the
graphical
Explorer,
is
there
anything
that
kind
of
indicates
that
always
supported
by
that
query?.
D
D
I
think
the
challenge
here
is
in
the
front
end
in
the
ux
I.
Don't
know
how
we
display
or
I
don't
know
how,
if
Nick
or
Kong,
had
a
discussion
and
how
we
want
to
display
this
in
the
filter
bar
right.
How
we,
if
you
click
label,
is
there
another
or
like,
because
we
discussed
this
before
where
right
now
we
have
the
when
you
click
on
a
filter
like
label,
there's
is,
and
it's
not
right
and
one
option
is
to
add
another
option
like
an
or
right.
D
The
other
option
was
to
over
I
mean
make
the
is
a
bit
different
like
where
you
press
s,
and
then
you
get
the
multi
select.
So
if
you
get,
if
you
select
multiple
ones,
that's
basically
an
or
yes
A
or
B,
and
if
you
wanted
an
ad
you'd,
have
to
S,
then
a
then
enter
Then
open.
Another
label
filter
is
B
to
do
the
end,
but
might
be
not
so
intuitive,
but
yeah
I,
don't
know
those
are
the
concerns.
C
Some
of
the
exists
right,
like
I
I've,
seen
design
for
this
before
from
before.
Whenever
this
kicked
up
like
a
year
ago,
and
there
is
like
a
filter
bar
multi-select
component
that
already
exists
so
I
think
a
lot
of
those
pieces.
Are
there
I,
don't
know
how
like
how
close
they
are
to
being
usable,
but
yeah
I'll
keep
an
eye
and
and
see
what
what
questions
are
still
open.
There.
D
Yeah
I
think
also
this
wasn't
really
in
a
super
I
guess,
refined
state
where
we,
you
know,
had
everything
and
we
decide
to
move
forward
or
something
but
I.
Just
I
spoke
with
Donald
about
this
and
kind
of
like
we
already
have
the
most
of
the
back
end
working,
it's
just
adding
a
param
to
graphql.
Why
don't?
D
We
just
you
know,
move
this
forward
because
it
has
been
installed
for
a
while,
and
we
also
got
like
things
from
users
and
I
think
even
internally,
in
slack,
I
saw
some
like
requests
around
like
do
we
have
or
or
something
in
our
Channel
recently
so.
C
Yeah,
it's
a
huge
issue
that
comes
back
almost
on
every
survey
as
well.
I
think
Heinrich.
We
did
alter
the
front
end
and
the
user
experience
for
it.
Based
on
your
input
where
we
should
like
doing
the
is
one
of
approach
and
I
think
Nick
LinkedIn,
the
component.
That's
been
done
for
that
that
we
pushed
Upstream
to
pajamas
I,
think
it
makes
sense
and
is
a
good
iteration
in
the
next
NBC
in
terms
of
getting
something
out
there
that
works,
but
I,
don't
know
Nick
if
you
have
strong
opinions.
C
Otherwise
this
work
was
all
done
before
you
started,
so
I
would
want
your
stamp
of
revolt
and
then
put
on
it.
No
that
I
I
was
tracking
that
down
this
morning
and
I'm
I
mean
I.
Think
the
existing
components
that
we
have-
and
that
is
one
of
approach-
is
pretty
much
what
I
had
put
in
the
the
like
save
views
and
queries
because
I
had
thrown
like
an
ore
filter
in
there,
and
it
was
basically
the
same
so
I'm
happy
to
see
that.
D
Interesting
I
didn't
know
we
already
had
this
in
pajamas
and
so
yeah.
It's
a
good
thing.
It's
already
there
and
we
just
need
to
like
implement
it
in
our
application.
I
guess
one
point
of
confusion.
I
realized
also
is
that
if
you
do
an
or
filter
with
just
one
username
or
one
user
or
one
value,
it's
basically
just
like
an
and
right
I
mean
or
if
you
chose
and
one
of
this
user
but
I
guess
it's
fine.
A
Cool
I
think
yeah
and
yours
is
read-only
unless
anyone
wants
to
weigh
in
on
it.
Also
awesome
demo
Heinrich
thanks
Omar
like
we
could
go
into
a
load
of
stuff
about
Gila
triage
as
well
like
that
runs
the
triage
apps
project
and
some
of
the
queries.
There
are
hilarious
for
the
number
of
knots
that
they
include
to
get
around
the
fact
that
we
don't
have
War
but
I
know
we
need
to
build
to
build
it
into
the
rest
API
as
well.
A
For
that,
but
like
yeah
like
one
day
anyway,
yeah
so
Ian,
did
you
want
to
go
through
this
or
just
leave
us
read
only.