►
From YouTube: Plan Stage Weekly - 2022-07-28
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
B
B
There's
been
a
lot
of
ux
conversations
about
this
stuff
about
orphan
tasks.
The
fact
that
we
can't
list
tasks
quite
well
things
like
that
so
what's
happening
is
now
when
we
click
add
a
task.
The
only
thing
we
can
do
so
you
know
the
only
thing
we
will
be
able
to
do
soon
is
just
create
one
directly
into
the
issue.
We
won't
be
able
to
add
an
existing
one.
B
There's
several
reasons
for
that.
One
of
them,
particularly,
is
that
currently
it's
only
searchable
by
title,
which
is
really
confusing
compared
to
existing
workflows
like
when
we
add
related
issues,
for
example,
so
we're
turning
off,
adding
existing
tasks
for
now
and
we'll
refine
it
and
then
we'll
turn
it
back
on
when
we're
ready.
So
I
guess
for
mvc
now,
we'll
only
be
able
to
create
so
I'm
gonna
create
another
tab.
I've
been
creating
a
lot
of
tasks,
and
this
is
what
happens.
B
You
can
see
my
new
task
here,
there's
a
few
things
like
currently,
for
example,
when
the
form
is
open,
the
add
task
button
is
hidden.
Now
we
want
to
leave
it
and
just
refocus
when
we
click
it
works.
If
the
form
will
work
we'll
submit
when
we
type
enter,
we've
also
put
a
cap
of
255
characters
on
it.
B
That's
a
few
things
that
we're
currently
refining
it
with
ux,
because
I
guess
one
of
the
things
that
happened
in
the
first
iterations
is
that
we
didn't
have
a
lot
of
back
and
forth
with
ux
when
we
built
when
we
started
building
it.
So
now
we're
really
refining
things.
It's
pretty
good
rajat
built
a
remove,
but
so
now
I'm
having
maybe
it's
a
conversation
we
should
have
since
we
can
only
create
and
not
add
an
existing,
because
if
I
remove
something
it
doesn't
really
delete
it.
B
It
just
removes
it
from
this
issue,
so
it
creates
an
all
finish,
an
orphan
task,
so
maybe
a
conversation
to
have
with
ux
to
see
if
that
still
makes
sense,
with
the
new
ux
of
like
not
being
able
to
add
an
existing
task,
and
then
we
can
re-add
this
later.
Maybe
it
should
be
a
delete
instead
of
a
remove-
and
I
don't
have
it
on
this
branch,
but
upcoming
change.
Is
that
we'll
be
able
to
open
the
model
when
clicking
on
the
title
of
the
task
here
so
similar
to
this?
B
If
it
works,
yeah
we'll
display
the
same
model
when
clicking
on
the
title
of
the
task.
Here,
it's
just
on
a
separate
branch.
It's
coming
soon,
hopefully
we'll
be
in
production
early
next
week,
but
yeah.
So
that's
current
progress
like
I'm,
showing
you
upcoming
changes
really
but
yeah.
That's
that's!
Where
we're
at
with
this
widget
any
questions
from
anyone.
B
It's
a
task,
that's
that
doesn't
have
a
parent,
a
task
that
is
not
attached
to
an
issue
and
it
it's
a.
I
think
it's
an
ongoing
conversation,
so
I
I
watched
the
workout
in
amazing.
B
Yes,
so
that's
that
it's
the
conversation
that
we
need
to
have,
I
suppose,
with
product
a
bit
further.
I
suppose
it's
an
ongoing
conversation
about
what
what's
possible.
So
currently,
we
want
to
avoid
this
because
they're
hard
to
find
when
they're
orphaned,
they
don't
have
a.
I
don't
know
they
can't
go
anywhere
and
be
like
baby
task
is
looking
for
his
mommy.
D
We
just
don't
have
like
look
at
all
the
tasks.
Viewed,
yes,.
B
A
Yeah,
so
we
can
view
all
all
tasks
orphaned
or
with
parents
in
the
issue
list
now.
B
A
Or
you
can
still
use
the
there
is
a
work
item,
slash
new
route,
where
you
could
create
not
just
task
at
any
of
our
legacy,
issuables
or
work
items,
and
you
could
create
a
a
task
without
like
there's
no
way
to
associate
a
task
there
with
a
parent
they're
all
orphans.
B
But
yeah
it's
definitely
something
that
we're
still
figuring
out.
I
think
like
what's
possible
in
terms
of
relationship
and
orphanage
of
tasks,
so
we'll
see
how
that
goes,
I'm
just
showing
you
what
the
current
thing
is
and
the
changes
that
we're
making
and
why
we're
making
them.
C
B
C
C
C
Yeah,
I
think
also
like
right
now.
The
tasks
show
up
in
the
issue
list
right
and
then
I
you
know
occasionally
look
at
the
issue
list
and
I
find
it
odd
to
see
like
these,
because
right
now,
there's
no
indicator,
and
just
I
just
see
these
titles
that
are
very
specific
and
very
vague.
I
mean
they're
vague
because
they're
supposed
to
be
part
of
the
bigger
issue
right
there.
C
Right,
yeah,
but
by
default
it's
like
it's
included
right,
yeah.
A
I
mean
simon
we're
just
complaining
about
this,
especially
locally,
it's
impossible
to
find
a
issue
in
the
issue
list
for
me,
because
I've
created
so
many
because.
A
Now
you
can
that's
new
though,
but
yeah
and
then
we'll
have
the
there'll,
be
the
work
item,
type
icons
added
to
the
list
view
which
I
think
will
help.
A
B
A
Yes
exactly,
but
I
just
don't
know
how
many
people
like
how
many
people
actually
click
on
issues,
how
many
normal
you
just
click
on
issues
and
like
use
that
list
without
filtering
at
some
point
for
something.
What.
C
C
A
C
A
A
B
B
To
use
I've
noticed
that
kong
just
asked
one
the
same
thing
for
the
related
like
the
linked
items,
widget,
which
is
the
the
old
one.
So
I
might
just
use
that
one
because
it
feels
like
it's
the
one
that's
going
to
stay.
I
just
don't
want
to
add
a
new
model
component
at
every
level
like
the
description
and
then
each
widget,
because
we
want
to
click
on
it
and
open.
I
feel
like
we
should
reuse
the
model.
So
I
reused
the
one
from
the
description.
C
B
B
No,
I'm
not
importing
I'm
emitting
an
event
and
just
opening
the
same
okay
yep,
because
I
don't
want
to.
I
don't
want
to
keep
importing
the
same
component
everywhere.
I
just
don't
think
it's
very
performant
so
I'll
just
reference
the
other
model
and
I'll
emit
it
towards,
like
the
other
widget.
Instead,
it's
fine.
C
I
guess
just
one
thing
about
like
switching
from
description
to
like
this
new
widget.
Is
that,
like
some,
we
kind
of
have
to
think
about
the
auditing
thing,
maybe
a
bit
sooner.
I
mean
the
original
idea
of
keeping
it
in
the
description.
Before
was
that
you
know,
even
if
you
remove
it,
there's
like
description
changes,
you
know
what
tasks
get
removed
and
all
that
and
if
we
like
like
right
now,
we
can't
delete
tasks
in
the
widget
anyway.
C
A
C
I
mean
it's
not
perfect
anyway,
right
because
even
description
changes,
that's
just
the
title.
We
didn't
really
store
the
changes
to
the
tasks
you
know,
labels
or
signees
or
whatever.
We
are
adding
now
so
kind
of
lose
that
with
you
just
delete
the
task
right,
but
yeah.
So
that's
also
something
to
think
about.
Do
we
really
allow
delete
learning
because
for
issues
right
now,
we
don't
actually
allow
deleting
we
just
close
issues
right
and
we
delete
them
only.
A
That
yeah,
I
wonder
if
delete
of
task,
is
a
hard
delete
or
is
it
more
of
an
archive
and
what
kind
of
permissions
do
you
need
to
delete
that
because
even
yeah
with
an
issue
even
as
the
author,
I
can't
delete
it
unless
I'm
was
it
maintainer
in
the
project.
D
Yeah
so
let's
double
check
that,
but
I'm
pretty
sure
you
have
to
be
an
owner
to
delete
an
issue.
A
It's
the
only
one
that
can
delete
issues
on
on
our
plan
test.
There
are
other
owners,
but.
C
C
A
Yeah,
that's
a
good
point
too.
Do
we
have
any
on
the
hierarchy?
Widget?
Are
we
just
showing
for
now
title,
and
I
don't
remember
what
else
was
on
it,
but
we're
not
showing
the
state
of
the
task.
B
A
B
A
Yeah
for
sure-
and
it's
a
little
bit
like
that's
part
of
the
complexity-
that
we
took
away
by
removing
it
from
the
description
in
that
we
don't
worry
about
it,
tying
into
a
the
check
mark
or
the
check
box
next
to
it,
and
that
was
not
being
synced.
A
Okay,
but
yeah
henrik.
I
agree
that
we
should.
A
A
Okay,
all
right,
so
we
had
the
ama
conversations
earlier
today.
I
think
they
went
pretty
well.
A
Do
you
all
have
any
other
questions
that
weren't
answered
that
I
can
attempt
to
answer
that
we
can
send
over
to
gabe
and
melissa,
or
we
can
just
have
a
conversation
beyond
what
we
just
did
around
work
items?
Any
kind
of
what
do
you
all
want
to
talk
about
as
far
as
work
items.
B
I
don't
have
extra
questions
not
at
this
stage,
at
least,
but
I
just
wanted
to
say
that
it
was.
I
mean
it
was
a
bit
disappointing
that
I
couldn't
join,
but
I
watched
the
recording
and
I
thought
it
was
super
interesting.
I
feel
like
there's
still
a
lot
of
things
that
are
uncertain.
There's
a
lot
of
debate
around
like
the
level
of
customizations
and
things
like
that
which
are
far
along
the
road.
B
That's
why
I'm
like
not
not
necessarily
eager
to
dive
into
it
today,
but
it
would
be
nice,
I
suppose,
to
sort
of
have
a
clearer,
long-term
picture,
because
that's
something
I'm
struggling
with
a
little
bit
is
I
have
a
rough
idea
of
what
we're
trying
to
achieve,
but
it's
like.
What's
the
long
term
goal,
where
do
we
stop?
How
far
are
we
willing
to
go,
and
also
what's
the
next
step
like
I,
don't
really
have
a
big
visibility
of?
What's?
B
What's
the
next
thing
that
we're
building
as
part
of
this
big
initiative,
it's
it's
so
big,
it's
hard
to
visualize
the
different
parts
and
how
we're
going
to
chain
them
and
like
there's
always
conversations
also
about
dependencies.
Like
I
should
we
have
done
it
in
a
different
order
so
like?
How
do
we
decide
the
order?
What's
the
next
one?
What
are
or
what
are
the
multiple
next
ones?
B
And
then
maybe
we
should
order
them
based
on
dependencies
like
try
to
have
a
longer
vision
of
the
next
steps,
and
then
we
can
make
decisions
on
order
based
on
what
those
next
steps
are.
So
I
feel
a
little
bit
in
the
dark
at
the
moment
in
terms
of
visibility,
but
I
don't
have
any.
I
don't
have
any
particular
questions
on
implementations
or
things
like
that.
A
Yeah
and
I
think
alexandria
asked
a
similar
question
in
one
of
the
amas
around
like:
what's
the
what's
the
what's
the
checkpoint
or
what's
the
next,
the
next
few,
like
bigger
steps,
we
think
right
now
it's
getting
tasked
to
ga.
What
do
we
do?
After
do,
we
focus
on
tests
still
and
tweak
that
to
kind
of
work
on
the
next.
B
B
Are
we
sure-
and
I
don't
even
know
what
else
is
missing
like
I'm
just
trying
to
like
build
like
I'm,
not
even
that
much
involved
in
tasks
I'm
trying
to
help
with
a
few
things,
but
I'm
mostly
focused
on
hierarchy
and
even
for
hierarchy,
I'm
like
when
are
we
ready
to
turn
it
on,
like,
I
don't
know,
what's
missing
and
where
we
want
it
to
go
so
yeah?
I
just
wish
I
just
I'm
wishing
for
a
clearer
picture,
just
in
general
of
next
steps
and
more
longer
term.
A
Yeah
definitely
want
to
have
a
clear
list
of
like
the
next
few
checkpoints,
and
then
we
can
work
on
those
checkpoints
individually
and
say:
okay.
This
is
what
we
really
need
to
get
done
to
get
tasks
to
ga
or
to
hit
this
checkpoint,
and
then
we
can
like.
We
don't
have
to
say
I
don't
want
to
put
it
in
a
timeline
or
anything
or
put
it
on
a
roadmap
or
put
dates
on
anything.
You
just
need
to
list
out
what
those
checkpoints
are
and
then,
like
I
said
we
can
re.
A
We
can
evaluate
like
when
we're
actually
going
to
complete
these
things
after
we
get
to
each
checkpoint,
so
yeah.
I
think
I
think
gabe
nick
melissa
alexis
are
working
on
on
documenting
those
checkpoints,
but
if
not,
we
should
definitely
I'll
talk
to
them
to
make
sure
we
get
something
like
that
done.
A
As
far
as
the
ga
to
tas
yeah,
I
was
also
struggling
and
still
I'm
struggling
with
what
what
he
really
needs
to
be
in
for
ga,
because
that
has
that's
changed
every
time
we've
gotten
close
to
getting
it
to
to
actually
turning
it
on
oftentimes
because
of
extra
feedback
we've
gotten
internally,
but
then
also
when
we've
gotten
that
feedback.
I
haven't
really
been
sure
on.
A
A
So
we
need
to-
and
I've
been
talking
with,
various
people,
because
I
don't
think
we
have.
It
documented
anywhere
saying
that,
like
who's,
the
dri
there
and
everyone,
I've
talked
to
it's
been
kind
of,
everyone
has
kind
of
said
that
it
should
be
product
and
it
normally
is
product
that
makes
the
final
decision
because
they're
the
ones
that
are
communicating
with
the
stakeholders
they're
the
ones
that
have
the
most
input
to
be
kind
of
the
decision
makers
and,
of
course,
taking
input
from
engineers
from
ux
from
everyone
else.
A
C
A
Yeah,
so
ga
is
also
a
like:
we've
been
using
the
term.
Ga
I've
been
thinking
of
it
more
as
the
first
nbc
or
when
we
default
on
the
work
items
future
flag.
Ga
is
generally
available,
charlie.
A
I
think
the
my
interpretation
of
of
that
of
turning
on
the
work
items
feature
flag
and
now
the
work
items
hierarchy
feature
flag.
A
Turning
those
on
is
the
first
iteration,
and
it
is
at
that
point
still,
okay
to
have
the
the
alpha
yeah
the
alpha
tag
in
graphql
we're
also
looking
at
in
that
first
iteration
being
officially
beta,
which
I
didn't
know.
We
had
a
process
to
make
something
actually
beta
outside
of
what
you
did
simon
for
for
dark
mode,
which
is
just
saying
that
this
is
beta
but
yeah.
A
I
think
if
we,
if
we
put
it
in
the
in
the
product
somewhere,
that
this
is
our
beta,
then
it's
considered
beta
and
then
we'd
have
to
go
through
a
couple.
Other
steps
to
get
it
to
generally
available.
A
So
to
answer
your
question
yeah,
I
think
if
we
turn
it
on,
if
we
turn
on
those
feature
flags
on
and
default
them
to
on,
we
can
still
keep
the
alpha
tag
in
graphql,
and
I
think
we
should,
because
I
feel,
like
oh
yeah.
Dark
mode
is
alpha,
but
I
think
we
should.
We
should
keep
that
that
tag
in
there
for
a
little
bit
until
it's
nice
and
stable
and
we're
sure
that
it's
not
going
to
it's
not
going
to
change
much.
A
A
That's
what
we
yeah!
That's
that's
what
we
have
in
for
task
currently,
which
makes
it
kind
of
difficult
to
use
graphical
in
production
because
that'll,
I
think
it
takes
away
the
autocomplete.
A
A
All
right,
anyone
else
have
any
other
work
item
stuff.
A
Yeah,
if
you
haven't
gotten
a
chance
to
watch
the
amas-
and
I
apologize
enough
for
almost
everyone
here-
it
was
the
middle
of
the
night
for
you
all,
so
I
apologize
for
it
being
at
that
time.
A
Maybe
we
can
have
another
one
internally
at
a
more
reasonable
time
in
the
next
couple
of
of
weeks,
but
yeah.
If
you
didn't
get
a
chance
to.
A
I
highly
suggest
you
do.
I
think
it
is
a
it's
a
good
walk
through
of
kind
of
a
product's
vision
and
just
vision,
around
work
items
and
some
of
the
methodologies
that
were
that
we're
thinking
about
some
of
the
defaults
that
we're.
A
B
Yeah,
I
just
thought
that
I
might
mention
it
in
this
meeting,
so
it's
kind
of
a
follow-up
on
the
feedback
we've
been
gathering
during
the
past
couple
of
retros,
so
I'm
proposing
that
we
use
health
status
to
help
with
the
visibility
of
well
health
status
of
our
deliverables.
B
It's
like
it
there's
a
few
ideas
like
I
can
expand
on
like,
for
example
like,
instead
of
having
like
managers
and
product
managers
and
so
on,
like
asking
engineers
like,
oh,
is
it?
Is
it
going
to
make
it?
Is
it
going
to
make
it
like?
We
can
have
like
that
overview
of
deliverables,
like
mainly
probably
mainly
the
primary
deliverable,
like
it's
really
useful,
to
see
health
status
in
the
epic
tree,
for
example,
for
issues,
and
we
can
see
like
what's
at
risk
of
not
making
it
and
what's
it's
likely
to
make
it.
B
I
think
that,
and
that
will
also
give
us
like
it.
I,
like
the
visual
aspect
of
like
seeing
like
what's
looking
good
and
what's
not
looking
good,
and
maybe
it
will
help
us
plan
our
milestones
a
little
bit
better
in
the
future
as
well,
but
I'm
mostly
looking
at
communicating
better
between
engineering
and
like
product
design
managers
to
have
a
good
idea
of
like
how
likely
we
are
to
be
able
to
deliver
a
feature
for
a
specific
milestone.
B
Basically,
but
please
read
comment
on
the
emma
yeah.
Let
me
know
what
you
think
and
if
there's
like
this
is
one
suggestion
and
it's,
it
should
probably
be
just
part
of
like
an
improvement
on
our
planning.
But
this
is
one
idea
that
I'd
like
to
implement.
A
Yeah,
I
think
it's
a
great
idea,
it's
fairly
lightweight
to
you,
know,
to
report
on
the
status
of
of
things
as
a
manager.
What
I
would
like
would
be
to
receive
a
notification
when
the
health
status
is
changing.
So
maybe
that's
a
like.
B
B
How
we
see
how
we
can
expand
on
it,
like
one
of
the
suggestion
that's
been
made
on
my
bird
request
is:
if
no
one
is
assigned
to
an
issue
by
a
certain
date
within
the
milestone,
it
should
be
put
at
risk
by
default,
and
I
think
that's
a
great
idea
because
it
becomes
at
risk
by
default
if
no
one's
picked
it
up
and
like
being
notified
of
the
health
status.
Change
specifically
like
that's
also
a
great
idea
like
you
could.
B
Could
you
sign
up
for
notifications
just
for
health
status
or
being
signed
up
to
notifications
signs
you
up
for
health
status.
Probably
is
more
realistic,
but,
like
I
don't
think
we
have
notifications
for
that,
like
we,
don't
have
notifications
for
like
change
of
labels,
for
example.
A
Yeah
and
it
looks
like
there's
a
quick
action
for
health
status,
so
we
can
use.
We
can
definitely
automate
that
just
using
gitlab
bot.
A
A
B
I
think
the
like
the
initial
proposal
is
for
product
planning
team,
even
though
I'm
mentioning
here
and
there's
a
lot
of
project
management,
but
we
could
just
implement
it
throughout
plan
completely
like
the
page
update
in
the
mr
is
just
product
planning,
but
if
project
management
is
also
keen
like,
I
think
we
should,
we
could
implement
it
at
the
plan
level.
That'd
be
great,
especially
with,
like
all
the
overlap
we
have
between
the
two
teams
I
feel
like
it
would
probably
have
be
greater
value.
D
Are
you
thinking
that
the
gitlab
bot
thing
would
be
in
the
issue
or
would
be
in
the
merge
request.
C
B
B
B
Oh
no,
it
was
just
the
gitlab
thing
is
just
about
updating
the
health
status
at
risk
when
there's
no
assignee
at
a
certain
stage
during
the
milestone.
B
Well,
yeah,
I
would
suggest
reading
the
merge
request
I
submitted,
but
the
main
idea
is
just
like
the
main
deliverable
is
healthy
by
default
at
the
beginning
of
the
milestone
and
like
dris
update
as
the
milestone
moves
through
as
we
like,
we
see
dependencies
and
the
like
unlikely
to
make
it
like
that's
when
the
drl
updates
the
status.
That's
that's
the
idea.
D
Okay,
cool
yeah,
so
I
saw
I
saw
that
and
then
I
heard
get
that
bot
thinking
is
it
gonna
leave
more
comments?
I
find
that
merge
requests
are
quite
noisy
because
of
a
lot
of
automated
stuff.
That
happens.
You
know
suggesting
reviews
and
then
danger,
and
then
all
this
sort
of
stuff
anyways
doesn't
matter.
That
is
true.
D
A
Ignore
a
lot
of
the
stuff
that
I
shouldn't
on
that
on
that,
because.
C
D
D
B
D
I
I
think
my
favorite
was
when
it
suggested
gitlab
art
as
a
reviewer.
A
Cool,
we
should
also
get
some.
I
think,
one
of
the
other
teams
years
ago,
when
we
released
health
status,
tried
dog
fooding
it.
I
wonder
if
they
still
do
use
it,
but
I
I
want
to
dig
into
what
team
it
was.
That
was
using
that
to
see
if
they
have
any
learnings,
because
I
don't
think
we
ever
got
any
or
we
didn't
get
much
feedback
on
it
from
from
anyone.
A
So
maybe
there's
other
hints
they
can
give
us
or
tips.
They
can
give
us
with
the
thing
that
we
built,
but
they
used
because,
like
off
the
top,
my
head,
I'm
thinking
again
as
a
as
a
manager
like
I'm
going
to
want
to
be
able
to
see
the
stuff
that
is
at
risk.
A
B
A
Yeah,
just
because
I'm
thinking
it'd
be
tough
to
to
click
into
every
issue,
to
get
the
health
statuses
well,.
B
The
the
initial
proposal
is
just
to
use
it
for
the
main
deliverable
so
like
we
have
an
epic
and
it's
like
all
the
issues
within
that
epic,
because
it's
easy
to
see
in
the
epic
tree,
but
if
there
is
a
desire
to
use
it
for
all
the
issues
in
the
milestone,
I
think
board
would
be
probably
a
good
way
to
look
at
it,
because
I
I'm
pretty
sure
it
is
on
board.
It's
just.
We
haven't
used
it.
B
So
I
can't
I
don't
remember
seeing
it
because
I
haven't,
we
haven't
used
it,
but
it
must
be
somewhere
in
there
and
if
it's
not
well,
let's
build
it.
A
B
15
for
that
yeah,
so
we'll
try
for
50.,
but
like
we're
waiting
for
feedback
on
this
still
I'd
like
to
hear
from
product
managers
on
it
see
what
they
think,
because
it's
also
about
them
receiving
that
information.
So
we'll
wait
but
yeah.
Hopefully
we
can
have
that
feedback
in
time
and
start
using
it
in
54.
A
I
was
just
gonna
say
we
should
well,
let's
keep
it
just
in
the
product
planning
handbook
page
for
now,
and
then
let
me
think
about
if
we
want
to
like,
we
should
get
feedback
from
both
groups,
but
let's
hold
off
on
making
it
like
a
shared
or
a
partial.
That's
shared
between
both
of
the
teams.
A
A
But
I
may
change
my
mind
on
that
soon
and
then
we'll
just
we'll
just
use
it
on
both
teams
in
54.
A
A
An
issue
that
I
create,
I
think
I
cloned
it
because
there's
way
too
many,
it's
too
pretty
of
an
issue
or.
B
But
yeah
I'd
be,
I
think
we
should
build
it
on
board.
I
don't
know
why
I
thought
it
was
done,
but
I
guess
it
isn't.
I
think
it
was
scheduled
and
then
other
priorities
came
along.
We
should
definitely
build
it.
D
Make
them
visually
they
get
stale
like
they,
they
look
either
they
start
to
gray
or
they
hard.
B
C
I
did
yeah,
oh
no.
I
just
wanted
to
mention
so
I've
seen
david,
so
he
used
to
post
like
status
updates
without
using
the
health
status.
If
you
look
at
the
issue
like
he
has
a
section
in
his
comment
called
status
in
review
and
he
comments
it
like
that,
like
every
other
day
yeah
as
far
as
I've
seen
him
so
just
fyi.
A
Yeah-
and
I
think,
there's
other
there's
other
groups
that
I
think
it's
product
intelligence
that
pings
their
slack
channel
every
week
to
go
into
the
issues
and
post
an
update,
and
I
think
they
provide
a
template
there,
which
may
be
something
we
want
to
consider
in
the
future.
But
I
think
a
good
first
iteration
in
improving
the
the
visibility
of
of
status
and
what
we're
working
on
in
engineering
is
yeah
start
off
with
health
status.
A
C
B
A
C
B
B
A
I'm
bad
at
that.
I
let
it
I
let
it
pull
in
the
labels
from
the
issue,
including
the
workflow
label,
and
then
I
just
leave
it
there
and
don't
change
it
in.
Mrs,
but
again
like
like
hadrick
said
I
don't
know
if
we're
using
workflow
labels
in
mrs
for
any
kind
of
metrics
that
I
know
of
so
I
don't
think
it's
that
big
of
a
deal.
We
don't
do
much
with
that.
B
B
C
C
C
A
B
D
So
late,
I
I
snuck
in
a
agenda
item
at
the
top
there
and
finally
off
manage
this
release.
Sometime.
I've
got
a
couple
of
things
I
have
to
just.
D
A
That's
that's
everyone
now
right.
D
Lucky
last.
I
guess
it's
been
super
fun
though,
but
there's
a
lot
of
owner.
D
I
wanna
have
work
to
be
done
in
terms
of
technical
bet,
so
yeah
soon
projects
can
can
be,
can
have
owners
added
directly
via
the
ui
right
now
you
can
do
it
via
api,
but
if
you
try
to
do
it
in
the
ui,
it
doesn't
work.
C
A
All
right,
all
we'll
have
a
good
rest
of
your
days.
Talk
to
you
all
later.