►
From YouTube: Release Management Think Big US/EMEA #16
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
So
we're
here
for
our
16th
release
management
think
big
session
hannah.
I
know
that
you
only
got
30
minutes
today,
so
we
have
two
topics
on
the
agenda.
The
first
topic
is
about
creating,
like
a
permission,
schema
for
environments
for
different
related
objects.
So
let
me
give
you
some
concepts
around
how
this
issue
came
up.
So
ori
pained
me
on
a
future
flags
issue
being
like
users
wanted
to
that.
She
was
talking
to
feature
flags.
A
We
have
a
very
similar
setup
around
like
deploy,
keys,
they're,
scoped,
specifically
to
an
environment,
and
then
other
attributes
like
ci
tokens,
the
ci
job
token
is
obviously
on
the
project
level.
So
when
we
started
to
talk
more
about
global
things,
that
users
are
leveraging
environments
with,
they
have
to
specify
a
scope
and
then
copy
paste
that
scope
across
many
different
projects.
A
B
Examples
just
hi
have
having
having
worked
on
a
commission's
issue.
Recently,
I
was
still
working
out.
The
permissions
model
at
gitlab
is
actually
it's
quite
it's
it's
many
layered
and
I
think
I
think
we
would
just
have
to
be
really
careful
to
to
make
the
permissions
clear.
So
in
the
protected
environments
work
I
found
some.
I
found
some
issues
between
the
permissions
that
exist
on
the
project
versus
the
permissions
that
this
is
for
them.
B
You
know
some
inconsistencies
and
I
think
a
couple
of
at
least
one
actual
bug
you
know
and
then,
when
you
think
about
it,
we've
got
like
here's
one
place
where
we
set
the
permissions
in
the
project
and
then
we
have
another
place
where
we're
setting
a
different
set
of
permissions
and
they're
kind
of
a
subset,
but
not
always
and
yeah.
B
I
think
that
permissions
is
a
very
powerful
part
of
gitlab,
but
it's
it's
a
bit
complex
and
if
we
can
simplify
it
in
our
implementation,
I
think
that
would
be
a
great
thing.
A
Well,
good,
I'm
glad
we
have
your
support
here.
That's
that's
important
for
me.
I
think
that
one
part
that
I'm
struggling
with
as
as
a
former
release
manager
is
that
our
permissions
schema
is
not
flexible
in
gitlab.
C
B
Yes,
yeah,
I
completely
agree,
so
that's
that's
a
potentially
I
mean
we
can
do
a
minimal
version,
but
it's
potentially
a
big
fan
of
worms
because
in
fact
one
of
the
limitations
on
the
current
model
is
it's
hard
to
to
you
know
you:
can
users
can
only
change
missions
in
a
very
specified
way?
And
you
know
they
don't
have
a
lot
of
flexibility
as
opposed
to
other
systems
where
you
know
they
can
create
roles.
I
mean
we
don't.
B
Obviously
we
don't
want
to
go
there,
but
yeah
I
mean
I
think
we
could
just
kind
of
have
a
generic.
You
know
higher
level
permission
that
would
fit
would
fit
into
the
gitlab
main
declarative
policy
framework,
and
then
we
could
have-
and
here
are
some
refinements
of
that-
you
know
for
four
hour
use
case.
A
I
love
that
so
thinking
big,
taking
a
step
back
on
what
I
would
expect
users
to
do
so
I
think
that
this
makes
sense
to
have
it
in
the
ui
rather
than
an
ammo
file.
So.
A
I'm
not
able
to
globally
apply
this
for
my
instance
or
project
like
set
of
projects.
The
same
group.
I
would
like
to
separate
out
the
role
permission
paradigm
and
look
at
specific
groups
or
or
better
yet
a
specific
banking
customer
that
I
talk
with
frequently
doesn't
even
use
groups
and
projects
in
gitlab.
They
they
create
random
projects
and
groups,
and
they
piece
them
together
with
topic
labels,
so
they
have
yeah
so
they're,
creating
business
unit
hierarchies
from
projects
that
are
spanned
across
multiple
different
portfolios.
A
So
we
don't
we
and
that's
because
of
the
the
pro
the
project
and
group
permissioning
structure.
They
want
to
have
a
separations
of
duties,
so
they're
keeping
teams
of
the
same
group
in
separate
projects
and
groups
and
connecting
them
together
with
a
topic
label
and
that's
to
that's,
because
we
don't
have
a
really
great
way
of
like
enforcing
compliance
needs
out
of
our
current
paradigm.
B
Speaking,
I
was
going
to
say,
speaking
of
compliance
is
also
not
really
I
mean.
What's
an
easy
way
to
audit,
I
mean
commissions
is
a
bigger,
bigger
issue
than
just
release
management.
You
know
it
scans
spans
the
entire
product,
but
I
mean
how
can
you
say
you
know
joe
in
accounting?
Has
the
access
to
this.
It's
actually
not
really
that
easy
right
like
access
to
deploy.
You
know
we
don't.
As
far
as
I
know,
we
don't
have
any
I'm
not
suggesting
we've
necessarily
built
it,
but
it
is.
B
It
seems
to
be
a
lack
that
we
don't
have
a
view
of
what
are
all
the
permissions
for
an
individual
person
in
one
particular
go.
You
know,
but
depending
you
know,
they
might
be
derived
in
all
different
ways,
but
yeah
it's
it
seems
it
seems
to
me
a
big
hole
that
we
don't
have
that
in
some
way
or
report
or
something
you
know.
A
A
And
it
gets
like
it
just
gets
tricky
when
you're
also
looking
at
like
a
matrixed
system
that
isn't
using
the
natural
flow
and
gitlab
that
are
grouping
projects
that
you
can
see
at
the
top
level.
In
an
inheritance
and.
A
Like
the
compliance
team
is
working
on
permissions
from
like
a
user
perspective
in
a
different
way
like
the
managed
team,
they
own
that.
So
what
I'm
trying
to
like
bifurcate
here
is
us
being
beholden
to
the
role
user.
Specific
permission
schema
in
order
to
afford
a
greater
flexibility
of
using
gitlab.
The
way
users
want
to
use
gitlab
so
allowing
them
to
create
separations
of
duties
at
the
environment
level
without.
B
A
To
rely
on
the
role
permission
schema,
so
how
can
we
like
bake
in
flexibility
by
creating
that
that
fluidity
of
permissions.
C
B
At
that
granularity,
the
the
protected
environment
is
the
beginning.
You
know
it
is
already
its
own
commission's
system
or
more
or
less
it's
very
small,
but
I
think
we
will.
I
mean
it
doesn't
have
to
be
called
protective
environments,
it
could
just
be
environments
and
then
we
could
progressively
add
to
it.
You
know
what
are
these
environments?
Who
has
access
to
them?
What
can
they
do
to
them?
And
you
know
that
could
be
different
between
staging
and
production
and
et
cetera,
and
so
there's
the
seed
of
that
is
already
there
actually.
B
A
In
a
more
structure,
in
a
way
that
like
allows
us
to
actually
create
this
appending
of,
like
other
objects
that
are
beyond
just
protected
environments,
because
we
would
want
to
we'd
want
to
add
the
things
to
the
environments
inside
of
gitlab.
You
know
like
I
want
to
control
feature
flags
for
this
environment
in
a
single
view,
and
I
think,
like
this,
allows
us
to
also
connect
in
the
environment's
dashboard
view.
All
these
related
objects,
too,
like
being
able
to.
B
Could
that
be
like?
Maybe
we
would
name
it
something
else,
but
environment,
permissions
and
then
protected
environment
would
just
be
one
of
those
attributes
on
on
those,
and
you
know,
and
what
this
environment
is
protected
and
it's
protected
for
these
people
or
whatever
kind
of
turn
it
around
a
little
bit.
But
the
focus
is
the
environment.
Yeah,
the
environment
is
what
we're
interested
in
and
who
can
do
what
to
those
environments.
D
Would
with
a
good
parallel
to
this,
be
the
protected
branches.
I
I'll
share
my
screen
real,
quick.
D
B
A
Yeah,
I
think
that
this
could
be
a
paradigm
that
we
emulate,
because
you
see,
even
in
the
same
view,
we
have
branches,
tags,
tokens
and
keys,
which
are
a
view
of
the
other
things
that
I
thought
that
we
would
want
to
be
also
like
controlling
per
environment.
So
I
I
yeah.
I
completely
agree
that
we
would
be
expanding
environments
to
to
kind
of
match
this
pattern.
A
Maybe
this
could
be
the
nbc
like
we
refactor,
protect
environments,
to
kind
of
match,
protected
branches
and
then
add
other
environment
permission
functionality.
Maybe
what
do
you
think.
B
A
Yeah,
if
I
think
about
the
use
case
that
I'm
trying
to
solve
with
this
environment's
permission
structure
like
the
way
I
see
it,
is
like
a
matrix,
we
have
like
environments
permissions
and
then
you
have
like
rolls
across
the
top,
and
you
have
all
the
features
that
are
in
that
environment
and
it's
like
a
variable
tokens
branches
like
whatever,
and
then
you
have
like
a
check
box
for
each
roll
that
you
can,
and
you
also
have
the
option.
I
want
to
enable
adding
specific
users.
A
I
want
to
enable
adding
specific
groups-
and
that
will
add,
like
we
can
afford
the
flexibility
of
that
bank
as
referencing
to
add
specific
people
or
groups
to
each
of
those
different
attributes
under
that
environment
matrix
and
then
I
think
you
could
expect
below
that
you'd
be
able
to
have
an
expanded
out
like
protected
variables,
permission
management
or
future
flag
permission
management
like
just
like
the
protected
branches
section.
B
It's
complete,
but
it's
completely
clear.
Actually
I
mean
you
know
you
see
this
in
many
types
of
systems
right,
particularly
when
the
users
can
define
their
own
roles
right
and
define.
What's
a
role
is
just
a
bucket,
but
in
in
gitlab
you
know,
role
had
really
clearly
defined
right.
There's
you
know
developer
reporter
maintainer
and
yeah,
so
so
the
only
way
around
it
is
to
do
what
you're
describing,
which
is
to
essentially
build
a
kind
of
mini
commission's
system.
A
Roles
from
environments
or
allow
like
there
to
be
more
flexibility
there,
that
would
solve
like
a
lot
of
our
a
lot
of
our
problems.
We're
hearing
from
customers
right.
D
D
D
B
B
Just
thinking
of
how
how
you
know
when
we
have
a
hierarchy
of
groups
and
sub,
do
we
can
we
not,
can
we
we
can
assign
someone
to
a
group,
but
if
we
assign
them
to
the
top,
they
get
all
the
children
right
or
is
there
a
way
of
controlling
that.
A
So
they're
disabling
inheritance
in
the
compliance
team,
so
really
yeah,
so
they
should.
That
should
be
a
configuration
option.
That
is
that
a.
D
A
B
D
One
thing
we'll
have
to
be
careful:
if
we
do
add
another
concept
of
like
permissions,
is
that
we
we
almost
have
we'd,
have
all
these
different
ways
to
add
people
and
manage.
So
we
have
like
roles,
we
have
guest
developer,
et
cetera
and
we
have
groups,
so
you
have
access
to
groups
in
that
whole
hierarchy
and
if
we
add
a
third
permissions
model,
then
you
have
to
make
sure
that
users
are
clear
about
how
to
add
themselves
to
certain
privileges.
It
could
get
confusing.
If
we
have
a
lot
of
different
ways
to
do
it.
A
A
So
if
we
say
like
those
are
the
three
things
that
you
can
add
just
consolidating
it
in
one
view
and
allowing
people
to
say
here,
I
want
to
have
all
of
my
protected
environments,
enable
group,
maintainer
and
project
maintainers
and
specific
group
deployers
or
I
want
feature
flags
on
production
environments
to
be
managed
by
only
project
maintainers,
but
not
group,
maintainers
and
deployers,
so
like
being
able
to
manage
that
logic
in
a
single
place.
B
D
The
other
thing
I'm
thinking
about
too,
is
that,
like
our
all
our
tiers
and
our
pricing
is
based
on
roles
right
now,
like
that's
our
whole
pricing
structure,
is
that
you,
a
user
who
has
more
privileges,
costs
more
yeah?
Well,
I
think
it's
like
there's
like
a
cap
now
that
I'm
saying
that
I'm
not
sure
I'm.
D
B
No,
I
think,
actually
yeah
well
protected,
protect
well,
but
we
do
that
also
at
a
feature
level
right,
because
protected
environments
is
an
ee,
you
just
don't
have
it
on
your
screen
at
all
right.
If
you're
investing
on
an
ee
license.
A
D
A
But
sean
to
your
point,
yes,
you're,
absolutely
right,
like
per
premium
features,
do
end
up
using
a
lever
of
you
can
specify
you
have
to.
You.
Have
the
privilege
of
specifying
specific
roles
like
that
common
pattern
that
we
see
in
features
that
are
premium
and
ultimate
affording
that
flexibility,
because
that's
a
part
of
multi-project
management,
which
is
a
pricing
capability
in
silver
and
premium
right.
B
A
A
Is
this
something
that
we
want
to
only
push
down
to
each
of
the
feature
levels
because
we
could
say
yeah
or
future
flags
need
to
have
their
own
permission,
schema
that
relies
on
role
assignments
and
we're
not
going
to
management.
That's
at
the
environment
level,
that's
a
choice
that
we
can
make
and
then
we'll
have
this
disparate
experience
that
we're
noticing,
between,
like
protected
branches,
protected
environments,
deploy
keys,
deploy
tokens
specifying
environment
scopes
and
ci
variables
in
the
ml
file.
So
like.
I
think
that
we
just
have
a
bunch
of
different
ways
to
manage
permissions.
B
A
But
I
do
wonder
if
there's
like
an
easier
fix
around
containing
particular
permissions
that
are
in
the
release
stage,
that
we
can
help
improve
like
if
a
release
manager,
if
we
only
think
about
the
release,
manager's
persona
and
what
they're
responsible
for
for
managing
or
like
a
dev
team
lead.
Someone
who's
like
coordinating,
builds
having
that
single
user
flow
might
be
like
what
we
can
deliver
or
render
as
a
first
iteration.
B
B
I
I
really
like
this
idea
by
the
way,
I
think
it's
it's
really
needed
and
it
is
potentially
big
and
it's
all,
and
I
think
that
part
of
the
part
of
the
reason
we've
got
these
different
approaches
is
in
the
past.
I
don't
think
we've
looked
at
this
whole
thing,
big
picture,
and
so
there's
these
little
like
protected
branches-
and
you
know
again,
you
know
protected
environments,
do
things
slightly
differently,
and
so
I
think
it
would
be
this.
B
This
would
be
the
sort
of
feature
that
would
be
really
quite
beneficial
to
maybe
do
a
couple
of
iterations
on
paper.
Before
we
go
near
any
actual
code,
I
think
yeah
and
we
can
kind
of
chip
away
at
what
we've
got
already
and
refine
that,
but
with
the
you
know,
with
the
larger
road
map,
you
know
the
future,
maybe
potentially
even
exporting
it
to
the
rest
of
the
organization.
A
Yeah,
I
like
that
so
from
what
I
think
actionable
next
steps
around
this
feature
set,
would
be
opening
up
an
issue
around
matching
protected
environments
to
protected
branches.
A
If
that
like,
because
I
think
protected
branches
are
a
little
bit
more
adopted
and
people
are
a
little
bit
happier
with
the
way
they
work
and
matching
that
schema
and
then
creating
a
separate
issue
for
allowing
environment
scopes
for
variables
or
like
environment
scopes,
to
be
managed
in
the
ui,
and
I
think,
like
those
are
two
existing
features
that
we
can
like
start
incrementally
delivering
as
a
part
of
the
release
management
story.
A
And
then
I
can
open
up
an
epic
around
ops
settings
for
permissions
and
we
can
create,
like
an
op
section,
think
big
discussion
around.
How
do
we
want
to
enable
users
to
easily
set
the
permissions
for
different
objects
per
environment?
A
And
I
think
that
that
will,
I
think,
that's
a
good
discussion.
Okay,
all
right.
C
Projects
or
groups-
and
you
mentioned
something
like
a
topic
label.
What
do
you
mean
by
that?
It's
really
like
a
label
that
they
assign
to
issues
and
merge
requests
that
make
everything
belong
to
a
single
bucket.
A
Let
me
see
if
I
can
find
it,
they
showed
it
to
me
and
that-
and
I
was
like
I've
never
seen
this
before,
but
it
really
is
like
it
is
like
a
label
that
lives
on
the
project
and
it's
how,
like
the
complaint.
C
Okay,
so
like
css
or
html,
whatever
right,
you
have
another,
but
I
don't
know
how
to
configure
that.
D
I'm
thinking
of
the
same
thing:
it's
not
it's
not
like
a
label
like
our
concept
of
a
label.
It's
just
text
that
you
can
add
in
the
project
settings
that
show
up
on
the
project
home
screen
right.
They
kind
of
group
things,
but
I
don't
know
how
you
would
use
that
for
anything
other
than
superficial
perfect,
like
it's
really
just
text.
I
don't
think
you
can
certainly
monitor
things.
A
They
they
have
a
bunch
of
reports
from
the
api
that
allows
them
to
like
export
it,
and
then
they
can.
B
B
C
C
A
So
it
still
lives
in
a
group
and
project,
it's
just
they.
They
match
the
permissions
of
those
projects
and
the
groups
based
off
of
that
filtered
label
or
topic.
So
it's
like
a
manual
process.
They're
going
through
like
they'll,
create
project
a
and
group
a
project
b
under
group
b,
and
those
will
have
two
different
permission
structures,
but
people
who
are
maintainers
in
project
a
and
they
want
the
g
maintainers
in
project
b.
They'll,
add
them
at
that
level,
but
not
at
the
group
level.
A
A
So
I'll
create
these
issues
and
we
can
start
thinking
about
what
that
looks
like
the
other
topic
that
I
had
on
the
agenda
are
gitlab
run
books.
A
A
A
But
this
next
feature
set
something
that
I
think
that
we'll
be
delivering
in
2021,
so
something
that
will
like
you
know
next
year,
but
I
wanted
to
start
the
dialogue
on
it.
Monitor
health
is
creating
a
thing
called
an
issue
type
incident,
so
they're
using
issues
as
a
way
to
create
incidents
inside
of
gitlab.
So
they
pretty
much
cloned
issue
type
rebranded,
as
incidents
started,
removing
issue
type
specific
scope
and
started
adding
back
specific
stuff
to
an
incident
so
that
they
can
link
incidents
back
to
everything
instead
of
gitlab.
A
I
think
we
can
take
a
learning
from
this,
because
when
I
look
at
run
books
commonly,
we
see
the
issue
like
the
run
book
created
at
time
of
release
or
deployment.
So
when
I
think
about
this,
it's
like
the
the
issue
that's
generated
at
the
release
post
for
product
managers.
The
issue
that's
created
for
the
runner
team
when
they
cut
their
release.
A
A
They
also
want
to
share
them
across
projects
and
there's
a
way
that
we
could
leverage
something
like
an
issue
template
to
create
deployment
run
books.
So
they
could
trigger
a
bot
kind
of
like
how
we
automatically
create
issues
like
the
retrospective
issue.
You
can
automatically
trigger
on
the
23rd
of
every
month
the
following
release
run
book
and
it
would
maybe
have
web
hooks
that
trigger
several
events,
and
you
can
link
that
across
multiple
different
projects.
A
Leveraging
group
milestones
you
could
assign
it
to
different
release.
Managers
per
like
an
assignee
table,
you
know,
or
a
release
manager
roulette
so
like.
I
can
feel
I
can
see
like
a
lot
of
the
issue.
Functionality
help
facilitate
a
run
book
really
cleanly.
A
I
have
victor
and
configure
on
the
issue
because,
when
I
also
consider
like
disaster
recovery,
run
books
or
automatic
rollback
runbooks,
those
might
not
necessarily
make
sense
in
in
an
issue
type,
but
I
could
see
if
we
could
support,
run
books
at
the
group
level
and
leverage
the
issue
template
functionality
and
then
have
like
triggers
inside
of
git
lab
that
say:
okay,
we
have
this
job
in
a
pipeline
and
if
test
results
are
less
than
80
passing,
do
an
automatic
roll
back
to
staging
or
proceed
with
roll
out
to
a
different
environment,
and
that
could
like
be
a
triggered
event
from
this
runbook
template.
D
B
Yeah
and-
and
I
think
taking
it
back,
the
way
you
mentioned
jackie,
taking
a
different
view,
is
the
way
to
go,
because
we
could
then
eventually
build
out.
Is
this
going
to
be
a
jupiter
notebook
or
whatever
you
know,
that's
that
would
just
be
in
that.
I
think
we
were
looking
at
it
from
a
different
perspective
before
and
yeah.
Even
if
you
just
have
an
issue
template,
then
you
can
start
working
out.
How
do
you?
A
I
think
fundamentally,
if
we
can
support
things
like
executing
scripts
from
the
issues,
or
maybe
we
add
like
run
book
quick
commands
so
like
we
can
say,
there's
a
slack
web
hook
from
the
run
book
that
you
run
slack
command
listed
in
the
issue
like
building
out
that
feature.
Functionality
would
be
a
really
great
quality
of
life
experience
and,
like
I
could
see
a
world
where
we
add
a
quick
command.
A
That's
like
generate
release,
notes
for
this
release
based
off
of
this
run
book
from
that
run,
book
issue
so
like
adding
quick
commands
to
execute
scripts
from
that
document,
I
think,
would
be
a
really
great
enhancement
to
bring
this
whole
deployment
list
full
circle.
B
B
A
Today,
because
we
just
clone
the
existing
issue
type,
so
we
don't
have
to
worry
about
rebuilding
off
that
feature.
Functionality
and,
what's
even
cooler,
is
when
we
think
about
release
evidence.
These
issues
can
be
sucked
back
into
release
evidence
because
we
have
issues
already
in
the
docket
for
hardening
release
evidence.
So
that's
kind
of
the.
D
A
Yeah,
so
in
the
epic
I
kind
of
have
I
kind
of
have
like
a
an
iteration
path
on
the
epic
that
says
we
clone
it
and
then
we
start
removing
stuff,
and
then
we
add
stuff
so
like
the
nbc
is
hey
now
you
can
use
this
run
book
template
and
maybe
we
create
three
different
template
types,
one
of
them
being
like
a
cloud
native.
A
You
know
very
much
like
you
are
continuous.
You
tag
each
commit
and
deployment
to
production,
and
you
generate
a
tag
like
we
can
do
it
that
way
or
you
can
do
a
hybrid
where
you
have
to
specify
and
it's
a
little
bit
more
manual
action
but,
like
you
know,
just
thinking
through
making
it
really
easy
to
use
existing
stuff
and
paradigms
in
gitlab
to
link
and
support
this
runbook
use
case.
B
One
thing
that
comes
to
mind
is
like
I
mean
if
you're
looking
at
the
kind
of
runbook,
where
okay,
you
know,
do
this
step
through
this
step.
Do
this
step
just
there's
essentially
table
based
right,
like
you,
you
know,
and
so
I'm
not.
I
wonder
how
that
we
would
possibly
do.
Would
that
kind
of
go
in
the
issue
body
and
that
would
be
the
run
book
and
then
the
the
comments
would
be
the
actual.
What
happened
you
know
then?
Then
they
clicked
this
button.
B
Then
they
then
they
did
this
and
and
if
and
if
we
did,
that
would
normal
markdown
tables
do
it
for
us
or
do
we
want
to
have
something
a
bit
more
flexible,
because
you
know
markdown
tables
are
great
but
they're
just
fiddly
to
work
with
right.
You
know
we
have
a
little
short
shortcut
but
they're,
there's,
probably
great
libraries
for
doing
that.
You
know
doing
tables
in
a.
A
That's
a
really
great
call
out,
because
markdown
tables
will
be
a
pain
to
manage.
My
initial
thought
is
that,
like
the
templates
that
we
create
will
be
just
a
series
of
checks,
check
boxes
and
they
would
have
like
code
blocks
for
scripts
that
you
need
to
run.
So
the
nbc
is
that
you
have
to
go
to
your
cli
and
run
this
script.
B
B
C
B
So
so
the
potential-
and
so
you
know
I
in
the
past-
I've
used
these
stupid
notebooks
for
different
purposes
and
when
they
get
real,
you
know
when
they
get
really
long.
You
get
a
bit
lost
right,
particularly
when
you've
got
output,
because
the
output
can
be
really
long
as
well,
see
scrolling,
and
you
know-
and
so
I
guess
you
know,
two
possible
approaches
would
be
to
have
it
at
some
section
on
the
hot.
You
know
the
the
steps
in
one
section
or
have
them
just
you
know
throughout
it,
but
then
have
a
button.
A
B
Yeah,
like
we
thought,
like
we
do
with
comments,
you
know
right.
A
But
that's
kind
of
what
we're
thinking
for
for
run
book.
So
if
you
want
to
take
a
look
at
the
at
the
epic
and
add
some
additional
thoughts
and
considerations,
I
am
all
open
for
it.
I
know
that
we're
at
time
I'll
take
some
actions
from
our
first
discussion
topic
around
the
environment's
permission,
schema
and
then
we'll
talk
more
about
run
books
as
we
get
closer
to
next
year.