►
From YouTube: Configure, Release, Monitor Field Sync: July
Description
This is a recording from the the July Configure, Release, Monitor Field Sync
https://gitlab.com/gitlab-com/Product/-/issues/4486
A
All
right,
this
is
the
july
edition
of
the
release.
Configure,
monitor
we're
gonna
get
started
today
with
a
short
demo
from
seb.
B
B
Right,
let's
start
first,
that
was,
I
thought
I
wasn't
trust.
Okay,
I
have
an
updated
demo
and
it's
a
different
demo
that
I
wrote
because
I
have
we
have
some
problems
with
our
staging
environments,
but
so
I'll
show
a
little
preview
of
our
new
ui,
which
will
be
very
quick
but
I'll
answer,
questions
as
well.
So,
let's
see
here
we
go
so
where
are
we?
Can
you
see
something
that
says:
welcome
to
gitlab
observability
ui?
Yes,
absolutely!
Yes
right!
This
is
running
locally.
B
So
this
is
our
fork
of
grafana
that
we're
starting
to
restyle
and
everything
so
don't
mind
some
of
the
things
when
it
says
griffin
or
not.
This
the
background
will
change
here
as
well,
because
I
think
that's
theirs
their
artwork
and
I
have
to
check,
but
basically
I'm
gonna
log
in
just
if
you're
familiar
with
grafana.
This
will
be
basically
the
same
thing
but
we're
showing
I'm
showing
what
we're
starting
to
restyle.
B
So
we
removed
the
the
blog
and
all
the
other
like
call
to
actions
that
we're
on
this
page
we're
trying
to
and
there's
going
to
be
a
few
more
that
are
going
to
get
changed.
Like
these
links
and
everything
are
going
to
get
changed,
we
want
to
make
this
interface
less
call
to
action,
but
more
direct,
directs
usable.
Why?
Because
this
is
a
place
where
you
can
store
links
to
dashboard,
creates
some
panels
to
preview
things
in
grafana,
but
is
often
underutilized.
B
You
have
a
lot
of
other
pieces,
like
blog
posts
and
people
don't
often
know
what
to
do
with
that
page.
So,
since
our
product
is
by
default
already
embedded
within
our
own
product
through
at
first
an
iframe,
we
will
not
put
a
thousand
call
to
actions
here
since
it's
already
part
of
a
product,
then
the
next
thing
is
well
we're
doing.
We've
done
small
updates
right,
like
you,
like
our
logo,
and
things
like
this,
we're
also
removing
all
kinds
of
functionality.
B
There
was,
for
example,
an
alerting
tab
here
that
we
removed,
because
it's
a
legacy
way
of
doing
alerting
within
grafana
that
we
don't
want
to
support
it's,
not
the
prometheus
manner
and
what
else
we
we're
going
to
still
be
cleaning
up
a
lot
more
things
right
now.
B
Grafana
and
this
supports
a
lot
of
data
sources,
but
some
of
them
are
enterprise
that
we're
going
to
not
support
and
we're
going
to
also
dial
down
the
support
of
these
different
diet
sources
to
a
few
essential
ones
like
prometheus,
probably
I'll
I'll,
have
elastic
left
in
there,
because
elastic
could
be
used
in
the
future
and
then
jager
the
other
plugins,
and
things
will
get
removed,
not
that
we
can't
bring
them
back
in
later.
But
we
don't
want
to
have
to
support
things
that
we
won't
that
nobody
will
ask
there's
a
balance
there.
B
We
could
also
decide
to
go
with
most
of
them
in
there
already
and
then
see
what
the
customers
want.
But
I
I'm
I'd
rather
like
I'd
rather
have
a
simpler
code
base
that
we
can
build
upon
yeah,
and
so
that's
it.
This
ui
is
going
to
get
embedded
into
gitlab
at
first
with
an
iframe.
It's
not
when,
when
embedded
the
color
will
change
and
it'll
look
a
bit.
B
This
is
still
localhost.
It's
not
running
inside
of
our
branch
of
our
staging
environment
for
observability,
but
soon
it
will
as
well.
So
when
you,
when,
I
eventually
show
the
staging,
it
might
say,
grafana
and
we'll
have
to
merge
things
together.
That's
it!
I
just
wanted
to
give
a
very
quick
update
like
this.
Instead
of
the
tracing
demo,
that
I'll
I'll
give
next
time
and
I'll
figure
a
few
more
things
out
or
I'll
I'll
do
a
video.
A
Awesome
thanks
seb.
Do
we
do
we
know
what
will
happen
to
the
rafana
instance
that
we
currently
ship
with
gitlab?
Are
we
gonna
gradually
get
rid
of
that
and
then
ship
yeah
instead.
B
Yeah
I
talked
to
I
talked
to
the
product
manager
in
chart
of
that
part
and
yeah
yeah
we
do
want
to
over
the
next
year
do
a
replacement
of
it.
B
I
I
think
we're
going
to
have
ours
like
it
is
currently
there,
and
the
problem
is
that
it's
not
maintained
at
all
anymore
and
since
it's
the
same
code
base,
then
this,
but
this
we're
going
to
evolve
instead
at
first,
we
thought,
let's
keep
it
in
there
for
another
year,
but
we're
probably
in
within
the
next
few
months,
see
how
we
can
accelerate
that
and
replace
it
sooner
because,
after
all,
like,
like
there's
no
reason
the
code
base
is
the
same.
B
It
supports
the
same
things,
but
I
have
to
do
a
bit
more
digging
for
that
to
to
know
what
our
customers
are
using
within
that
in
terms
of
feature
right.
If,
for.
B
B
It'd
be
good
to
know
who
who
from
our
customers,
is
using
the
embedded,
grafana
right
like
and
and
if
there's
a
place,
that
I
can
go
to
check
that
that'd
be
great
yeah.
C
So
seb,
I
have
a
quick
question.
Sure
the
the
dashboards
that
will
eventually
be
displayed
through
the
screen
that
you
just
showed
us
will
replace
the
monitoring
dashboards
that
we
currently
have
in
the
product,
yeah
and
and
what's
the
time
frame
for
that,
it's
going
to
be
next
quarter
or
next
month.
B
So
the
to
replace
the
current
dashboards
that
we
have
in
our
product,
basically
we're.
B
Yeah
yeah,
so
that's
that's
what
we're
talking
about
like
the
the
current
dashboards
that
we
have
in
there
and
that's
one
of
the
things
that's
at
first.
We
wanted
to
change
later
next
year,
but
we're
going
to
accelerate,
but
I
don't
have
a
precise
timeline
yet
because
it
depends
on
we
have
to.
We
have
to
finish
the
bare
bones
of
forking
the
project
first,
which
will
happen
during
15-3.
B
B
Going
a
bit
deeper,
yeah,
so
yeah.
I
forgot
to
mention
that
this.
What
I'm?
What
I
showed
the
bare
bones
that
I
showed
is
what
we
want
to
put
into
15
3
as
the
beginning
of
our
observability
components,
and
what
will
people
be
able
to
do
with
that?
They'll
be
able
to
send
their
own
traces
tend
their
own
errors
for
error
tracking,
but
they'll
also
be
able
to
add
their
own
prometheus
data
sources,
for
example,
because
we're
not
gonna
be
able
to
remove
that
we're,
not
gonna.
B
C
Yeah,
so
we're
gonna
have
a
new.
I
guess:
entry
in
the
vertical
menu
that
says
observability
or
is
it
gonna.
B
B
Yeah,
that's
what's
going
to
happen!
Okay,
that's!
What's
going
to
happen!
The
plan
is
to
have
that
in
an
iframe
you're
authenticated
with
your
user
at
the
name
so
shared
at
the
namespace
it'll,
be
in
gitlab.com,
not
self-hosted,
yet
not
that
you
couldn't
build
it
and
put
it
together,
but
we
won't
support
it
yet,
but
we
are
definitely
building
it
in
a
way
that's
self-hosted
will
be
available
like
so
in
a
supported
manner
as
well.
B
D
Okay,
and
are
we
going
to
to
support
like
any
default
dashboards?
Are
we
adding
like,
if
you
use
it
for
the
first
time
in
your
in
your
project,
will
be
will
be
there?
Some
default
dashboards
for
error
tracing
what
we
support
already
at
first.
B
At
first
at
first,
no,
but
eventually
that's
definitely
a
goal
right
like
as
soon
as
we
have
the
bases
in
place,
then
it
will
be
about
thinking
what
kind
of
default
dashboards
can
we
put
back
in
that
work
well
for
default
dashboards.
One
important
thing
is:
you
need
to
know
what's
running
on
the
customer
side
like
in
their
clusters
in
their
systems,
there
are
things
that
you
can
do.
B
There
are
certain
things
that
you
there
are
defaults
that
you
can
already
put
in,
but
it's
complicated
in
the
sense
that
you
need
access
to
these
places
right
like,
for
example,
if
you
want
to
do
default,
aws
dashboards,
you
need
access
to
the
aws
environments
and
everything,
and
these
are
systems
that
we
haven't
plumbed
in
yet
so
plans
to
do
that.
Absolutely
because
that's
what's
part
of
doing
a
good
experience,
no
need
to
rebuild
what
shows
by
default,
but
a
lot
of
plumbing
is
missing
to
to
have
that
out
of
the
box.
B
The
error
tracking
is
a
bit
different
in
53
it.
It
runs
inside
of
the
rails
of
the
original
ui.
So
you
see
that
you
see
it
there
and
what
we
provide
is
a
url
that
you
can
then
start
sending
your
errors
to
with
credentials
and
a
way
to
create
those
credentials,
and
then
they
will
already
show
up
within
the
like.
I
showed
in
the
pre
in
the
previous
demo
that
I
can
eventually
do
again,
but
it
will
be
inside
of
the
rails
right
like
yeah.
D
B
C
In
153
seb,
are
we
going
to
have
the
ability
to
create
an
alert
based
on
the
metrics
you're
collecting.
B
No
because
we're
not
collecting
metrics
in
53
right
we're
doing
only
traces.
Oh,
I
see
what
you're
saying,
okay,
so.
B
A
A
C
Right
right,
but
what
I
was
referring
to
is,
I
don't
know
a
few
months
ago.
C
Maybe
last
year
you
know
when
you
go
to
the
monitoring
screens
and
you
see
these
dashboards
of
the
metrics
of
the
different
clusters
and
all
that
you,
let's,
let's
talk
about
like
a
memory
consumption
graph,
you
used
to
be
able
to
click
on.
There
was
a
dot
dot
dot
on
the
right
top
right
and
you
would.
E
C
B
Can
point
you
from
graphite:
that's
that's
exactly
it
in
153.
They
already
have
it.
They
can
bring
that
all
that
information
in
the
grafana,
that's
managed
by
us,
or,
I
should
say
our
I
shouldn't
say,
refund
anymore.
This
is
our
fork
now,
but
that's
what
they'll
be
able
to
do
and
then
well
we'll
have
more
and
more
features.
B
Why
it's
the
name?
Okay,
thank
you
and
even
ops
trace
is
now
gitlab,
observability
components
right,
like
yeah.
A
Gratitude
anyway,
even
though
you
weren't
here
sorry
about
scepter
jump
straight
to
your
apologies,
so
better
late
than
never,
let's,
let's
go
back
to
the
top,
and,
let's
start
with
some
some
gratitude.
This
is
a
great
practice.
Thank
you
over
to
you.
F
Yeah
yeah,
I
just
wanted
to
thank
victor
and
his
whole
team
for
being
very
supportive
of
the
get
ops
workshop
and
also
the
formulation
of
the
underlying
examples.
F
That
kind
of
I
worked
hard
to
conform
to
what
he
had
apparently
heard
his
customer
feedback
that
they
wanted
two
projects
they
wanted
to
use,
customize,
which
I
utterly
loathe,
but
I
stuck
with
what
he
had
collected
from
customer
feedback
as
a
as
a
pattern,
and
I
also
appreciate
just
about
gitlab,
I
I
heard
a
story
from
someone
else
who
came
from
another
company
and
they
were
saying
that
at
another
company
they
were
at
when
someone
would
like
from
field
would
create
something
that
didn't
require
product
changes,
that
kind
of
opened
up
a
whole
new
world
for
customers.
F
That
particular
product
organization
would
be
really
frustrated
with
them
because
they
took
some
fame
and
fortune
away
from
them,
and
I'm
so
glad
that
we
just
collaborate.
You
know
wherever
it
comes
from,
everyone
can
contribute
and
it
will
be
treated
well,
and
so
I
just
felt
that
victor's
support
with
and
his
team's
support
through
chat
and
other
things.
They
were
responding
quickly,
especially
if
I
had
a
workshop
coming
up
coming,
but
also
you
know,
spoke
to
our
culture
in
a
very
strong
way
that
I
really
appreciate.
F
A
Awesome
great
to
hear
definitely
victor
saw
the
message
and
I'll
relate
the
note
again.
I'm
also
very
thankful
for
one
thing
like
thinking
about
even
this
meeting
in
particular,
all
of
us
have
opportunity
to
get
into
so
many
different
spaces,
sometimes
that's
practically
overwhelming,
because
I
have
no
idea
what's
going
on
in
your
particular
area,
but
at
the
same
time
it's
there's
always
something
different
and
new
to
learn
about
to
to
get
into,
and
that's
that
certainly
makes
work
enjoyable
and
interesting
and
fun.
A
Awesome
all
right,
anyone
else
have
anything
to
add
great,
otherwise,
we'll
jump
to
darwin's
question
about
modern.
F
Yeah,
I
think,
if
we
wanted
to
do
this,
this
would
just
be
a
one-time
test
and,
as
far
as
I
understand,
this
is
amazon,
doing
a
scalable
elastic
service
around
these
two
capabilities
and
it's
just
your
standard
service,
oriented
architecture,
endpoints-
and
I
think
I
made
this
ask
about
a
year
ago,
just
to
see
if
there
was
interest
just
his
background.
What
it
earns
us
is
a
logo
on
the
partner
list
on
those
particular
products
at
incompatible.
F
A
F
Team,
on
the
other
side
that
whenever
they
get
one
of
these
service
listings,
it's
like
a
technical
win
for
them,
so
it
adds
to
their
their
stack
of
gold
and
and
pete
always
tries
to
make
sure
he's
making
deposits
and
everyone's
how
everyone
is
being
measured
even
down
to
the
individual
level,
and
I
think
it's
a
great
approach
to
alliances,
but
it
seems
they
can
be
one
time
test.
I
just
don't
have.
I
could
potentially
set
up
the
services.
F
I
just
don't
have
an
idea
of
what
kind
of
testing
would
flush
out
known,
pain
points
or
what
kind
of
spot
checks
would
show
that
yeah
there's
a
95
chance.
This
is
completely
compatible
and
if
any
efforts
around
that
are
are
worth
it
to
the
monitoring
team.
In
terms
of
you
know,
the
extra
brand
brand,
the
extra
goodwill
of
being
on
those
pages
so.
A
That
I
haven't
looked
at
this
since
you
peed
last
year.
So
again
the
idea
is
aws
host
has
prometheus
as
a
service,
and
that
and
to
be
this
as
a
partner.
We
would
work
with
that
instance
of
prometheus
to
to
with
our
product
and
making
sure
that
it
works.
Something
along
those
lines
is
that
correct.
F
Yeah
and
each
service
partner
program
is
a
little
bit
different.
This
one
sounds
pretty
lightweight
that
if
we
did
a
one-time
test,
it
might
be
sufficient.
Obviously,
if
we
had
a
customer
report,
a
problem
and
we've
said
that
we're
compatible,
then
that
does
create
a
little
bit
of
an
obligation
to
check
out
what's
going
on
and
if
it's
on
our
side
or
their
side
kind
of.
A
That
existed,
this
may
make
more
sense
now,
because,
in
theory,
what
is
going
to
be
building
for
metrics
could
work
with
could
have
prometheuses
forward
metrics
from
anywhere,
including
from
amazon,
yeah.
A
F
Would
be
this
would
be
the
same
as
like
today
when
you
deploy
lab.
If
you
want
metrics,
you
have
to
deploy
a
prometheus,
and
so
you
have
to
self-manage
it
or
it
could
be
a
managed
service
like
this,
so
it's
actually
taking
yet
another
part
of
git
lab
when
we
put
it
on
cloud
and
farming
it
out
to
manage
service.
F
That
is
one
of
amazon's
new
managed
services.
So,
from
a
customer
perspective,
they
love
this
stuff,
because
now
there's
no
hosts
to
manage
no
performance
to
manage
nothing.
They
just
turn
it
on
and
it
auto
scales
to
their
needs
so
very
similar
to
using
s3
for
our
file
systems,
as
we've
done
with
a
lot
of
stuff.
C
It
sounds
like
it
would
be
something
like
what
we've
done
with
the
gitlab
kubernetes
operator,
with
openshift
right
to
get
certified.
F
It's
not
a
certification
process,
it's
much
lighter
than
that
yeah.
So
it's
and
the
amazon,
linux,
2
and
amazon
linux
2022
ones,
are
a
little
more
intensive.
We
have
to
provide
logs
to
show
security,
testing
and
stuff
like
that,
this
one
it
would
be
good
if
we
did
do
it
to
collect
the
evidence
that
shows
that
we
tested
it.
You
know
just
whether
it's
logs
or
screen
caps
and
stuff,
so
we
could,
if
they
require
that,
for
this.
F
Okay
yeah,
so
I
linked
you
not
just
to
the
service
but
to
the
partner
list
on
the
service
page
and
we
would
be
listed
there.
It's
a
and
I
I
what
I've
been
trying
to
do
is.
I
will
run
all
the
details
I
can
for
the
team.
Any
teams
who
do
these
service,
like
for
the
amazon,
linux,
2022
and
20
amazon,
linux
2
for
the
distribution
team,
I'm
doing
all
the
stuff.
I
possibly
can.
F
F
I
possibly
can
to
be
the
catalyst
to
making
it
happen
if
the
team
is
willing
to
engage.
A
Can
we
do
this
as
a
follow-up,
so
17
we're
going
to
be
working
on
this
at
some
point
in
the
future
with
regards
to
our
metrics,
and
this
could
be
something
they
look
at
when
they
get
to
that
stage?
Darwin,
if
you
don't
mind
creating
an
issue
on
the
prometheus
aws
thing,
that'd
be
awesome,
I'm
less
certain
about
the
grafana
one,
because
we're
not
we
have
our
own
ui,
so
we're
not
going
to
be
certified
for
performance.
F
Well,
it's
just
a
service,
so
today
you
have
to
point
our
ui
at
a
grafana
yeah.
That's
a
good
point.
B
It's
not
going
to
be
compatible
forever
right,
like
we
will
keep
some
retro
compatibility
for
some
dashboards,
but
not
for
everything
yeah,
but
for
the
prometheus
parts.
Yeah
do
create
an
issue.
That's
100
percent
like
the
way
we're
doing
metrics
and
how
and
how
it
works.
Like.
C
F
I'll
create
it
and
whenever
you're
able
to
get
to
it,.
F
Okay,
victor
answered
the
next
one,
but
just
basically
for
those
of
you
who
are
architecting
just
understand
that
if
you
pick
to
need
a
dns
host
instead
of
a
port
for
any
new
service,
you
stand
up,
it
has
a
ripple
effect
that
that
suppresses
adoption,
because
frequently
dns
is
not
in
the
same
place
as
firewalling.
So
in
a
standard
infrastructures
code
stack,
I
can
say
open
this
port.
F
Frequently
firewalling
is
inside
the
platform
provider,
but
frequently
dns
is
not
it's
completely
separate
a
special
software
special
service
and
so
then
that
same
infrastructure's
code
can't
very
easily
reach
out
and
do
that
host
tweak.
So
if
you
have
a
decision
and
it's
not
hard
to
tack
towards
a
port
I
tend
to
in
this
in
this
regard-
to
architecture,
favoring,
a
port
is
a
good
idea.
As
far
as
adopt
adoption
friction,
I
take
an
approach
in
architecture.
F
If,
depending
on
the
weighting
of
all
the
other
things
going
into
that
decision-
and
you
might
view
it
as
oh-
well-
that's
okay
for
new
customers,
but
actually
you
can
get
enough
of
these
build
up
that
people
won't
adopt
a
major
version
because
they
gotta
do
a
whole
bunch
of
infrastructures,
code
visits
and
other
things
to
get
to
the
next
version
of
gitlab
and
so
they'll
start
holding
up
on
a
version
when
there's
too
many
of
these
knock-on
effects
that
they
have
to
test
with
complicated
by
ac
stacks.
F
So
just
I
just
wanted
to
share
that
with
everyone
that
if
you
can
favor
port
opening
new
ports
instead
of
opening
it's
instead
of
requiring
dns
changes
at
all
that
that
helps
everyone
downstream
from
you.
F
No
not
to
my
knowledge,
but
what
I
did
was
immediately
upon
trying
to
figure
out
cass.
I
was
like
oh
well,
douchebags
you
build
do
a
port
right
and
I
found
that
we
can,
but
then
victor's
team
said.
Oh,
don't
do
that
if
you
do
that,
you've
got
to
install
from
source,
and
I
didn't
even
want
to
know
the
details
of
why
so
in
that
case,
if
that
was
a
literal
constraint
that
they
couldn't
get
around,
then
it
made
sense.
F
We'd
have
to
resort
to
dns
if
it
was
like
16
times
easier
for
the
for
the
engineering
team,
but-
and
I
also
understand
that
it's
not
necessarily
sometimes
in
software
engineering
teams-
it's
not
necessarily
there's
not
so
a
view
of
weighing
the
friction
impacts
of
making
a
decision.
You
know
port
or
post.
So
I
don't
know
of
any
more,
but
I
also
won't
know
of
any
more
usually
until
it's
too
late.
That's
why
I
bring
it
up.
A
Cool.
Thank
you.
For
the
note.
That's
helpful.
All
right,
I'm
going
to
jump
down
to
my
point
under
product
update.
So
recently
I
was
watching
the
issue
while
chris
is
on
vacation
on
the
ability
to
update
protected
environments.
The
issue
was:
we
introduced
a
new
capability,
the
ui
in
the
ui.
Only
owners
could
update
warming
or
change
a
protected
environment,
whereas
previously
maintainers
could
so
having
two
different
behaviors
is
actually
obviously
not
good.
But
the
fundamental
question
is:
how
should
we
look
at
roles
and
permissions
when
it
comes
to
protect
itself?
A
A
Just
wondering
how
how
has
it
been
your
experience
in
the
field
talking
to
customers
about
roles,
information,
that's
one
question,
and
also
for
chris.
Why
did
we
make
the
decision
we
made,
making
it
more
strict,
meaning
only
owners
could
update
these
going
forward.
E
Yeah,
I
could
answer
that
first
and
then,
maybe
if
we,
if
anyone
from
the
fields
representing
the
field,
can
hear
or
have
heard
anything
or
dealt
with
this
love
to
hear
feedback,
yeah,
kevin
yeah,
so
clarification
group
level
was
talking
just
group
level.
I
I
got
that
clarification
from
chinea
too,
because
yeah
so
group
level.
We
made
the
decision
that
only
owner
roles
can
make
those
configuration
settings
and
so
rationale
for
that
was
at
least
at
the
moment.
E
We
wanted
to
maintain
some
consistency
for
the
setting
other
related
settings
in
ci
cd
for
group
level,
and
so
right
now
those
are
only
restricted
to
owners.
That's
one
reason
this
was
raised
by
an
immediate
customer
need,
and
so
this
this
decision,
this
option
solve
that
and
solve
that
immediately
in
the
short
term.
So
that
was
you
know.
That
was
a
factor
that
I
was
considering.
E
If
we
went
the
other
direction,
it
would
have
taken
a
lot
of
config
reconfiguration
on
their
ends
to
support
to
rearrange
the
roles
and
permissions,
and
I
was
weighing
that
in
my
mind
as
well.
E
Another
reason
is:
zhenya
did
look
up
some
data
around
who
is
actually
making
these
changes
using
the
api,
and
he
found
that
only
owner
roles
were
doing
that
anyway,
and-
and
it
was-
and
it's
not
very
frequently
used
so
kind
of
another
reason
that
maybe
owner
makes
the
most
sense
for
right
now
for
this
type
of
change,
I
think
kevin.
E
You
pointed
out
on
the
issue
that
I
think
you
you
were
asking
whether
we
should
be
thinking
about
highly
regulated
industries
versus
maybe
a
more
broad
general
kind
of
a
building
or
making
that
product
decision
product
design
decision
for
my
more
widely
applicable
audience.
In
my
mind,
this
feature
already
is
sort
of
built
for
highly
regulated
industries,
so
one
so
from
kind
of
from
that
lens,
it
makes
sense
to
cater
to
their
needs
a
little
bit
more.
That
was
another
sort
of
line
of
thinking
for
me
and
then.
E
Lastly,
in
my
mind,
I
think
I
think
it's
tough
both
ways,
but
it
seems
to
me,
starting
with
a
highly
like
a
more
restrictive
model,
is
easier
to
change
in
the
future.
I'm
curious,
if
others
disagree,
but
to
me
it
seemed
like
it's
something
that
we
can
revisit
in
the
future
and
potentially
open
it
up
to
more
roles
so
and
for
all
those
reasons
right
now,
it
made
sense
to
go
that
direction.
A
Thanks
for
sharing
I,
when
I
looked
at
the
data
that
shenya
provided
it
to
me,
that's
not
conclusive,
because
we're
looking
at
seven
days
in
and
when
I
press
that
out
it
doesn't
necessarily
show
more
people.
I
think
I
wasn't
able
to
show
whether
or
not
those
users
that
did
something
were
owners,
because
I
figured
out
how
to
do
it.
E
A
F
D
F
F
F
Constraint
allowing
customization
of
existing
rules
because
that's
going
to
complicate
support
beyond
beyond
imagination,
yeah.
A
F
Go
ahead,
as
you
can
see,
quite
frankly,
we
don't
have
a
way
for
you
as
a
stage
pm
to
create
a
cross-cutting
concern
and
put
a
lot
of
pressure
on
this,
because
this
is
a
huge,
cross-cutting
concern.
We
have
no
cross-cutting
pm's
that
you
can
appeal
to
hey.
You
know
secure,
not
security,
but
authentication
and
arbok
pm.
There
is
no
such
thing,
so
it
I
think,
a
lot
of
these
really
big
issues
that
are
cross-cutting.
We
suffer
under
for
lots
of
years.
F
If
I
can
have
these
two
key
features
from
you,
so
there's
a
bigger
issue
here
of
not
of
ineffectual
ability
for
someone
like
yourself,
you
have
this
one
concern
for
this
one
thing,
but
it
keeps
coming
up
again
and
again
and
again
and
again
across
all
the
stages.
This
would
be
wonderful
if
you
all
had
some
sort
of
mechanism
where
you
could
aggregate
the
pressure
and
show
show
the
need
across
many
different
concerns
in
each
vertical.
A
There
is
a
working
group
at
the
moment
and
obviously
working
groups
have
always
been
super
effective
at
affecting
change.
Looking
at,
I
think
the
charter
of
that
group
is
to
look
at
the.
A
A
Yeah,
this
is
again,
like
you
said
this,
like
pops
hit
like
once
every
month
or
two
months,
so
it's
nothing
new
but
yeah.
We,
we
do
meet
probably
from
the
product
leadership
level,
to
push
investing
this,
because
it
is
super
important,
curious
to
darwin,
yoon,
zang
and
jan,
like
how?
What
how
do
you
advise
people
when
they're
frustrated
with
how
our
rules
and
permission
work?
F
A
lot
of
red
face
because
without
configurability,
like
you'll,
get
into
a
customer
who's
highly
regulated,
and
they
just
can't
have
these
two
permissions
together
and
they
might
have
to
make
in
some
cases
a
product
decision
or
get
super
custom
about
something
or
they're
doing
bizarre
workarounds,
because
they
just
can't
you
can
also
separate
projects,
helps
so
like
separate,
build
from
deploy,
which
we
do
in
the
git
ops
anyway,
but
it
also
frequently
pulls
these
issues
apart
nicely
also
kevin.
F
I
have
a
video
about
how
gitlab
groups
can
be
used
and
all
kinds
of
gitlab
user.
Only
groups
can
be
used
all
over
the
map
and
a
lot
of
people.
It's
not
surfaced
well
in
the
product,
so,
for
instance,
you
can't
pick
a
group
as
an
approver
and
there's
not
even
the
stanza
that
says
groups
in
the
in
the
picker
for
approvals
approvers
unless
you've
added
the
group
to
the
project.
So
it's
very
not
discoverable.
F
Where
are
all
the
places
you
can
use
user
only
groups
or
that
you
can
use
create
groups
that
you're
not
allowed
to
create
projects
in
in
order
to
make
them
user
groups
both?
So
this
one
video
kind
of
tries
to
tie
all
that
together
and
that
helps
a
little
if
they
we
have
a
lot
of
legos
and
if
you
show
them
some
opinionated
ways
of
putting
together
the
legos
to
create
much
a
little
bit
richer.
Arbok
scenario.
It
helps
sorry
jen.
D
F
Well,
yeah,
but
further
than
that,
we
don't
so.
I
already
have
an
issue
open
and
jackie's
interacting
on
it
that
when
we
punt
a
product
feature
request
into
a
workaround
or
a
working
solution,
we
never
get
that
in
docs
and
we
never
commit
to
maintain
it.
Yet.
We've
punted
a
feature
request
into
it,
and
so
customers
are
seeing
a
feature
right
in
the
ui
of
another
product.
F
Saying
I
need
this,
we
say:
oh
well,
you
just
do
that
this
way
and
then
that
this
that
explanation,
that's
a
blog
or
a
sample
repo
that
starts
to
rot,
and
so
we
don't
get
that
a
lot
of
times.
We
do
have
the
feature
with
some
assembly
required,
but
we
don't
maintain
it
even
when
we
close
product
feature
requests
based
on
a
good
workaround,
and
so
I
have
this-
and
I
actually
put
this
on
another
item
here.
F
There's
a
couple
things
I'd
love
to
make
for
monitoring,
but
the
fact
that
they
won't
be
maintained
in
perpetuity
is
a
disincentive
for
me
because
then
it's
you
know,
then
it's
just
like
a
one-time
thing
that
somebody
stumbles
upon
in
two
years
and
can't
get
it
working.
So
we
have
a
bigger
issue
that
opinionated
assemblages
of
things
we
already
have
can
be
very
effective
for
for
helping
with
this,
but
we
never
kind
of
institutionalize
it
to
the
point
of
maintaining
that
opinionated
scenario
or
it's
we're
not
good
at
it.
Yet
I
should
say.
D
And
but
I
can
imagine
that
for
for
the
enterprise,
it's
it's
surely
an
issue
and
something
that
pops
up
frequently
in
the
discussion.
A
Next
item
is
a
fyi
and
we're
working
on
our
okrs
and
we're
really,
I
don't
know
your
experience
with
okr
has
been,
but
it's
a
working
progress
for
sure
for
for
the
r
d
area
space.
So
hopefully
we
are
going
to
be
all
working
producing
okay,
ours
in
the
right
way.
So
you
can
take
a
look
at
what
we
have
planned
for
deployment,
which
is
kind
of
like
a
uber
category.
A
Categorization
of
both
configure
and
release
part
of
monitor,
there's
one
created
by
victor
for
configure,
there's
another
one
created
by
crisp
or
release.
That's
that's
in
progress.
We
hope
to
have
it
all
drafted
up
by
the
end
of
this
week.
So
if
you're
interested,
I
hope
you
are
take
a
look
and
please
provide
your
feedbacks.
A
And
then
the
next
point
is
right:
over
the
last
few
iterations
of
this
meeting,
I
haven't
seen
a
lot
of
aggregate
feedback
for
our
particular
area.
How
do
I,
how
do
we
enable
more
of
it
is
it?
Is
that
even
reasonable
curious
to
your
thoughts.
D
Yeah
it
feels
it
feels
really
difficult.
I
have
been
thinking
about
how
to
like
gather
feedback
from
the
solution.
Architects,
like
I
usually
post,
like
a
little
summary
of
what
we,
what
we
discuss
here
to
the
solution
channels.
I
like
one
week
in
advance.
D
I
ask
generally
just
in
the
channel
to
pass
on
feedback,
but
yeah
the
engagement
is,
is
pretty
low,
I'm
not
sure
how
frequently
solution
architects
approach
you
product
managers
directly
with
with
questions
where
we
could
rather
say:
okay
like
pass
it
along
to
to
yan,
and
he
will
aggregate
it's
not
really
something
important
now,
but
yeah.
I'm
I'm
discussing
this
also
with
tim
and
vladimir
zelvo
on
how
to
engage
at
least
from
the
from
the
solution,
architect,
side,
small
iterations.
Next
next
time.
A
Awesome,
thank
you
so
much.
I
just
quick
answer
on
your
question.
How
often
it's
whenever
there
is
something
very
specific.
F
F
D
And-
and
there
it
there,
it
makes
sense,
but
we're
still
like
getting
our
overall
sentiment
from
prospects
from
customers.
That
is
something
we
need
to
yeah.
We
need
to
be
able
to
collect
for
this
meeting
and.
A
D
F
I
think
that,
right
now
we
push
everyone
to
issues
and
not
only
essays,
but
the
sals
know
to
do
that,
and
it's
also
known
to
not
be
very
effective
in
true
prioritization.
F
We
could
potentially
help
them
find
the
right
issue
to
advocate
on.
But
the
problem
right
now
is:
there's
no
advanced
metrics.
There's
issues
out
there
that
are
five
years
old
and
customers
saying.
Are
you
going
to
fix
this
I've
seen
one
lately
where
there's
something
that's
five
years
old,
we
finally
fixed
it,
and
now
the
fix
is
broken.
It's
got
a
bug,
and
now
the
bug
is
falling
into
the
same
another.
F
Also
we
have
in
periscope
or
something
it
aggregates,
all
the
deal
values
of
any
posted
links
that
are
put
in
there
for
salesforce.
So
there's
all
kinds
of
data
there
already
about
aging
desire.
Recent
activity,
customers
customer
account
value
deal
value,
so
it
just
seems
like
better
metrics
around
that
and
then
being
able
to
make
sure
your
tags
are
good.
That
one
you
know
relates
to
monitoring
or
relates
to
whatever.
A
How
do
you
so
one
question
I've
been
always
curious
about
is
how
do
you
essays
and
camps
actually
find
the
issue?
Because
there's
so
many
issues,
lots
of
issues
are
repeats.
F
Dude,
you
have
to
be,
you
have
to
be
well
when
you're
in
it,
and
especially
on
the
essay
side.
You
got
to
be
a
google
expert
already,
but
I'm
telling
you
it's
hard
and
the
way
that
issues
are
broken
down,
causes
them
to
get
diffuse
and
lost.
Another
frustration
of
mine
is
authorship,
is
lost,
I'll
put
in
a
really
cool
suggestion
and
by
the
time
it
hits
the
release
announcement.
There's
no
idea
that
I
brought
that
up.
F
That's
a
totally
separate
issue
that
makes
me
not
want
to
contribute,
but
this
this
one
issue
of
just
the
way
it
gets
broken
up
and
everything.
Now.
What
do
you
vote
on
and
especially
when
issues
are
closed
when
they
close
them?
I
don't
get
that.
Let's
move
it
over
here
and
close
this
one
and
a
whole
bunch
of
value
and
conversation
and
salesforce
urls.
F
So
the
process
of
breaking
down
features
for
issues
and
epics
for
work
does
not
honor
the
ability
to
detect
aggregated
demand
and
current
demand,
and
so
that's
the
frustration
that
well.
This
is
the
way
you
do
it.
We're
not
going
to
stand
up
a
parallel
system,
add
comments,
but
we're
also
going
to
manage
the
issues
for
development
in
a
way
that
completely
diffuses
the
value
of
the
weighting.
We're
trying
to
add.
E
Kevin
I
was
gonna
just
on
this
topic.
If
we
for
me,
at
least,
if
we
look
at
the
like,
if
you
scroll
to
the
top
of
the
agenda
for
like
field
update,
I
think
we
we
we
were.
I
think
we
tried
to
be
pretty
thoughtful
about
what
type
of
sort
of
feedback
or
types
of
things
we
want
to
discuss
in
this
meeting
and
yet
a
dorm's
point.
E
We
don't
want
to
recreate
the
entire
sort
of
system
we've
built
of
of
async
communication
and
feedback
and
salesforce
updates
and
issues
and
everything
but,
like
I
think,
maybe
it
could
be
worth
like
thinking
about
how,
if
these
are
still
relevant,
how
we
can
focus
on
getting
this
type
of
thing.
These
so
like
customer
escalations,
maybe
specific
use
to
success
or
failure
stories
like
those.
E
Which
you
know
which
at
least
to
us
when
we
like
brainstormed
this
list,
we
felt
like
we
weren't
getting
as
much
so
yeah.
A
F
Collection
like
in
customer
escalations
if
they
had
to
attach,
or
they
were
highly
encouraged,
and
you
actually
showed
them-
how
you
used
issues
and
epics
to
a
given
escalation
that
this
escalation
is
because
of
this
bug
or
this
new
bug
I
entered,
then
you
could
start
automatically
starting
to
understand.
Whoa
we're
getting
like
50
escalations
around
these
three
feature:
requests
that
aren't
actually
that
complicated,
we're
just
not
prioritizing
because
we're
getting
somewhat
beat
by
so
many
other
people,
so
kind
of
the
quality
side
or
the
bug
side.
If
you
can
get
it.
F
A
Okay,
we're
almost
out
of
time
after
some
ac
updates
and
then
saw
me.
I
wanted
to
highlight
that
there's
a
gigahome
radar
that
was
just
published,
something
that
we
can
share
with
customers.
So
please,
please
take
a
look
and
share
with
all
your
friends.
I
haven't
read
it
yet
I'll.
Read
it
shortly!