►
From YouTube: Plan Weekly Team Meeting | 2020-02-17
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
C
Yeah,
so
it's
in
regard
to
adding
custom
issue
types,
so
my
I
was
thinking
where
should
we
define
actually
define
the
project
or
group
level
or
the
top
group
level
actually
to
to
kind
of
propagate
that
to
the
entire
organizational
hierarchy?
C
A
Yeah
I
responded
to
that
initially
and
I
think
a
long
term
goal
or
short
term
if
it's
even
possible
with
the
merging
groups
and
projects
together
is
we
want
to
get
groups
that
are
issues
at
the
group
level
as
soon
as
like
practically
possible
without
like
duplicating
the
future?
Just
so
we
don't
have
to
like
manage
to
do
different
things
of
it.
So
I
would
also
say
that
putting
it
at
the
group
level
is
where
we
should
go
and
then
eventually
the
same
thing.
A
That's
gonna
back
a
group
in
a
project
will
also
back
a
workspace,
so
we
would
have
it
at
the
workspace
which
would
wrap
all
top
level
groups,
so
it
could
define
there
be
defined
there,
which,
if
we
put
it
at
the
group
level,
I
think
it
would
make
it
easier
to
support
that
later.
On.
A
I
think
any
group
level,
starting
at
the
top,
I
would
think,
there's
a
manage
access
and
I
link
to
this
they're
working
on
a
proof
of
concept
right
now
for
like
standardizing
the
behavior
of
cascading
settings
from
workspaces,
all
the
way
to
groups
and
subgroups
and
some
projects
down,
I
think
we
should
coordinate
with
them.
Drew
blessing,
is
the
one
assigned
to
it.
A
But
this
is
like
sort
of
the
common
behavior
where
we
don't
have
a
standardized
inheritance
model
for
how
things
do
flow
downstream
and
I
think,
like
I'm,
not
sure
what
the
final
ux
is
going
to
be.
But
I
would
assume
that
if
I
have
issue
types
defined
at
my
highest
level
group
at
the
lowest
level
group,
if
I
want
to
add
another
type,
maybe
I
could
do
that.
A
Maybe
there's
a
bit
there's,
also
a
desire
to
like
basically
for
from
a
compliance
standpoint
prevent
people
from
mucking
up
the
issue,
types
downstream,
that
don't
have
access
to
it,
and
so
eventually,
I
think
it
will
be
an
optional
thing
where
the
top
level
group
would
define
it
if
other
subgroups
are
allowed
to
change
it
or
add
to
it.
A
C
A
Yeah
as
an
mvc,
I
think
it's
great
to
start
at
the
top
top
group
level.
The
the
thing
that
is
that
I
guess
sid
basically
said
no
to
like
a
dag
based
thing
for
sharing
resources
across
groups,
but
like
there's,
also
the
proposal
to
be
able
to
assign
an
issue
to
multiple
like
sibling
groups,
so
to
speak,
and
so
just
thinking
through
the
implications
of
if
we
are
able
to
pull
that
off.
What
does
that
mean
for
types
issue
types?
If
two
top-level
groups
have
the
same
issue
type?
A
Can
we
basically
infer
that
they're
the
same
thing
and
like
reference
in
that
way,
just
thinking
through
some
of
those
implications
across
top
level
groups,
I
think,
is
worth
doing
at
the
onset,
but
as
an
mvc
standpoint,
starting
with
just
the
top
level
groups,
great.
D
Yeah
hi,
sorry,
I
joined
it
a
little
bit
later
and
I
didn't
expect
this
will
be
first
on
the
agenda
yeah.
So
I'm
just
catching
up
and
reading
through
the
comments
yeah.
But
thank
you
for
paying
attention
to
me.
The
purpose
is
just
to
draw
more
attention
to
make
sure
that
everybody
is
aware
of
the
implications
of
this
change,
because
I'm
not
sure
if
everybody
understands
that,
then
all
issue
types
will
be
listed
will
be
treated
and
listed
as
any
other
issues.
D
So
we
can
have
a
separate
view
or
page
for
them,
but
they
will
also
be
included
wherever
we
list
other
types
of
issues.
So
so,
from
user
point
of
view,
this
might
be
a
biggest
change
regarding
this
conversion
but
yeah.
So
I
just
want
to
make
sure
that
everybody
understands
this
and
everybody
is
on
the
same
page.
If
we
go
down
this
road,
it
would
be
quite
bad
to
try
to
separate
them
later
on
all
levels
of
code
base
and
try
to
do
separation
later,
because
we
have
it
on
many
places.
C
Yeah
like,
and
I
think
from
the
backend
perspective,
we're
kind
of
in
agreement
that
we
can
use
the
same
underlying
object
for
a
lot
of
these
things,
requirements,
incidents
and
so
on
and
so
forth,
and,
like
my
understanding
and
I'm
certain
agreement
with
the
fact
that
the
ui
and
the
ux
should
kind
of
separate
different
types
of
or
different
sets
of
issue
types,
I
I
can.
C
I
can
see
how
some
customers
would
not
want
to
combine
together
different
sets
of
issue
types
like
they
want
to
keep
together
like
separate,
totally
separate,
same
requirements,
test
cases
and
all
that
like
pre-collaborative
stuff
and
that
have
what's
related
to
development,
there's
a
different
set
of
issue,
types
on
different
views
and
and
different
like
auto
completion
and
all
that
stuff.
C
So
from
ui
perspective,
I
think
that
does
make
sense,
and
there
might
be
some
confusion
if
we
start
to
mingle
everything
together
again
from
the
backend
perspective,
I
think
it
makes
sense
to
to
have
it
as
a
single
object
and
it
will
just
because
a
lot
of
the
functionality
is
the
same.
The
filtering
the
like
being
able
to
put
to
a
center
milestone
a
signature
and
so
on
and
so
forth.
C
So
yeah.
That's
that's
something
that
to
consider
and
to
think
about,
and
and
probably
to
kind
of
I
suggested
that
maybe
we
should
consider
adding
yet
another
abstraction
level
at
the
issue,
type
level,
sort
of
think
how
that
will
will
play
out,
but.
A
I'll
I
had
the
next
point.
I
think
we
can
keep
dedicated
views
for
certain
types
of
issues
if
desired.
So
it's
just
like
a
it's
like
a
filtered
down
list.
A
So,
for
example,
incidents
have
their
own
list
view
that
you
can
find
within
the
ui,
but
you
also
they
show
up
in
the
issue
list,
which
I
think
is
fine
right
and
I
think
that's
fine,
because
the
like,
ultimately
we're
going
to
add
filtering
by
issue
type
and
if
we
have
or
filtering
so
basically,
I
can
filter
just
to
the
types
of
issues
that
I
want
and
then
we're
going
to
have
save
filters
and
searches.
A
So,
basically,
in
these
different
views
I
can
create
my
filter
and
then,
like
basically
save
my
view,
so
every
time
I
go
back,
it's
the
same
thing
as
creating
a
bookmark,
but
it's
going
to
be
like
a
better
experience
in
the
product
so
like
I
can.
I
only
see
the
things
that
I
want
right.
So
I
can
build
my
own
kind
of
customized
views.
Yes
right
and
I
agree.
D
With
this-
and
I
think
that
if
we
are
all
in
agreement
regarding
this-
that
we
can
have
separate
view
for
them,
but
they
will
also
be
on
issue
page,
then
that's
fine,
but
this
is,
I
don't
agree
or
I'm
not
sure
about.
D
We
can
do
this
only
on
backhand
side
and
have
separate
views
as
alexandra
mentioned,
because
it
implies
to
do
many
additional
checks
or
filtering
on
backend
side,
because
there
are
many
places
where
we
check
just
for
projects
issues
without
checking
issue
type
or
something
similar
yeah.
So
if
we
commit
to
convert
some
resource
to
issue
type,
it
should
also
mean
that
we
treat
it
as
any.
A
D
Yes,
there
is
no
problem
to
do
this.
It's
completely
fine
but
yeah.
There
might
be
some
other
scenarios
like
exporting
of
some
issue
type
or
or
some
drop
downs
or
referencing
of
other
issue
type
and
stuff
like
this.
So
if
we
want
to
separate
some
issue
type,
it
would
be
hard
to
do
this
on
all
these
levels.
A
Yeah,
I
think
the
only
thing-
and
this
is
like
the
last
one
I
had
is
the
reference
problem-
is
the
only
thing
that
I
see.
That's
really
would
be
tricky
to
solve
with
types
of
issues
right,
because
we
have
a
new
flexible
like
syntax,
for
you
can
basically
define
the
key
and
then
match
on
the
id
of
the
thing.
A
Instead
of
using
a
symbol
since
we're
running
out
of
those
and
to
me,
it's
like
the
tricky
part
is
going
to
be
preventing
the
issue
type
from
being
named
certain
things
like
custom
issue
types
they
would
conflict
with
system
defaults
so
like
almost
have
reserved
type
words
like
test
case,
for
example,
is
going
to
be
a
system
default
incident,
it's
going
to
be
a
system
default,
but
then,
when
you
reference
them,
if
you
were
to
change
the
issue
type,
which
is
something
we
want
to
support,
I
would
expect
it
also
would
change
the
reference
filter
to
point
to
the
correct
issue
type
if
that
makes
sense.
C
Yeah,
that's
that's
not
an
easy
thing,
because
that's
referenced
in
text,
so
you
basically
would
need
to
kind
of
search
all
the
text.
References
and
do
the
update.
So
to
say,
I'm
not
sure,
that's
viable,
viable
thing
like
one
way
to
solve,
is
like
to
be
able
to
filter
them
down
somewhat
by
a
specific
reference.
But
when
you
reference
it
just
use
the
generalized
issue
reference
and
it
will
point
because
it's
initial
object.
C
It
will
point
to
the
correct
object,
but
the
reference
itself
will
be
like
general,
and
I
will
not
tell
you
specifically
what
kind
of
object
that
is,
although
that's
doable
as
well,
when
you
parse
it
and
make
it
a
html
and
so
on.
A
I
I
think
that
that
would
work
so
because
we
want
to
make
those
like
references,
have
more
rich
data
anyways.
So
just
like
how
we
show
closed,
you
know
when
an
issue
is
closed
when
it's
referenced.
It's
a
similar
type
thing
where
we
could
just
like
expose,
maybe
like
the
the
issue
type,
is
an
icon
or
something,
and
the
status
eventually
will
have
status.
You
know
to
the
right
of
it
as
well,
but
just
use
the
generic
reference
syntax
for
some
fine
with
as
well.
I
think
we
can
sort
that
out.
Yeah.
D
I
think
that
the
generic
reference
syntax
would
be
more
visible
because
we
we
cannot
backward
change
reference
type.
We
it's
not
possible
to
go
through
all
system
notes
and
check
when,
where
we
reference
it,
so
it
would
be
better
to
use
one
type
of
reference
and
do
just
very
lightweight,
flavoring
or
or
adding
a
type
on
the
fly
when
we
when
we
render
it
to
user,
but
that
would
be
all
we
can
do
like
this.
E
D
I
get
only
issues,
I
don't
get
requirements
or
if
I
export
some
issues
to
user
or
list
them
in
api,
I
get
only
issues
if
we
convert
requirements
to
issue
type.
It
means
that
if
I
ask
for
issues,
I
get
issues
but
now
also
also
requirements,
because
these
will
be
issues
too
just
a
different
type,
and
by
separation
I
mean
that
we
would
have
to
go
through
the
all
code
base
and
where
we
don't
want
to
get
some
issue
type
like
requirements,
we
would
have
to
do.
D
We
would
have
to
add
a
specific
filter
yeah
to
ignore
them
in
these
listings
and
there
there
may
be
quite
a
many
places
where
this
customization
would
be
required,
and
if
we
want
to
do
this
separation,
then
my
question
would
be
if
it's
really
so
beneficial
to
do
this
issue
type
conversion,
because
we
would
have
to
implement
separate
api
and
additional
layers
too.
So
I
would,
I
wouldn't
be
so
sure
that
we
want
to
do
this
issue
type
conversion.
Then.
E
D
A
F
D
G
So
again,
I
I
put
a
note
here.
I
don't
really
mind
doing
this
up
front,
but
I
guess
I
just
want
to
understand
when
we're
gonna
have
that
filtering
in
place
and
if
there's
gonna
be
a
way
to
like
default.
Those
to
not
show,
I
think,
that's
going
to
be
a
fast,
follow,
that's
going
to
be
requested
by
a
lot
of
the
users.
H
D
This
is
exactly
yeah,
I'm
on
the
same
page
with
you.
I
just
want
to
make
sure
that
everybody
understands
these
implications.
E
D
Yeah
these
issues
are
linked
from
the
comment
I
put
to
the
to
the
note.
So
I
would
really
appreciate
your
expertise
and
ux
point
of
view
about
this
change
and
I
think
that
ux
approval
would
be
would
be
needed
for
going
forward
to
be
fit
so.
H
Yeah
so
I'll,
just
I'm
really
on
board
with
this
change
and
like
getting
onto
a
primitive
of
some
sort,
I
do
think
requirements
would
be
the
right
object
to
go
first
and
just
thinking
through
it,
because
epics
would
have
so
much
more
migration.
H
Of
course,
that's
just
my
high
level
thought
so
I'm
open
to
any
thoughts
on
how
we
would
progress
towards
moving
those
other
types
onto
the
primitives,
and
I
also
just
wanted
to
mention
that
we
should
think
about
just
like
we're
thinking
about
these
databases,
apis
everything
we
should
also
think
about
tracking
out
of
the
box.
So
we
get
that
for
free,
we've
been
doing
a
lot
of
one-offs
in
terms
of
our
getting
our
gmails
and
everything.
H
H
G
That
is
something
we'll
have
to
work
through
on
and
the
issue,
because,
right
now
we're
tracking
number
of
requirements
created.
We
need
to
figure
out
how
to
keep
that
metric
as
we
transition
them
to
issue
types,
because
right
now,
I
think
that
means
they'll
all
lump
into
gabe's
issues
created
metric,
which
isn't
a
horrible
thing,
but
it
does
pretty
much
take
out
my
primary
for
for
what
we're
trying
to
just.
G
A
So
I
think
it's
something
to
sort
out
as
well,
but
it
also
should
theoretically
make
instrumentation
easier,
because
we
don't
have
to
do
it
once
and
the
other
thing
that
is
beneficial
is
that
from
a
compliance
standpoint
now,
like
the
compliance
team,
basically
has
to
integrate
with
one
object,
instead
of
like
add
compliance
for
epics
ad
compliance
for
issues
that
complies
requirements
for
all
these
different
things.
So
it
basically
gives
them
a
single
object
to
do
all
their
compliance
needs
with
which
I
think
is
great.
G
It
would
be
very
easy
at
that
point
then,
to
just
filter
out
the
you
know
like
for
me.
I
would
just
filter
out
epics
and
issues
and
I
would
get
test
cases
and
requirements
for
free
and
I
think
that's
a
much
cleaner
perspective,
because
right
now
the
overlap
is
really
hard
overall,
again,
very
good
change.
It's
there
just
might
be
some
growing
pains
in
the
meantime
and
that's
okay.
G
I
I
If
we're
100
committed
to
issue
types,
then
that
unblocks,
some
of
the
conversation
that
we're
having
here
basically
like
if
there's
never
going
to
be
a
different
type
of
board
other
than
one
that
renders
different
issue
types,
then
I
think
we
don't
have
to
do
any
refactoring,
because
I
think
it's
redundant
to
have
a
prefix
like
issue
board
if
we're
never
going
to
have
a
different
type
of
board.
C
Yeah,
it
makes
sense
to
me
that
there
is
quite
a
bit
of
way
to
get
epics
into
issue
types.
I
think
requirements
are
somewhat
simpler
from
my
perspective,
just
because
they
don't
have
this
inheritance
thing,
and
this
inheritance
thing
within
the
epics
is
something
that
will
make
epics
might
like
epic
migration
to
issue
types
somewhat
more.
Well,
it's
not
problematic
we'll
need
to
either
add
support
for
the
inheritance
within
the
issues
or
somehow
migrate
migrate.
C
The
the
epics
into
out
of
the
out
of
the
parent
strat
pattern
child
structure
into
some
linkage,
sort
of
thing
that
we
have
within
the
issue.
So
that
generally
does
make
sense
to
me,
but
there
is
some
time
to
get
to
the
epic
board
so
to
say
not
not
specifically
for
types,
because
the
types
is
somewhat
easy
right.
You
just
filter
by
the
feel
that,
but
this
the
epic
specific
type
of
words.
What
should
I
say,
the
type
of
words
where
you
have
this
inheritance
stuff
is
where
the
problem
is.
C
A
I
think
I
I've
added
to
that
under
point
three
under
christian's
point
about
this,
like
customers,
the
way
they
think
about
us
already
is
they
think
about
their
issue
types
in
a
hierarchy.
They
just
want
to
be
able
to
define
what
that
is
so
like.
A
We
could
solve
this
by
adding
types
to
epics
right
and
allowing
them
to
define
their
types
for
their
different
within
their
hierarchy
and
then
once
they
do
that
we
could
basically
convert
those
types
over
to
issue
types
and
those
issues
over
issues
with
the
definable
relationship,
but
really
what
they
want
to
be
able
to
do
it,
whether
it's
through
a
hierarchy
or
through
the
linkage,
is,
do
the
roll-up
be
able
to
define
what
the
roll-up
looks
like
by
issue
type
and
so
like
it
basically
can
map
it
to
their
business
domain
and
how
they
have
their
business
domain
organized
in
terms
of
like
their
planning
objects.
A
So
I
think
once
we
at
least
sort
of
support
that
level
of
linkage
or
customizable
linkage
or
relationships,
then
it's
easier
to
like
allow
them
to
create
what
that
looks
like
and
then
might
basically
click
a
button
and
migrate.
The
epics
that
have
these
different
levels
into
that
other
kind
of
hierarchy
that
they
define
from
the
relationship
standpoint
like
we
can
sort
through
it.
It's
going
to
be
a
little
bit
tricky,
I
think
for
sure,
but
we
want
to
add
that
customizable,
like
relationship
level
anyways.
So
I
think
we
do
that
same
time.
D
D
We
can
add
other
types
of
boards
same
as
we
did
with
epic
board.
For
me,
having
a
board
called
just
board
seems
to
be
quite
generic
but
yeah.
I
I
agree
with
you
that
if
we
would
ultimately
end
up
just
with
issue
type
boards,
we
might
not
need
this
rename,
but
it
might
be
more
specific
to
rename
it
to
issue
thai
port.
A
I
just
had
a
point
because
I
don't
know
if
mars
are
ever
going
to
convert
to
a
type
of
issue,
maybe
I'm
not
sure,
there's
also
a
future
case
where
I
would
like
to
see
basically
like
my
issues
but
like
grouped
by
merge,
requests
so
or
merge
request
group
by
issue.
So
I
could
like
basically
have
swim
lanes
for
my
each
issue
that
shows
merge,
requests
and
different
statuses
or
whatever.
A
A
There's
also
the
use
case
where
I
think
vulnerabilities
is
using
issue
the
issuable
quest,
which
is
for
those
listening,
there's
issuable
and
then
on
top,
that
is
issue
and
which
is
where
we're
talking
about
issue
type
and
merge
requests
and
epic
share
the
issuable
stuff
along
with
vulnerabilities
right
now.
I
believe-
and
I
know
that
they
wanted
boards
as
well.
A
So
I
don't
know
how
that
complicates
stuff.
If
we
do
the
refactor
and
name
it
issue,
boards
that'd
be
fine.
I
would
almost
like
think
about
based
on
issuable
types,
which
of
which
issues
one
of
them,
but
I
would
totally
leave
that
up
to
the
engineers,
I
think
for
y'all
to
call.
E
Gabe
like
as
we're
talking
about
that
random
thought,
are
we
changing
the
name,
issuable
or
issue
at
any
point,
or
has
there
been
thinking
there.
A
We
would
change
the
issuables
in
the
code
only
so
it's
not
user
facing
it's.
It's
basically
like
a
class
that
has
behaviors
defined
that
are
common
across
things
that
use
them
like
merge,
requests
and
issues
in
terms
of
calling
issues,
something
different,
I'm
open
to
that.
What
I
think
will
eventually
happen
is
we'll
we'll,
basically
reference
types
instead
of
issues
specifically
if
that
makes
sense.
It's
like
when
I
go
into
jira
and
I
create
a
new
issue.
A
There
might
be
one
button
that
says
create
issue,
but,
like
I
basically
select
the
type
when
I
want
to
view
it
on
the
board,
I'm
viewing
it
by
type,
and
I
call
it
a
feature
or
a
bug
or
something
else,
and
so
I
would
assume
that
eventually,
like
the
ui
will
not
just
be
like
issues,
it'll
be
hey.
I
want
to
view
my
features
review,
my
whatever
things,
and
but
I
think,
changing
issues
though,
like
is
the
base
thing-
would
be
really
hard
too,
because
our
apis
are
named.
A
E
H
Alexis
I
had
that
same
question
this
week
too,
and
maybe
we
could
even
do
like
just
a
lightweight
diagram
of
how
issue
bulls
stacks
up
compared
to
issue
type,
but
it's
really
just
those
like
assignee
and
labels.
There's
like
three
or
four
fields,
which
is
issuable,
and
it's
just
on
mrs
issues
everywhere.
E
Yeah,
that
makes
sense
we
could
dig
into
that
a
little
it
same
same
issue
I
had
with
like
iteration
milestone
and
like
what
are
those
like
time,
box
or
kit.
You
know
like
what
I
so
anyway
not
to
get
into
that.
Wormhole
sounds
good,
let's
think
further
into
it.
A
Now
we
call
it
and
then
sort
of
the
way
it
works
in
object-oriented
programming
is
you
have
like
the
base
shared
abstraction
down
below
in
the
code
and
then
each
like
merge,
request
or,
let's
say
milestone:
iteration
inherits
basically
the
things
from
its
class
parent
class
so
to
speak,
and
then
like
merges
that
in
so
in
terms
of
what
we
do
like
in
the
ui,
I
think
that
we,
you
should
feel
complete
freedom
to
explore
whatever
you
want
and
then
like
that
shouldn't
have
much
impact
on
what
we
do
from
a
code
standpoint.
D
Yeah,
I
think
it's
our
engineer's
issue
that
we
caused
this
confusion
to
some
extent,
because
issuable
used
to
be
just
backhand
specific
name
for
this
abstraction
of
sharing
the
logic
across
the
resources.
But
it
was
purely
on
a
code
base
level.
It
was
not
user
facing
term
which
we
would
present
outside.
So
I
I
I
was
here.
D
C
D
B
A
Cool,
if
there's
nothing
else
on
that,
I
think
natalia
you
have
item
3c.
J
Yes,
it's
like
very
short
demo
and
I
finished
like
five
minutes
before
the
call.
So
if
something
goes
wrong,
forgive
me
so
it's
basically
like
with
assignees.
We
are
a
factor
in
confidentiality
to
be
a
widget,
and
part
of
this
functionality
is
also
adding
a
shared
state.
So
currently
our
sidebar
is
connected
to
the
same
apollo,
client
and
it
has
the
global
state
now
and
ux
is
not
changing
that
much.
I'm
sorry
alexis
for
the
ux
changes
on
the
sinus.
J
J
H
Thanks
natalia,
that
was
cool.
I
just
put
a
note
in
workflow
here.
This
is
an
mr
showing
how
you
talk
about
a
feature
in
the
release
post
if
it's
not
ready
to
go
or
it's
behind
a
feature
flag.
So
we're
doing
this
right
now
with
our
mvc1
of
epic
boards,
I've
been
trying
to
work
with
the
wording
and
get
it
right
to
let
our
customers
know
that
it's
not
fully
going
to
be
there
for
them.
H
E
H
Yeah,
I
think
yeah
we're
gonna
do
updates,
so
the
next
release
post
will
be
saying
more
what
you
can
do
with
it
and
again
how
to
enable
or
disable
the
feature
flags.
So
if
the
first
one's
going
to
be,
you
can
really
just
see
it
static
of
you,
then
you'll
be
able
to
add
an
edit
and
the
the
goal
will
be
more
people
trying
it
in
beta
and
just
it's
not
official
yet,
but
it's
mostly
for
one
of
our,
like
our
bigger
customers.
H
The
tams
are
pretty
active
in
the
internal
channels
with
us
so
like
I
can
just
tell
them
and
then
they'll
tell
their
whole
team.
So
they'll
know
they'll
get
the
heads
up
ahead
of
it
as
well.
We'll
just
see
when
this
is
going
to
go,
because
I
think
it's
actually
we
just
punted
it.
So
it's
actually
going
to
be
1310,
but
as
soon
as
we
in
the
code
base
have
put
the
feature
flags
in
we'll,
let
them
know.
C
I
was
wondering
for
the
release.
I
don't
know
if
it
makes
sense
at
all
which
is
like
throwing
ideas.
Is
it
worth
having
some
sort
of
an
alpha
section
or
something
where
you
list
everything
that
you
have
on
the
feature
flags
and
stuff
like
that,
so
just
to
kind
of
showcase,
the
things
that
are
being
released
on
the
feature
flexes
right
now
we
do
release
them.
We
do
have
documentation.
We
do
state
how
to
enable
disable
that,
but
that's
not
surface,
as
I
understand
yeah
stuff
like
that.
C
H
I'll
take
that
feedback,
I'm
the
release,
post
shadow,
this
release
and
next
week
I'm
the
manager
of
the
release
post
so
I'll.
Take
that
feedback
to
farnoosh
and
just
see
if
she's
thought
about
grouping
up
under
feature
flags,
I'm
not
sure
how
many
other
teams
are
doing
it.
But
I
think
that's
a
really
good
idea.
H
E
Are
you,
okay,
I'm
just
trying
to
envision
that?
Are
you
envisioning
like
showing
all
the
feature
flags
within
the
release,
posts
and
then
kind
of
what
functionality
each
of
those
enables
is
that
what
you're,
you're
envisioning.