►
From YouTube: Scalability - Feature Category information dashboards
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
Great,
so
thanks
for
both
joining
dialing
in
on
the
call
today,
I'm
just
opening
up
the
a
document
to
take
notes
in
so.
The
reason
that
I
was
hoping
to
chat
with
both
of
you
today
is
that
there
is
this
issue
now
about
adding
the
feature:
category
information
to
the
dashboards,
to
finish
up
this
project,
about
having
the
feature
category
information
on
all
of
the
controllers
and
the
endpoints,
and,
as
I
was
just
saying,
to
bob
yeah,
because
we
just
had
our
one-on-one.
A
I
want
to
understand
where
we
are
now
in
terms
of
what
is
going
to
be
visible
on
the
dashboard
and
talk
a
little
bit
about
what
is
going
to
happen
in
the
middle.
Between
that
being
the
starting
point
and
the
end
point
being
stage.
Groups
are
using
it.
They
can
see
interesting
things
happening
and
they
know
what
to
do
about
what
they
see,
because
I
feel
like
there's
a
there's,
a
certain
amount
of
stuff
that
we're
going
to
have
to
build
or
write
or
prepare
for
stage
groups
to
be
able
to
give
them.
A
This
I
feel
like,
if
we
just
dump
it
on
in
their
slack
channel
they're-
probably
not
going
to
use
it
if
there's
not
a
lot
of
instruction
for
what
they're
what
they
can
use
it
for.
So
that
was
what
I
was
hoping
to
to
talk
about
today,
and
perhaps
we
could
start
by
talking
about.
What's
there
at
the
moment,
what
that
ticket
entails
for
putting
it
on
the
dashboard
and
what
we're
expecting
to
see
when
that
ticket
is
finished.
B
Yeah
bob:
do
you.
C
Want
to
start
well,
maybe
you
could
start
by
explaining
what
is
going
to
be
on
the
on
the
dashboard
that
we
have
now.
I
already
told
rachel
that
that's
more
of
a
dashboard
for
us
to
see
like
the
information
is
there
like.
We
have
stuff
coming
in.
B
C
B
Yes,
and
the
other
thing
we
don't
have,
is
the
aggregation
across
all
services
right,
so
we
have
error
rate
per
sidekick
per
feature
category
for
web,
no
future
category
per
gift
for
each
category
and
per
api
per
feature
category.
What
we
don't
have
is
an
aggregation
of
those
now
for
us.
The
aggregation
is
going
to
be
useful
for
teams.
I
actually
think
the
aggregation
across
service.
Maybe
we
don't
need
right
now,
like
that.
You
know
like
for
them
like.
B
B
Exactly
and
part
of
the
reason
we
don't
have
that
now
is
because
I've,
you
know,
I've
still
got
this
first.
Mr
open
part
of
the
reason
is
we
need
to
determine
the
waiting
for
each
service
and
also
part
of
the
reason
is
that-
and
this
is
sort
of
a
bigger
miss.
This
is
quite
a
big
miss
at
the
moment,
but
I
don't
think
it
should
block
us
from
moving
forward.
Is
that
we
don't
have
app
decks
per
feature
category.
B
We
just
have
error
rate
per
feature
category
for
the
http
traffic,
so
for
web
git
and
api.
So
for
sidekick
we
have
both
aptx
and
error
rate
per
feature
category
and
per
cue.
B
The
cardinality
of
doing
that
by
controller
action
makes
it
impossible
to
do
that
for
the
rail
side
anyway,
but
we
also
don't
have
app
decks.
So
what
we
probably
need
to
do,
there
is
add
a
new
metric
with
like
two
buckets
and
probably
not
the
status
code
right
bob
and
just
like
two
buckets
feature
category,
and
then
we
use
that
for
the.
B
B
Yeah,
okay
and
yeah
so
like
this
is
where
we're
sort
of
hitting
problems
with
the
prometheus
cardinality.
Basically
because
like
if
we
have
controller
times
action
times,
feature
category
well
actually
times
feature
category
shouldn't
really
add
much
because,
like
every
future,
casper
is
every
controller
action
player
is
just
one
of
each
category,
but
then
time
status
code
times
every
host
we
have,
and
it's
times
all
the
buckets
we
have
for
the
the
timings
like
that.
That
quickly
multiplies
very,
very
fast.
C
And
yeah,
so
what
is
next?
I
think
then,.
A
So
once
we've
added
the
so
once
shawn's,
mr
is
in
that
essentially
closes
this
project's
worth
of
work.
We
everything's
categorized
it's
on
that
dashboard.
That's
done
so.
It
sounds
like
forward
from
this
is
the
next
project
and
determining
what
what
one,
what
the
outcome
of
the
project's
going
to
be
like
how
far
the
next
step
takes
us
and
all
the
pieces
of
work
that
we're
going
to
have
to
do
to
get
to
that
next
step.
So
I
suppose
that
that
becomes
a
question
is
what
is
the
end
point
of
the
next
step?
B
Yeah,
so
I'm
just
gonna
share
a
link
in
zoom
chat.
I
guess
which
is
an
issue
I
got
mentioned
on,
but
I
didn't
realize
that
you
weren't
already.
B
One
thing
I
mentioned
in
there
is
that
we
would
like
to
be
able
to
create
these
team
specific
dashboards.
So
like
there
are
a
couple
of
ways
we
could
do
it
right
like
we
could
create
a
dashboard
that
has
a
drop
down
for
team
or
we
could
create
team
specific
dashboards
like
that
we
auto
generate
based
on
those
teams.
I
think
initially
we'd,
probably
just
do
the
former,
but
one
advantage
of
the
second
one
is
that
it
would
be
very
easy
because,
like
we
can
use
common
code,
that's
like
you
know,
json,
like
that.
B
That's
the
selling
point
that
would
make
it
easier
for
teams
to
add
their
own
spin
on
their
dashboards
as
well
to
like
customize
them,
whereas
obviously,
if
it's
one
shared
dashboard
that
you
have
a
drop
down
for.
B
A
This
is
where
everything's
been
customized,
so
that
anyone
from
either
infrastructure
or
development
can
look
at
the
top
stuff
and
see
something
common
that
they
understand,
and
then
everything
below
that
is
whatever
the
the
team
feels
that
they
need
to
see,
and
perhaps
we
even
work
with
the
team
on
that
to
show
them
what
the
options
are
for
the
extra
stuff
that
they
can
view.
That
is
specific
to
them.
B
Yeah,
I'm
just
going
to
throw
out
a
few
options
here
as
well,
because
I
was
just
thinking
about
some
other
things
we
can
do
here
so
like
team,
specific
dashboards,
when
we
aggregate,
if
we
know
which
feature
categories
belong
to
a
team
which
we
need
to
know
to
make
this
team
specific
dashboards.
That
means
that
we
also
could
do
some
funky
stuff
with
like
label,
replace
and
prometheus
to
do,
dashboards
by
team.
B
Yes,
depending
on
which
point
we
do
the
label
replace
right
like
if
we
do
the
label
replace
like
we
still
have
the
cardinality
in
the
underlying
metric.
If
we
use
the
label
replacement
in
the
recording
rule,
I'm
just
a
bit.
B
B
B
Also
things
that,
like
you
know
like
what's
a
good
example,
how
many
pods
do
we
have
running,
for
instance,
like
that's,
very
easy
to
get
out
from
ets,
like
you
probably
could
figure
it
out
from
cabana,
but
it's
kind
of
a
hassle
so
like
those
sort
of
like
infrastructure
level
things,
but
in
terms
of
application
of
our
stuff.
A
I
think
that
I
mean
I
haven't
read
the
whole
issue,
but
just
from
the
just
from
the
title
like
this
is
this
is
specifically
about
when
changing
the
feature
flags,
they
want
to
know
what
they
should
be
looking
at,
and
I
don't
think
that
the
feature
play
part
is
actually
that
important.
This
is
just
the
trigger
mechanism
for
when
they're
going
to
be
looking
at
the
dashboards,
but
in
general
they
could
look
at
the
dashboards
at
any
time
whether
they've
been
football
flagged
or
not.
A
B
Yeah-
and
I
also
think
that
or
I
worry
that
if
the
goal
is
to
build
dashboards
for
the
teams
that
we're
still
missing
the
part
of
like
when
and
why
did
they
use
the
dashboards,
whereas
if
the
goal
is
to
use
them
in
the
process
of
feature
flag
rollouts,
then
that's
sort
of
like
your
thin
end
of
the
wedge.
Like
your
your
introduction
to,
like
you,
know,
regularly
checking
you
know,
what's
going
on
on
these
dashboards,
because.
A
We
already
know
that
there's
been
more
effort
around
well
there's
more
effort
being
put
into
the
way
that
feature
flags
are
changed
and
I'm
not
I'm
not
really
keen
on
putting
in
too
much
process
around
watch
the
grass
flip
the
flag
watch
the
graphs
again,
because
I
don't
you
know
making
processes
really
big
is
challenging,
but
at
least
if
we
can
show
people
when
you
flip
the
flags.
This
is
how
you
would
look
at
it.
This
is
what
you
would
see.
This
is
where
you
get
the
documentation.
This
is
the
board.
A
B
C
Not
all
feature
flags
are
created
equal,
like
the
the
there's
sometimes
like
that,
depending
on
what
the
future
flag
is
gating,
different
things
would
need
to
be
watched
like
is
this
going
to
put
more
pressure
on
redis?
Is
this
going
to
put
pressure
on
the
registry?
Is
this
going
to
put
pressure
on
sidekick,
and
that
depends
on
the
feature
flag?
So
it's
hard
to
tell
in
that
sense
what
the
team
should
be
watching.
C
Well,
I
think
that's
what
we're
trying
to
solve
with
the
feature
categories,
if
we
can
give
them
here's
all
your
cues.
Here's
all
your
requests,
he's
all
your
yeah
whatever.
Then
they
can
deduct
from
the
flag
that
they
flip
what
they
need
to
watch
like
if
they're
opening
up
a
new
api
endpoint
that
should
be
already.
C
B
You
would
have
to
have
the
drill
down
be
like
to
go
to
the
controller
dashboard
for
that
service,
with
already
the
controllers
and
actions
pre-selected,
somehow
or
like
the
beach
category,
also
as
a
drop
down
on
the
controller
dashboard
and
feature
casper
has
a
control
feature
category
as
a
drop
down
on
the
controller
that
will
probably
make
sense.
I
could
go
and
just
do
that
now,
but
because
we
would
have
to
use
different
metrics
for,
like
you
know,
fundamental,
like
you
know,
we're
going
to
run
into
problems
if
we
don't
use
different
metrics.
B
That
also
means
that
the
dashboards
experience
to
be
slightly
more
clunky,
but
I
think
I
think
the
fundamental
idea
is
right,
like
what
we
want
to
do
is
we
want
to
end
up
with.
B
What's
a
good
example,
image
comments:
that's
probably
not
going
to
show
up
on
their
overall
dashboard
because
their
overall
dashboard
has
got
like
a
huge
amount
of
stuff
on
it,
because
the
code
review
team,
like
is
responsible
for
a
huge
like
part
of
get
lost,
so
they
would
really
want
to
drill
down
for
that,
whereas
the
package
team
is
rolling
out
like
hey.
We
now
support
like
this
major
new
feature,
then
that
probably
will
show
up
on
their
overall
dashboard,
because
it's
like
a
big
thing.
C
I'm
wondering
if
the
the
stage
groups
themselves
would
want
to
drill
down
by
feature
category
and
and
not
by
end
point
by
q
by
because
they
know
what
huge
repairs
they
just
want
to
and
that's
where
the
future
categories
come
in.
They
want
to
have
like
a
focus
on
the
ones
that
apply
to
them
that
are
important
to
them
within
all
yeah.
B
That's
a
fair
point:
feature
categories
are
really
just
an
abstraction.
We
use
to
help
map
things
to
teams,
like
teams,
don't
actually
need
to
care
about
them
day-to-day.
You
know
we
made
them.
They
just
slightly
care
about
them
when
they
add
a
controller
and
they
need
to
say
what
future
category
is,
but
they
don't
really
think
like.
If
you're
on
a
team,
you
don't
think
oh
well,
this
is
like
you
know.
This
is
related
to
what's
a
good
example.
I
can't
think
of
an
example.
A
I
think
that
some
stage
groups
do,
I
think,
some
stage
groups.
It's
it's.
It's
a
big.
You
know
it's
a
it's
a
big
group
altogether,
but
I
know
that
with
the
issues
they
do
have
the
category
scoped
label
that
show
up
on
things,
and
I
think
that
some
of
the
product
managers
might
be
interested
from
the
category
perspective.
A
Sorry
from
the
feature
category
perspective,
so
I
think
we
should
definitely
have
a
way
of
grouping
them
all
together,
so
that
a
an
engineering
manager
or
product
manager
could
look
at
everything
that
they
are
responsible
for
and
then
be
able
to
drill
down
by
feature
category,
but
I
think,
having,
I
think
if
we
obscure
that
we
might
be
taking
data
away
from
them,
but
I
also
think
that
it's
difficult
to
try
and
predict
what
they're
going
to
want.
B
B
So
maybe
the
way
we
do
this
is
we
basically
insert
ourselves
into
future
flag
rollouts
for
a
period
of
time
like
help
find
the
charts
that
people
need
to
look
at
help
build
the
chance
if
they
don't
exist
or
make
them
easier
to
find,
and
just
like
say
we're
going
to
spend
like
a
month
two
months,
just
like
deeply
involved
in
feature
flag,
rollouts
and
trying
to
help
teams
understand
those
as
much
as
possible.
A
C
But
yeah
because
it's
like
I
see
some
people
are
struggling
with
finding
where
they
need
to
look
so
when
they
create
the
future
flag
issue.
I
just
comment
like
here's,
a
graph
and
here's
a
link
to
thanos
link
to
the
logs.
Look
at
this
when
you
roll
this
out
and
then
yeah,
which
I
found
easier
because
then
I
don't
need
to
do
it.
B
And
going
back
to
cabana
versus
like
prometheus
as
well,
I
think
that's
part
of
the
issue
right
like
it's
like
for
me
doing
something
ad
hoc,
I
know
cabana
will
have
the
granularity.
I
need,
and
I
will
just
go
in
and
build
something
like.
Basically,
everything
I
share
in
cabana
is
just
like
one
of
the
share
links
like
for
a
ad
hoc
visualization
I've
created,
but
like
that's,
not
discoverable,
unless
you
already
know
how
to
use
cabana
and
like
obviously,
we
want
to
teach
people
how
to
use
that.
B
But
I
think
the
big
advantages
of
the
dashboards
is
discoverability
like
it's
already
showing
you
what
you
want
to
use
and
you
can
add
dashboards
and
cabana,
but
I
don't
think
they're
anywhere
near
as
discoverable
and
also
we
just
have
a
million
like
saved
reports
and
dashboards
and
stuff,
and
it's
like
it
doesn't
have
the
same
structure
as
grafana,
where
you
can
like
make
it
all
nice.
Basically
so
yeah.
A
I
think
that,
as
you
said,
that
inserting
ourselves
into
the
road
are
the
feature
flags
in
a
more
con
in
a
more
in
a
less
ad
hoc
way
will
definitely
help.
People
understand
how
to
use
the
dashboards
more,
because
I
imagine
that
if
we
build
the
dashboards
and
then
go
to
the
stage
groups
and
say
hey,
we've
built
these,
please
use
them.
B
Yeah,
I
think
that
makes
sense.
I
think
I
feel
like
that's
probably
the
way
to
go,
because
we've
got
so
many
ways
we
could
go
with
this
and
it
can
be
quite
difficult
to
teach
people.
I
think
there
are
two
things
that
make
it
difficult
for
us
to
teach
people
how
to
use
this
just
in
terms
of
a
training
sense.
B
B
When
am
I
gonna
use
this,
and
even
if
you
like,
I
remember
doing
like
when
I
joined
the
scalability
team,
I
watched
like
a
prometheus
talk
like
that
was
sort
of
explaining,
but
it's
only
now
that
I've
used
prometheus
a
lot,
but
I
actually
understand
what
that
talk
was
like.
I
felt
like
I
understood
it,
but
I
didn't
really
understand,
like
I
didn't
know
like
what
was
going
on.
B
Yeah
and
I
think
the
temptation
for
a
lot
of
people
certainly
me
is
to
like,
when
you
understand
something,
to
try
and
explain
it
in
the
most
fundamental
terms
like
so
I
was
actually
talking
to
a
candidate
about
this.
B
Like
you
know,
you
could
explain
it
in
terms
of
the
the
data
sites
that
are
available
in
prometheus,
the
metrics
that
are
available,
you've
got
counters,
gages,
histograms,
etc,
but
when
you're
using
it
when
you're
typing
in
a
query,
it
doesn't
tell
you
whether
it's
counter
engage
or
a
histogram
like
that's,
not
what
you're
you're
looking
at
like
what
you're
looking
at
is
like,
which
metric
do
I
want?
How
do
I
know
which
metric
I
want?
B
So
that's
one
reason.
Well
that's
most
reasons.
Actually
the
motivation
and
the
the
explaining
it
is
harder
if
you're
trying
to
do
that
up
front
rather
than
trying
to
do
it
to
solve
a
particular
task.
So
I
think,
having
it
focused
is
also
a
good
way.
We
could
get
some
prometheus
grafana
cabana
training
in
in
a
relevant
way
to
the
teams
that
will
actually
hopefully
stick
because
they
will
continue
to
use
it
in
future.
C
B
B
C
Rachel
also
brought
up
something
interesting
that
might
be
relevant
because
you
mentioned,
like
let's
work
with
the
feature
groups
and
to
roll
out
flags
and
build
dashboards
and
help
them
help
them
get
the
information
they
need,
and
rachel
mentioned,
like
maybe
pairing
up
with
one
or
two
groups
and
the
beginning,
to
start
like
to
start
with
something.
And
what
do
you
think
about
that?.
A
Only
for
people,
I
think
it
sort
of
overlaps
with
what
sean's
been
saying
about,
focusing
it
on
tasks
and
feature
flag
robots.
So
what
we
could
do
is
I
could.
I
could
ask
well
one.
I
know
that,
having
spoken
with
with
people
in
registry,
it
sounds
like
they'd
be
keen
for
to
work
with
us
on
this,
but
the
other
thing
that
I
could
do
is
just
ask
amongst
the
ems.
A
If
there's
any
other
stage
groups
that
would
be
willing
to
to
be
the
first
round
of
people
who
work
with
us
on
this,
and
we
just
pick
maybe
two
or
three,
and
we
start
there-
work
with
them-
iterate
roll
it
out
to
a
bigger
group
and
see
how
that
goes.
But
I
like
the
idea
of
tracking
what
we're
doing
across
the
stage
groups
to
make
sure
that
we
touch
everyone.
C
A
Well,
I
think
that's
why
at
least,
if
we
have
maybe
two
two
or
three
engineering
manager
participants,
they
can
also
talk
about.
I
don't
I'm
not
interested
in
this,
I'm
more
interested
in
that
and
just
across
a
small
group
you
see
what's
common
and
not
common,
and
at
least
it
gives
you
the
the
starting
ground
of
the
commonality
stuff
rather
than
building
something
specifically
for
registry
and
then
realizing
at
a
later
stage
that
really
less
than
half
of
this
is
relevant
for
other
people.
B
I'm
just
going
to
say,
I
think
our
default
failure
mode.
Certainly
mine
is
to
go
too
generic,
so
I
think
I
think
it's
unlikely
we'll
end
up
too
specific.
Just
because,
like
you
know,
my
temptation
is
to
definitely
to
go
too
generic
and
also
the
way
we're
talking
about
this.
It
sounds
like
a
cross
between
a
scalability
project
and
also
a
gitlab
working
group.
B
I
don't
know
if
we
want
a
working
group
for
this
but
like
when
we're
talking
about
participants
like
maybe
maybe,
if
we
wanted
to
limit
the
fantastic.
That's.
A
A
I
think
from
here
it's
about
setting
up
this
project
being
specific
about
what
we're
what
we
want
to
achieve
and
then
reaching
out
to
find
those
those
those
three
people
that
would
be
interested
in
working
with
us
to
start,
and
perhaps
that
is
finding
the
ones
that
are
the
most
common
users
of
future
flags,
so
they're
the
most
likely
people
to
join
in.
Or
is
this
just
a
case?
If
I
should
just
ask
for
participants
and
pick
three.
A
So
what
I
will
do
is
I
I'll
try
and
write
up
what
we've
done
here
into
an
epic,
and
I
will
put
that
epic
into
our
structure
and
copy
well
I'll
copy
the
whole
team
on
just
so
that
everyone
knows
what
we're
thinking
about
here
and
then
we
have
to
figure
out
when
we're
going
to
be
picking
this
up
to
work
on.
B
Yeah,
I
think
it
would
be
good
to
sync
up
with
marion
on
that,
which,
obviously
you
probably
would
anyway
sorry
slightbot
would
have,
would
have
pinged
me
for
saying,
obviously
there,
which
you
probably
would
have
anyway,
obviously
so,
because,
like
he's
assigned
to
that
issue
that
I
linked
to
so
like,
he
might
have
a
particular
opinion
on
like
hey
whether
this
is
a
good
idea
but
be
like
if
this
is
something
we
want
to
do
soon,
like
the
issues
due
date
is
november,
the
2nd,
for
instance,
but,
like
you
know,
if
this
is
something
like
we
want
to
get
in
place
now
or
if
it's
something
we'd
want
to
leave
until
after
the
holidays,
because
we've
got
a
couple
of
projects
in
flight
that
basically
take
us
up
to
christmas
anyway
or
like
do.
A
Sure
yeah,
I
think,
in
terms
of
what
we're
doing
in
the
team
at
the
moment,
we
need
to
get
this
the
rate
limiting
stuff
out
of
the
way
and
done
the
I'd
left
some
space
open
for
a
project
about
italy,
but
it
seems
that
there's
a
one
specific
bug
that
has
caused
this
problem,
so
I'm
busy
discussing
with
alberto
how
it
gets
resolved
if
we're
going
to
go
back,
yeah.
B
Didn't
fix
that
so
because,
like
yesterday,
I
was
like
I'm
just
kind
of
sad
because,
like
I
found
the
security
emma
and
like
because
I
was
reviewing
another
security,
mr
and
I
was
like,
I
don't
think
this
will
work
very
well
because,
like
we're
either
solving
a
security
issue
but
like
breaking
up
a
big
performance
and
scaling
improvement
or
the
opposite
like
you
know,
we're
basically
saying
we
can
only
have
one
or
the
other
and
what
we
really
want
both
and
then
seven
months
ago
we
created
an
issue
about
that
and
then
it
just
kind
of
stalled,
but
because
it's
heinrich,
I
think
he
thinks
he's
figured
out
a
solution.
B
So
hopefully,
hopefully
that
will
go
away
and
that
might
actually,
like
you
said,
get
rid
of
a
lot
of
the
italy
incidents
that
we've
had
lately.
A
Yeah
and-
and
that
means
what
I
think
there
was
like
11
incidents
over
the
past
three
months-
would
go
away,
which
means
that
gitly
falls
back
down
into
the
like
the
normal
range
for
how
many
incidents
are
being
created
on
it,
which
is
obviously
less
stressful
and
the
service
web
project
that
we
created
about
looking
into
incidents.
Those
incidents
are
so
old
now
that
I
don't
think
it's
relevant
anymore
for
us
to
go
digging
in
there.
So
I
would
put
forward
that
this.
A
B
B
C
The
dashboard
is
just
there
to
prove
to
us
that
we've
added
the
information
to
all
endpoints
and
like
the
I
haven't,
set
the
threshold
to
like
how
much
of
it
can
be
not
owned.
But.
B
Thing
I
feel
like
with
the
the
blog
post
that
I
wrote.
This
is
another
example
of
where
we
could
have
like
restructured
the
project
a
bit
like
to
have
some
impact
on
the
stage
groups
like
each
like,
because
I
feel
like
we've
kind
of
done,
the
same
thing
again,
but
in
a
much
smaller
scale
where,
like
you
know,
we've
we've
added
this
to
a
dashboard
that
only
we
use
we've
added
this
to
the
banner,
but
we're
the
heaviest
students
of
cabana
like
we've
added
this
prometheus,
but
we're
the
heaviest
users
of
prometheus.
You
know
well.
A
It's
it's
also
a
hard
one,
because
you
want
to
bring
people
along
in.
You
want
to
bring
people
along
from
the
point
at
which
it
makes
sense
to
them
to
be
brought
up
right.
A
Yeah
and
if
you've
only
labeled,
like
five
percent
of
the
controllers,
again
like
how
much
value
does
the
stage
group
get
out
of
it,
how
much
value
do
we
get
out
of
it?
I
take
your
point
like
rearranging
it.
We
may
have
been
able
to
get
somewhere
slightly
different,
but
I
don't
think
that
this
is
all
bad.
I
think
that
all
of
the
stage
group
focused
stuff
happens
in
the
next
project.
B
Oh,
no,
I
think
I
think
that's
fine,
like
I
just
it's
just
cause,
I'm
like
keyed
into
noticing
that
pattern
now,
like
you
know
well.
C
I
think,
like
a
a
way
of
doing
this
would
be
starting
the
project
that
we
just
like
the
the
thing
that
we
just
discussed
now
would
be
part
of
the
first
project,
and
we
just
do
a
single
feature:
category
like
a
single
group,
not
a
feature
category
but
a
single
stage
group
with
their
feature
categories
and
building
out.
C
B
I
quite
like
that
idea,
actually
because
the
time
to
like
getting
some
feedback
from
a
stage
group
is
lower,
if
we're
just
doing
it
hyper
focused
because
we
don't
have
to
like,
like
we
can
just
hard
code
it
right
like
we
don't
have
to
do
the
whole
like.
How
do
we
map
feature
categories
to
teams
like
how
do
we
keep
that
up
to
date?
All
we
have
to
do
is
say
these
are
the
future
categories
for
this
team.
Here's,
your
dashboard,
let's
go
and
work
with
you
on
this,
like
you
know,.
B
Exactly
like
you
would
like
you
would
say
in
code
like
it's
like,
don't
repeat
yourself,
but
if
you're
not
repeating
just
like.
What's
the
one
in
ruby
you
ain't
gonna
need
it
like
if
you're,
not
if
you
haven't
actually
duplicated
the
code,
yet
don't
assume
you're,
gonna
duplicate
it
like
you
know,
just
do
do
what
you
need
to
do
to
get
the
the
thing
out
the
door
now
and
because
we're
doing
all
this
in
json.
B
That
would
be
huge
because,
like
then
we're
we're
not
spending
like
a
week
two
weeks
like
just
talking
to
ourselves
again,
which
is
what
I
worry,
would
I
do.
A
B
A
So
I'll
create
the
epic
and
I'm
gonna
go
and
find
a
stage
group
and
I'll
put
in
the
channel
which
one
I'm
thinking
about
or
if
there's
anyone
specifically
that
you
think
are
going
to
be
better
than
others.
But
we
can
have
that
that
conversation,
async
yeah.
I
think.
B
I
think
we
look
at
because
I
think
now
we
can
look
at
the
feature
categories
yaml
and
see
which
groups
have
the
most
feature.
Sorry
feature
flag,
example
and
see
which
group
have
the
most
feature
flags
open
at
the
moment.
That's
one
way
we
could
do
it.
We
could
say
you're
a
heavy
user
of
feature
flags,
we'd
like
to
speak
to
you
and,
like
you
said,
registry,
like
package,
you
know
you're
you're,
clearly
doing
stuff
in
this
space.
Like
you
know,
would
you
be
interested
in
like
pairing
more
deeply
with
us?
B
I
think
david
in
particular,
on
the
package
team
was
like
bob
and
I
have
like
interacted
with
him
a
bunch
lately
on
this
stuff.
He
is
like
super
duper
engaged
on
this,
so
that
would
be
a
good
start
too.
So
yeah.
A
Okay,
awesome:
I
think
this
would
have
been
a
very
productive
call
anything
else
before
we
before
we
end.
A
Great,
thank
you
so
much.
This
has
been
great.
I'm
going
to
the
notes
are
available
in
the
scalability
meetings
document
and
I'll
upload
this
onto
and
say,
unlimited,
if
not
unlisted,.
A
Have
a
good
day
and
we'll
chat
too
bye.