►
Description
AsyncAPI Conference 2021 - Day 1
16th November 2021
Learn what are the contribution guidelines to add changes to the AsyncAPI specification. What stages are there? What is it all about with this philosophy to update tools too? Let's have a look at recent AsyncAPI spec contributions and how the process looked like.
A
A
A
I
mean
we're,
not
we're
not
trying
to
convince
everyone
that
we're
smart
here
and
we
know
everything
that
happens
in
the
even
driven
world.
Of
course,
I
have
some
experience
like
fran
has
his
experience
from
the
past
work
with
different
patterns
and
different
protocols,
but
in
even
driven
architectures.
The
amount
of
protocols
is
tremendous.
A
We
don't
and
that's
why
we
need
you
to
contribute.
We
need
you
to
bring
your
request
for
changes
to
show
your
use
cases,
to
explain
how
you
use
the
tool
in
production
and
how
the
specs
should
be
improved,
because
you
can't
do
everything
with
the
asking
api
specification
at
the
moment
or
there's
something
broken
in
the
specification.
A
A
A
A
So
sometimes
we
drive
topics,
but
most
cases
will
like
more
views.
We're
just
gonna
give
you
different
options.
We're
gonna,
advise
you
like
what
you
can
do
here.
What
what
is
the
what's
gonna
happen?
If
you
take
the
red
pill
and
and
what's
going
to
happen
with
the
other
one,
how
it
is
going
to
affect
others,
and
it's
how
it's
going
to
affect
you
and
other
tools
as
well,
we
might
help
choose
the
right
doors.
A
A
A
A
A
A
A
Okay,
so
let's
talk
about
a
a
contribution
guide
in
theory,
everyone
likes
theory
right
so
go
grab
your
coffee
and
I'm
gonna
finish
in
a
few
minutes.
So
principles
like
we
have
some
basic
principles
in
the
in
the
contribution
guide.
So
first
one
is
like
favor,
no
change.
So
basically,
it's
pretty
on
you
like
it's
on
you
to
prove
that
you
add
value
to
the
spec,
because
we
always
will
have
an
approach
like
if
you
can
do
something
with
this
spec
at
the
moment
different
way.
A
But
it's
it
can
solve
your
use
case.
Then
we're
always
going
to
favor
the
old
solution.
We
will
always
favor
as
well
as
simplicity,
over
expressiveness
consistency
in
the
in
the
spec.
So
if
there's
some
part
of
the
spec,
that
has
some
different
solution
for
a
problem,
some
specific
solution
for
a
problem-
and
we
want
to
improve
something
in
another
section
of
the
spec.
We
will
try
to
to
map
the
same
approach
to
make
it
as
less
confusing
for
spec
users
as
possible.
A
So
we
will
always
push
this
on
pull
requests.
We'll
always
push
also
to
to
ask
you
to
consider
like
make
the
solution,
like
even
the
simple
implementation
open
for
extensibility,
like
that.
We
want
to
that
whatever
you
add
something
it
can
be
easily
extended
and
not
that
we
want
to
improve
it
next
release
and
it's
going
to
cause
breaking
change
understandability,
which
basically
means
remember
the
spec
file,
it's
markdown
file
written
as
a
block
of
text
for
humans,
so
we
need
to
always
be
super
clear
as
much
as
possible.
A
A
A
We
need
you
in
the
project.
We
need
your
involvement,
you
need
to
share
the
use
cases
and
you,
as
a
person
that
contributes
always
have
to
also
research
other
use
cases,
to
see
how
others
will
will
do
it
and
we're
here
to
help
we
we
want
to
also
have
a
good
database
of
use
cases,
so
that's
principle
that
you
have
to
follow
when
you
contribute,
but
yeah
we're
gonna
help
as
much
as
possible.
A
Now
in
the
contribution
guide,
we
have
a
something
like
request
for
change
or
champions.
So
some
details,
when
you
contribute
request
for
change,
is
just
an
issue
or
pull
request.
We
have
templates
for
it
just
keep
in
mind
that
we
favor
pull
request
more.
Even
though
it's
strange,
but
basically
if
you
already
have
an
idea
how
to
solve
something
like
your
request
for
change,
is
not
just
giving
us
a
a
heads
up
like
saying
like
something
is
wrong
for
a
given
use
case.
A
But
if
you
already
have
you
know
it's
something
is
wrong
and
I
know
how
to
fix
it.
Then.
Please
open
up
er,
show
in
the
spec
how
it's
gonna
change
because
of
your
proposal.
It's
much
easier
to
interact
and
review
this
way,
make
sure
you're
always
doing
what's
required
by
the
contribution
guide.
Of
course,
we
as
a
committers,
we
have
to
look
into
contribution
guide
and
make
sure
that
every
request
for
change
follows,
but
the
more
pull
requests
we
get.
A
The
more
requests
for
change
and
we're
gonna
be
slowing
down
so
high
quality
is
is
a
key
here.
If
you
take
about
the
quality
care
about
the
quality
of
the
request
for
change
as
much
as
possible,
it's
gonna
speed
up
things,
yeah,
there's
a
champion
so
called
a
person
that
drives
the
topic
to
to
get
it
into
a
stage
that
gets
it
into
the
spec
and
releases.
A
To
do
it
and
don't
don't
be,
don't
feel
sad
that
you
come
in,
make
a
request
for
change,
but
you
say
you
can't
drive
it
forward.
We
still
care
about
your
request
for
change
and
others
might
too.
There
might
be
people
that
want
to
become
committers
in
the
spec.
They
want
to
help.
They
just
don't
have
ideas
how
to
how
even
use
case
could
be
improved.
But
if
you
have
some
idea
like
you,
have
some
requests
for
change.
Just
do
it
like.
A
A
So
there
are
different
stages.
When
you
contribute
to
the
spec,
my
favorite
one
is
strowman
yeah,
it's
that's
how
it
basically
looks
like
we
have
a
new
new
proposal,
a
new
request
for
change
actually
and
yeah.
We
try
to
understand,
what's
the
use
case,
asking
some
follow-up
questions
asking
for
examples
asking
for
more
justification
for
a
given
change.
A
There
is
a
stage
that
is
described
as
rejected,
but
we've
never
used
it.
So
I'm
not
gonna
talk
about
it
more.
You
just
remember
that,
like
it's
all
about
collaboration
and
rejection
only
comes
in
if
there's
a
collaboration
only
from
one
side
of
the
of
the
table.
So
if
they
there's
no
champion-
and
nobody
reacts
to
follow-ups
questions
from
for
the
release
request
for
change-
that's
something
that
will
most
probably
get
rejected.
A
But
yeah
theory-
I
hope
you
already
came
back
with
your
coffee,
because
now
we're
gonna
talk
about
a
real
life
so
again
in
real
life.
It
really
takes
time,
for
example,
that's
that
proposal
from
from
gerald,
so
gerald
decided
to
champion
a
request
for
change
to
to
get
some
solution
into
the
spec.
That
can
solve
a
a
problem
that
like
before
to
the
to
release.
A
You
could
only
describe
your
application
with
servers
that
all
had
to
implement
the
same
protocol,
because
there
was
no
way
to
wire
to
connect
channels
with
a
specific
server.
Only
and
many
people
asked
many
people
knew
it
has
to
be
improved,
but
then
gerald
jumped
in
and
proposed
to
make
things
better.
A
A
Now
some
stages
can
be
skipped
like
we
have
some
stages
described
in
the
in
the
contribution
guide.
But
it's
a
theory
that
sets
some
kind
of
process
but
like
in
this
case,
if
like
gerald,
was
super
motivated
and
worked
hard
on
the
proposal
and
was
so
advanced
on
a
proposal
level
stage
that
it
was
okay
to
jump
directly
to
to
accept
it.
There
was
no
need
for
changing
the
labels
in
github,
because
how
engaged
we
or
where
here.
A
It
is
hard
to
engage
community
getting
a
use
case
and
getting
comments
from
community
is
on
your
side,
but
we're
going
to
help
you,
as
I
said,
we're
facilitating.
So
if
there's
a
good
proposal,
we're
happy
to
see
it,
but
we
would
like
to
hear
others
we're
gonna
use
using
api
official
channels
to
promote,
but
also
you
have
to
take
some
actions
like
if
that's
not
enough,
like
in
case
of
marek
and
his
proposal,
come
to
one
of
the
community
meetings
present
your
request
for
change,
get
feedback
from
others
talk
openly
about.
A
A
A
A
We're
automating
a
lot
as
much
as
possible,
but
I
think
the
most
important
for
you
is
that
the
it
is
also
a
collaborative
work
and
anybody
from
the
community
can
engage.
There
is
a
release,
coordination
needed
for
every
release.
Anybody
can
be
a
release
coordinator,
anybody
can
volunteer
and
that's
what
happened
now
so
2002-1
and
2-2
release.
A
So
yeah
I
mean
it
takes
time,
but
just
think
about
others
like
first
of
all,
like
again
this
example
with
gerald
like
you're
fixing
your
use
case,
but
it's
not
just
your
use
case
you're,
helping
many
different
community
members,
so
be
one
of
the
brave
ones.
Take
things
forward
and
help
us
out.
Thank
you.