►
From YouTube: Release Management Think Big #15 - APAC
Description
Reviewed Auto Change Logs & Release Notes
B
B
A
Let's
see
we're
already
recording,
so
that's
good.
Apparently
I
forgot
to
record
the
new
secrets
management
sync
last
time
so
now
I'm
like
kicking
myself
in
the
face
for
it,
because
I
try
to
try
my
best
to
always
record
and
that's
why
I
have
things
to
set
to
auto
record.
So
I
don't
have
to
worry
about
it,
but
you
know
yeah.
It
is
what
it
is.
C
A
A
A
A
So,
typically,
it
allows
us
to
sort
of
consider
moon
shots
or
really
big
picture
ideas,
and
then
we
can
identify
opportunities
to
potentially
iterate
and
implement
those
features.
So
a
really
good
example
of
this
was
how
we
decided
to
partner
with
package
to
create
aversion,
dependencies,
scope
and
vision.
A
So
now
we
have
this
idea
out
there
that
we're
going
to
begin
iterating
on
to
allow
us
to
distribute
binaries
within
the
releases
page
right,
so
how
this
meeting
works
and
how?
How
has
worked
in
the
past
is
that
we
would
have
a
meeting
every
other
week
for
an
hour
and
there
would
be
several
agenda
topics
that
were
populated
either
from
previous
conversations
that
we've
had
or
during
the
week
something's
been
identified
and
we'll
drop
it
on
this
agenda.
A
A
A
A
A
A
C
A
Yeah
and
typically
I
will
the
day
before
I'll
post
in
the
slack
channel.
Hey
here's
our
agenda,
don't
forget
to
populate
topics,
but
since
this
was
our
first
apac
one,
I
wanted
to
give
you
like
a
a
context
setting
and
then
lobby
some
topics
for
us
to
discuss,
so
you
can
get
a
feel
for
how
we
do
it
and
then,
if
this
isn't
valuable
for
you
all,
we
don't
have
to
do
the
apac
time
zone
anymore.
A
A
So
then
it
all
turns
okay,
so
which
which
topic?
Do
you
want
to
dive
into
which
one's
the
most
interesting,
I
feel,
like
both
of
you,
might
have
context
around
automatic
release
notes,
given
that
we
have
the
releaser
cli
tool
and
cries.
You
worked
on
some
of
those
issues.
Just
does
that
sound
good
to
kind
of
dive
into
and
talk
about.
B
And
it's
always
why
don't
we
adopt
this
as
a
feature?
But
the
problem
I
see
is
that
all
of
these
examples
is
working
very
well
for
the
given
project,
because
it's
very
specific
to
the
given
project-
and
I
was
thinking
if
we
adopt
one
of
these
as
a
feature
that
it
may
not
work
well
for
for
many
cases,
because
you
know
like
every
release
process
is
a
bit
different
and
the
people
the
way
people
do
their
release
notes
are
a
bit
different.
B
Like
kind
of
more
pluggable,
so
people
have
listed,
we
support
different
ways
to
generate
release
notes
and
they
still
will
not
cover
all
the
cases,
but
we'll
cover
like
a
few
like
few
of
them.
So
and
you
have
an
option
to
choose
which
which
way
to
to
use
for
your
releases,
because
some
people
like
may
have
may
be
happy
just
with
list
of
commits
or
just
a
list
of
the
merch
comments
or
list
of
the
merch
requests
with
given
label
like
there's
so
many
options.
A
B
Even
if
we
so
even
if
we
start
with
just
one
and
keep
it
that
for
a
long,
it
should
be
done
in
with
like
being
pluggable
in
mind,
so
that
we
can
easily
add
up
new
or
something
that
at
least
that's
what
I'm
thinking
like.
That's
what
I've
been
thinking
every
time.
I
see
one
of
those
examples
and
people
saying
why
not
we
use
it.
C
C
So
if,
for
every
reason
you
end
up
increasing
the
major
release
for
your
module,
it
may
not
be
compatible
in
the
future
with
other
with
other
releases.
That's
sorry
with
other
projects,
that's
because
of
the
nature
of
go
modules.
If
you
add
a,
for
example,
you
have
a
v2
eventually,
that's
automatically
released,
because
you
know
you
follow
your
semantic
release
and
you
have
a
breaking
change
in
your
commit
and
then
automatically
created
a
v2
tag.
C
A
Yeah,
so
I
think
these
are
all
super
good
points,
and
I
appreciate
the
granular
look
at
it
if
I
was
to
frame
up
the
generic
requirements
on
what
I
hear
time
and
time
again
about
what
people
are
looking
for
from
an
auto
change.
Log
is
that
they
want
a
configurable
option
per
project
for
generating
release
notes
and
by
configurable.
They
want
to
be
able
to
set
the
source
of
the
release
note.
A
So
maybe
they
have
it
from
issues
for
merge,
requests
from
git
tag,
annotations
and
all
of
those
should
be
set
at
the
project
level
or
cascaded
down
from
the
group.
That's
like
a
generic
requirement,
so
I
think
that
that
lends
itself
really
nicely
to
what
you
were
saying.
Craz
is
that
we
should
build
multiple
ways
to
support,
generating
release,
notes
and
allow
the
users
to
select
them
when
I
think
about
the
way
a
way
to
iterate.
A
A
B
Oh
yeah,
I
think
we'll
we'll
always
persist
it
when
we
create
a
release,
because
we
have
a
database
record
for
the
release
and
it
will
be
just
another
field
in
the
in
the
database
and
they
also
always
have
a
way
to
go
and
manually
edit
it
if
the
auto
generated
or
maybe
not
there,
that's
probably
a
decision.
We
need
to.
C
B
C
A
B
A
So
from
like
a
user
flow
perspective,
we
would
have
a
user
potentially
using
the
yaml
file
to
generate
a
release
and
inside
of
that
animal
file
it
would
allow
some
sort
of
scripting
or
because
today,
that's
how
users
are
doing
it.
They're
scripting
from
the
ammo
file
to
auto,
generate
or
there's
the
option
of
like
adding
a
file
in
like
your
repository
or
have
it
be
a
setting.
A
So
I
think
this
is
where
we
see
some
paradigms
that
come
up
in
gitlab,
where,
if
we
have
this
be
a
configurable
option,
do
we
need
to
add
like
an
anchor
to
the
ammo
file,
or
how
do
we?
How
does
that
impact
the
user
experience
if
they
have
the
option
to
change
like
how
release
notes
are
generated?
Do
they
need
to
commit
that
to
the
ammo
file,
or
is
this
a
setting
toggle?
How
would
you
envision
that.
C
B
A
A
A
Does
my
problem
make
sense
like
when
what
I'm
saying
is
like
the
the
disruption
of
introducing
two
places
to
set
where
you
want
to
the
events
to
say?
At
the
same
time,
a
release
is
generated,
you're
going
to
create
a
change
log,
but
you
would
be
setting
your
release
generation
in
a
different
place
from
the
release
notes,
generation.
C
B
Yeah,
if
we
think
about
when
you
create
release
from
manually
from
gitlab
like
how
it
is
going
to
work,
if
we
have
made
like
few
different
options,
you'll
probably
have
a
like
select
list
and
choose
how
you
generate
your
change
log
and
that's
basically,
should
be
the
same
in
yama.
Of
course,
it's
just
different
interface
for
actually
the
same
endpoint
create
release
and
you
may
specify
so,
but
we
may
I
don't
know
there
may
still
be
need
for
some,
like
more
general
project
level
configuration
that
that
will
be
in
settings
or
for
a
group.
A
So
I
would
be
I'd
be
interested
in
how
we'd
want
what
what
action
we
want
to
drive
users
to
so,
for
example,
if
everything's
going
to
be
scripted
inside
the
ammo
file
from
a
release
generation
perspective,
we
need
to
support
release
notes
alongside
that
experience,
or
we
create
a
global
setting
that
specifies
I'm
going
to
only
use
the
ammo
file
just
to
specify
a
release,
generation
and
release,
notes
creation
or
I'm
going
to
use
semantic
release,
or
I'm
going
to
only
manually
push
release
notes.
Once
I
create
a
tag
from
master,
I
mean
we
can.
A
We
can
go
like
anywhere
with
this.
I
just
would
want
to
want
to
direct
users
to
what's
the
best
practice
that
we'd
want
to
instrument
and
you're
right
like
what
might
be
the
first
iteration
may
not
be
where
we
end
up
where
we
end
up.
This
might
be
all
in
the
settings
panel
and
it
creates
the
ammo
file
for
them.
Based
off
of
the
settings
that
they.
A
B
A
A
C
I
don't
know
from
from
my
perspective
like
if
there's,
if
there's
a
sample
in
the
documentation
that
I
can
use,
then
I'll
just
figure
the
rest
out.
But
that's
that's
from
my
perspective.
I
don't
know.
Maybe
if
there
are
other
release
managers
out
there,
that
are
not
that,
don't
want
to
mess
into
the
technical
details
and
yeah.
It
will
be
very
useful
right
because
it
sets
everything
up
for
them.
A
Yeah,
like
that's
the
difference
between
a
build
manager
and
a
release
manager,
you
know
a
release.
Manager
may
not
be
the
technical
person
they
may
be.
A
project
manager,
that's
confirming
gates,
are
passed
their
their
control
board.
You
know
versus
a
build
manager,
who's
like
actually
creating
the
release
pipeline.
A
A
B
C
B
A
That
sounds
good,
so
I
think
we
already
have
a
bunch
of
issues
on
release
notes.
So
what
I'm
working
on
with
farnoosh
the
product
operations
product
manager
is
creating
a
dog
fooding
set
of
release,
notes,
auto
generation
so
that
we
can
start
getting
rid
of
the
release
post.
As
we
know
it
today
and
leveraging
an
in
product
feature
for
auto
generated
release
notes.
B
A
A
Yeah,
so
the
release
post
process
is
super
manual
as
a
product
manager.
I
open
up
a
merge
request.
That's
called
a
release
post
item
and
I
follow
about
30
steps
inside
of
that
release.
Post
item
merge
request
where
I
open
up
an
mr
against
the
features
gamble,
and
I
fill
that
out
and
I
copy
paste
that
information
into
the
categories
yaml
and
then
I
copy
paste
that
feature
block
into
a
primary
feature
block
that
then
gets
merged
into
the
web
page
for
the
release
post
that
gets
released
on
the
22nd.
A
It
has
nothing
to
do
with
the
merge
request,
that's
actually
being
merged.
So
that's
where,
like
at
the
end
of
the
day
when
you
merge
your
feature,
I'm
refreshing
the
branch
page
to
make
sure
that
that
features
made
it
in.
So
I
know
whether
or
not
to
merge
my
release
post
item
in
so
it's
completely
disconnected
there
isn't
any
relationship
between
the
merged
work
that
you
did
and
the
release
post
item
that
I
created
so
from
a
a
cycle
at
the
beginning
of
the
quarter.
I
batch
create.
A
All
of
these
merge
requests
for
all
of
our
direction.
Items
that
we're
expecting
to
ship
in
the
quarter
so
I'll
have
about
40
merge
requests
open
at
the
beginning
of
the
quarter.
For
the
next
three
milestones,
I
will
work
with
nicole
to
get
those
items
merged,
as
you
guys,
complete
the
work
and
that
there's
a
bunch
of
handover
mess
in
between
where
the
release
post
manager
then
aggregates
all
of
those
merged.
Mrs
from
across
the
50
different
product
managers
to
create
the
marketing
blog
post
that
we
know
today.
A
So
I
have
validated
with
enterprises
that
they
are
using
issues
to
create
their
content
for
the
release
notes.
So
they
have
an
issue
or
an
epic
with
a
description
and
then
the
copywriters
will
copy
paste
that
into
their
web
page
content.
So
the
idea
of
one
thing
is
to
support
the
creation
of
the
release
post,
as
we
know
it
from
issue
content.
B
B
Yeah,
that's
what
I
was
thinking,
because
there
is
basically
no
way
for
us
to
cover
everyone's
use
case
in
even
like
think
about,
but
we
should
give
them
like
some
basic
building
blocks
that
are
already
gitlab
features
like
issues
and
a
way
to
like
go
from
there
and
you
know
like
customize
it
for
their
use
case
and
what
you're
saying
kind
of
makes
sense
if
you
have.
If,
if
you
have
those
issues-
and
you
just
need
their
description
as
a
part
of
your
release,
notes
and
then
you
specify
a
label
name
and
on
every
release.
B
It
goes
pick
up
those
issues
with
that
label
and
builds
them
together.
Just
you
need
to
figure
out
like
which
issues
for
which
release,
because
you
may
have
open
issues
from
different
releases.
So
something
like
this
that's
kind
of
generic,
but
very
flexible
and
still
like
saves
people.
But
at
the
end,
probably
there
will
be
people
that
just
don't
want
to
write
them
themselves,
even
in
issue
description
because
they
already
written
it
in
the
commit
message
or
something.
A
But
that's
where,
if
we
support
semantic
release,
they
can
leverage
that
industry
standard
tool
for
generating
their
auto
change
log
and
the
people
who
want
more
fit
and
finished
release
notes
they
can
leverage
issue
descriptions
right.
I
think
that's
where,
like
we
can
support
the
enterprise
use
case
and
the
developer
use
case
by
implementing
a
more
industry
standard
tool,
while
then
pivoting
toward
a
more
custom
tool
that
you
can
afford
to
do
with
issues.
A
So
issues
is
where
my
head
is
at
for
dog
fooding,
because
customers
would
also
use
that
and
then,
for
the
more
general
use
case,
going
really
cheap
by
just
implementing
semantic
release.
As
a
first
generation,
I
think,
would
cover
most
of
our
customers
use
case,
because
then
they
just
have
to
use
the
semserv
syntax
with
their
commit
message
to
get
that
populated.
B
B
A
You're,
so
right
about
that.
That
is
why
marin
at
the
delivery
team,
when
I
was
talking
about
dog
fooding,
this
he's
like
I
don't
really
know
if
that's
gonna
work,
because
it'd
be
a
huge
change
management
exercise
for
all
you
developers
out
there
to
effectively
do
this,
but
today,
like
the
release,
managers
for
each
release
are
having
to
manually
edit
commit
messages
and
that's
a
huge
amount
of
work
for
them.
C
From
just
thinking
like
you
have
an
mr
with
a
thousand
commits
right
at
the
end
of
the
day,
you
choose
the
strategy
to
merge
that
into
your
default
branch.
If
you
squash
that
into
a
single
commit
and
that
single
command
had
like
followed
these
semantic
release
kind
of
commit
messages,
then
you
know
you
will
solve
a
little
bit
of
that
issue,
because
it's
then
up
to
the
to
whoever
is
merging.
A
A
A
Message
for
this
yeah,
I
love
that
so
when
we
do,
I
have
an
issue
out
there
about
implementing
semantic
release
in
our
auto
dev
box
templates.
That
might
be
a
best
practice
that
we
create
documentation
for
that
suggests.
Yeah
you
want
to
squash
set
set
that
at
your
project
level
that
you're
always
going
to
squash
your
commits,
so
that
you
can
leverage
the
benefits
of
semantic
release
with
your
work,
that's
perfect!
I
love
that
I'll
create
an
issue
for.
A
B
B
B
B
A
B
A
A
I
know
that
farnoosh
is
getting
really
anxious
to
implement
a
dog
fooding
option
for
us
so
that
we
can
get
rid
of
the
release
post
process
because
it's
a
inexpensive
process
when
you
have
like
50
product
managers
spending
two
weeks
out
of
the
month,
generating
mrs
for
release
posts.
It's
not
it's
not
efficient!
B
And
I
was
also
thinking
we
kept
like
sort
of
two
different
at
least
two
different
target
groups
here,
because
we
have
releases
that
the
way
we
do
it,
which
is
like
public
facing
release
that
you
you
like
review
to
the
to
the
world
every
month
or
every
week,
but
some
companies
also
have
their.
They
are
never
releasing
anything
publicly.
It's
all
just
like
internal
daily
releases
and
in
that
case,
release
notes
are
usually
more
like
low
level
like
commit
messages
and
developer
centric.
So
yeah.
B
A
A
B
Like
I
said
we
should,
we
should
try
at
least
for
a
while
and
see
how
it
goes,
and
I
think
it
makes
sense
to
give
as
diverse
perspective
on
that
is
possible,
so
that
you
have
a
product
people
ua
developers.
So
I
don't
know
how
how
it's?
What
would
you
say
how
it's
compared
to
other
big
things,
because
it's
been
mostly
me
and
jaime
saying
like
pointing
problems
and
why
we
can't
do
it,
which
is
not
much
in
the
thing
big
kind
of.
C
C
A
Yeah
cause
right
now,
it's
like
three
in
the
morning
for
hayana.
I
guess
what
we
can
do.
What
I
can
think
about
is
having
this
be
a
discussion
topic
that
hyon
and
I
have
like
we
populate
these
ideas
a
week
before
and
then
her,
and
I
could
talk
about
it.
We
can
record
it,
publish
the
recording
and
then
we
can
discuss
that
kind
of
feedback
to
get
a
little
bit
more.
A
You
know
information.
It's
like
we're
such
an
anti-pattern
with
this
meeting,
because
it's
synchronous,
so
it's
not
it
doesn't
it
doesn't
do
the
it's
not
the
gitlab
way.
It
doesn't
naturally
lend
itself
to
a
super
diverse
audience,
but
we
can
continue
iterating
on
that.
I
think
it's
great
to
have
face
time
with
you
all
and
to
hear
your
perspectives.
I
love
learning
from
you,
so
it's
been
super
valuable
for
me
and
I
like,
when
you
tell
me
that
things
aren't
going
to
happen,
because
I
then
just
work
harder
to
make
it
happen.
A
B
A
A
Yeah,
so
we
had
one
we
had
two
with
package,
so
I
think
the
next
one
that
we'll
do
will
be
with
monitor
from
like
a
post-deployment
monitoring
experience.
How
do
we
finish
the
life
cycle
of
incident
management
and
then
there's
a
product
design
think
big
at
the
entire
op
section
level.
So
I
can
try
to
find
like
a
recording
of
that,
but
it's
seriously
like
20
people
on
the
call
doing
this,
like
just
brainstorming.