►
From YouTube: Dogfooding the Releases Page
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
A
So
I'm
talking
to
an
expert
here,
but
what's
interesting,
is
that
our
teams
are
starting
to
consume
that,
as
is,
and
we
need
to
balance
their
feedback
and
kind
of
think
about.
How
can
we
improve
that
page
as
it
exists
today,
until
we
can
get
rid
of
or
transition
the
release
post
process
away
from
the
way
it
is
today?
But
it's
my
understanding
and
that's
why
farnoosh
is
included
in
this
process?
Is
that
we'll
have
the
release
post
process?
A
How
does
that
sound,
okay,
perfect
and
then
I
wanted
to
introduce,
furnish
she'll,
be
shadowing
this
engineering
relationship
between
you
and
I
and
potentially
sean
as
we
start
to
think
about
back-end
experiences
and
she
is
making
enhancements
to
the
product
development
workflow.
So
she'll
be
here
to
be
like
jackie
you're,
not
following
the
product
development.
Workflow,
like
it's
written
and
to
make
enhancements
to
both
me
and
the
product
development
workflow
process,
which
is
a
really
cool
thing
for
us
to
be
the
the
specimen
that
gets
analyzed
in
that
regard.
A
So
I'm
half
excited
half
like
petrified.
I
like
constructive
criticism
and
farnoosh
is
incredible
at
giving
it
so
I'm
ready
to
receive.
So
let
me
share
my
screen
and
we
can
walk
through
the
release.
Notes,
epic,
as
it's
written
today,
to
give
that
landscape
that
I
was
talking
about
earlier.
So
from
a
product
goal
perspective
we
want
to
in
an
end
state
world.
So
in
the
future,
what
we
want
to
help
users
do
is
set
what
source
they
want.
A
Their
release
notes
on
the
releases
page
to
be
generated
from
so
we
want
this
to
be
flexible
and
potentially
generated
from
multiple
sources.
So
these
kinds
of
things
could
be
a
header
inside
of
an
issue
or
an
epic
or
a
merge
request,
and
it
gets
filtered
and
pulled
into
that
releases
page
from
labels.
A
So
that
is
like
a
big
picture
idea
where
we
eventually
want
to
go
taking
a
step
back.
We
have
some
iteration
paths
that
we
need
to
consider,
and
I
think
some
of
this
can
get
parallelized
with
other
teams.
In
addition
to
us,
but
the
first
one
is
this
idea
of
auto
change.
Log
creation.
A
So
currently
our
delivery
team
has
a
very
manual
way
of
changing
and
editing
commit
messages
back
into
the
automated
change
log.
That's
created.
What
we
may
think
about
doing
is
instrumenting
semantic
release
as
a
part
of
our
ci
templates,
but
also
adopting
semantic
release
internally,
so
that
we
can
use
semver
syntax
to
pull
in
those
commit
messages
to
reduce
some
of
the
scripting
burden
and
maintenance
burden
that
marin's
team
is
currently
maintaining
on
their
delivery
side.
A
Another
iteration
path,
which
is
more
about
release,
notes
in
the
enterprise
and
what
git
lab
will
probably
end
up
consuming
and
using
are
making
enhancements
to
that
source
of
the
release,
notes
field
so
building
in
the
capabilities
to
pull
release,
notes
from
an
issue
pulling
the
the
title
of
a
merge
request
or
an
epic
and
what
we
need
to
also
prioritize
are
thinking
about
the
existing
releases
page,
and
how
can
we
make
that
more
usable
and
replace
the
marketing
website?
As
we
know
it
does
that
all
make
sense?
A
Okay,
so
we
have
some
check
boxes
down
here
that
are
about
the
requirements
of
both
the
end
state,
which
is
the
fancy
fletcher
source
and
auto,
generate
release.
Notes
from
this
based
on
labels,
and
then
we
have
the
requirements
that
are
currently
being
satisfied
by
these
requirements
are
currently
being
satisfied
by
our
existing
release
post.
A
So
this
is
kind
of
like
the
continuity
of
dog
fooding
that
we
need
to
think
about
as
we
go,
and
some
of
these
features
are
currently
in
your
releases
page
today,
nathan,
like
it
links
the
documentation,
we
have
a
link
to
the
existing
marketing
blog
post.
You
can
provide
quick
access
to
the
tier,
so
those
kinds
of
feature
sets
have
to
be
maintained
in
our
final
solution.
A
There's
a
couple
of
enhancements
around
highlighting
upcoming
releases.
So
this
is
where
the
idea
of
a
draft
release
becomes
more
relevant
and
we've
talked
a
little
bit
about
that
in
our
release.
Management
syncs.
But
this
epic
here
will
be
creating
a
release
so
that
somebody
who
is
looking
forward
to
13.4
can
see
what
are
all
the
issues
scheduled
for
that
milestone
as
a
salesperson
and
potentially
draft
release
notes
from
those
features
as
kind
of
like
a
published
state.
So
we
can
think
about
how
we
want
to
intersect
release,
notes
and
draft
releases
together.
A
In
my
mind,
the
nbc
is
that
we
just
create
the
object
of
a
future
release,
don't
have
a
tag
to
it
and
then
once
the
tags
associated
to
it.
That's
when
we
populate
the
release
notes,
but
there
will
eventually
be
like
a
future
state
where
people
kind
of
want
to
see
the
release
notes
before
it's
the
version
cut.
But
we
can
deal
with
that
when
we
get
there.
A
Other
requirements
are
the
searchability
of
release,
notes,
which
is
something
that
we're
weighing
in
the
next
milestone,
where
we've
already
weighed
but
we'll
prioritize
it
in
the
next
milestone
for
delivery
in
like
13.6
or
so
so.
This
will
be
existing
release,
notes
and
that
search
will
eventually
be
expanded
so
that
we
can,
you
know,
filtered
on
labels
and
that
kind
of
thing.
A
From
a
structure
standpoint,
I've
discussed
auto
change
logs
already
adding
semantic
release,
which
is
a
part
of
the
auto
change
log
story,
adding
epic
access
source
sources,
adding
issues
of
sources.
I've
left
out,
merge
requests
for
now,
but
we
may
create
an
epic
for
merge,
request
and
track
the
merge
request
activities
in
there
and
then,
of
course,
more
fine
fine-tuned
kind
of
like
release
notes
are
confusing,
so
we
should
probably
remove
them
from
tags.
A
You
know
that
kind
of
stuff
is
also
in
this
epic,
this
adding
issues
as
the
source
for
release
notes
on
release
tags.
This
has
some
dog
fooding
enhancements
of
your
existing
page
today
in
it
nathan.
A
You
and
these
may
be
features
that
we
need
sean
for
too,
so
I'm
open
to
also
just
planning
in
our
milestone
that
you
and
sean
are
going
to
be
like
at
reduced
capacity.
A
So
we
can
support
this
dog
fooding
effort
more
thoroughly,
which
is
I'm
completely
comfortable
with
that
just
means,
instead
of
planting
a
weight
of
10
issues
as
deliver
10
weight
at
them
ours
as
a
deliverable
that
we
only
plan,
maybe
five
as
deliverable,
and
that
way
we're
able
to
be
more
dedicated
to
the
releases
enhancements
page
to
dive
into
the
first
request
from
monica,
which
is
our
sales
representative.
A
B
Yeah
yeah
no
problem,
my
first
thought
yeah,
so
the
the
split
between
the
the
two
different
repositories
was
it
used
to
be.
B
I
think,
if
I'm
thinking
of
the
right
thing
it
was
the
the
get
lab
runner.
Although
the
ci
was
a
separate
product
and
then
gitlab
itself,
that
was
a
super
long
time
ago.
So
I
don't
really
know
if
that's
really
relevant
like
I
can't
imagine
they
would
really
care,
because
that
was
so
far
back
in
our
history.
So
ever
since,
like
anytime,
any
kind
of
modern
feature
will
have
been
developed
in
that
mono
repo.
B
A
That
sounds
good
and
I
will
I'll
pull
up
your
initial,
mr,
after
this
meeting
and
kind
of
link
it
back
to
all
of
this
stuff
so
that
we
can
access
everything
in
one
place.
B
So
one
question
about
this:
what
is
when
they're
saying
they
they're
trying
to
distinguish
which
features
are
available
versus
sas
for
self-manage?
Are
there,
like?
I
don't
know
which
features
they
like
pretty
much
they're
they're
on
parity
like
if
you
self-host,
you
have
all
the
features
that
you
would
if
you
were
on
gitlab.com.
B
A
A
This
is
all
representing
exactly
what
the
release
post
says,
but
if
we
go
to
the
actually,
I
can
just
link
from
your
page.
What
am
I
doing
if
we
go
here?
We
have
these
little
badges
that
tell
us
what
tier
they're
in,
but
also
if
they're,
in
dot
com
or
sas.
B
B
B
A
Yeah
or
just
an
indication
that
both
of
these
features
are
available
on
this
page
and
dot
com
are
self-managed
because
right
now
we
only
see
the
ultimate
in
premium
and
core
starter
tiers.
We
don't
see
gold,
silver
and
free.
A
A
I
don't
know
if
that's
really
485,
but
they
want
like
here's,
the
new
ones
and
here's.
The
total.
B
So
if
we
would
add
something
like
this,
would
we
also
are
they
wanting
it
on
that
page?
You
were
just
on
or
are
they
wanting
it
more
on
the
our
current
public
releases
page.
A
B
A
A
Okay,
so
nathan,
what
I'll
do
is
put
a
release,
p2
label
on
these
issues,
because
I
don't
know
what
else
you
have
in
in
queue
for
13.4,
but
I
would
love
for
these
to
get
shipped
as
a
part
of
13.5.
B
C
Nathan,
if
you
can
ping
me
also
after
you,
have
a
look
at
the
release
page
to
also
have
an
idea
of
how
these
changes
are.
Gonna.
Look
like
the
only.
C
B
C
A
And
then
for
for
neusha's
benefit,
we
do
mostly
everything
async.
A
So
the
best
way
to
keep
a
prize
will
be
to
follow
these
issues
and
just
peeing
me
or
at
end
friend,
for
an
update
or,
if
you're
looking
for
anything,
we
don't
have
a
lot
of
synchronous
meetings
and
by
a
lot
we
virtually
have
zero
synchronous
meanings
that
are
about
existing.
You
know
functionality
that
we're
building.
D
That
sounds
great
because
we're
completely
connected
between
my
goals
and
requirements
for
our
release
post
process
and
now
this
epic,
I
think
we're
very,
very
much
async
streamlined
in
that
respect,
and
I
will
make
sure
I
think,
to
keep
things
simple.
I
will
probably
anytime,
I
think,
I'm
participating
in
any
activity-
that's
relevant
I'll,
probably
ping,
you
jackie,
so
that
you
can
manage
the
communication
rather
than
me,
pinging
the
team
when
it
may
or
may
not
be
irrelevant.
D
D
I
think,
for
the
for
from
the
standpoint
of
change
and
culture
management,
we
will
keep
the
release
post
blog
page
up
and
running,
probably
in
tandem
for
a
while,
as
we
dog
food
and
feel
our
release
features
at
a
place
where
I
can
strongly
go
in
and
say
we
need
to
flip
the
switch
right
in
partnership
with
marketing
sales
and
so
on
and
so
forth.
That
is
totally
true.
D
Eric
schurter
is
in
the
loop,
and
you
know
we're
basically
jackie
and
I
are
very
much
in
comps
to
make
sure
any
optimizations
I'm
making
to
that
release.
Post
process
is
in
sync
with
our
goals
here
right,
however,
a
bit
of
exciting
news
in
two
separate
meetings
this
week
with
leadership,
including
sid,
we
are
getting
the
clear
charge
that
we
need
to
be
focused
on
optimization
and
enhancement
of
existing
features
and
not
just
shipping
features
anymore.
D
This
is
really
great
news
for
us
at
scale
to
be
getting
that
kind
of
push
from
our
ceo
from
said,
and
some
of
the
simple
struggles
such
as
man.
There's
such
an
attachment
to
this
release,
post
page
with
endless
scroll
of
like
100
plus
features
shipped,
they
might
resolve
themselves
and
become
a
smoother
path
for
us
to
be
like
hey,
we're
going
to
cut
this
down
by
marketing,
let
them
focus
it
on
an
intro
and
start
dog
fooding
sooner
our
own
release
feature.
D
A
And
then
sean
will
be
your
partner
on
the
back
end
side
nathan.
So
if
we
need
to
pull
him
in
he'll,
be
the
person
that
we're
assuming
his
capacity
will
take
a
hit.
B
So
those
if
I
kind
of
understand
right
just
to
make
sure
I'm
understanding
the
whole
scheme,
so
the
the
very
first
things
we're
biting
off
are
just
kind
of
changing
the
format.
Changing
the
details
on
in
those
release
notes.
But
then
the
long
term
vision
is
to
actually
build
something
into
the
product
that
generates
these
release,
notes
from
merge
requests
and
issues
and
hopefully
use
that
ourselves.
B
The
one
comment
I
did
have
I
know
we
had
talked
about
using
semantic
release
internally,
and
I
think
we
had
talked
about
that
in
the
previous
meeting.
I
thought
about
that
since
that
meeting-
and
I
don't
know
if
that
would
be
a
benefit
to
us
as
an
organization,
because
our
versions
are
very
much
controlled,
they're
much
more
like
marketing
and
monthly
driven
they're,
not
really
driven
by
what
features
are
in
there.
So
it's
not
like.
We
just
release
a
minor
version.
B
Whenever
there's
a
new
feature
it's
every
month,
there's
a
minor
version,
so
semantic
release
is
much
more
about
driving
the
version
number
off
of
the
changes,
so
that
may
make
less
sense
than
when
we
talked
about
it
initially.
That
was
my
only
comment
on
that.
A
That's
a
good
thought,
because
I
did
talk
to
marin
about
it,
and
his
initial,
like
inclination,
is
that
he
would
rather
source
the
change
log
from
merge,
request
titles
and
then
our
marketing
release
notes
from
issues
or
ethics
where
product
and
marketing
are
so.
That
was
his
also
gut
feels
that
we
could
generate
change
logs
for
more
curated
sense
versus
commit
messages.
B
Yeah-
and
I
don't
even
know
if
it's
necessarily
about
with
the
source
of
the
release-
notes
I'm
just
more
thinking
like
with
semantic
release.
Normally
you
say
you
know
you
have
a
little
tag
that
says
what
kind
of
changes
it
and
then
that
changes
the
version
number.
So
we
probably
don't
want
that
intensive
relationship
that
our
version
number
of
gitlab
is
determined
by
developers.
A
B
A
That's
a
really
great
call
out
you're,
so
good,
you're,
very
observant-
and
you
know
you
know
your
audience.
I
like
that
about
you,
so
I
did
want
to
dive
a
little
bit
more
into
the
thinking
big
aspect
of
sourcing
from
different
different
areas.
I
think
we
need
to
build
it
as
flexible
as
possible
so
that
people
can
say
yeah.
I
want
to
pull
this
information
from
any
place
that
I
want
inside
of
git
lab,
whether
that's
a
merge
request
title
a
header
inside
of
an
issue,
a
header
inside
of
an
epic.
A
B
My
initial
thought
is
that
it'd
be
great
to,
since
we
already
have
this.
This
release
syntax
and
our
kit
labs
ciamel
that
we
just
released
it'd
be
great
to
kind
of
extend
that
and
say
you
know
I
don't.
I
haven't
really
looked
at
it
too
carefully,
I'm
assuming
we
have
some
kind
of
release,
notes,
property
or
something
you
can
just
type
like
set
to
a
variable,
but
maybe
in
that
there
could
be
some
sub
properties
there,
that
you
can
configure
it
to
point
to
merge,
requests,
titles
or
yeah.
B
Somehow
we
we
specify
the
target
inside
that
gitlab
ci
gammel
that'd,
be
my
initial
thought.
Is
that
your
that
way,
it's
all
generated
from
that
yaml
file.
A
That's
from
thinking
too
that's
where
it'll
be
the
most
flexible.
I
am
worried
about
any
like
backward
changes
and
the
maintainers
getting
a
little
anxious
about
implementing
a
change
like
that
inside
of
the
ml
file,
because
every
time
we
do
add
a
new
attribute,
they're
like
okay.
Well,
this
could
make
things
slower
right,
because
then
the
system
is
having
to
parse
through
all
of
those
messages
and
inject
that
which
the
release
cli
should
be
able
to
handle.
It's
not
rails
doing
that
work.
A
So
what
we've
built
should
be
able
to
service
that
that
need,
but
I
think
it's
easier
to
fail
fast
in
the
ui
with
those
kinds
of
features,
because
the
yaml
file
has
such
a
strong
maintenance
cycle
on
it,
like
it's
taken
us
nine
months
to
deliver
release
generation
from
the
amble
file.
This
was
my
first
feature
that
I
was
on
when
I
joined
and
we
finally
shipped
it.
A
A
B
Right,
yeah,
yeah,
that's
a
good
point.
I'm
trying
to
think
it's.
This
kind
of
similar
conversation
we
had
with
deploy
freezes
was
like
how
much
do
we
put
in
the
yaml
file
versus
how
much
do
we
put
kind
of
in
the
like
in
a
settings
page
somewhere,
and
I
think
we
kind
of
ended
up
in
a
nice
way
where
you
you
just
in
your
gamble
file,
you
say:
use
deploy
freezes
and
then
you
configure
them
in
the
ui.
So
maybe
it's
something
something
like
that.
A
I
like
that,
like
set
source
and
yeah,
I
love
that,
like
yeah,
if
you
enable
set
source
variable,
then
you
have
to
set
source
inside
of
the
panel.
That's
a
really.
A
C
B
Then
the
other
advantage
of
that,
too,
is
that
you
can
configure
stuff
at
the
group
level
and
we
can
have
the
group
level
settings
kind
of
go
down
to
everything.
So
cascading,
that's
great.
A
Yeah
yeah,
that's
really
good!
I
like
that
on
I'll,
add
an
issue
for
that
right
now,
okay,
what
was
my
other
thoughts
that
I
needed
your
brain
power
on?
Well,
I
have
you.
A
From
a
lengthy
releases
page
perspective,
I
have
a
lot
of
anxiety
about
this
because,
as
we
start
to
get
more
requests,
people
may
want
to
jam
things
like
the
actual
release,
content
block
onto
the
releases
page,
and
that
could
be
like
a
200
character.
Blurb
at
each
of
these
line
items
and
one
of
the
complaints
we
have
about
our
existing
blog
is
that
it's
too
long.
A
So
I
wanted
to
talk
about
like
interactions
of
being
able
to
set
collapses,
or
maybe
adding
like
a
hover
option
where,
like
you,
can
add
a
helper
text
for
each
item
added
that
allows
you
to
hover
to
then
read
the
content,
but
I
don't
really
like
hover
interactions
in
git
lab
my
least
favorite
one
is
the
comment
pop-up
because
it
pops
up
and
it
stays
wherever
wherever
it
follows
me.
So
I
don't
want
to
experience
that
same
like
hover
over
interaction
problem,
but
I
would
love
to
brainstorm
on.
How
do
we
avoid
lengthy
releases?
A
How
do
we?
How
do
we
keep
the
simplicity
and
beauty
and
search
ability
that
your
current
feature
has
nathan,
because
that's
what
sales
loves
about
it?
They
love
going
to
it
and
they
were
demoing
it
to
customers,
because
they're
like
look
at
how
easy
it
is
to
search
and
find
this
kind
of
stuff
like
they
just
pulled
up
command
f
and
looked
for
their
features
that
they're
looking
for
like
they
love
it,
because
it's
so
accessible,
but
other
people
are
gonna.
A
B
My
my
first
thought
is
that
we
could
do.
I
think
we've
talked
about
this
before,
but
is
making
the
main
releases
page
different
than
the
individual
release
page.
So
maybe
the
main
releases
page
just
shows
like
the
first
paragraph
of
content
and
then
to
see
the
whole
thing
you
have
to
click
into
it.
That
could
be
that
doesn't
really
on
the
individual
release.
Page
you'd
still
have
that
massive
block,
but
maybe
that's
okay,
because
it's
you're
only
looking
for
that
one
release.
B
That's
my!
I
guess
my
first
thought.
C
Yeah
that
was
also
my
first
thought,
as
we
can
make.
I
don't
know,
do
some
separation
in
the
in
the
release?
Notes
where
you
just
add
like
the
highlights
of
what
this
release
is
about.
If
you
still
want
to
show
something
but
other
content
since
yeah,
we
know
how
long
a
release
item
is,
and
it's
so
difficult
to
have
20
items
in
a
single
page
and
then
yeah.
C
We
can
definitely
go
crazy
with
the
interactions
another
way
we
have
some
components
in
pajamas,
it's
like
the
pop
over,
but
not
a
performance
like
a
special
one.
Where
you
have
you
can
add
images,
you
can
add
everything
you
want,
but
then
the
interaction
is
a
bit
different
from
just
the
tooltip.
It's
the
one
that
is
clickable
and
then
you
have.
You
can
have
more
structured
content,
so
we
can
definitely
play
around
with
the
these
elements.
D
I
have
a
question
that
might
lead
to
an
idea.
If
I
may
do,
we
have
the
anything,
I'm
not
aware
on
the
marketing
side,
but
do
we
have
the
concept
of
anything
that
would
be?
That
is
a
collective
kind
of
list
of
capabilities
per
like
category.
A
Yeah,
like
that's
what
I
was
thinking
feature
xaml,
would
be
a
list
of
everything
that
people
have
added,
that
is
a
marketing
value
to
to
the
organization,
so
as
a
product
manager.
When
I
add
my
release
post,
I
add
a
feature
example.
If
the
feature
is
sellable
or
I
haven't
already
added
it
as
a
part
of
the
first
iteration.
D
I'm
just
I,
I
was
just
thinking
about
the
idea
of
a
detailed
view
being
somewhat
specific
if
it's
helpful
to
a
user
to
a
category,
but
that
might
not
be
a
great
idea.
A
So
there's
two
two
worlds:
when
we're
looking
at
a
release:
page
there's
people
who
are
going
to
consume
that
binary
and
build
on
top
of
it,
so
it's
a
distribution
platform
and
then
there's
people
who
are
orchestrating
and
planning
releases
from
that
view.
So,
for
example,
I
want
to
trigger
subsequent
events
for
when
that
release
has
been
added
to
that
page,
so
they
use
the
releases
api
to
act
as
a
web
hook
almost
to
trigger
other
events.
A
I
am
a
provider
of
software
here
you
go
to
download
this
on
a
version
dependencies
use
case.
We
are
distributing
like
packages,
so
the
release
notes
again
need
to
be
more
consumable
in
a
way
that
people
like
yeah.
These
are
the
changes
that
are
different
from
the
previous
release.
So
I
know
like
what
I'm
downloading.
A
I'm
a
little
worried
about
if
we
accommodate
too
much
of
like
the
get
lab
jargon
into
the
releases
page
in
the
future
right
like
if
we
build
this
off
of
the
features
animal
that
won't
be
usable.
For
you
know,
customers
in
the
same
way,
but
if
we
can
populate
things
from
existing
archetypes
that
we
have
inside
of
gitlab
like
issues
fx,
mrs
whatever,
that
makes
it
flexible
but
still
configurable
enough
for
the
end
user's
use.
A
To
recap:
I'm
going
to
create
an
issue
on
adding
a
configuration
for
release,
notes
in
the
aml
file
to
support
our
idea
of
emulating
the
deploy
phrases.
Pattern
question
about
settings:
do
we
want
to
add
like
a
release,
settings
option
in
the
side
panel
because
we
have
deployed
freezes
we'll
have
this?
How
to
where
do
we
just
expand
the
existing
settings.
B
C
Now,
I'm
just
looking
here
how
it
is
right
now,
so
it's
the
same
at
the
group
level.
I'll
say
if
we
make
a
change
in
the
project
level
may
be
interesting
to
do
the
same
at
the
group
so
that
people
know
where
to
configure
it
right.
The
same
way
to
me,
it's
interesting
to
have
the
the
release
is
a
section
there
in
the
settings
since
we're
expanding
it,
but
just
so
yeah
that
would
go
with
the
one
direction
in
both
levels.
B
A
A
I
know
that
the
operations
team
is
exploring
adding
releases
as
its
own
side
panel
option.
How
exciting
is
that
and
then
maybe
that's
where
we
can
add
settings
under
the
releases
side
panel
option
and
go
from
there.
C
B
I
know
we
had
talked
about
too
someday
doing
like
if
we
did
add
some
filtering
and
searching
to
that
releases.
Page
we'd
have
a
default
search
or
default
filters,
so
that
could
go
there
too.
A
Yeah
you're
right,
you're,
totally
right.
That
makes
a
lot
of
sense.
Okay,
I
like
that.
The
other
issue
that
I
think
we
need
that
I
need
to
create
is
about
adding
this
to
the
settings
option
in
the
front.
End:
okay
and
then,
of
course,
building
out
the
apis
to
configure
it
right.
B
Are
you
talking
about
the
change
log
release,
change
log,
yeah.
A
B
A
I
can
too,
and
I've
been
playing
with
like
how
other
companies
have
thought
about
this,
and
everyone's
super
lazy,
like
they
all,
are
relying
on
changelog
or
they're,
pushing
it
to
the
end
user.
So
I
feel
like
this
is
a
real
problem
that,
if
we
solve
like,
we
could
be
super
compelling
for
people
who
are
orchestrating
across
hundreds
of
projects.
Right
now,
you
know
it'll
be
great.
A
Release
notes
just
can't
take
it
awesome.
Well
I'll,
give
you
back
some
time
unless,
if
there's
any
other
topics
you
want
to
talk
about,
I
can
stop
the
recording
and
we
can
use
this
time
for
something
else.