►
From YouTube: CDF - SIG Events Meeting - 2021.08.30
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
A
D
D
Autumn
showed
up
for
us
today,
it's
cool
out
for
the
first
time
in
a
while.
It's
like,
oh,
I
need
a
hoodie
today,
yeah.
A
A
D
And
it
looks
like
new
orleans.
Thank
god,
held
up.
This
was
our
first
test
of
the
the
new
weather
system
that
they
put
in
after
hurricane
katrina,
and
it
looks
like
it
held.
C
D
A
D
And
then
katrina,
it,
the
all
the
levee
system
just
broke.
I
mean
literally.
C
But
they
still
have
a
pretty
big
rescue,
starting
now
that
it's
daylight.
D
But
we
don't
have,
they
don't
have
the
kind
of
flooding
it's
just
mainly
trees,
roofs.
You
know
normal
things
from
high
winds
and
high
and
lots
of
water.
You
know.
D
D
A
No,
so
let's
kick
off,
as
you
see,
andrea
is
not
here
and
I
I
heard
he's
still
on
paytime
leave,
so
he
will
not
join
us.
I
guess
he
will
come
back
wednesday
first
of
september.
I
guess
okay,
so
that's
why
I'm
here
and
I
haven't
talked
to
him
since
he
left
work
vacation
either.
Okay,
so
my
action
from
last
time
there
is
not
is
not
done.
A
C
Yeah
we
brought
it
up
a
couple
times
and
but
we've
been
kind
of
postponing
until
we
get
everybody
in
the
same
room
to
kind
of
sign
off
on
what
what
we
have
on
the
going
on
in
the
in
that
discussion.
C
So
I
think
that
is
like
one
of
the
next
things
that
we
need
to
get
taken
care
of,
especially
since
we
have
like
kubecon
and
what's
the
other
one
devops
world,
those
those
things
coming
out,
that
we
can
then
say
that
we
have
a
name
and
we
can
reference
things
based
on
that
name.
So.
A
A
A
But
I
would
propose
them
that
we
tried
to
nail
down
that
discussion
on
our
next
c
meeting
in
two
weeks
and
I
hope
that
andrea
will
be
there
as
well
and
we,
I
will
make
sure
that
we
send
out
a
mail
to
the
group,
so
everyone
that
is
interested
at
least
comes
so
they're.
Aware
of
that.
We
will
try
at
this
to
make
a
decision.
Next
on
the
next
sig
meeting.
A
A
A
The
issue
yeah
sounds
good,
but
until
then
I
guess
we
should
continue
the
discussion
in
the
github
discussion
that
exists.
So
there
is
a
discussion
for
it
and
yeah.
There
hasn't
been
too
much
activity
in
this
one,
but
anyone
you
guys
here
or
if
anyone's
watching
the
recording.
Please
go
there
and
involve
yourself
yeah.
A
As
well,
oh.
A
A
D
Have
that
I
have,
I
have
really
noodled
on
this
quite
a
bit
in
my
head,
like
I
finally
woke
up
in
the
morning,
and
I
realized
the
name
that
I
liked
the
best
for
the
listener.
A
D
D
D
It's
simple,
it
gets
to
the
point.
Everybody
will
understand
what
it
is.
So
I
think
that
is
the
cleanest
and
easiest
one
now
for
the
listener
and
for
the
project
itself
for
building
out
the
listener.
That
was
the
one
that
I
tried
to
think.
I
thought
on
the
most
I
went
through
words
like
kinetic
something
that's
in
perpetual
motion.
D
I
thought
about
all
all
kinds
of
different
ways
to
represent
something
other
than
continuous,
like
kinetic
delivery,
and
what
I
realized
is
that
this
is
a
complicated
subject
and
people
are
struggling
with
really
understanding
it
in
the
first
place
are
used
to
doing
you
know
kind
of
imperative,
scripted
cd
pipelines,
so
we
need
to
make
it
friendly
and
we
need
to
make
it
feel
easy
and
we
need
to
create.
D
So
I
thought
we
should
name
our
robot
and
our
robot
is
our
listener
and
the
name
I
came
up
with
is
evie
and
we
could
spell
it
out
as
a
name
evie
or
we
could
just
use
evie
and
that
you
know
kind
of
talks
about
events,
because
that's
really
what
that,
where
it
came
from
and
the
I
would
make
the
logo
and
the
brand
as
simple
as
possible,
and
I
would
put
the
brand
the
the
logo.
D
So
evie
could
be
a
a
girl,
and
I
like
the
idea
of
using
a
girl
as
the
image,
because
it
does
fit
into
the
efforts
that
we're
trying
to
do
on
the
diversity
side
listening
to
headphones,
and
it
could
be
as
easy
as
just
a
round
face
with
two
closed
eyes
and
a
ponytail
and
she's
got
headphones
on
because
she
is
really
evie
is
really
our
listener.
D
Evie
itself
is
not
an
event,
it's
a
listener,
and
so
that
is
what
I
came
up
with
in
the
time
that
I
took
in
looking
at
words
and
looking
at
synonyms
and
looking
at
all
the
things
that
people
had
put
out
there
to
try
to
think
about
how
we
could
represent
it,
and
I
tried
to
make
it
as
approachable
and
as
simple
and
as
easy
as
possible,
where
I
could
imagine
people
sitting
in
a
room
and
talking
about
you
know
the
eevee
listener.
D
Have
you
integrated
into
evie
and
I
felt
like
it
was
the
that
was
the
best.
I
could
do
and
I
kind
of
liked
it-
I
actually
felt
when
I
started
thinking
about
it
and
I
really
thought
about
it
for
a
while
before
I
brought
it
up,
I
thought
it
could
be
a
really
really
fun
way
of
representing
the
listener.
A
And
you
can
you
can
exchange
your
whatever
great,
so
I
think
it's
good
to
have
it
noted
what
you
mother
said.
Otherwise,
of
course,
people
should
look
into
this
video
to
understand
the
the
description.
Finally
yeah
discussion,
if
you,
if
you
could,
that
would
be
great.
A
D
D
It's
hard
it's
hard
to
come
up
with
a
approachable
kind
of
name
for
a
project
like
that
believe
me.
I
it
took
forever
when
we
did
artillious
we.
I
worked
on
it
quite
some
time
to
come
up
with
that.
The
other
problem
with
this
stuff
is
that
so
much
is
already
taken,
so
we
have
to
have
a
github
repository
that
it's
not
the
names
not
used
and
some
of
the
more
cool
kind
of
technical
names
like
like
you
know.
D
D
So
I'll
put
I'll
write
it
I'll
I'll,
put
it
out
on
the
discussions
now
that
I've
talked
about
it
and
give
some
ideas
of
what
that.
What
that
brand
could
look
like.
A
A
A
A
C
It
there,
I
think,
the
way
we
need
to
like.
Basically,
I
think
we
need
to
separate
out
the
overall
protocol.
Like
you
know,
cd
events,
I
think
is
from
the
protocol
standpoint
makes
sense
and
then,
when
we
get
into,
you
know
how
it
works.
That's
where
we
get
into
having
like
evie
in
place.
A
Yeah
I
mean:
there's
it's
not
just
the
listener.
We
need
either.
We
need
some
kind
of
when
we
need
sdks
probably
to
send
these
events,
so
we
need
maybe
some
helper
tools
to
send
them,
even
maybe
a
standalone
microservice
or
something
to
send
the
events
as
well
yeah.
So
there
could
be
more
tools
or
more
robots
in
this
robot
family
or
whatever.
C
Right
great,
I
know
on
the
artillia
side,
one
of
the
ada,
I
believe
it
was
adam
gardner
from
the
captain
project-
is
asking
us
around
events
for
deployments
and
deployment
completion
so
on
the
ortus
project,
we're
starting
those
discussions
to
get
the
requirements.
C
C
The
one
question
that
came
up-
and
I
can't
remember
how
this
was
being
handled-
I'm
still
trying
to
get
the
requirements-
is
how
are
events
secured.
So
let
me
give
you
example.
C
Say
you
do
a
a
get
you
do.
A
pr
merge
on
a
private
repo
and
that's
going
to
you
know,
send
out
an
event.
How
is
the
authentication
handled
so
only
certain
people
can
see
that
event
or
you
know,
or
get
notified
of
that
event.
So
that
was
one
thing
that
we
are
looking
at
to
understand.
C
Is
you
know
you
don't
want
anybody
to
deploy
an
application
to
production,
so
there
has
to
be
some
sort
of
security
around
the
events
when
you
go
to
to
listen
and
ascend
them.
So
that
was
one
thing
that
we
that
came
up
in
our
discussions,
that
we
have
to
understand.
A
I
guess
I
could
have
two
comments,
though,
when
it
comes
to
the
point
of
production,
I
guess
the
access
to
the
actual
image
repository
would
guard
you
from
deploying
things
that
you
should
not
be
able
to
deploy
as
well.
Now
you
could,
of
course,
have
like
branches
in
your
image
repository,
maybe
that
have
different
accesses
and
you
can
have
like
a
staging
area
and
a
production
area
that
is
okay
to
download
or
whatever
for
more
more
people.
Maybe
maybe
that's
one
way
to
tackle
that
problem
and
regarding
who
should
list?
A
You
should
be
able
to
listen
to
what
I
guess
you
who
are
sending
an
event
you
should
decide
buy
some
I
mean
we
should
probably
standardize
on
some.
I
don't
know
routing
key
or
something
for
the
message
envelope
or
such,
which
would
help
like
message
brokers
to
see.
Should
we
propagate
these
kinds
of
events
or
not
to
the
to
the
the
next
more
central
domain
or
whatever?
A
I
guess
we
will
have
like
islands
of
internal
domains
where
events
are
sent
and
then
some
more
as
official
events
or
public
events
should
leak
between
those
those
domains,
but
maybe
not
all
of
them.
So
there
we
could
maybe
have
some
kind
of
private
event
handling
handle.
If
you
would
use
a
message,
bus,
like
a
rabbit
mc,
you
could
have
set
it
up
with
routing
keys,
probably
to
see
what
kind
of
events
should
be
federated
out
from
my
this
internal
domain
to
the
outside
world,
or
something
like
that.
A
So
I
think
that
there
are
ways
to
tackle
it.
We
use
in
ericsson,
we
use
events
a
lot
and
we
we
don't
have
these
security
limitations
between
the
organizations
in
ericsson.
So
so
we
don't
really
restrict
the
federations
at
least
not
that
much
yet
based
on
routing
is,
but
I
see
the
possibility
to
do
it
at
least.
So
that's
that's
one
way
to
do
it.
D
Oh
our
health,
like
the
last
four
minutes,
we
it
kicked
us
out.
As
you
know,
I.
C
D
C
That
was
the
only
thing
I
wanted
to
bring
up
was
that
the
artelias
project
is,
has
some
requirements
gathering
around
events?
So
look
for
that
in
the
next
couple
weeks.
D
Now,
fine,
you
know
I
was,
I
think
it
might
have
been
our
on
our
side,
our
bandwidth,
because
I
was
uploading
our
earlier
recording.
So
I
think
it's
done
now.
A
C
I
figured
there's
gonna,
be
there's
gonna,
be
some
sort
of
like
you
said,
for
lack
of
a
better
word,
some
sort
of
token,
or
something
that's
going
to
get
passed
around,
that
we
can
use.
That's
not
going
to
expose
user
id
passwords
and
things
like.
A
That
so
we
can
deal
with
access
control
to
the
image
repositories
that
way,
for
example,
so
that
just
the
authenticated
or
the
authorized
people
can
access
the
download
and
deploy
certain
images.
B
A
Yep,
okay,
great
so,
let's
go
on.
I
happened
to
listen
to
the
cdf
podcast
the
other
week
or
maybe
some
days
ago
where
shipwright
was
introduced.
I
don't
know
if
you
listen
to
it.
A
D
D
D
D
C
D
A
C
I
don't
know
that
name.
I
think
it's
jason
hall.
D
C
And
it's
it's
basically
a
another
way
to
build
the
container
images,
so
I
think
it's
going
to
be
a
good
fit
and
to
get
their
input,
especially
around
the
build
and
push
area
and
kind
of
this
discussions
that
we
had
last
week.
I
believe
it
was
in
the
vocabulary
meeting
around
repository
events.
You
know
docker
artifact
repository
events,
not
source
events.
A
Yeah
yeah
right.
I
think
I
also
made
a
comment
in
that
vocabulary.
A
Mom
actually
minutes
documents
on
on
this,
and
I
also
heard
that
shipwright
is
actually
using
tecton
to
to
build
certain
things
or
to
run
its
pipelines
right,
and
maybe
we
have
some
kind
of
good
way
forward
there,
as
well
than
to
to
quickly
make
a
poke,
since
we
already
have
tecton
in
the
pock
for
the
events
right.
C
Yeah,
I
think,
there's
other
way
around
where
shipwright
has
created
a
set
of
tasks
for
techton,
so
they
can
fit
in
fit
into
tecton.
That
way,
but
don't.
A
D
D
I
don't
know:
oh
there,
it
is
your
screen.
Oh
I'm
going
to
push
you
off.
E
A
A
D
D
A
D
A
D
Could
look
like-
and
this
is
easily
we
could
do
this
easy
in
black
and
white,
and
if
we
did
it
right,
we
could
always
make
her.
You
think
about
like
one
time
we
were
at
github
or
github
universe
and
they
have
their
octa-cat
and
there
was
a
a
place.
You
could
go
and
customize
what
your
octa-cat
look
like.
D
D
These
kinds
of
kind
of
human
logos
I.
A
D
E
A
A
I
saw
that
it
was
discussed
on
web
hooks
versus
event,
sending
from
the
sm
systems
or
other
repository
managers
and
such.
C
Right,
the
discussions
around
more
specifically
on
the
artifact
repositories
that
the
artifact
repositories,
depending
on
which
one
that
you're
working
with
they
send
out
their
completions
events
differently
over
different
protocols.
So
if
you're,
some
of
them
don't
send
them
out
at
all.
C
C
Basically
the
decision
was
made
to
we'll
need
to
have
some
sort
of
plug-in
or
something
to
a
like
docker
hub,
for
example,
and
then,
when
we
have
that
that
plug-in
into
docker
hub
that
the
consensus
was
that
when
we
get
a
an
event
from
docker
hub,
whether
it's
a
web
hook
or
a
grcp
that
that
would
be
transformed,
we'd
have
a
transformer
that
would
then
transform
it
into
a
cloud
event.
C
And
then
from
there.
The
cloud
event
would
be
sent
out
to
everybody
else.
So
it
was
a
a
proxy
type
of
a
proxy
with
the
transform.
As
part
of
the
process.
A
Yeah,
if
I
should
only
provide
my
five
cents
on
that
discussion,
I
think
that
I
mean
we
have
had
similar
discussions
for
our
events
in
erickson
as
well.
A
I
mean
who
should
send
the
event
and
who
should
actually
who
should
be
the
the
source,
so
the
the
transmitter
of
any
event
and
one
general
rule
of
thumb
that
we
have
come
to
is
that
the
instance
that
actually
performs
the
operation
that
the
event
is
about
should
also
as
long
as
it's
decent
and
possible
should
also
send
the
event,
which
means
that
if
a
builder
tool
builds
an
artifact,
then
the
builder
tool
should
send
the
event
saying
now.
A
So
that's
maybe
just
one
concern
about
that,
but
I
I
agree
that
it
might
not
be
suitable
for,
like
global
deployments
to
have
each
such
repository
send
events
on
some
kind
of
global
message:
bus
for
these
kinds
of
events,
so
maybe
that
that
idea
doesn't
really
hold
when
we
come
to
the
global
scale
that
we
do
here.
C
Yeah,
that's
part
of
the
the
question
that
was
raised
if,
let's
say
for
docker
hub
that
you
have
your
your
project,
that
your
that's
been
uploaded
to
docker
hub
as
the
owner
of
that
project.
Of
that
that
project
do
you
want
to
really
be
managing
everybody
that
wants
to
listen
to
that
upload?
You
know.
So
there
has
to
be
another
way
to
deal
with
a
global
scale
of
setting
up
how
you
register
to
listen.
A
Yeah
and
then
the
idea
there
would
be
then
that
the
docker
hub
would
have
its
own
message,
bus
message,
domain
or
whatever
we
would
call
it,
and
it
would
send
well
as
all
its
upload
events
to
that
domain
and
then
whoever
is
interested
could
subscribe
to
messages
from
that
domain
somehow
or
should
have
federation
set
up
to
its
own.
I
don't
know
message
broker
of
some
kind,
yeah.
C
I
mean
yeah
and
that
and
that's
kind
of
like
where
the
the
proxy
idea
came
into
play
and
also
the
the
proxy
with
the
transform
came
into
play,
where
you
don't
have
the
originating
tool
emitting
cloud
events,
yet
that
we
know,
because
we
came
up
with
a
list
of
probably
about
25
different
tools,
just
within
15
minutes
that
we
know
that
we'd
have
to
be
interacting
with
and
a
lot
of
those
have
web
hooks,
but
not
all
of
them.
You
know.
A
A
Yeah,
yeah,
and
but
anyway,
as
close
as
possible
to
the
source,
then,
and
and
also
the,
I
think
the
idea
is
that
the
events
should
be
should
have
a
time
stamp
on
them
when
that
should
be
as
close
to
the
original
timestamp
when
the
actual
event
occurred
in
the
system
as
possible,
yeah
as
well,
so
that
you
can
more
or
less
rely
on
the
timestamp
for
the
event
saying
that
this
was
uploaded
at
blah,
blah
blah
blah
that
time.
Yeah.
C
A
C
If
you
think
about
let's
say
we
take
an
example
like
the
alpine
base
image
for
docker,
there
are
so
many
there
are
hundreds
of
thousands
of
people
that
are
consuming
the
alpine
base
image
that
may
want
to
listen
to
to
get
notified
that
the
base
image
has
a
security
fix
in
it
that
somebody
just
rebuilt
the
base
the
base
alpine
image,
and
because
of
that,
I
should
then
trigger
my
pipeline
to
go
consume
the
new
version
of
that
image.
C
As
part
of
my
my
my
ci
pipeline,
exactly
yeah,
you
know
so
there's
there's
that
you
know.
That's
that's
going
to
be
hundreds
of
thousands.
If
not
millions
of
people
list
you
know,
has
the
potential
to
listen
for
a
new
alpine
update.
A
Yeah
yeah
absolutely
and
that's
more
when
we
come
to
like
deployment
and
the
infrastructure
of
this
event
system
more
or
less
the
ecosystem
around
these
events
is
not
really
related
to
the
event
protocol
itself.
C
It'll,
I
think,
they're
going
to
play
hand
in
hand.
You
know
there's
going
to
be
like
I
said
when
you
get
into
kind
of
like
what
we're
getting
into
is
when
you
look
at
the
security
around
that
you
know,
if
you
have
a
restricted
repository
that
you
want
to
make
sure
that
you,
you
know
the,
and
this
is
where
I'm
not
sure
if,
if
the
event
gets
sent
out
anyways
and
you
still
have
to
validate,
you
know
authenticate
with.
C
If
you
want
to
get
information
about
the
the
event
or
how
we
handle
that,
but
that's
going
to
come
into
play
when
we
talk
about
it
as
part
of
the
scaling
problem
as
well.
A
Yeah
yeah,
and,
of
course,
if,
if
a
repository
manager
would
need
to
send
rest
rest
calls
or
perform
rest
calls
to
the
multitude
of
of
receivers,
it
would
also
need
to
store
or
handle
the
credentials
to
be
able
to
send
or
to
be
able
to
create
those
rest
calls,
because
most
probably
many
of
those
receivers
will
require
authentication
as
well.
So
there
we
need
to
be
some
ticket
handling
or
token
handling
there
as
well.
C
Exactly
and
if
you
have
you
know
like
docker
hub
trying
to
send
to
a
listener
in
a
private
network
how's
that
going
to
you
know,
you
know
from
that
that
standpoint,
so
I
have
a
feeling
that
we're
going
to
be
looking
at
more
of
a
polling
method
which
isn't
optimal
but
or
something
that
way.
So
you
can.
You
don't
have
to
have
you
know
inbound
ports,
open
and
firewall
rules
in
place
to
deal
with
inbound
events
coming
in.
C
A
A
Very
interesting
topics,
many
of
these
and
yeah
for
sure
we
will
need
to
discuss
them
further
on.
C
C
You
know
it
kind
of
has
to
be
self-managed
where
you
can
go
subscribe,
but
at
the
same
time
you
know
if
you
have
a
100
000
people
subscribing
to
an
alpine
update.
You
know:
how
do
you
manage
that
persistence
of
keeping
track
of
who
to
who's
interested?
In
this
event,.
C
C
C
C
A
E
A
C
And
I
think
overall,
the
project
gives
us
the
most
flexibility
to
start
with
and
if
we
need
to
kind
of
push
out
of
the
project,
a
a
specification
that
we
would
go
and
you
know
go
into
the
formal
process
you
know
like
spdx
did
I
mean
spdx
has
been
working
on
their
their
specification
for
10
years.
So
I
think
we
should
start
with
a
a
project
initially.
A
No,
at
least
not
if
cloud
events
is
not
a
standard.
We
can't
really
standardize
on
proper
cloud
events.
If
yeah
yeah,
I
guess
yeah
yeah,
then
there
was
something
that
should
be
brought
to
this
meeting.
I
just
copy
the
texture.
More
big
players
involved
is
shipwright
considered
a
big
player,
maybe
not
but
red
hat.
D
Not
it's,
you
know
it's
it's
it's
a
fairly
decent
sized
project
within
red
hat.
I
believe
I
think
that.
Well
I
mean
it's.
This
is
a
thing
for
the
cd
foundation.
They
we
haven't.
Ortilius
was
the
first
open
source
project
that
they
brought
in.
That
was
outside
of
the
realm
of
an
orchestration
tool,
so
I
think
we
should
give
them
as
much
love
as
possible,
actually
because
I
think
that
they
will
be,
you
know,
certainly
if
they
build
some
events
for
building
containers.
A
C
Oh,
that
was
tracy
miranda.
D
A
D
Yes,
that
was
god,
what
is
her
name.
C
So
I
would
say
that
we
get
the
naming
figured
out.
We
get
the
once
we
have
the
naming
figured
out,
then
we
can
go
and
get
the
organization.
C
You
know
the
github
organization
created
get
some
of
the
repos
kind
of
moved
around
and
then
the
next
step
would
be
to,
and
I've
told
the
the
cdf
toc
about
the
events
wanting
to
become
a
project
of
some
sort
or
specification
and
they're
all
on
board
with
that.
So
I
think
we
just
need,
I
think,
we're
a
little
early.
C
C
C
I
don't
think
I
and
I
don't
think
we're
that
far
off
you
know
maybe
a
month,
maybe
you
know
a
couple
meetings
and
then
I
think
we'll
be
pretty
close
to
being
where
we
want
to
be
to
then
have
the
cd
foundation,
and
you
know
the
whole
kubecon
piece
announcing
that
you
know.
So.
I
think
we
should
target
a
bunch
of
stuff
before
cubecon.
A
I
agree
so
that
moves
us,
I
guess,
on
to
the
conference's
meetups
item
in
the
agenda,
where
I
just
pasted
that
we
have
a
slot
on
cubecon
for
the
events,
booth
or
a
cdf
version.
I
don't
have
more
information
about
that.
I
guess
you
might
have
more
tracy
on
it
or
how
does
that
work?
I.
D
Don't
all
I
know
is
right
now
is
that
we
have
it's.
I
grabbed
a
time
slot.
It
was
like,
as
the
earliest
time
slot
I
could
get
and
I
sent
in
names
and
those
of
us
who
are
going
to
be
on
that
should
get
some
kind
of
an
invite.
A
D
A
A
D
Why
can
you
know?
Is
it
a
time
problem
or.
A
D
For
kubecon,
I
don't
think
I've
seen
an
agenda
quite
yet
I
know.
Well,
I
have
I
got
one
talk
accepted
for
get
ups
khan.
I
didn't
get
anything
accepted
for
cube
con
and
I
haven't
seen
an
official
agenda
published
yet,
but
maybe
they
do
have.
A
One,
but
it
is
a
schedule,
it
seems
so
we
have
the
cicada
track.
It
seems
here
with
the
aha.
Andrea,
is
getting
giving
a
talk,
yeah
right,
hi,.
A
A
A
D
Would
be
the
highest
like
the
cd
events
and
then
the
a
project
would
be
like
evie.
C
Yeah
and
then
we
in
that
you
could
have
like
a
repo
for
the
protocol
standard
which
would
be
you
know
we
could
do
a
markdown,
a
hugo
markdown,
so
we
can
actually
publish
kind
of
like
documentation
that
way.
That's
what
we
did
with
our
ortelius
was
all
of
our
documentation
is
markdown.
C
That's
focused
around
the
hugo
server,
so
you
end
up
building
your
website
and
your
documentation
that
way,
so
you
still
have
your
whole
pr
process
to
do
updates
to
documentation,
but
it
makes
it
easier
than
trying
to
do
like
a
shared
google
doc
or
something
like
that
or
a
github
wiki,
those
type
of
things
we
we
found.
It
was
just
easier
to
go
that
route,
but
that's
that's
what
I
would
recommend
that
we
would
have
those
type
of
things.
A
F
A
Of
course
the
listener
will
be
there,
but
there
will
also
probably
be
like
maybe
some
kind
of
protocol
tools
or,
of
course,
maybe
a
sender
or
sdks
for
sending
these
events
or
different
kinds
of
maybe
persistent,
store,
plugins
or
whatever
that
are
needed.
C
Exactly
exactly,
and
then
we'll
probably
want
to
do-
and
I
don't
know
if
this
is,
if
we'd
want
to
do
some
sort
of
like
swagger,
where
you
could
do
you
know
your
your
your
definition
of
the
the
json
payload
and
then
you
could
have
a
way
to
try
it.
You
know
that
type
of
documentation
around
there.
A
D
A
A
D
Okay-
and
I
put
my
my
my
thoughts
in
the
disc
in
the
discussion
thread.
D
D
I
just
you
know
what
I
did.
I
pulled
this
off
of
istock
and
I
just
looked
for
something
to
prototype
it
from
we
would
have
to
have
some
we'd
have,
but
we
have
to
have
something.
That's
simple
and
kind
of
looks
like
you
know,
other
women
that
we
know
in
technology
right.