►
From YouTube: Plan | Weekly Sync 2022-08-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
Cool
plan
team
meeting
17th
of
august
2022
right.
I
have
the
first
item
so
yeah
like
this
came
up
during
the
week
and
I
wasn't
sure
how
far
we
got
with
it
or
whether
we
stalled
with
it
or
what.
But
we
used
to
have
the
notion
of
creating
a
unified
notification
center,
and
I
know
alexandria
was
working
on.
Parsing
mentions
out
of
comments
and
issue
descriptions
and
all
that
kind
of
thing.
So
my
questions
were
like:
do
we
still
have
all
these
tables?
Are
we
keeping
them
up
to
date?
A
What
would
it
be
like?
What
would
it
take
to
finish
this
feature,
and
would
it
help
with
some
of
the
slowness
we're
seeing
related
to
calculating
participants,
which
is,
in
some
cases
like
extremely
slow
gave
you?
The
first
comment.
B
Yeah,
so
I
actually
surfaced
this
on
my
team's
15
up
for
planning
issues,
something
that
I'd
love
to
classify
in
the
maintenance
bucket
right
for
things
and
then
slowly,
chip
away
at
a
community
member
had
me
a
couple
weeks
ago
with
an
interesting
idea
that
if
we
had
taken
a
more
passive
approach
to
doing
this
sort
of
that
would
be
almost
done
now.
B
I
don't
know
if
it
was
a
viable
path,
just
because,
like
I
don't
know,
if
we
could
selectively
know
which
issues
have
been
migrated
to
using
the
appropriate
tables
or
not.
In
any
event,
I
think
this
would
be
great
because
I
think
there's
a
lot
of
performance
wins
anyways
because
it
seems,
like
you
know,
having
to
parse
through,
like
thousands
of
lines
of
markdown,
to
get
out
all
the
references
millions
of
times
a
week
would
help.
So
if
we
want
to
share
this
with
product
planning,
I
don't
know
where
things
are
at.
B
B
He
at
least
outlined
the
whole
plan,
so
I
think
if
his
implementation
path
still
stands,
then
it
should
be
easy
to
pick
back
up,
and
I
also
wanted
to
call
out
that
the
building
the
proper
notification
center
and
like
is
a
huge
undertaking
right,
and
I
think
this
would
at
least
if
we
did
this
at
least
allow
us
to
surface
all
the
issues
that
you're
subscribed
to,
which
is
probably
one
of
the
most
uploaded
issues
in
all
of
our
stage.
C
Yeah,
I
recently
actually
chatted
alexandra
about
this
in
slack
in
our
plan
channel
like
because
I
was
curious
about
what
the
state
of
things
are,
so
actually,
where
the
tables
are
there
and
we're
active,
we
are
saving
the
data.
Every
time
you
know,
descriptions
are
updated,
notes
are
updated
and
all
that
are
created
and
updated.
C
So
new
notes
and
new
descriptions
are,
you
know,
have
what
we
think
is
the
correct
data,
but
you
know
we
still
have
like
there
are
edge
cases
or
anything
and
the
thing
is
we
don't
use
this
data
right
now
right,
so
we
don't
know
if
it's
100
correct.
You
know
until
it's
out
there,
so
the
next
step
actually
is
to
use
this
data
in
computing.
The
participants,
so
participants
does
not
entirely
contain.
C
I
mean
it's
not
100
mentions
right
because
it
contains
the
issue.
Author,
the
note
authors
and
all
that,
so
the
participants
logic
has
to
account
for
those
and
yeah
instead
of
parsing
mark
down
it
just
uses
dimensions
table.
So
I
think
that's
the
next
step
and
I
was
also
just
going
to
note
I
kind
of
found
it
confusing-
that
we're
saying
notification
center
here
and
the
subscription
thing.
So
I
guess
you
could
say
it's
part
of
the
notification
center.
C
A
Just
to
clarify
there,
you
said
new
notes
and
new
descriptions
have
what
we
think
is
the
correct
data
did
do.
We
need
to
do
some
kind
of
backfill
migration
to
migrate
all
previous
issues
and
describe.
C
So
we're
actually
doing
what
the
you
know:
community
contributor,
like
kind
of
mentioned,
it's
like
the
new
things
right
now
are
actually
being
you
know,
filled
up
in
the
table
so
that
the
main
thing
we
need
to
do
is
to
verify
right
now
and
to
find
out
which
ones
need
migrating.
If
there's
a
way
to
do
that,
so
we
only
migrate
the
rows
that
need
to
and
yeah.
A
Cool
so
for
some
context,
some
epic
sidebars
don't
load
at
all
at
the
minute.
If
there
are
too
many
comments
on
the
epic
and
it's
really
a
horrible
experience,
because
the
queries
are
combined
anyway,
the
the
request
times
out
before
you
get
labels
or
any
other
information
about
the
epic
and
I
feel
like
if
we
could
just
use
a
table
to
look
up
participants.
A
I
mean
I
wonder
in
the
first
place,
how
useful
participants
actually
is-
and
I
certainly
don't
think
we
should
be
blocking
the
rest
of
the
sidebar
on
on
the
basis
of
it
not
being
available
quickly,
but
even
better.
If
we
could
maintain
the
same
experience
or
even
improve
it,
but
also
improve
performance
as
well.
C
And
also
I'd
like
to
add
that
the
code
review
theme
also
has
problems
with
this
recently
because
of
some
system
note
like
that
had
like
thousands
of
commit
references
and
then,
when
you
play
smart
down,
we
also
parse
these
commits
for
some.
You
know,
because
we're
checking
access
and
all
that,
but
they
worked
on
some
optimizations,
though
I
think
it's
still
like
kind
of
a
hack
right
or
a
workaround.
They
kind
of
skip
these
system
notes
that
are
that
don't
have
user
references,
so
it's
kind
of
yeah
a
trick.
A
Gabe,
I
think,
you're
the
only
pm
on
the
call
so
like.
If
I'm
looking
for
a
solution
to
this
problem,
I
have
where
participants
are
far
too
slow
in
some
epics.
I'm
trying
to
gauge
like,
what's
the
appetite
to
to
fix
this
I'd
like
to
complete
this
work,
to
a
certain
extent
that
we
could
use
consume
this
table
to
calculate
participants
like.
Are
we
talking
like
a
three-month
thing,
or
is
it
like
on
the
long
finger
for
a
year
or
what?
What's
your
read.
B
I
it's
one
of
those
things
where
customers
don't
ask
for
this
necessarily,
but
if
we
can
use
this
work
to
solve
the
problem
of
eventually
somewhere
in
the
ui,
showing
a
list
of
all
the
issues
that
I'm
subscribed
to
it's
a
huge
win
for
the
wider
community
and
I
think
for
everyone
who
likes
to
use
gitlab-
and
it's
I
mean
it's
a
quality
of
life
thing.
So
that's
where
I
sort
of
saying
if
we
can
couch
some
of
the
work
in
maintenance,
at
least
all
the
backfills
and
getting
the
data
model
right.
B
Then
it
makes
the
the
the
effort
to
actually
build
it
to
the
ui,
much
smaller.
That
makes
sense.
So
it's
sort
of
one
of
those
things
that,
like
I,
wouldn't
dedicate
all
the
team
to,
but
just
like
to
chip
away
out
slowly
over
time.
If
we
can
all
do
that
as
a
team,
I
don't
know
if
that
answers
your
questions,
but
I
think
it's
it
would
be
nice
to
deliver
on.
E
I
can't
type
very
fast,
apparently
yeah,
and
we
could
also
do
some
research
into
you
know
if
users
use
this,
why
what
they
expect
to
see
here,
and
I
don't
think
that
negates
what
gabe
just
said
but
like
to
your
point,
you
know:
do
users
even
want.
A
E
And
why
john
and
I
know
the
create
team
was
playing
around
with
removing
participants
entirely,
so
I
could
loop
in
with
them
and
understand
why,
as
well.
A
C
F
B
Matthew
narrats
from
create
was
working
on
doing
some
solution,
validation
around
the
notification
center.
I
don't
know
how
far
he
got.
I
think
it
sort
of
started
out
because
we
didn't
have
engineering
capacity
to
kind
of
move
it
forward,
but
the
idea
is
sort
of
evolving
to
do
is
to
be
instead
of
like
having
all
of
your
notifications
only
delivered
to
email,
they
can
all
be
in
gitlab
and
then
sort
of
changing
how
to
use
behave
to
make
more
sense.
B
And
then,
as
part
of
that
you,
you
could
basically
see
all
the
lists
or
a
list
of
all
the
issues
that
you're
participating
in
or
subscribe
to
or
whatever
right,
because
we're
using
it
for
the
participants
for
notifications
and
so
like
trying
to
bring
that
all
together
into
a
cohesive
experience,
similar
to
what
github
has
rather
nice
little
review
page
for
a
single
person,
but
I'm
not
sure
where
that's
at
and
I
like.
B
G
Yeah,
I
don't
want
to
jump
in
front
of
cash
all,
but
jackie
bauer
started
sort
of
renewing
interest
in
that
notification
center
by
getting
some
volunteers
to
it's,
it's
a
perpetual
topic
where
man
I
really
wish
we
could
do
a
notification
center
or
make
to-do's
better
or
whatever
clump
that
all
in
and
she's
sort
of
pulling
people
who
are
interested
involved.
Volunteering
their
time
on
the
ux
side
to
explore
some
ideas,
so
that'll
link
to
the
issue
right.
There.
H
Yeah
so
I
discovered
octobox,
I
think,
almost
five
years
ago
it
has
been
a
quite
old
project
and
it
always
supported
github.
It
never
supported
anything
else,
but
it
basically
uses
get
a
public
apis
by
authenticating
user
via
sso,
and
you
can
basically
log
in
with
your
github
account
and
then
it
pulls
in
all
the
notifications
and
organizes
it
well.
H
It
doesn't
fetch
the
data
and
show
it
within
its
own
app,
but
it
basically
creates
a
set
of
links
in
an
accessible
way
where
you
can
basically
look
at
different
categories
like
which
projects
you
have
and
what
kind
of
notification
from
a
particular
project
you
receive.
So
I
think
we
can
at
least
look
at
how
octobox
is
doing
and
maybe
get
some
ideas
from
there.
B
Hey
guys
next
one
one
of
the
things
to
just
future
thinking,
I'd
love
to
see
participants
evolve
into
something
more
like
sharing
like
we
talked
about
that
and
I'll
hire
heinrich
chat
with
me
a
bit
on
the
issue
about
adding
a
non-project
member
to
a
confidential
issue,
which
is
a
big
blocker
for
a
couple
of
companies
adopting
gitlab
and
then
there's
also
the
idea
of
like
sharing
issues
with
other
groups
and
projects
that
sort
of
thing,
but
anyway
like
that
would
seem
like
if
it
became
this
like
mechanism,
show
who
the
who
had
access
or
who
the
issue
or
work
item
was
shared
with
it
might
have
a
little
bit
more
value
other
than
just
like
seeing
it
right,
because
I
I
don't
think
it
adds
a
ton
of
value
on
its
own
from
like
an
user
standpoint,
but
I
think
it
could
evolve
into
being
something
that
adds
value
so
definitely
worth
doing
some
more
research
on.
B
A
Next
step,
there
is
probably
for
us
to
decouple
those
like
the
immediate
problem
that
we
have
on
on
the
product.
Planning
site
is
with
this
epic
thing,
so
I
think
the
first
thing
we'll
do
is
decouple
those
queries
and
then
maybe
we
should
just
like
henrik.
You
mentioned
that
there
was
a
partial
migration
done.
A
As
far
as
the
notification
center
itself
like
we
can
revisit
that
in
future.
I
suppose
cool
all
right
after
the
next
item.
Just
a
quick
one,
we
need
to
update
documentation
related
to
tasks
today,
as
it
still
describes
the
old
experience
and
not
the
experience
that
we'll
release
marcin
has
been
working
on
this,
but
needs
help
from
an
engineer
to
help
him
close
out
the
threads
that
are
currently
open.
On
that,
mr
mostly
related
to
permissions.
A
Could
anyone
from
engineering
who's
currently
on
the
call
volunteer
to
help
close
those
threads?
If
not,
I
can
look
for
somebody
outside.
A
All
right,
cool
I'll,
look
outside
the
call
martian
you're
up
next.
I
All
right,
so
I'm
just
some
time
ago,
gabe
and
nick
has
raised
it
a
couple
of
times
we
at
some
point.
We
want
to
start
introducing
two
users,
the
term
work
item.
I
guess
since
like
it's,
the
it
shows
up
in
a
couple
places-
and
I
thought
a
separate
dog
page
would
be
good
for
that
and
then
in
in
the
dogs
nav,
we
couldn't
nest
tasks
under
it
and
I
don't
know
like
we
could
explain
the
the
things
we're
planning
for
for
work
items
to
have
in
common.
I
I
Okay,
bye
see
your
read
only
and
so
cushion.
H
Yeah,
so
I
was
just
adding
that
a
couple
of
months
ago
we
had
this
discussion
on
our
slack,
like
most
of
our
features
are
increasingly
focusing
on
enterprise
users,
while
we
don't
think
of
features
from
ground
up
for
our
ics
or
essentially
community
users,
who
are
not
necessarily
paying
customers
of
gitlab,
but
at
the
same
time,
are
looking
forward
to
such
features,
and
there
were
like
direct
comparisons
with
competition
where
there
are
features
exclusively
useful
for
ics
and
in
individual
contributors.
H
So
I
think
notification
center
is
kind
of
a
pro
project
that
can
be
sold
to
our
higher-ups
as
something
that
we
can
work
on
as
a
team,
and
then
it
can.
It
basically
is
kind
of
overlapping
between
something
for
ics
and
something
for
the
enterprise
users
as
well.
B
Yeah,
I
was
gonna
say
like
I,
I
agree.
I
talked
with
melissa
here
now
and
I
talked
to
her
all
the
time
about
like
how
do
we
make
progress
on
today's
notifications?
I
feel
stuck
like
I'm.
You
know
where
should
I
live,
is
plenty
of
the
right
place
and
long
term.
B
I
don't
know
if
plan
is
the
right
place,
because
it
doesn't
have
a
lot
to
do
with
planning,
but
I
think
if
this
is
something
we
all
like
agree
that
we
want
to
come
together
around
and
contribute
to,
I
think
it
might
be
more
realistic
to
make
progress
while
also
maintaining
velocity
with
our
direction
items
you
know
like
if,
if
we
want
this
to
be
a
stage-wide
sort
of
like
initiative
that
we
contribute
to
and
it's
not
like
deliverable
necessarily
but
something
that
we
want
to
make
consistent
progress
on
month
over
month.
B
I
know
there's
a
ton
of
appetite
across
the
company
too,
that
we
could
drum
up,
support
and
help
with,
and
so,
if
that's
something
that,
like
you
all,
really
are
passionate
about
doing,
then
I
will
put
on
my
pm
hat
for
that
and
try
to
help
get
things
coordinated
and
kind
of
treat
it
more
like
a
true
open,
open
source
thing
where,
like
everybody,
can
just
sort
of
work
on
it
as
they
can,
but
yeah
that
would
be
cool
if
y'all
want
to
do
that.
E
A
Yeah,
the
second
benefit
of
that
is
that
we
actively
encourage
contributors
to
look
under
a
particular
label
and
for
issues
with
weight
one,
and
that
kind
of
thing
like
assuming
that
the
majority
of
contributors
are
first-time
contributors,
are
relatively
new.
The
benefit
of
having
like
the
whole
thing
like
a
really
small
iteration,
fully
scoped
out
and
waited
and
with
this
correct
label,
is
that,
like
some
people
from
the
community
can
just
pick
up
issues
and
they
can
see
what
they're
going
to
contribute
to
and
everything.
F
B
B
The
question
is
like:
how
do
we
want
to
proceed
like
I'm
going
to
say,
go
for
it
we'll
figure
out
along
the
way
we
can
kind
of
do
something
and
learn
as
we
go,
but
blair
might
think
otherwise,
because
there's
a
sort
of
we
just
want
to
make
sure
we
don't
introduce
anything,
that's
weird,
but
I
I
trust
everyone
like
we're
all
working
together,
we'll
figure
it
out,
but
is
there
anything
that
blair
or
nick
or
alexis
y'all
want
to
do
to
at
least
like
help
us
figure
out
what
we
need
to
do?
B
G
So
that's
that's
where
I've
gotten
myself
to
I'm
now
the
police,
on
validation,
okay,
I
I
think
honestly,
coordinating
with
that
effort
is
probably
our
best
bet.
Listen.
The
notification
center
had
the
biggest
push
forward
with
with
the
nearest
before
I
was
even
here,
and
so
I
think,
there's
it's
you
know.
A
lot
of
good
can
come
from
a
passion
project
with
a
bunch
of
people
who
care
about
the
topic
taking
it
forward.
G
If
that
solves
our
problem,
though
they
may
be
wanting
to
go,
do
this
for
a
different
reason,
not
sort
of
the
multi-fold
issues
that
we're
seeing
here?
Basically
everything
all
of
this
is
converging
on
a
notification
center
and
and
what
not
here
so
yeah
not
really.
I
think.
E
I
think
if
we
really
tried,
we
could
find
a
lot
of
this,
like
user
proof
of
this
being
a
problem
game
like
I
can
help
you
with
that.
I
think
there's
a
lot
of
stuff
on
like
sas,
there's
a
lot
of
feedback
on
nps
like
there's.
This
is
a
theme.
I
think
it
should
be
pretty
easy
to
find
some
like
high
level
stuff.
B
But
yeah
the
problem
is
not
like
I've.
That's
there's
so
much
data
about
that
that
exists
in
all
the
issues
and
things
like
that.
It's
just
the
the
solution,
I
guess
is
what
I'm
saying
is
like.
Okay,
how
we
take
all
that
and
matthew
started
on
the
design,
but
part
of
what
he's
proposing
is
radically
changing
how
to
do's
work
and
removing
all
the
automation
generation
of
it
and
a
bunch
of
other
stuff,
and
then
we
have
some
engineering
constraints
like
how
do
we
actually
store
all
the
notifications
like?
B
Can
we
store
all
the
notifications
that
ever
get
delivered
in
email
in
gitlab?
So
there's
there's
a
couple
of
things
there.
G
G
I
would
say
is
if
it's
you
know
that
that
much
of
a
wanted
feature,
if
we
can
really
produce
that
story,
we
can
definitely
dedicate
time
to
running
it
quickly
through
validation.
I
I
would,
I
think,
someone's
already
posted
donald
already
posted
some
beginning
solution,
validation
or
research
validation
on
that.
So
it's
whether
we
want
to
go
in
that
direction
or
not,
is
there
value
it
seems
like
there
is?
G
It
seems
like
it's
pretty
easy
to
make
that
case,
and
if
so,
we
can
reserve
the
time
to
do
the
proper
validation.
You
know,
light
validation,
considering
all
the
work
that's
already
been
done
on
it
and
make
it
a
real
thing.
E
B
Okay,
cool
is
the
next
time
I'll
I'll
connect
with
jackie
and
let
her
know
we're
interested
in
taking
more
like
organic
approach
towards
pushing
this
forward
just
and
and
then
see
what
we
can
do
there.
I
think
she
already
has
meetings
scheduled
on
every
few
weeks
or
something
like
that
if
you're
interested-
and
this
has
inspired
you-
I
definitely
encourage
you
to
go
to
that
issue
that
she
created
and
kind
of
just
make
it
known,
because
I'm
gonna
volunteer
there
as
well.
I
think
the
first
session
is
playing
for
august
26th.
B
So,
even
if
you
can't
come
to
the
zinc
stuff,
it
doesn't,
everything
will
be
recorded
and
it'll
be
mostly
async,
I'm
assuming
so
I'll.
Do
that
as
next
step.
J
A
Cool,
so
I
have
the
next
item
and
all
the
previous
items
and
yeah.
If
I
don't
get
some
like
kind
of,
I
don't
know
some.
If
somebody
doesn't
ask
me
what
I'm
talking
about
with
this
like
I'll,
be
really
upset.
So,
according
to
the
cross-functional
working
group,
it's
counter-intuitive,
but
when
you're
adding
type
labels.
A
First
of
all,
this
is
really
important
now
to
avoid
things
like
engineering
allocations
and
also
so
that
we're
reporting
correctly
what
proportion
of
work
we're
working
on
bugs
tech,
debt
and
new
features,
and
the
thing
about
bug
is
that,
like
it's
supposed
to
be
a
defect
in
shift
code
and
our
definition
of
ship
code
is
that
the
feature
flag
is
defaulted
to
on.
So
in
things
like
tasks
when
we're
fixing
a
bug
with
tasks,
but
we
haven't
switched
on
tasks,
say
the
hierarchy
widget.
A
Yet
it's
not
actually
a
bug
until
it's
in
the
shipped
code
and
therefore
everything
that
contributes
to
a
feature
whether
it's
a
tech
debt
fix
a
bug
fix
whatever
until
it's
released
to
customers,
it's
a
feature
either
a
feature
edition
or
a
feature
enhancement.
Once
it's
shipped
to
customers.
Once
we
ship
a
bug
to
customers,
though
it's
a
bug
right,
it's
a
defect
in
the
system
and
yeah
yes
breath
bugs
are
not
featured.
That's
the
that's!
Basically
the
story
like,
but
there
is
logic
to
it.
A
It's
just
counter-intuitive
when
you
go
to
imply
this
or
apply
this
label
to
your
mrs
and
issues
I'll.
Just
ask
that
you
check
like
it.
There
are
some
like
edge
cases
where
the
feature
itself
hasn't
been
released,
but
the
code
that
you're
working
on
hasn't
been
released
just
watch
out
for
it
anyway,
and
if
you
have
any
questions
you
know
raise
raise
a
question
with
one
of
the
dris
for
the
issue,
but
again
like
we
don't
want
to
spend
too
much
time
worrying
over
type
labels.
A
C
Bug
performance
also
kind
of
like
confuses
me
because,
for
the
same
reasons
like
for
similar
reasons
like
if
it's
a
performance
issue
that
you
know
that
doesn't
break
users,
behavior
or
workflow
right
now,
should
that
be
above
performance
or
it
should
be
the
enhanced
future
and
feature
enhancement
right.
A
But
I
think
that's
been
removed,
so
yeah
like
look
it's
weird
as
well,
but
it's
just
kind
of
I
think
the
closest
type
that
it
fits
under
currently
is
bug,
and
that
could
change,
I
guess,
but
yeah.
I
also
find
it
weird.
A
Yeah,
I
and
I
agree
but
like
yeah,
but
that's
also
true
with
the
feature
itself
right
when
we're
writing
documentation,
we
don't
write,
enabled
on
gitlab.com
and
15.3
enabled
for
self
hosting
in
154.
We
say
like
the
feature
was
brought
in
behind
a
feature
flag
and
then
the
future
flag
was
enabled
by
default
right.
I
A
Yeah
interesting
interesting,
I
couldn't
find
the
line.
Maybe
somebody
from
product
can
help
me,
but
I
couldn't
find
the
line
in
the
handbook
that
explicitly
says
a
feature
isn't
shipped
or
released
or
whatever
generally
available
until
the
feature
flag
is
defaulted
to
on,
but
I
know
it
to
be
true,
and
I
know
we
don't
write
the
release
post
until
it's
at
least
defaulted
to
on.
So
there
must
be
some
guidance
in
the
handbook
somewhere
there
that
we
can
point
to
for
this.
D
And
it's
also
with
like,
I
always
struggle
with
when
we
should
close
a
feature
issue
like,
should
it
be
closed
when
we
default
the
feature
flag
on
and
then
I
think
it
would
make
sense
that
anything
like
once.
The
actual
future
issue
is
closed.
Anything
any
defects
that
are
found
at
that
point
are
actually
bugs
because
that's
considered
delivered,
but
then
I
feel
like
we
should
be
closing
those
future
issues
once
we
actually
deliver
it,
regardless
of
future
flags,
because
we
have
a
different
issue
for
future
flag
management.
D
C
I
think
this
shipping
thing
also
affects
like
feature
addition
and
feature
enhancement,
but
because,
if
we
introduce
a
new
feature
with
like
multiple
mrs
we're
supposed
to
label
it
as
feature
edition
right,
because
it's
for
the
same
feature.
But
then,
if
it's
a
shipped
feature,
then
we
say
enhancement
and
then
that's
very
blurry
line
too.
B
A
Yeah
we're
we're
supposed
to
like
as
ems
and
pm's,
I
think
nine
to
once
a
month
and
look
and
make
sure
that,
like
our
teams
are
delivering
broadly
along
the
ratios
that
but
it's
in
kinds
of
mrs
right,
it's
not
which
itself
is
problematic
because
you
know
some
are
bigger
than
others.
E
B
F
I
D
And
to
answer
gabe's
question:
I
don't
think
we
have
enough
data
yet
to
see
if
there's
value
in
subtypes,
I
tend
to
agree
that
there's
not
as
much
value
as
there
is
in
in
classifying
types.
D
But
again
I
just
don't
think
we
have
enough
data
yet
to
to
be
able
to
tell
if
there's
any
value
there.
D
Be
nice
to
automate
a
lot
of
that
stuff,
especially
at
the
subtype
level,
but
down
the
road.
A
Is
a
heinrich's
comment
about
bug
performance
like
generally
shared
by
everybody
else,
about
subtypes,
then
because
that's
kind
of
how
I
feel
about
them
as
well,
they're,
almost
too
specific
to
be
useful
and
in
most
cases
like
they
don't
really
describe
what
the
thing
does
like
bug.
Ux,
I
would
imagine,
is
every
book
right
because
it's
being
experienced,
if
it's
not
being
experienced,
it's
not
a
bug.
I
don't
know,
but
is
that
generally
how
people
feel
about
it
like
the
subtypes
are
too
specific.
B
It's
too
nuanced,
I
guess
right
like
the
edition
versus
enhancement
right
like
what
is
it?
What
is
what
is
the
very
clear
delineation
between
the
two
right
like
because,
if,
if
we're
iterating
on
a
feature
like,
let's
say,
iterations
everything's
an
enhancement,
even
though
we
might
be
like
adding
a
new
field
or
doing
something
like
that,
I
just
never
know
exactly
when
to
use
which
that's
all.
A
Yeah,
it's
like
was
health
status,
an
addition
of
a
new
feature
or
an
enhancement
of
an
issue.
B
I
think
I
based
on
what
I
read.
I
think
you
only
use
the
edition
label
if
you're
adding
something
to
feature.yaml
in
the
release
post
and
then,
if
you
are,
if
it
basically
it
doesn't
it's
not
a
new
feature
in
feature.yaml,
then
it's
an
enhancement,
but
I
could
be
wrong.
J
Yes,
I
was
looking
for
an
issue
I
raised
that
I'm
not
persuaded
users
have
any
experience
of,
but
it
looks
like
a
bug
so
and
and
anything
that
a
customer
sees
that's
wrong
is
above
right,
so
we
might
not
have
turned
a
feature
on
yet,
but
if,
for
example,
some
corner
case
means
that
features
causing
500
errors
on
gitlab.com,
that's
a
bug
because
he's
booking
another
feature,
but
I
mean
you
know,
I
suppose,
a
database
migration.
That's
on
get
on
on
self-managed.
A
At
least
what
I
think
was
interesting
is,
like
you
said
at
the
beginning,
like
any
misbehavior
that
a
customer
can
see
is
a
bug
and
the
question
is
like
what
does
it
mean
that
what
does
it
mean
that
a
customer
can
see
it
right
like
because
we
want
to
release
stuff,
that's
incomplete
behind
a
feature
flag
so
that
we
can
test
it
as
early
as
possible
in
a
production
system?
A
But
we
know
when
we
release
it,
it's
not
complete,
so
if
we
would
treat
being
behind
a
feature
flag
with
being
arbitrarily
on
on
any
given
instance,
so
in
other
words
the
instance,
admin
could
switch
it
on
or
not
as
being
delivered
to
customers.
Then
literally,
everything
we
would
do
after
the
feature
flag
is
implemented,
would
be
a
bug
fix.
A
F
Well,
I
mean:
aren't
we
even
even
with
our
with
our
iteration
we're
not
supposed
to
be
shipping
bugs
I
mean
if,
if
it's
a,
if
it's
a
missing
capability
of
a
feature
that
we're
building,
that's
not
a
bug,
but
if,
if
something
is
missing,
that
is
that
should
be
there
by
all
reasonable
expectations
by
the
customer
in
terms
of
well,
my
name's
not
showing
up,
but
it
should
be
showing
up.
Well,
that's
probably
a
bug,
that's
not
a
that's!
Not
should
that
shouldn't
be
part
of
our
iteration.
F
F
C
F
C
F
If,
if
it's,
if
it's
to
all
of
gitlab.com,
then
yeah
it's
kind
of
shift,
isn't
it?
I
mean
you're
you're,
directly,
impacting
customers
and
expecting
them
to
use
that
feature.
If
it's,
if
it's
kind
of
just
within
org,
then
well.
Okay,
that's
we're
the
we're
the
guinea
pigs,
but
if
you're
shipping
it
to
a
customer
and
expecting
them
to
actually
use
it
and
provide
feedback,
I
kind
of
feel
like
those
are
bugs.
F
D
Yeah,
I
think
so
too.
I
think
we
shifting,
because
I
think,
with
the
way
we
what
we
talked
about
earlier,
like
our
mentality,
has
been
shipped
means
feature
flag
defaulted
to
on,
but
that
doesn't
really
account
for
for
turning
it
on
for
for
all
of
sasserell.com.
D
K
I
think
it
needs
to
be
this
definition
here
that,
if
it's
turned
on
for
globally
forget
that.com,
it
is
a
shipped
feature,
because
we
had
this
discussion
yesterday
with
crucials
and
merge
request.
We
could
have
just
disabled
the
feature
and
merchant
merch
requests
and
then
enable
the
feature
flag
again
one
day
afterwards,
but
it
would
have
been
a
bad
experience
for
a
user
because
they
had
work
items
and
they
didn't
have
work
items
for
24
hours
and
then
had
they
had
it
again.
A
A
A
A
Just
to
be
as
accurate
as
possible,
you
know
or
like
to
have
a
common
definition,
because
the
current
like
currently
well
like
I've,
been
trying
to
establish
this
in
the
working
group
so
that
we
have
a
common
definition
more
than
I
care
about
like
that.
These
are
labeled
as
features
rather
than
bugs.
A
A
A
Take
us
home,
it's
no.
D
J
Yeah
my
question
was
about
whether
or
not
if
an
issue
was
raised
as
a
feature
issue
rather
than
a
bug
issue.
Might
it
get
under
the
radar
and
you
end
up
shifting
shipping
the
bug
anyway,
that's
more
a
question
for
team
prioritization,
I
guess
and
and
and
how
you,
how
you
imagine,
your
issues
being
opened.
A
I
would
have
the
same
concern
in
the
opposite
direction
that,
like
the
bug,
would
be
like
a
p4
s4
and
would
other
things
would
like
take
priority
and
it
would
never
be
fixed,
like
like
an
example
from
yesterday,
would
be
in
the
planning
hierarchy
widget.
It
was
labeled
like
the
title
is
child
items
and
we
wanted
to
change
it
to
tasks
like.
A
Okay,
so
I'll
create
that
issue
like
and
I'll
ask,
and
anyone
who
wants
to
I'll
put
it
in
the
channel
and
if
you
want
to
come
in
and
vote
on,
whether
you
think
something's
a
bug
or
a
feature
or
why
you
can
do
that
I'll
also
share
it
with
the
cross-functional
group,
so
they
can
have
an
idea
of
what
it
looks
like
to
actually
use
these
labels
to
try
and
segregate
work.
This
way
and
yeah
cool
nobody
has
a
demo
or
anything
they
want
the
demo.
D
E
D
Now
we
should
have
the
hack
milestone
to
work
on
notifications,
take
a
break
from
tess
just
kidding.
A
Awesome:
okay,
we're
at
time
anyway.
Let's
leave
it
there
thanks
everyone
for
the
deep
discussion
appreciate
it
ciao.