►
From YouTube: Plan Stage Weekly - 2023-03-23
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
Cool
welcome
all
plan
stage
weekly
for
March
23rd.
A
A
Okay,
so
Martin's
got
a
read-only
team
update.
A
You
can
all
read
it
just
about
as
time
off
coming
up
and
who
to
go
to
for
technical
writing
coverage
and
then
down
to
Amanda
I'll
go
ahead
and
read
through
what
she
has
here.
I
want
to
make
sure
we're
aware
of
work
streams
between
the
group
switch
overlap
and
Aid
in
a
shared
Future
Vision
product
planning
is
thinking
about
how
to
consolidate
filter
capabilities
across
views
list,
board
roadmap
and
project
management
is
thinking
about
how
to
create
a
grouping.
Architecture
should
also
apply
across
views.
A
C
Questions
no,
but
on
that
note
it's
not
a
question
more
of
a
comment.
Heinrich
and
I
are
communicating
and
working
together
on
this
to
make
sure
that
we
are
aligned,
so
it
is
covered.
C
C
Partial
with
Eugenia
and
Heinrich
will
probably
be
involved
as
well
because
of
his
knowledge
about
filters
and
saved
query
stuff
to
sort
of
like
align
things
as
much
as
possible
on
the
back
end,
because
there
are
a
lot
of
differences
actually
and
then
that
way
we
can
optimize
the
code
on
the
front
end
to
remove
a
lot
of
Transformations
and
cater
for
specificities
between
the
different
endpoints
and
so
on.
C
So
we
still
need
to
to
create
some
back
end
issues
for
this
which
I
know
Eugene
is
looking
into
and
I've
created,
like
some
sort
of
like
first
iteration
for
the
front
end
already
I've
done
a
couple.
Spikes
and
I
created
issues
as
an
outcome
for
it.
So
there
is
like
the
simplification
of
like
the
transformation
between
token
neural
parameters
and
API
parameters,
and
the
other
part
is
moving
and
unifying
the
fetching
of
token
suggestions
to
the
component
to
the
Token
components
so
that
we
stop
repeating
the
same
functions.
C
Are
we
talking
about
the
saved
views?
Is
that.
B
D
B
C
To
onboards
we
switched
to
like
Group
by
Apex,
basically.
C
Don't
I
don't
see
anything
that
should
block
us
from
doing
that,
I'm
just
not
sure
how
it
would
look
from
the
back
end
because,
like
so,
the
endpoints
are
quite
different
between
lists
and
boards
and
I'm,
not
really
even
talking
about
the
filter
in
here.
It's
mostly
that
we
fetch,
like
we
fetch
issues
at
the
top
level
of
the
project
or
the
group
for
the
list
and
for
board
it's
per
list
on
the
board.
C
E
Yeah,
so
basically,
my
idea
is
to
start
with
save
views
for
the
issue
list
right,
so
we're
basically
persisting
a
set
of
the
parameters
or
the
you
know,
filter
parameters
that
we
currently
provide
that
comes
from
the
filter
bar.
We
persist
that
into
a
row
in
the
database
and
then
add
a
name
column
or
something
to
name.
This
kind
of
you
know
save,
filter
or
save
view
right
and
The.
Next
Step
would
be
to
be
able
to
add
a
type
or
switch
types
for
these
views,
because
technically
they
should
support
the
same.
E
You
know
set
of
filters
right
and
then
initially
we'll
have
the
type
column,
let's
say
list,
so
these
are
list
views
and
then
we
would
support
a
type
column
core
called
like
a
board
view,
for
example,
and
so
when
you
open
this
view,
we
check
the
type.
If
it's
a
list
view,
then
you
know
we
load
The
View
component
for
issue
list
and
use
the
filter
parameters
and
use
the
query
that
we
do
now.
E
A
What
today
is
our
list
view
that
is
more
detailed
than
what
it
is
now
so,
instead
of
right
now,
we're
adding,
like
we
add
all
the
metadata
within
issues
to
the
list
rows,
instead
of
doing
that,
having
more
of
like
how
like
finder,
you
can
change
from
the
thumbnail
View
to
a
more
detailed
view,
doing
something
like
that
within
issue
View,
or
are
you
thinking
more
just
yeah,
getting
swim,
Lanes
or
group
by
and
everything
else
that
we
have
in
boards
into
the
list?
View.
B
That's
probably
fine,
that's
the
find
a
view.
Change
example
is
that's
a
good
one
kind
of
more
like
that,
yeah
just
being
able
to
easily
switch
between
a
list
view
into
viewing
it
yeah
like
odd
column,
wise
or
something
I,
mainly
yeah,
just
not
having
completely
separate
sets
of
filters
for
the
issue
list
versus
the
Board
page
that
they
have
diverged
so
much
when
it's
kind
of
displaying
the
same
information,
but
just
in
a
different
layout.
B
A
I
mean
because
so
the
to
you
now
that
the
list
views
are
in
graphql
like
they're
they're,
using
the
same
issue,
issue
type
in
both
boards
and
the
list
View.
So
it's
probably
not
too
many
reasons
why
we
couldn't
update
the
view.
B
C
The
list
is
fetched
at
the
group
or
project
level
and
on
the
board.
We
have
the
list
in
between,
but
like
heinrich's
been
saying,
it's
probably
not
like
it's
not
a
huge
problem,
because
now
that
I
mean
once
boards
are
full
of
Polo,
which
is
a
work
in
progress.
C
We
could
just
do
a
view
like
we
could
do
a
view
switch
and
like
instead
of
having
a
different
route,
we
could
have
a
parameter
that
loads
the
board
app
still
it.
It
would
be
like
fake
pretending
that
we're
viewing
the
same
set
of
data,
but
we
wouldn't
refetch
them.
We
could
refetch
them.
C
C
When
we
build
the
different
workout
interviews
and
the
tokens
we
want
to
use
on
work
items
and
so
on,
like
I'm
sort
of
I'm
trying
to
unify
what
we
already
have,
but
I'm,
really
keeping
in
mind
the
upcoming
work
on
work
items
and
trying
to
make
it
easier
for
us
to
implement
it
instead
of
like
again
building
a
brand
new
app,
a
brand
new
filter
bar
and
so
on,
I
just
I'm
trying
to
make
something
super
duper,
reusable
and
modular
and
flexible,
so
that
we
can
build
work
items
really
quickly.
Basically,.
E
E
C
Right,
true
true,
but
like
it's
not
like
the
parity
between
issue
board
and
issues
list
is
not
trivial
because
the
as
it's
highlighted
in
that
big
table
of
parameters,
we
have
differences
and
we
don't
have
necessarily
the
same
available
parameters.
And
the
other
main
difference
is
that
on
board.
We
need
to
pass
pass
the
filters
at
multiple
levels
because
of
the
lists,
because
we
add
a
level
of
complexity
with
lists.
E
Yeah,
this
is
also
something
I'm
trying
to
think
about,
like
with
save
use,
how
we
could
simplify
this
on
the
back
end
side
with
the
graphql
or
like.
If
we
want
to
query
these
by
the
same
thing
we
do
now
where
it's
like
under
a
board
or
under
a
list,
then
issues
right
or
versus,
like
just
do,
project
issues
with
the
front
and
figure
out
what
the
filter
parameter
should
be
for
this
list
or
something
like
that.
I,
don't
know
if
it's
possible
or
maybe
not,
because
there
are
like
logic
where
it's
time.
C
I,
like
the
I,
like
the
concept
theoretically,
but
I'm,
really
worried
about
the
complexity
of
building.
Something
like
that.
To
be
honest,
like
all
the
different
use
cases
we
had,
you
would
have
to
cater
for
on
the
front
end
and
have
like
what
it
would
mean
in
terms
of
performance
like
between
the
moment.
The
response
comes
back
from
the
API
in
the
memory
we
can
actually
display
something,
because
we'd
have
to
do
all
these
calculations
about.
C
How
do
we
group
things
together
where
things
should
be
displayed
and
so
on,
but
like
if
we
can
formalize
that
idea
and
we
could
build
a
POC
and
see
like
with
like
a
set
of
basic
requirements
and
a
basic
back-end
endpoint
and
see
how
we
can
achieve
that
I'm
happy
to
explore
it
in
this
bike
or
a
POC
and
see
how
it
goes.
E
E
E
C
A
Yeah
because
right
now
in
graphql,
the
input
for
boardless
and
boards
is
issue
filters.
But
then
the
issues
query
has
its
own
set
of
individual
filters.
C
C
Yeah
it's
not
as
simple
as
issuesless.
That's
what
I
was
talking
about
before
yeah.
A
But
so
is
there
a
reason
we
don't
have
like
issues
issues
filters
the
object
available
as
an
input
type
for
the
issues
list.
C
No,
that's!
That's
why
I
that's
why
I
created
this
epic
part
like
it's
one
of
the
reasons,
because
we
have
differences,
for
example
like
if
I
just
look
at
that
table.
Milestone
title
is
an
array
which
actually
caters
for
all,
which
is
pretty
funny.
If
you
could
pass
an
array
of
Milestones
on
issues
list
which
is
not
supported
on
boards.
C
Assignee
is
named
differently.
We
don't
have
a
sign.
You
well
card
ID
on
each
like
we
don't
have
any
of
the
wild
cards
on
issues
lists,
except
for
Milestone,
like
we
don't
have
a
tiny
weight,
we're
missing
iteration
title.
We
may
we're
missing:
iteration
Cadence
ID
epic
wellcon
ID
like
it's.
The
set
of
filters
is
different
when
it
should
be
the
same.
A
Yeah
I
agree
is
that
what
you
were
talking
about,
Heinrich
on
China,
can
kind
of
consolidate
that
on
the
back
end
site
or
figure
out
a
way
to,
because
even
for
like
epic
issues
like
there's,
no
reason
why
we
shouldn't
have
the
ability
to
filter
epic
issues
by
this
same
filter,
filter
object
or
filter
input
issues,
filters,
yeah,.
C
Way
like
I,
created
the
Epic
in
that
way,
where
we
look
at
the
differences
on
the
back
end
and
we
can
unify
both
I
want
to
unify
the
end
point
and
the
set
of
filters
and
also
unify
the
implementations
on
the
front
end.
It's
painful
both
ways
anyway,
so
yeah
I
think
it
benefits
everyone
to
unify
both
sides
of
the
problem.
E
E
We're
in
a
state
where
the
back
end
in
front
end
is
like
split
right:
two
implementations
in
the
back
end
to
implementation
in
the
front
end
and
then,
when
something
happens
like,
for
example,
when
I
added
the
or
filter
right
and
so
I
thought
about
it
like
yeah.
We
need
this
in
the
issue
list
I
added
to
the
issue
list
and
then
we
have
to
add
it
into
the
issued
list
front
end
right,
I.
It.
C
B
C
Worked
on
the
Epic
stuff
and
decided
not
to
put
an
S2,
maintain
consistency
with
the
names
of
the
attributes
to
adjust
the
the
normal
filters
that
were
already
existing.
So
we
have
like
that.
We
just
added
another
difference
between
the
end
points,
and
that
means
on
the
front
end.
We
have
to
build
different
functions
when
we
transform
the
API
parameters,
which
is
really
painful.
C
And
I
understand
how
it
can
be
intentional,
but
like
because-
and
that's
probably
why
Amanda
raised
it
in
in
the
agenda.
It's
like
for
a
project
management
I
did
all
on
issues
list
and
product
planning
edit
or
on
epics
list,
and
implementation
is
different
and
I.
Don't
know
like
why
there
wasn't
a
conversation
early
on
to
decide
on
the
standardization
for
the
or
objects,
so
they
would
be
the
same
and
like
every
time
someone
implements
something
not
every
time
but
like
in
filters.
C
You
can
see
like
someone
implements
a
new
thing
and
they
make
their
own
decision
without
consulting
anyone
without
looking
at
the
well.
Maybe
we
should
Define
a
standard
because
there
is
no
defined
standard,
so
when
someone
implements
they
can
make
their
own
decision
so
yeah.
That's
that's
what
I'm
trying
to
push
for
so
that
we
we
unify
those.
A
Yeah
so
I
think
it.
It
definitely
makes
sense
to
to
consolidate
the
different
types
within
like
issues,
and
that
makes
like
epic
list
and
epic
board
filters.
I
think,
ideally,
those
are
consistent
and
we
work
towards
getting
those
consistent
I
do
wonder
if
we
should
spend
too
much
effort
into
consolidating
issues
and
epics
knowing
that
down
the
road
they're
both
going
to
be
work
items
so
I,
don't
know
if
it's
worth
the
effort
to
do
that
right.
C
Now
depends
where
you
want
to
spend
the
effort,
the
effort
that
you
don't
understand,
consolidating
the
back
end.
You
spend
it
in
building
extra
front-end
code
to
like
you,
write
extra
fontain
code
and
then
it's
more
code
to
maintain
in
the
future,
because
we
have
to
build
different
functions
on
the
front.
C
End
like
my
goal
would
be
to
use
the
exact
same
transformation
functions
for
issues
in
epics
because
they
are
so
close
and
I
want
to
use
like
build
them
so
that
we
can
use
them
with
work
items
as
well
in
the
future,
but
because
we
still
have
those
differences
between
issues
and
epics.
I
have
to
write
different
functions
to
cater
for
all
those
differences.
D
B
C
It's
a
lot
of
code
like
if
you
look
at
one
of
my
Spike
merge
requests
just
trying
to
consolidate
the
transformation
function,
I've
deleted
so
much
like
deleted
because
it
doesn't
get
merged.
Obviously,
because
there's
too
many
differences
to
actually
merge
it,
but
that's
not
it
like
it's
insane
how
much
code
gets
deleted
because
all
of
a
sudden
it's
the
function,
is
in
one
spot
instead
of
having
like.
C
Currently
we
have
so
it
would
be
three
transformation
functions
roughly
because
it's
too
split
between,
like
it's
filter,
tokens,
API
parameters
and
URL
and
for
each
implementation.
So
you
have
that
set
of
transformation
function.
You
have
it
for
issue
boards,
epic
boards,
epics
list
and
issues
list,
and
then
you
have
it
for
anything
like
cycle
analytics
somewhere
else
and
and
so
on
and
branches
and
and
whatnot,
but
they
do
the
same
thing
down
the
line.
The
logic
is
the
same:
it's
just
written
differently
and
it
caters
for
those
tiny
differences.
C
C
C
just
to
give
you
an
idea
of
code
maintenance
like
I'm,
looking
at
really
long-term
benefits
here
in
terms
of
adding
implementations
like
we've
been
talking
about
like
adding
types
of
boards,
adding
more
types
of
swim
lanes
and
now
we're
adding
work
items
and
the
way
we
filter.
All
of
these
objects
are
the
same
and
I'm
trying
to
reduce
the
amount
of
code.
We
need
to
write
every
time.
We
add
one
of
those
objects
or
we
add
another
type
of
filter.
C
D
And
just
to
add,
at
one
point
in
time
in
history,
we
had
a
single
search
implementation
across
gitlab,
except
for
to
lose
page.
Like
today's
page
had
a
bunch
of
drop
downs
where
you
would
individually
select
projects,
labels
Etc,
it
didn't
have
to
organize
input,
but
pretty
much
everywhere
else.
D
Across
gitlab
we
had
a
single
implementation
which
had
same
JavaScript
logic
being
used
across
filtering
and
every
page
would
have
its
own
tokens
defined
in
a
hammer
and
that
worked
out
fairly
well
until
we
introduced
view
based
filtering
and
now
we
have
a
mess.
B
D
So
I'm
not
saying
that
was
good.
What
I'm
saying
is
that,
as
long
as
we
had
a
unified
implementation,
we
knew
what
we
were
getting
into
every
time.
We
would
fix
a
bug
or
add
a
feature,
but
now
we
would
have
to
really
dig
into
the
code
base
to
see
what
flavor
of
filtering
it
is
using
before
we
can
is.
C
B
D
B
C
A
list
on
an
issue
board
in
the
list
on
an
epic
board
is
not
the
same
type,
not
the
same
resolver.
It's
totally
different.
The
end
point
is
completely
different.
It's
the
same
structure,
but
the
back
end,
for
it
is
completely
different.
It's
like
a
completely
separate
Ruby
file.
Basically,
it's
not.
B
A
I
mean
because
that's
why,
like
even
right
now,
between
Mrs
and
issues
like
Mr
listview,
still
uses
the
the
Hamel
filtered
search,
I
believe
and
one
of
the
reasons
I
think
why
that
got.
Why
why
the
Hamel
filtered
search
got
complex
was
because
there
is
a
decent
amount
of
Divergence
now
between
Mrs
and
issues.
So.
C
Like
extend
on
instead
of
conditions,
hopefully
and
widgets,
should
make
it
easier
to
compose
like
in
my
mind,
the
long-term
vision
for
word
guidance
is
that
it's
the
same,
like
everything
is
a
work
item
and
you
combine
different
widgets
for
different
types
and,
in
my
opinion,
like
a
page,
is
a
composition
of
all
the
available
widgets
for
a
work
item.
You
just
check
which
widgets
are
available
and
display
the
page.