►
From YouTube: Verify Monthly Field Sync
A
B
Hey
morning,
oh
sorry
is
a
little
late.
I
think
I've
got
the
first
one,
but
I
misplaced
it
under
delivery
updates.
So
my
apologies
and
kristoff
has
got
one
as
well,
but
it
follows
on
jackie
with
your
update,
your
delivery
update
around
pipeline
execution
and
and
that
group's
focus
on
infradev
and
scalability
issues.
B
I
had
a
customer
come
back
to
me
and
express
some
disappointment
in
in
the
like
sort
of
features
and
functions
that
were
included
on
one
of
our
most
recent
releases
and
it
turned
out.
There
was
a
pretty
low
degree
of
awareness
of
all
of
the
you
know
like
linear,
query
and
database
scalability
efforts
and
ci
pipeline
abuse
efforts
that
we
were
making.
A
So
I
was
interested.
I
saw
this
issue
that
you
posted,
because
first
we
had
some
direction:
page
updates
on
our
shift
to
scalability,
and
we
had
a
category
direction
where
we
created
a
new
direction
page
on
ci
scaling,
and
we
posted
that
in
customer
success
and
promoted
that
so
I'm
not
exactly
sure
a
hundred
percent
on
how
we
can
engage
further
other
than
like
multimodal
communication
doing
the
category
page
walkthroughs
and
promoting
that
in
our
typical
channels
and
of
course,
these
things
and
communicating
those
changes.
A
So
we
did
direction
page
updates
and
we
promoted
those
in
the
customer
success
channels
on
on
two
different.
Like
two
different
kind
of
escalation
channels,
so
we
can
try
to
promote
that
also
to
cs
leadership
so
that
they
can
communicate
that
to
you
further,
maybe
in
your
one-on-one,
so
that's
another
channel.
That
could
be
helpful.
B
No,
those
are
great
points,
and-
and
thank
you
for
emphasizing
that
I
do
recall
the
the
the
note
that
was
put
in
the
customer
success
channel.
I
think
it's
important
to
remember
that
we're
not
the
only
conduit
you
know
by
which
customers
receive
information,
nor
do
all
of
our
customers
get
customer
success.
Representatives
like
a
tam
right-
and
you
know
in
in
interacting
with
this
customer
champion.
B
They
were
totally
unaware
of
these
efforts,
so
you
know
I'm
fine
to
wear
part
of
that
and
say
all
right.
You
know
as
a
tam
and-
and
I
will
take
that
back
to
the
broader
cs
organization-
we
need
to
make
sure
that
we
are
cross
promoting
these
things
that
you're
sharing
with
us
with
customers.
I
I
can't
actually
recall
whether
I'd
share
the
ci
pipeline
abuse,
category
effort
or
any
other
sort
of
category
direction
updates
on
infradev
with
this
customer.
B
I
sincerely
doubt
I've
done
with
any
other
customers,
and
I
don't
know
that
that
would
be
true
or
false
of
my
peers
as
well.
I
I
think
what
I'm
getting
at
is
is-
and
I
want
to-
I
don't
know
if
it's
like
the
format
or
if
it's
the
cadence
or
if
it's
something
else
about
our
release
posts
that
we
publish
monthly.
B
A
Okay,
I
hear
you
I'll
take
this
back
to
my
my
team
internally,
given
that
we're
prioritizing
a
lot
of
infradev
and
sas
first
thoughts
as
far
as
when
we
start
to
make
a
swing
toward
over
indexing
on
like
dot-com,
audiences
and
catering.
To
that
this
might
just
be.
I
want
us
to
not
lose
sight
that
you
know
the
release
post
will
be
the
conduit
by
which
we
communicate
on
most
of
our
information.
B
And
I
think
this
is
something
I
I'm
happy
to
take
the
action
to
bring
to
farnoosh
as
well
like
it
like
it
from
a
from
a
release
post
communication
standpoint.
Like
do
we
know
where
our
customers
are
reading,
because
it
was
very
clear
like
I
was
very
well
aware
of
all
these
efforts
so
kudos
to
the
product
team
for
helping
me
be
aware
of
all
the
things
we're
doing,
but
you
know
I'm
sort
of
in
part,
that's
what
I'm
paid
to
do.
Our
customer
was
not,
and
I
was
really
surprised
by
that.
B
A
Yeah
right
so
there
we
don't.
We
don't
necessarily
want
to
promote
that
we're
working
on
some
of
that
stuff
publicly
as
well.
So
I
think
that
that's
where,
like
ultra
transparency
on
pipeline
abuse
prevention,
is
a
is
a
fine
line
to
toe.
We
can
be
transparent,
but
not
like
linking
and
cross-linking
these
issues
so.
B
A
But
I'm
saying
that
we
were
it's
just
they're
published
in
the
normal
mechanisms
that
they
have
been
like
as
soon
as
we
dedicated
all
of
those
teammates,
we
created
the
category
direction
page
we
dedicated
on
the
category
direction.
Page
says,
like
20
of
our
team
has
been
shifted,
so
we
we
can
continue
to
iterate
on
how
how
to
vocalize
and
how
to
continue
to
promote
and
cross-reference
and
make
sure
people
are
seeing
that
kind
of
information.
C
B
The
the
context
in
the
this
conversation
was
really
like:
exciting
microsoft,
being
new
functionality
right,
what's
going
to
keep
us
kind
of
an
innovative,
fast-moving
market-leading
company
and
they
felt,
as
though
1312
was
not
that
I
don't
know
on
what
objective
basis
you
could
really.
You
know
say
like
that:
release
really
met
the
bar
that
one
didn't.
I
think
every
individual
pm
has
an
idea
of
of
kind
of
like
the
weight
throughput
that
their
team
can
produce
on
a
you
know,
release
cadence
on
a
monthly
cadence.
B
C
C
I
have
an
open,
mr
right
now
in
terms
of
just
things
we're
doing
for
runner,
and
I
was
just
maybe
it's
not
the
right
thing
to
do,
given
that
we
have
less
marketing
folks,
but
maybe
we
should
think
about
from
the
leadership
standpoint,
maybe
an
ongoing
performance
and
an
availability,
specific
blog
post
kind
of
like
series-
and
I
know
it's
going
to
be
kind
of
hard
saying.
Can
you
I
know
you
need
the
title
then
say
well.
This
work
here
is
potentially
meaning
you're
seeing
less
innovation
each
month.
C
B
I
mean
we
discussed,
like
I
think,
even
from
a
self-managed
context,
where
you
might
not
be
the
direct
benefactor
of
like
a
performance
of
permitted.com
or
like
a
kubernetes
migration.
I
do
think
there's
a
pretty
high
degree
of
sympathy
in
our
customer
base.
You
know
this
understanding
of
technical
debt
right.
B
Maybe
it's
not
right
for
me
to
color
like
ci,
pipeline
abuse
is
technical
debt,
but
the
need
to
address
things
that
are
not
new
features,
things
that
are
ancillary
to
like
new
product
functionality,
a
shiny
new
thing,
it's
really
important
as
a
company
and
as
a
sas
provider
to
to
address
those.
I
feel
like
talking
about
those.
I
love
the
idea
of
a
blog
post.
I
think
that'd
be.
B
B
B
D
Monopolizing
the
agenda
yeah
well
like-
maybe
maybe
I
can
add
I
just
wanted
to
before.
We
move
to
another
topic,
just
sort
of
the
as
an
alternative
things
viewed
at
the
same
question.
Actually
it's
interesting
because
I
could
use
the
whole
rapid
action
approach
for
the
13.12
release
with
a
customer
who
expressed
exactly
opposite
in
this
case.
It
wasn't
related
to
cic.
It
wasn't
related
to
to
verify
stage.
It
was
more
related
to
the
create
stage.
D
So
I
have
a
customer
launched
by
a
large
bank
that
was
basically
saying
hey.
We
love
all
the
new
features,
you're
delivering,
but
we've
been
experiencing
a
number
of
issues
with
what
we
consider
a
core
value
of
occur,
not
valid
over
core
capability
of
gitlab,
storing
code
committing
codes,
and
they
were
basically
their
request
was
hey.
Can
you
stop
delivering
new
features
and
focus
on
fixing
some
of
the
performance,
and
you
know
the
core
capabilities
and
the
whole
communication
that?
Yes,
we
do
that.
D
Sometimes
we
stop
and
go
back
and
and
look
at
the
performance
infrastructure
topics,
but
actually
quite
important
and
relevant.
So
I
think
sort
of
I
was
trying
to
use
this
to
say
that
the
customers,
the
different
customers,
want
to
see
different
things
and
releases.
Somebody
wants
to
have
shiny
new
features.
Somebody
wants
to
see
doesn't
really
want
any
shiny
features.
E
Thanks
vladimir
was
actually
looking
at
the
upcoming
releases,
thanks
thanks
to
you,
sharing
your
link
anyway.
No,
I
it's
it's
less
of
a
topic
and
rather
confirmation,
I
believe,
more
focused
on
darren
as
well,
because
I've
got
lately
and
might
be
coincident,
but
more
cus,
more
and
more
customers
asking
around
what
essentially
can
call
enterprise
management
for
runners,
because
they're
scaling
their
number
of
runners
and
it's
becoming
hard
for
the
admins
to
to
maintain
and
to
keep
an
eye
on.
E
E
C
Maybe
so
I'm
gonna
give
everyone
a
call
homework,
so
kristoff
specific
to
the
monitoring
question.
Let's
make
sure
we
get
as
much
details
from
that
specific
customer
in
terms
of
what
are
they
leveraging
any
of
our
existing
grafana
prometheus
monitoring
and
the
reason
is,
we
may
be
able
to
help
them
solve
that
in
initial
problem,
current
problem,
with
the
current
monitoring
with
that
said
for
everyone
else,
and
for
you
as
well
christoph
look
at
the
epic
and
under
the
epic.
C
There
are
a
couple
things:
there
is
an
admin
view
sub
epic
and
there's
also
monitoring
epic
drill
into
that.
If
you
see
a
use
case
that
you're
carrying
from
your
customers,
that's
not
covered,
that's
added
to
those
to
the
right
place
and
we'll
figure
it
out
afterwards.
So
the
homework
is
yes,
we
have
a
vision,
but
we
may
not
have
captured
all
of
the
use
cases.
C
So
if
you're
hearing
something,
let's
capture
it,
if
we
can
solve
it
with
the
existing
monitoring,
let's
see
if
we
can
solve
it
fast
with
the
existing
monitoring
and
then
really
fast.
In
terms
of
where
we're
at
we
were
hoping
to
go
faster
with
the
new
views,
the
idea
was
clean
up.
The
admin
view
figure
out
the
monitoring
strategy.
Today
it's
grifan
and
prometheus,
and
obviously
that
means
customers
have
do
a
lot
of
work
on
their
own
to
set
that
up
and
the
idea
was.
C
If
we
figure
out
the
admin
view,
then
we
simply
find
the
monitoring
we
don't
know
yet
we're
moving
a
little
bit
more
slowly
on
the
admin
view
than
we
had
hoped,
because
we
had
some
changes
in
the
org,
but
our
front-end
team
is
working
on
some
foundational
stuff.
So
right
now
it's
kind
of
slow,
hopefully
in
the
next
few
releases
it
will
speed
up
so
but
yeah
tons
of
work
to
do
there.
I
just
don't
know
if
any
of
the
specific,
how
should
I
say,
pain
points?
E
Yeah
and
to
your
point,
that's
essentially
what
I
I
highlighted
today
to
them
as
well,
that
you
can
use
the
prometheus
setup
and
put
potentially
thanos
on
top
of
it
and
graffana,
depending
on
how
much
of
which
runners
that
you
have
as
well
and
the
pushback.
There
was
exactly
that
that
they
have
a
lot
of
runners,
and
so
you
need
to
set
it
up
for
each
runner.
C
C
Oh
gosh,
I
missed
the
section
of
the
agenda,
so
if
everyone
could
that's
interested
in
this
weigh
in
leaning
on
this,
mr
here,
this
camera
was,
the
idea
was
if
we
can
quickly
document
a
quick,
getting
started
guide
for
setting
up
runners
at
scale
and
in
addition
and
that's
getting
static.
I
have
a
section
on
monitoring
again,
not
saying
it's
going
to
be
perfect
on
day
one,
but
at
least
yeah.
C
We
know
it's
painful
right
now
with
all
of
the
runners,
but
maybe
a
simple
because
right
now,
if
you
point
them
to
the
run
book
christoph,
are
you
imagine
if
they
haven't
seen
this
before
the
run
book
is
like?
Oh,
my
gosh,
there's
so
much
here.
So
take
a
look
at
the
mr
weigh-in
see
if
we
can
at
least
get
them
to
something
they
could
use
with
the
mr,
if
we
can
actually
get
it
moving
and
published
and
then
we'll
certainly
circle
back
on
the
admin
view
feature
set
to
see
if
we
can
simply
file.
A
F
Yeah
so
following
the
delivery
update
in
14.1,
obviously
we
do
have
a
planning
issue
that
you
can
go
and
see.
What
are
all
the
issues
that
are
scheduled
for
this
iteration
still
still
draft,
I
probably
have
less
than
then
what
is
plan
and
there
will
be
some
carryover,
but
probably
the
most
interesting.
One
is
one
of
the
most
popular
requests
that
we
have
from
our
user,
which
is
allow
me
to
refer
to
a
job
at
the
same
stage.
F
I'm
sure
you're,
all
familiar
with
the
needs.
Keyword
where
you
can
reference
to
a
in
other
jobs
or
job
will
depend
on
another
job
to
running
outside
of
the
context
of
stages.
There
was
one
limitation
that
you
cannot
a
job
cannot
need
a
job
that
it
in
the
same
but
he's
in
the
same
stage,
so
job
needs
to
be
in
different
stages.
F
F
There
are
always
stages
behind
it,
but
for
the
user
themselves
they
won't
need
to
like
do
this
overhead
about,
let's
create
a
stage
put
all
the
jobs
that
we
need
to
run
first
and
then
the
second
they
can
just
like
list
the
whole
pipeline
with
all
jobs
and
just
add
links
dependencies
between
them.
This
is
very
similar
to
how
github
action
is
working
by
the
way
they
don't
have
any
concept
of
stages
and
yeah
and
like
because
it's
a
big
thing.
F
C
C
C
If
things
work
out,
we
might
be
able
to
get
an
unfortunate,
but
more
than
likely
that's
a
14-1
deliverable.
The
other
thing
that
we
really
need
to
wrap
up
and
close
the
books
on
in
1.
It's
kind
of
a
cross
stage
issue
between
runner
and
ci,
which
is
this,
is
probably
jamie's
one
of
jamie's
favorite
issues.
It's
the
variable
inside
of
a
variable
issue.
We
have
it
right
now
behind
the
feature
flag,
and
I
guess
this
is
speaking
back
to
jamie's.
First
point:
we
would
have
shipped
it
by
now.
C
We
would
remove
the
feature
flag
by
now,
but
we
will
focus
on
some
of
the
other
scaling
work.
So
my
hope
is
that
we
can
get
the
the
core
engineers
refocused
on
the
last
bit
of
testing
and
get
that
wrapped
up
in
14-1.
So
that's
kind
of
the
two
big
things
we
have
one
stretch
goal
for
runner
core
and
fourth
potentially
for
41..
C
It's
the
sticky
runners
mvc.
It's
the
whole
issue,
that's
been
around
for
quite
a
few
years
with
customers
asking
for
their
birth
year
specified
that
all
jobs
in
a
pipeline
executed
in
a
single
runner.
It's
been
around
for
a
while.
It's
gone
through
multiple
iterations
of
discussions,
it's
kind
of
one
of
those
issues
where
you
know
you
don't
want
to
touch
with
a
20,
24
kind
of
a
thing.
C
If
we
get
past
some
of
our
capacity
constraints
for
the
scaling
work,
then
that's
one
we
want
to
tackle
as
well,
but
that's
potentially
all
the
three
things
I
just
talked
about.
The
variable
inside
here
are
available.
The
power
9
architecture
support,
I
I
don't
know.
What's
pc
64
le
the
sticky
one
is
probably
the
stretch
goal
really
the
stretch
goal
for
14
one
in
terms
of
on
a
call,
and
there
are
a
couple
other
I'm
not
going
to
list
them
here.
A
couple
other
like
kubernetes,
related
issues
that
we're
working
on
as
well.
C
C
A
C
Yeah,
I
think
maybe
that's
one
way
to
do
it
or
I
think
we
could
potentially
simply
as
I
just
as
you
mentioned,
that
like
for
ronald
call,
maybe
we
just
create
a
view
so
that
you
link-
and
you
can
say
here-
are
the
things
besides.
The
things
that
we
want
to
highlight
here
are
the
things
that
are
on
the
coin.
Links
you
to
a
view
right.
Maybe
we
can
just
create
views
in
the
issues
and
the
actual
project
issues
that
people
can
link
to.