►
Description
AsyncAPI Conference 2021 - Day 1
16th November 2021
AsyncAPI is an open-source project that seeks to promote and facilitate the development of asynchronous APIs and event-driven architecture (EDA). The goal of AsyncAPI is to make building EDAs as simple as building REST APIs. In this talk, I'll explain our project, the contribution guide, the Diátaxis method for classifying technical content, and how to contribute to our Dev Docs.
A
Hi
everyone,
my
name,
is
alejandra
and
a
lot
of
you
know
me
online
as
alejandra
kitsali,
I'm
here
today
at
the
async
api
conference,
and
I'm
super
excited
to
be
here
with
you
all
today.
So
thank
you
for
having
me
and
thank
you
for
your
time.
So
you've
lasted
a
whole
day
of
the
first
very
day
here
at
the
conference
of
the
contributor
summit
and
my
talk
got
scheduled
to
the
end
of
the
day.
A
So,
if
you're
still
watching
kudos
to
you,
I'm
glad
you're,
still
awake
and
I'm
going
to
do
my
very
best
to
make
this
presentation
fun
and
interesting
and
educative
and
useful
for
all
of
you
watching,
of
course.
So
I
do
have
a
powerpoint
deck
to
show
you
all
and
we're
going
to
talk
about
how
to
contribute
to
a
sync
api
developer
documentation.
A
Some
of
you
have
probably
already
visited
our
docs
and
that's
awesome.
If
you
have,
if
you
haven't,
if
you've
never
even
visited
our
documentation,
don't
worry
about
it.
There's
plenty
of
time
to
do
that.
If
you've
already
visited-
and
you
think
hey-
you
know
what
I
am
here
today
at
your
talk
alejandra,
because
today
I
want
to
get
started
as
a
contributor.
I
want
to
start
contributing
to
all
of
the
docs.
Well,
if
that's
why
you
came
today,
I'm
excited
I'm
so
happy
you're
here
and
I'm
ready
for
you.
A
So
let's
go
ahead
and
get
started
and
tell
you
a
little
bit
more
about
who
I
am
what
the
documentation
looks
like
today
for
a
sync
api
and
we're
just
gonna
get
right
to
it
all
right.
Let's
get
started
all
right
cool,
so
the
first
thing
I
need
to
do
is
actually
screen
share.
So
let's
go
ahead
and
get
started
on
that
and,
as
we
just
mentioned
today,
we're
talking
about
how
to
contribute
to
async
api
docs,
and
I
wanted
you
to
enjoy
our
beautiful
little
logo
there.
A
I
know
I
like
the
animation:
let's
go
ahead
on
to
the
next
slide,
alright
cool,
so
you
may
or
may
not
have
noticed
and
seen
this
picture
of
me
before
on
social
media.
It's
a
favorite
of
mine
because
it
has
my
service
dog
with
me,
canela
and
so
she's
actually
really
happy
in
real
life.
Just
like
you
see
in
that
picture
anyway.
A
So
what
do
I
do?
Why
am
I
here
right?
So
I
joined
a
sync
api
here
a
very
short
time
ago.
I'm
so
excited
to
be
working
as
an
open
source
contributor
with
all
of
you,
other
amazing
people
and
what
I
joined
to
do
was
to
work
on
the
docs
and
learning
educational
materials.
A
So
I'm
going
to
go
ahead
and
get
started,
but
you
know
take
a
screenshot
here.
If
you
want
to
throw
me
a
question
and
github
directly,
that's
my
handle
can
ask
me
any
questions
if
you
want
to
spin
up
a
pull
request
and
you're,
adding
some
docs,
maybe
you're,
adding
a
readme
for
documentation
grab
my
github
handle
and
tag
me
into
your
pull
request,
and
I
will
be
there
ready
to
help
you
out
with
your
open
source
contribution
for
the
docs.
A
If
you
have
any
other
questions
that
you
want
to
send
my
way,
my
dms,
you
know
are
always
open
on
twitter
and
on
linkedin,
so
you
can
send
me
any
questions
you
got
and
if
I
don't
know
the
answer
to
something
which
I
probably
may
not
know,
because
I
don't
know
everything
and
I'm
new
to
the
team,
I
can
find
someone
that
knows
the
answer
or
I
can
help
you
get
started
on
our
slack
channel,
asking
questions
and
help
find
someone
that
can
help
you
out.
So
all
right.
A
So,
first
of
all
in
case
you
didn't
know-
I
do
want
to
let
you
know
this
exciting
news
that
actually
earlier
this
very
same
year,
the
async
api
initiative
was
actually
moved
under
the
linux
foundation,
which
is
super
exciting,
because
this
can
help
maintain
and
guarantee
the
neutrality
of
the
initiative,
which
is
completely
important
and
open
source.
Correct.
So
thank
you,
linux
foundation
and
it's
really
exciting.
A
This
is
like
a
new
area
of
growth,
a
new
stage
right,
so
in
this
talk
for
today,
I'm
not
actually
going
to
do
a
deep
dive
on
the
spec
of
our
api
itself,
because
I
know
that
a
lot
of
the
earlier
talks
we
had
today
in
our
contributor
summits
track
already
covered
that,
and
we
have
other
talks
and
a
piano
later.
A
Where
we're
going
to
talk
about
what's
coming
up
in
the
future
and
what
spec
changes
can
we
expect
to
see
for
the
next
version
of
3.00
and
fran
our
director
and
the
founder
of
this
spec
is
actually
going
to
be
in
a
broke
out
breakout
panel
session,
for
that
so
keep
your
eyes
peeled
for
that,
and
so
because
I
already
knew
that
we
had
a
lot
of
other
sessions
that
were
covering
introduction
to
the
async
api
spec
and
how
to
start
your
first
async
api
file
and
how
to
build
your
document
with
a
sake
api.
A
I
I
didn't
want
to
focus
on
that
for
today,
so
for
today,
in
this
talk,
we're
going
to
either
assume
that
you
already
have
a
basic
high
level
introduction
to
the
spec
or
more
or
less
what
the
initiative
does.
Or
you
know
I
will
definitely
be
happy
to
answer
any
questions
later
on.
If
you
think
that
I
missed
something
now.
A
What
I
will
mention
today,
though,
in
our
talk,
is
that
the
async
api
initiative
is
trying
to
make
working
and
creating
with
event-driven
architecture
as
simple,
well
simple
right,
but
as
easy
as
we
work
today
with,
for
example,
http
apis.
Http
rest.
We
want
it
to
be
as
simple
as
that,
and
the
thing
is
when
we're
working
with
event
driven
architecture,
there's
a
lot
of
different
kinds
of
configurations
that
you
might
use.
For
example,
there
are
a
lot
of
different
kinds
of
protocol
information
that
is
allowed.
A
There
are
different
options
when
you're
using
a
sync
api,
for
example,
as
you
see
here
in
my
slide,
kafka
websocket,
mqtt,
amp,
qp,
really
there's
all
kinds
of
protocols
and
if
you've
never
worked
with
a
broker
or
you
don't
really
know
the
difference
between
a
broker
and
a
server
or
their
similarities,
don't
feel
bad
feel
free
to
throw
me
a
question
later
on
and
we'll
be
happy
to
get
back
to
you.
A
Although
it's
you
know
in
the
road
map,
we
might
write
it
ourselves
or
maybe
that'll,
be
something
that
you
help
contribute
with
us.
Who
knows
I'm
welcome
to
any
of
the
above,
but
I'm
just
kind
of
throwing
out
there
that
we
are
really
in
a
way
at
the
beginning
stages
of
this
initiative.
This
initiative
is
only
about
two
years
old
and
in
such
a
young
initiative,
as
you
can
imagine,
even
the
docs
are
still
at
an
early
stage,
there's
so
much
information.
A
So
many
different
kinds
of
things
we
needed
to
document
so
let's
go
ahead
and
move
on,
and
I
kind
of
wanted
to
tell
you
a
little
bit
about
how
the
initiative
has
been
growing.
How
are
people
communicating
with
us
how
big
is
our
community
and
how?
A
What
are
things
that
we're
looking
to
change
so,
for
example,
currently,
as
of
2021,
when
we
checked
the
out
for
today,
we
were,
as
you
can
see,
at
some
pretty
big
stats
for
the
website,
which
we're
really
excited
about
a
hundred
thousand
five
hundred
fifty-seven.
That's
really
exciting.
We
have
150
plus
contributors
in
github
to
date,
and
we
have
a
lot
of
different
repositories,
because
we
have
a
lot
of
different
tools
that
we're
working
on.
It's,
not
just
the
spec.
A
So
when
I
mentioned
the
fact
that
we
have
about
150
plus
contributors,
this
could
be
all
across
it
could
be
for
the
spec.
It
could
be
for
the
tools
it
could
be
for
documents
talks.
You
know
what
have
you
it's
just
overall
in
general,
the
number
of
contributors
that
we've
had
for
async
api
initiative
and
as
I've
been
saying,
if
you
want
to
throw
me
some
questions,
we
do
have
a
slack
channel,
so
we
currently
have
a
thousand
five
hundred
plus
floats
in
our
slack
channel.
A
We
have
a
whole
bunch
of
individualized
slack
channels
for
different
kinds
of
questions
or
different
feedback
or
things
that
the
community
might
need
from
us.
So
if
you
have
questions
from
this
presentation
now,
you
know
that
you
should
join
us
in
slack
as
well.
You
probably
noticed
that
this
slide
is
in
spanish,
at
least
half
of
it,
and
that's
because
I've
actually
been
giving
some
talks
and
for
some
folks
from
latin
america,
and
so
I
think
I
might
have
left
this
slide
in
spanish,
which
is
pretty
hilarious,
but
basically
just
means.
A
The
first
line
is
how
many
unique
visitors
we've
had
for
our
website.
The
second
line
is
contributors
to
github,
and
the
third
line
is
users
in
slack
all
right
cool
now.
The
other
thing
that
I
really
wanted
to
talk
to
you
guys
about
is
that
we
also
have
public
meetings
in
which
we
talk
about
how
to
contribute,
and
we
also
have
individual
meetings
for
folks
who
are
just
interested
in
this
initiative
and
want
to
keep
up
to
date
with
the
latest
changes
and
what
have
we
been
building
for
the
last
month?
A
What
are
we
working
on
for
the
next
couple
of
weeks?
What's
in
our
road
map?
How
far
ahead
we
are
in
our
road
map,
all
those
kind
of
things
we
talk
about
in
our
public
meetings
and
in
fact
you
can
join
those
public
meetings.
They
are
absolutely
open
to
the
public
and
I'll
show
you
at
the
end
of
the
talk,
all
the
different
social
media
links
and
things
that
you'll
need
to
join
us
so
that
you
can
add
our
calendar
and
our
meetings
to
your
calendar
and
you're
welcome
to
join
whenever
you
want.
A
We
have
currently
a
model
of
governance.
That
is
an
open
governance,
because
we
believe
strongly
in
transparency
and
in
openness.
A
So
if
you'd
like
to
hear
more
about
that
or
actually
our
website
has
a
whole
section
where
it
describes
more
about
the
model
of
governance
that
we
chose,
we
also
have
a
blog
post
on
that,
but
you
know
I
don't
want
to
get
too
distracted
from
today's
main
conversation,
which
is
just
contributing
to
the
docs,
but
our
documentation
are
a
part
of
the
initiative
and
if
you
have
questions
that
you
want
to
bring
up
about
the
documentation
in
our
public
meetings,
please
do
that
we'd
love
to
hear
your
questions.
A
If
you
have
questions
about
how
to
improve
transparency
and
openness
in
our
documentation
or
any
questions
about
that,
please
don't
be
shy.
Send
them
our
way
all
right!
So
what's
our
agenda,
we
have
some
cool
stuff
that
we're
going
to
talk
about.
I
want
to
show
you
the
current
state
of
our
documentation.
A
I
want
to
show
you
kind
of
how
we
work
on
having
documentation
also
in
readme
and
individual
repo.
So
I'm
going
to
show
you
how
our
readmes
and
our
docs
look
in
there
as
well,
not
just
our
website
for
the
docs.
Then
I
want
to
walk
you
through
this
amazing
methodology
that
has
completely
changed
my
life,
and
this
is
the
diactixis
method
and
it
basically
teaches
you
how
to
divide
your
engineering,
documentation,
content
into
more
or
less,
are
usually
four
to
five
top
agnostic
content
buckets.
Now
we
don't
want
you
to
feel
limited.
A
You
know
it
doesn't
have
to
be
four
buckets
only,
but
once
we
get
to
that
section
and
I
explained
to
you
how
this
methodology
works
and
how
we
are
going
to
apply
it
to
our,
I
think
api
docs,
I
think,
you'll
understand
where
we're
going
and
how
you
can
help
contribute
with
this
new
idea
that
we're
bringing
forward
to
our
information
architecture
of
the
site.
Now
we
also
want
to
tell
you
about
community
feedback,
because
feedback
isn't
just
about
the
spec
or
the
tools.
We
also
want
feedback
about
the
docs.
A
So
I'm
looking
forward
to
you
the
community
to
send
us
that
feedback,
I'm
going
to
tell
you
about
contributions.
How
do
you
get
started
as
a
contributor
right?
That's
the
whole
point
of
today's
talk:
how
to
get
started
as
a
contributor
for
the
docs,
and
we
will
cover
that
and
I'll
also
show
you
how
you
can
find
our
contribution
guide
because,
of
course,
every
open
source
project
has
a
different
way
in
which
they
like
to
handle
that.
A
A
A
A
There's
a
lot
of
things
there
that
I
actually
want
to
change,
and
one
of
the
main
things
is
even
just
the
fact
that
it's
just
learning
in
the
navigation.
So
I
think
that
we
need
specifically
something
that
says
docs
right.
That
is
really
the
best
practice
to
let
people
know
where
the
docs
are
just
label.
Your
navigation
item
docs.
A
As
far
as
the
user
experience
is
concerned,
it
takes
you
directly
to
what
you're
looking
at
right
here
on
the
screen.
The
url
changes
from
async
api.com,
slash,
docs,
slash
in
this
case
getting
started,
and
then
it
doesn't
really
have
a
home
page
introduction
or
a
landing
page
or
just
a
home
page
to
the
doc
site
that
just
doesn't
exist
currently
right.
It
just
takes
you
boom
straight
into
the
introduction
and
ready
or
not.
A
Here
we
go
right,
so
we
want
to
change
that
up
a
bit
because
a
proper
doc
site
should
have
a
home
page.
That
explains
to
you
what
you
can
expect
to
find
in
this
document's
a
documentation
site,
and
it
should
show
you
the
main
content
buckets
that
we
will
be
targeting
so
that
you
can
then
kind
of
figure
out
what
your
learning
path
is
or
where
you
need
to
go
from
there.
A
That's
definitely
a
much
better
user
experience
and
it'll
be
better
to
navigate
for
people
that
are
new
to
this
api
spec
and
don't
really
know
where
to
get
started
now.
The
other
thing
I
want
you
to
notice
is:
I
want
you
to
see
how,
in
the
right
hand,
navigation
it
says
on
this
page,
and
we
have
one
header
and
it's
showing
select
your
next
chapter.
A
Now,
let's
go
ahead
and
move
along,
and
this
is
actually
a
screenshot
from
the
frame
site.
Sorry,
the
framework
that
I've
been
mentioning
earlier
at
the
taxes-
and
this
is
the
methodology
that
we're
going
to
be
applying
to
our
docs-
and
this
is
a
new
way
that
we
are
going
to
think
about
content
buckets.
And
I
want
you
to
think
about
this
as
agnostic
as
you
can-
and
I
know
that
that's
going
to
be
hard,
I
know,
but
for
today
that's
what
we
got
to
do.
A
Okay,
so,
according
to
this
methodology,
at
a
high
level
for
the
most
part,
all
engineering
documentation
can
be
reclassified
under
four
main
content
buckets.
So,
for
example,
here
we're
looking
at
tutorials,
how-to
guides
reference
and
explanation,
or
some
people
call
it
concepts
or
something
similar.
A
What
do
each
one
of
those
cover?
What
are
they
for?
Reference
is
going
to
be
things
such
as
your
cli
or
your
api
spec
and
your
individual
api
endpoints.
If
your
product
has
a
cli
you're
going
to
document
how
your
cli
works
under
reference
now
explanation
or
concepts,
so
that's
going
to
be
something
more
along
the
lines
of
it's
really
more
words:
engineering,
diagrams
and
lesser
code,
snippets
or
tutorials.
So
this
is
more
to
explain
to
your
audience
specific
terms,
specific
spec
details
and
perhaps
new
features
of
your
product.
A
A
A
A
So
when
you
see
a
tutorial,
I
want
you
to
more
think
about
a
beginner
task
that
somebody
needs
to
do
when
they're
first
getting
acquainted
with
your
product
or
your
api,
your
platform,
whatever
it
is,
that
you're
documenting-
and
it
doesn't
mean
that
this
is
you
know,
for
a
beginner
audience.
That's
not
at
all
what
this
is
about.
It's
not
about
how
advanced
you
are
or
not
as
a
technical
person.
This
is
about
hey.
I've
never
used
this
platform
before
so
teach
me
the
basics
of
your
platform
to
get
started.
A
As
you
can
see,
that
has
nothing
to
do
with
being
a
technical
or
non-technical
person.
That's
just
tutorials
are
learning
oriented
to
get.
You
started
on
the
first
typical
things
you're
going
to
do
in
this
new
product
or
technology
that
you're
documenting.
However,
a
how-to
guide
is
for
documenting,
more
specific,
detailed
use
cases
or
troubleshooting
guides.
What
do
I
mean
by
this?
Well,
let's
say,
for
example,
that
you're
on
boarding
someone
to
a
new
database
if
this
is
a
completely
new
customer
and
they're
new
to
your
database
and
perhaps
due
to
databases
as
well.
A
This
is
really
going
to
be
more
of
a
tutorial
scenario,
so
it
would
really
be
more
like
hey,
I'm
going
to
write
you
a
tutorial
for
how
to
create
your
first
mongodb
database.
Now.
Let's
imagine,
however,
that
you
are
currently
a
user
that
has,
I
don't
know,
perhaps
a
local
site
project
and
in
your
project,
you've
been
using
for
your
database.
A
This
is
a
specific
how-to.
Troubleshooting
guide
of
you
know
that
migrating
data
from
one
database
to
another
is
going
to
involve
a
much
more
detailed
use
case
and,
in
fact,
probably
some
troubleshooting
steps
that
you
want
to
alert
your
customer
to.
So,
as
you
can
see,
this
is
far
beyond
the
scope
of
the
tutorial.
A
So
if
we
go
back-
and
I
show
you
a
quick
screenshot
of
our
current
content
buckets
here-
you
can
remember
perhaps
that
we
have
the
content
buckets
so
far
of
getting
started.
Then
you
can
see
their
tutorials
specification
and
community
and
then
under
community.
It
says,
tooling,
that's
a
little
bit
weird.
A
I
don't
really
think
that
we
need
a
bucket
that
says
community
in
the
docs,
unless
it's
actually
because
we
have
a
whole
section
dedicated
to
showing
how
to
do
community
contributions,
for
example,
but
in
this
case
all
that
content
section
leads
you
to
is
a
huge
list
of
different
tools
that
the
community
has
contributed
for
async
api.
A
So
in
this
scenario
we
won't
really
be
needing
a
content
buckle
bucket
named
community
right.
That
doesn't
really
make
a
lot
of
sense
getting
started.
There
are
a
lot
of
docs
that,
like
having
a
section
called
getting
started,
it's
not
about
limiting
yourself.
You
know
nobody's
saying
that
you
have
to
limit
yourself
to
only
four
content
bucket
ideas
because
of
that
framework
that
we
just
been
discussing
so
far.
A
You
can
definitely
do
it
your
way
and
adapt
the
methodology
to
you
and
your
product
or
your
technology.
A
So
we
need
to
document
our
spec
and
anything
api
related
under
that
reference
section,
but,
as
you
can
see,
we're
actually
proposing
five
content
buckets
instead
of
four.
So
the
more
we
saw
the
content
and
our
particular
use
case.
We
felt
strongly
that,
because
our
open
source
project
has
so
many
tools,
we
really
did
actually
need
another
section
that
was
dedicated
to
documenting.
A
A
So
I
recommend
you
go
here.
First,
if
you
want
to
get
started
with
us,
I
mentioned
to
you
earlier
that
we
have
a
lot
of
public
meetings
and
that
you
can
join
those
meetings
to
learn
more
about
where
we're
at
at
the
road
map
and
also
you
can
throw
your
questions
about
how
to
contribute
to
any
area
you
wish.
In
this
case
I
hope
docs.
So
what
I
would
recommend
is
if
you
want
to
get
started
in
working
with
me
on
this.
A
You
want
to
go
ahead
and
join
our
slack
workspace,
and
once
you
join
our
slack
workspace,
you
can
send
me
any
questions.
You
want
about
a
specific
contribution.
For
example,
I
also
really
recommend
that
you
join
those
public
meetings
and
so
here's
the
link
to
those
zoo
meetings-
and
you
can
add
you-
know
your
calendars
and
join
our
mailing
list.
We
have
a
newsletter
lots
of
cool
stuff.
Here
are
our
contributing
guidelines,
which
I
mentioned
we
wanted
to
talk
about.
So
I
mentioned
that
we
wanted
to
talk
about
our
contribution
guide.
A
So
as
far
as
the
specification
contribution
guide
here
are
the
specifics.
If
you
want
to
contribute,
for
example,
to
the
specs,
so
if
you
wanted
to
propose
some
change
to
the
spec,
this
is
the
main
contribution
guide.
That'll
detail:
how
to
do
that
for
you,
if
you're
wondering
more
about
how
to
contribute
individually
to.
A
The
docs
excuse
me
the
pause
there.
I
was
trying
to
find
the
link.
Then
I
want
you
here
in
the
readme
to
actually
scroll
down
here
to
contribute
to
a
sync
api
and
then
right
over
here.
It
says
you
should
also
check
out
our
contribution
guide.
So
you
click
that
and
that's
what's
going
to
open
right
over
here,
and
so
this
is
the
document
that
we
just
opened.
A
So
this
is
the
next
thing
I
wanted
to
show
you
so
when
you're
contributing
to
a
sync
api,
we
have
basically
the
following
contribution
flow:
that
we
request
that
you
respect
and
follow
as
well.
So,
first
of
all,
if
you
want
to
do
something
for
the
docs,
let's
say
you
realize
that
you're
dying
to
help
contribute
a
websocket
tutorial.
A
So
the
first
thing
you
got
to
do:
is
you
open
an
issue
where
well?
Actually
I'm
going
to
show
you
here
in
a
sync
api?
In
our
case,
if
we're
talking
about
the
docs,
the
docs
are
actually
in
the
website
repo.
So
what
you
want
to
do
is
if
you
wanted
to
contribute
to
the
docs.
The
first
thing
you
got
to
do
is
open
an
issue
right,
so
you
go
here
to
the
website
repo
and
then
you
go
to
our
issues
right
over
there
and
you
see
here
the
button.
A
You
create
a
new
issue
if
you're
doing
something
for
the
docs.
In
this
case
it
would
be
feature
request.
Although
we
are
currently
working
on
a
template
issue
that
will
be
specifically
for
docs,
so
I'm
going
to
be
soon
after
the
conference
actually
having
here.
Hopefully
a
template
new
issue
just
for
the
docs
and
then
you
can
just
use
that
one
to
get
started,
but
until
we
get
that
out
there
for
now
you
can
use
feature
request,
and
so
you
open
that
new
issue
and
after
you've
opened
a
new
issue
and
you
detail
hey.
A
You
know
I
want
to
propose
that
we
add
a
new
tutorial
for
how
to
use
the
sync
api
and
websocket
protocol.
Maybe
you
already
have
an
idea
of
how
to
get
the
tutorial
started.
If
that's
the
case
go
ahead
and
move
on
to
the
next
step,
which
is
after
that
issue
has
been
approved,
then
go
ahead
and
open
a
pull
request
with
your
work
with
your
proposal
with
your
contribution
tag
me
in
that
documentation,
pull
request
with
my
github
handle
and
say:
hey
ollie,
here's
my
pull
request.
A
Can
you
take
a
look
at
this
tutorial?
Let
me
know
what
you
think
and
then,
of
course
I
will
add
any
other
folks
that
we
need
to
add
to
the
documentation,
pull
requests,
but
for
now
all
you
really
need
to
worry
about
is
adding
me
since
I'm
the
main
owner-
and
I
can
get
everything
else
started
so
after
your
issue
and
pull
requests
have
been
approved
and
everybody
says
wow,
your
contribution
looks
good
to
go.
We
are
ready
to
merge
this
then.
A
The
next
thing
that
will
happen
is
that
your
changes
will
be
merged
by
us,
the
main
contributor
team
and
then
they'll
be
published
on
the
next
release.
Now,
in
the
case
of
the
documentation,
once
we
merge
a
pull
request
for
docs,
it
actually
is
automatically
pushed
live.
So
in
your
case,
you'll
get
to
see
your
contribution
life
probably
much
sooner
than
other
sorts
of
contributions.
A
So
that's
exciting.
Of
course
we
have
a
code
of
conduct
which
applies
to
working
and
contributing,
so
we
really
do
request
that
you're,
respectful
and
read
the
full
text
of
the
code
of
context
so
that
you
can
be
nice
and
pleasant
to
work
with
all
right
cool.
So
we
talked
about
our
contribution
guide
and
how
to
get
those
links
and
information
to
get
started.
A
I
also
want
to
tell
you
about
community
feedback,
because
community
feedback
is
absolutely
priceless,
so
here's
the
thing
there's
all
kinds
of
way
in
which
you
can
give
us
community
feedback.
As
I
said
here,
if
you
were
to
join
one
of
these
channels,
you
can
leave
us
feedback
in
slack.
You
can
give
us
feedback
in
our
zoom
meetings
of
all
the
public
meetings
that
we
have
with
our
contributors.
You
can
send
us
a
message.
What
have
you,
but
you
know
you
can
also
send
us
information
via
an
email
if
you
really
wanted
to.
A
If
we
go
to
our
website,
there's
a
contact
form
section.
Let's
find
that
as
well.
No,
no,
not
a
contact
form
section!
Here
we
go
github
organization.
A
So
the
other
thing
that
I
wanted
to
show
you
was
how
to
leave
or
start
a
discussion.
So
we
have
github
community
discussions
so
that
you
can
leave
us
direct
feedback
via
a
discussion
as
well.
You
can
start
a
whole
discussion
thread
and
get
more
attention
to
help
prioritize
something
that
you
would
like
to
propose
to
be
contributed
or
to
be
done.
So
if
you
want
to
do
that,
then
you're
going
to
want
to
go
to
our
community
repo,
so
our
community
repo
is
where
we
actually
have
been
hosting
discussions
publicly.
A
So
you
just
go
to
async
api
community
repo
discussions,
and
then
here
you
see
that
we
had
actually
some
discussions
going
on
for
the
recent
hackathon
that
just
happened
in
october
and
our
upcoming
conference.
That
was
happening
right
now,
which
is
why
you're
watching
this
talk,
and
then
I
opened
a
section
for
discussing
things
or
questions
related
to
docs.
If
you
want
to
open
another
discussion
thread
about
documentation,
please
go
ahead.
If
you
have
more
questions,
we
have
all
these
other
options,
general
ideas,
questions
and
answers.
A
Oh
yes,
this
is
a
screenshot
of
the
of
this.
I
started
bring
your
async
by
docs
contributor
questions,
so
I
started
this
discussion
thread
which
I
just
mentioned
so
after
this
talk.
If
you
want
to
continue
this
discussion
that
we
started
today,
please
go
ahead
to
this
main
discussion,
discussion,
number
90
and
our
community
repo
and
then
just
go
ahead
and
throw
your
questions
and
join
the
thread.
That
would
be
amazing.
I
would
love
it.
A
Okay,
community
contributions,
so
we
already
saw
our
contributed
guidelines.
We
already
learned
about
the
contribution
workflow
and
how
that
works,
but
now
you're,
probably
wondering
okay,
so
you
told
me
alejandra
what
are
some
changes
that
are
coming
to
the
docs?
You
told
me
that
we
can
tag
you
in
pull
requests,
but
I'm
still
not
sure
where
to
begin.
How
can
I
start
contributing
to
the
docs
alejandra?
I
know
that
you
told
me
to
create
an
issue,
but
what
else
can
I
do
so?
Don't
you
worry
another
thing
that
I
actually
wanted
to
show.
A
If
you
create
an
issue,
then
you
can
go
ahead
and
add
labels
of
docs
or
documentation
enhancement
and
then,
by
doing
that
and
tagging
me
in
your
issue,
we'll
go
ahead
and
add
that
card
to
either
changes
coming
or
in
progress,
community
pull
request
under
review
or
done
what
have
you?
So
if
you're
yourself
are
looking
at
hey,
where
do
I
get
started?
How
do
I
contribute
alejandra?
I
feel
kind
of
shy,
no
worries.
A
You
can
look
at
some
of
the
upcoming
changes
and
things
that
we
want
to
bring
on
board
and
maybe
get
an
idea
from
that
now
right
now
we
did
mention
that
one
of
the
biggest
changes
is
this
redesign
of
the
information
architecture,
we're
talking
about
changing
the
main
content
buckets
for
our
async
api
docs.
So
if
you
have
a
interest
in
helping
us
in
this
move,
what
we're
looking
at
doing
is
possibly
the
following.
A
What
we'll
most
likely
do
is
I'll,
probably
just
create
a
google
spreadsheet
that
has
a
list
of
all
the
tasks
needed
to
reformat
and
move
all
of
our
docs
over
to
these
new
content
buckets
and
then
I
can
share
that
spreadsheet
publicly
with
you
folks
and
then
you
just
look
at
that
spreadsheet.
You
take
a
look
at
the
list
of
github
issue
tasks,
and
you
just
tell
me
hey.
I
can
pick
this
one
up
and
then
that's
how
you
start
contributing
and
that's
how
you
can
help
us
actually
in
making
this
change
to
the
docs.
A
The
other
thing
I
wanted
to
tell
you
guys
about
is-
and
I'm
gonna
head
over
here
right
about
now-
is
you're
going
to
see
that
we
don't
just
have
these
docs
here
in
their
main
site,
but
I
did
also
mention
earlier
that
we
have
here
individual
readmes
and
documentation,
as
you
can
see,
even
inside
of
our
repos
for
our
tools
and
the
spec.
A
So
another
way
to
contribute
to
the
docs
is
not
just
by
writing
documentation,
as
you
could
imagine,
but
we're
actually
going
to
need
a
lot
of
help,
doing
refactoring
work
and
refactoring
isn't
really
necessarily
rewriting
or
editing
we're
talking
about
moving
things
over.
So,
for
example,
I
mentioned
to
you
that
one
of
our
new
content
buckets
is
going
to
be
for
documenting
our
tools
that
we
have
now
in
this
case.
A
Modelina
that
you
see
here
is
one
of
our
tools
and
I
wanted
to
show
you
an
example
of
the
work
that
needs
to
be
done
and
moved
over
to
the
actual
documentation
site.
So
we
go
here
to
molina
and
modelina
main
readme
shows
you
how
to
get
started
and
then
there's
a
documentation
section
right.
So
it
says
all
the
documentation
for
this
library.
This
sdk
can
be
found
under
our
main
documentation
readme.
A
We
click
on
that
read
me
and
it's
actually
this
one
right
here
and
we
see
that
modelina
has
a
whole
library
just
for
docs.
So
here's
all
the
documentation
for
this
particular
sdk
tool
and
the
docs
live
the
docs.
I
forgot
the
word
in
english.
You
know
this
directory.
A
A
They
might
feel
that
that's
not
something
that
they
are
capable
of
doing,
but
something
as
simple
as
copying
and
pasting
as
your
factory
as
we
refactory
things
and
move
and
copy
docs
that
we
have
reap
in
repos
also
to
our
dock
site.
That's
something
that
any
beginner
can
do.
You
don't
have
to
be
afraid
about.
A
You
know
breaking
changes
or
anything
we're
here
to
help
you,
and
so
this
is
another
great
task
that
I'm
going
to
be
adding
to
that
spreadsheet
of
if
all
the
tasks
related
to
this
huge
information
architecture
change
to
our
docs.
So
that's
another
great
task,
we're
going
to
be
moving
over
a
lot
of
docs
that
currently
only
live
in
readme's
to
our
main
documentation
site,
and
you
know
we're
going
to
need
you
for
that
as
well.
A
Now
I,
this
is
a
framework
that
I've
been
talking
about
to
you
that
we're
using
to
inspire
us,
it's
diataxis,
as
you
see
right
here,
dot,
fr
and
here's
that
picture
that
we
saw
earlier.
But,
more
importantly,
if
you're
curious
about
who
has
adopted
this
framework
for
their
engineering
documentation,
I
would
recommend
you
checking
these
guys
out.
You
go
over
here
and
you
can
see
a
list
of
all
the
different
projects
right
now
that
have
been
using
this
framework.
A
I
can
give
you
an
example
right
here.
Actually,
so,
for
example,
you
go
here
to
I'm
going
to
show
you
gatsby,
so
gatsby
is
actually
another
one
that
completely
restructured
all
of
their
content.
Buckets
under
this
new
methodology
and
you're
gonna
start
to
notice
that
maybe
you've
seen
this
before
in
other
documentation
sites,
but
perhaps
you
hadn't
realized
it
here
we
see
tutorial
how
to
guides
reference
and
conceptual
guides
right,
just
kind
of
like
what
we
were
talking
about
earlier.
A
Actually
did
you
know
that
numpy
of
all
things,
the
numpy
is
also
using
the
diatexas
framework?
The
django
is
using
it
websocket
is
using
it.
So
there's
like
a
lot
of
folks.
You
know
that
are
picking
this
up
and
we
are
excited
to
join
the
cause
all
right.
So
I
think
that
now
you
have
a
much
better
idea
of
where
our
current
documents
are
at
and
what
the
roadmap
is
for
improving
our
docs
and
this
is
open
source.
A
So
we
are
so
excited
to
see
how
many
of
you
folks
would
love
to
join
us
and
help
contribute
to
the
docs.
I
mentioned
earlier
that
you
should
connect
for
any
questions,
or
this
or
github
or
slack
invite
twitter
linkedin.
You
have
any
questions
you.
Let
me
know
again,
thank
you
so
much
for
being
here
with
us
today.
I
had
a
really
great
time,
and
I
appreciate
you
bye.