►
Description
This video explains how to start contributing to AsyncAPI changes to the AsyncAPI repositories. You learn how to create and configure a fork on your local machine and then end up with a pull request to the upstream repository.
For more details read this blog post - https://www.asyncapi.com/blog/hacktoberfest-2020
A
Of
course,
there
are
different
ways
of
contributing,
and
I
personally
value
actually
every
kind
of
interaction
with
us.
There
are
many
contributors.
I
know
that
didn't
make
any
single
change
in
any
of
our
repositories,
but
they
still
contribute
to
the
initiative
by
talking
about
us
at
conferences
or
engaging
with
with
the
community
and
promoting
us,
but
in
this
particular
video
we
are
about
the
contributions
that
make
a
change
in
a
repository,
so
you
usually
start
with
an
issue
because
that's
a
place
where
we
discuss
things.
A
A
We
all
work
through
forks
and
it's
a
really
good
approach
to
not
make
changes
directly
in
the
master
branch
of
your
fork,
because
you
usually
make
more
than
one
contribution,
and
you
want
to
make
sure
that
your
fork
is
always
up
to
date
with
the
upstream
so
yeah.
My
good
advice,
don't
make
changes
directly
to
the
master
branch
of
your
fork
and
later
on
in
this
video,
we're
gonna
see
why
so,
first
of
all,
we
need
to
pick
up
an
issue
to
work
on.
A
A
A
A
A
A
A
A
A
Now
it's
important
to
configure
your
local
fork
because
you
always
want
it
to
be
up
to
date
with
the
upstream.
So
with
the
original
repository
html
template
in
the
async
api
organization,
not
your
fork,
because
you
need
to
know
that
html
template
repository
is
gonna,
live
in
asking
api
organization
and
it's
gonna
continue
to
evolving.
A
So,
let's
imagine
there's
a
timeline
here.
You
made
your
first
pull
request
to
the
project,
but
the
next
one
you're
gonna
do
in
two
three
months.
Let's
say
but
in
between
there
were
many
different
changes
into
the
upstream,
so
in
the
original
repository,
so
you
would
basically
have
to
make
a
lot
of
manual
work
to
make
sure
that
the,
when
you
make
a
first
attempt
three
months
later,
that
you
make
sure
that
the
your
local
fork
is
up
to
date
with
the
upstream.
A
So,
instead
of
going
into
this
issue
that
you
forget
to
do
it
and
it's
pretty
common
that
you
just
forget
in
three
months
that
your
fork
is
outdated
and
you
start
working
on
changes
locally
and
then
all
suddenly,
you
realize
that
you
made
a
lot
of
changes
to
pretty
outdated
branch
and
you
run
into
many
conflicts.
You
don't
want
that
so
better
to
always,
when
you
create
a
fork
and
clone
it
locally.
A
A
A
Okay
looks
good:
let's
go
to
the
pull
request.
You
see
the
git
even
suggested
link,
let's
copy
and
check
it
out.
Let's
paste
the
link
here,
so
you
can
see
it's
a
direct
ui
to
suggest
a
pull
request
which
comes
from
the
fork
into
the
upstream
before
you
click
on
create
requests.
You
need
to
know
that
we
follow
so-called
conventional
comments
to
read
more
about
conventional
comments.
Go
to
this
website,
but
let's
go
back
to
the
pull
request.
A
What
you
just
need
to
know
is
that,
in
our
case,
the
summary
of
the
pull
request
need
to
start
with
a
prefix,
a
special
prefix
that
indicates
to
our
ci.
If
given
pull
request
after
merge,
should
trigger
release
major
release,
minor
release,
patch
release
or
nothing
really
or
maybe
a
rebuild
of
documentation.
A
A
A
A
Give
us
some
time
to
review
your
request.
If
we
are
pretty
lame
with
response
time
which
may
happen,
we
sometimes
are
super
overwhelmed
by
our
work.
We
have
to
do
so.
Please
try
to
contact
us,
maybe
pinging
our
official
account
on
twitter
or
just
going
to
our
slack
or
just
mentioning
us
in
the
comments
and
yeah.
That's
it.