►
Description
30th of November 2021
A
A
Okay,
so
links
sent
before
we
jump
into
the
main
topic
and
I
invite
to
the
meeting
the
special
guest
there's
one
important
announcement.
So
if
you
joined
our
asking
api
conference
in
last
week
or
two
weeks
ago,
yeah,
it
was
two
weeks
ago.
If
you
did
it,
you
probably
heard
that
we
will
do
some
ruffle
like
we'll
try
to
pick
10
people
from
the
list
of
the
all
the
people
that
registered
and
and
yeah
randomly
select,
10
people
and
send
swag
packs.
A
A
A
A
A
A
The
process
I
was
doing
and
the
I
did
a
kind
of
screenshot
of
the
of
the
results
from
the
application
yeah
to
make
sure
that
I
really
were
not.
I
was
not
cheating.
I
hope
you
don't
mind.
We
did
it
this
way,
it's
just
because
we
did
not
foresee
all
the
things
when
we
organized
the
conference,
but
we
will
do
better
in
2022,
so.
A
A
B
A
Yeah,
okay,
so
let
me
share
a
screen.
I
guess
that's
still,
gonna
be
the
best.
So
the
thing
is
that
yeah,
let
me
just
remind
folks
that
just
joined
seven
minutes
after
the
start
of
this
live
stream,
so
the
live
stream
contributor
first,
is
about
contributing
to
asking
api
different
parts
of
asking
api,
and
today
we
talked
about
asking
api
specification
release
coordination
because
to
release
asking
api
specification
and
underlying
tools.
A
A
A
Like
some
facts
about
the
async
api
specification
release
coordination,
so
everything
we
do
related
to
the
release
should
be
described
in
the
release
process
instruction
in
the
spec
repo.
This
instruction
is
not
perfect.
I
don't
think
it's
ever
going
to
be
perfect
because,
depending
on
the
release,
always
different
person
will
look
into
this
this
instruction,
so
there
will
always
be
a
place
for
improvement,
and
also
that's
the
assumption
here.
A
A
Code
owner,
like
help
in
the
project
as
a
as
a
long-term
maintainer
of
the
project,
because
the
release
coordination
forces
you
to
learn
all
the
bits
and
and
and
pieces
like
all
the
details
about
the
release
process
like
who
currently
in
the
community
is
involved
in
the
release.
How
that's
done?
How
we're
picking
up
the
request
for
changes
to
to
get
them
into
the
release
so
basically
release
coordinator
at
the
end
of
the
day
is
one
of
the
most
experienced
people
in
the
in
the
in
the
spec
repo.
A
A
A
We
do
not
say
what
version
will
it
be
if
it's
going
to
be
minor
or
major,
because
we
don't
want
to
make
such
a
decision,
because
it
all
depends
on
the
types
of
the
of
the
contributions
of
the
request
for
changes
that
we
get
into
the
release
branch.
And
now
I
see
a
comment
from
jonas
that
my
screen
share
is
really
grainy.
A
A
Okay,
then
yeah,
unless
somebody
has
some
good
idea,
better
idea
that
I
just
used
so
making
text
larger.
Then
please,
let
me
know
because
I
I
I
don't
really
know
how
to
fix
it.
If
the
video
is
good,
so
it's
not
the
video
quality.
It's
somehow
related
to
the
resolution
of
the
screen
share,
but
I
can't
really
change
anything
in
restream.
A
A
Release
guidance
we
covered
that
and
now
faces
so
when,
like
dale
feel
free.
When
I
will
discuss
each
phase,
I
think
I'm
gonna
even
try
to
execute
few
because
yeah
we
have
45
minutes.
Maybe
I'm
gonna
be
able
to
to
execute
a
few
steps
because
we
did
not
yet
made
any
preparation
for
for
next
release,
so
yeah
the
key.
There
are
different
phases
of
the
phases
of
the
of
the
release
so
kickoff.
A
A
A
A
A
Okay,
so
the
basics
are
done
and
they
are
needed.
They
are
not
prerequisites
to
actually
for
anyone
in
the
community
to
work
on
on
their
request
for
changes,
but
just
the
important
is
to
know
like
like,
for
example,
I
know
that
for
for
january
we
will.
One
of
the
requests
for
changes
that
will
come
in
is
is
probably
to
add
solas
binding
to
to
the
spec,
because
solas
already
worked
on
them
binding
in
the
bindings
repo
it's
already
merged
approved.
A
All
the
works
have
to
be
rebased
and
they
cannot
be
like
pull.
Request
cannot
point
to
the
default
branch
to
the
master
branch,
but
they
have
to
point
to
the
to
the
release
branch.
So
that's
that's
some
extra
effort
that
contributors
have
to
have
to
take.
If
they
are
picked
for
a
given
release
cycle,
they
just
need
to
make
sure
that
they're
not
trying
to
merge
pull
requests
to
the
master
branch,
but
rather
the
the
name
of
the
the
branch.
A
So
definitely
I
say
release
coordinator
so
note
for
you
dale
next
days.
Please
let
know
people
in
the
spec
specification
channel
that
we
that
we
have
those
if
they
were
if
they
needed
them,
then
just
just
let
inform
people
that
we
have
release
branches
for
january
release
created
in
three
the
most
important
repos.
A
A
A
It's
a
file
called
code
owners,
so
every
single
repository
should
have
a
code
owners
that
indicates
who
has
a
right
access
to
a
given
repo,
because
a
given
person
from
the
code
owners
maintains
project
and
approves
pull
requests
so
therefore
has
to
have
right
access,
so
basically
pick
names
from
from
from
those
files
until
next
release.
I
hope
we
will
already
have
them
in
the
spec
json
schema
and
and
parser.js,
because
we
don't
have
those
files
there
so
yeah
next
release.
A
A
When,
when
somebody
contributes
something
to
the
spec,
people
focus
on
their
on
their
request
for
change,
but
there
are
things
in
in
each
repo
that
are
like
above
a
single
request
for
request
for
change.
So,
for
example,
the
rios
release
coordinator
also
has
to
push
someone
ask
someone
for
help
or
on
its
own,
on
his
or
on
her
own,
open
up
apr
to
the
to
the
release
branch
and
fix
the
the
version
of
the
async
api
in
the
examples
in
the
existing
examples.
A
So
yeah
in
the
async
api
spec
repo.
We
have
examples
directory
and
all
those
examples
simply
have
to
point
to
a
specific
version
of
the
of
the
of
the
async
api
that
we
that
we
release-
and
this
part
is
a
bit
complicated
because
you
don't
always
know
what
version
will
it
will
be
like
you
can
assume
that
it's
basically
going
to
be
2,
3
2.3
version,
because
that
would
be
like
super
hard
to
to
to
do.
A
3-0
release
really
right
before,
like
two
months
before
the
release
cycle,
but
yeah
like
you,
can't
you
don't
have
it
like
you're,
not
hundred
percent
sure
at
the
beginning
of
the
of
the
release
cycle.
So
that's
something
maybe
to
improve
in
the
instruction
dale.
I
don't
know,
maybe,
instead
of
having
it
as
a
kickoff,
rather
have
it
as
a
checklist,
something
that,
like
basically
nobody
will
remember
about
it.
It's
it's
something
that
release
coordinator
has
to
has
to
push
to
get
it
done,
because
it's
it's
it.
A
A
Then
it's
and
there's
a
lot
of
discipline
on
the
contributor
side
to
to
make
sure
like
that
changes
are
done
in
in
separate
comments.
So
yeah
in
the
json
schema
repo.
We
need
to
basically
copy
it's.
It's
not
bad.
If
you
just
assume
some
version
at
the
beginning
of
the
cycle
and
then
it's
gonna
be
changed
to
some
different
name.
The
most
important
is
that,
once
we
have
the
release
branch,
we
need
to
get
into
the
release
branch.
A
a
new
new
version
of
the
json
schema
file
and
yeah.
A
A
A
A
A
You
also
have
to
make
sure
that
that
parser.js
is
actually
using
the
the
the
release
candidates,
not
the
not
the
like
default
release
of
the
of
the
json
schemas
library,
because
when
we,
when
we
create
a
branch
with
this
release,
suffix,
we
already
have
a
ci
integration
and
configuration
that
provides
release.
Candidates
releases.
A
So
basically,
if
you
have
a
a
a
a
request
with
some
some
feature
to
the
to
the
release
branch,
when
we
merge
it
into
the
release
branch,
the
ci
will
release
a
npm
package,
but
it
will
release
package
with
a
specific
name
that
will
indicate
that
it's
a
a
release
candidate,
that
it's
not
a
main
package,
but
it's
it's!
It's
annotated
in
npm,
as
far
as
I
remember
as
next
and
then
yeah
there's
a
specific
version
just
for
for
release
produced,
so
so
going
back
to
the
release
process.
A
Before
like
to
to
enable
this
release,
candidates
configuration
you
need
to
make
changes
like
they
can
be
this
in
the
same
pr
as
as
we
talked
before,
you
just
need
to
change
something
to
configuration
these
three
repos.
Let
me
just
open
one
to
show
you
what
is
it?
That's
something
that
unfortunately
yeah
it's
it's.
A
You
can't
use
wildcards
in
the
in
the
tooling
that
we
use
in
the
plugins
that
we
use,
so
we
basically
have
to
manually
change
that
part
from
from
the
old
release
to
the
to
the
new
name
of
the
branch,
with
the
new
release.
Name,
that's,
unfortunately,
manual
stuff,
that
semantic
release
package
is
not
yet
supporting
no
wild
cards,
but
yeah.
That's
super
needed
to
enable
us
to
produce
release
candidates.
A
A
So,
just
learned
by
by
my
lessons
like
in
the
beginning,
I
was
I
was
just.
I
was
writing
release
notes
really
at
the
end
of
the
release
cycle.
But
it's
a
lot
of
work
and
it's
like
you
need
to
dig
in
your
head
a
few
months
back
and
and
figure
out
how
many
things
are
there.
It's
really
manual
manual
work
that
you
want
to
you
want
to
avoid,
and
you
also
want
to
include
contributors
in
in
the
process
of
creating
release
notes.
A
So
basically,
the
instructions
assume
that
the
best
way
is,
if
you
also
on
the
same
day,
open
up
a
draft
pr
to
the
website,
repository
with
a
blog
post,
called
release,
notes
and-
and
you
share
it
also
with
the
contributors.
So
whenever
something
that
contributors
already
have
approved
and
it's
merged
emerged
into
the
release,
branch
feel
free
to
ask
first
contributors
to
to
contribute
to
the
release.
Notes
like
or
at
least
add.
Some
comment
like
what
they
would
like
you
to
to
emphasize
the
most
in
the
release.
A
A
So,
instead
of
like
really
step
by
step
instruction,
it
was
easier
to
just
put
a
a
a
bullet
list
of
all
the
rules
that,
as
a
release
coordinator,
you
have
to
pay
attention
to
so
the
request
for
changes
like
anyone
can
review
and
just
remember,
to
always
consult
with
the
contribution
guide
and
and
feel
free
really
to
ping
the
pink
the
people
that
are
in
the
code
owners
at
the
moment.
It's
it's
just
me
and
fran,
but
just
like
look
on
the
request
for
changes.
Look
at
them,
especially
the
stage
three.
A
You're
not
you're
not
obligated
as
a
release
coordinator
you're,
not
obligated
to
to
help
people
to
get
go
from
stage
one
to
stage
two
or
from
stage
three
two
to
stage
three.
The
most
important
is
the
the
stage
three
accepted
for
you,
because
it
means
that
already
the
community
agreed
on
a
on
a
contribution
code
owners
agreed
to
it,
marked
it
as
marked
it
as
accepted,
but
it
could
be
marked
as
accepted
like
before.
A
The
release
cycle
started
right,
so
the
the
the
proposal
could
be
created.
Let's
say
looking
on
the
next
release
that
we
have
in
january,
like
we
started
preparations
today
and
but
let's
say
we
marked
some
requests
for
changes
as
stage
3
accepted
a
week
ago.
So
the
contributor
is
fully
relying
on
us
to
to
to
know
what
are
the
next
steps.
A
We
can
do
it
for
them.
I
did
it
once
and
it
was
like.
It
was
a
lot
of
work
and
I
felt
really
lost
and
I
was
afraid
that
I'm
gonna
actually
lose
some
things,
because
sometimes,
if
you,
if
you
worked
on
apr
for
a
few
months,
this
rebasing
from
from
master
to
some
to
some
release
branch
depends.
When
you
do
it,
it
can
cause
some
conflicts,
some
some
situations
that
actually
the
contributors
should
deal
with
because
they
know
the
best.
What
parts
should
be
how
the
conflict
should
be
solved.
A
So
I
encourage
you
to
just
give
instructions,
then
then
try
to
do
it
on
your
own
because
of
the
risk
now
yeah
you
be
before
you
accept
something
that
can
be
actually
merged
into
the
release.
Branch
just
make
sure
that
the
labels
are
there,
that
it's
accepted
that
yeah
again
it's
created
against
the
the
feature
branch.
A
Maybe
we
should
call
it
release
branch
in
the
instruction
and
that
the
the
rfc
is
accepted
and
just
double
check,
but
it
should
be
already.
It
should
be
accepted,
because
that's
this
condition
is
actually
met,
so
basically
make
sure
that
you're
merging
something
into
the
spec.
But
there
are
already
reference
implementations
in
the
json
schema,
of
course,
and
then
and
the
parser
they
are
approved
and
they're
actually
also
ready
to
merge.
A
A
A
Where
is
it
yeah
this
one
that
it
is
using
a
proper
version
of
asking
api
specs
package,
because
that's
that's
the
npm
package
that
holds
the
json
schemas
and
it
has
to
point
to
the
right
release
candidate
that
actually
contains
the
the
contributed
things.
So
what
I'm?
What
I'm?
What
I
mean
is
that,
like
first,
you
merge
in
in
case
of
request
for
change,
you
merge
a
a
spec
pr.
Then
you
merge
a
json
schema.
A
A
Just
use
the
ask
the
contributor
to
update
the
the
version
in
their
pull
request
to
point
to
the
release
candidate
from
the
schema
and
from
the
schema
from
the
package
that
holds
the
the
schema,
because
otherwise
people
will
not
be
able
to
to
use
the
release
candidate
if
parser
doesn't
point
to
a
proper
schema.
A
package.
A
A
And
here
huge
request
also,
even
though
javascript
converter
playground,
that
should
be
most
probably
upgraded
to
studio
this
here
on
the
list
react
component
marked
out
templates.
So
there
are
some
basic
tools
that
they
are
not
like.
Contributor
does
not
have
to
add
new
features
to
those
tools,
but
there
are
very
active
maintainers
that
will
make
sure
that
it's
there
so,
even
though
they're
active-
and
they
most
probably
will
notice
new
releases
as
a
release.
A
Car
and
coordinator
just
just
remember
that
once
a
a
first
request
for
change
is
already
merged,
and
we
know
that
it's
gonna
go
into
the
next
release
because
it's
already
merged
into
the
release
branch.
Please
ping,
folks
from
the
like
maintainers
of
the
of
this
repose,
that
yeah
and
when
the
next
release
is
coming
in
and
then
that
some
request
for
changes
are
already
merged.
So
if
they
want
to
support
them
in
these
tools,
they
can
start
working
on
it.
A
A
Yeah,
so
when
first
request
for
change
is
merged
it,
like
I
already
said
it
like,
it
means
that
we
will
for
sure
have
something
for
the
for
the
next
release.
We're
gonna
release
it,
so
you
have
to
open
up
a
pull
request
that
will
point
for
a
from
a
release
branch
into
the
master
branch.
So
we
can
already
reflect
transparently
that,
like
the
release,
will
will
happen
and
people
can
already
see
what
will
be
what
will
be
released,
and
that
has
to
be
done
in
all
the
three
repositories.
A
And
yes,
pink
maintainers
of
the
website
or
you
can
open
up
requests
on
your
own
like
basically
we
because
we
know
that
release
will
happen
and
we
actually,
I
actually
as
a
religious
coordinator.
I
forgot
about
this
step
and-
and
it's
pretty
important
shame
on
me,
but
we
need
to
update
documentation
right.
So
some
guides
are
very
specific
on
the
version
of
the
spec
and
yeah.
It
would
be
nice
really
to
have
on
the
release
date.
A
I
have
also
the
documentation
reflecting
the
latest
version
of
the
of
the
asking
api
spec,
so
yeah.
Please
keep
that
in
mind
and
if
it
comes
to
communication,
then
yeah
release
candidates.
That's
automated!
So
you
don't
have
to
worry
about
it.
We
have
automation
that
will
tweet
every
single
release
candidate.
They
will
it.
It
will
tweet
them
to
to
twitter,
but
also
there
will
be
a
a
message
in
the
dedicated
slack
channel
where
we
notify
every
new
release
but
of
course
proactiveness
is
encouraged.
A
So
I
I
guess,
like
information
in
the
specification
channel,
maybe
we
should
even
have
it
written
here
in
the
in
destruction
that
we
should
like.
Even
though
we
have
some
automation
would
be
good
to
have
a
a
memo
from
the
release
coordinator
in
the
specification
channel
that,
given
the
release,
is
there.
A
And
yeah
ship
it.
So
we
like
the
the
release
process.
The
release
cadence
does
not
specify
a
a
day
of
the
release.
We
only
specify
a
month
of
the
release
and
it's
up
to
the
release
coordinator
to
decide
when
is
the
best
day
to
make
a
release,
because
it's
it
all
like,
like
majority
of
the
work,
depends
on
the
release
coordinator
and
your
time
and
your
like.
Basically
your
time
and
how
much
you
can
spend
on
it
and
like
coordinating
is
a
lot
of
work.
A
A
So
if
you,
for
example,
see
that
there
are,
or
already
let's
say,
three
rfcs
merged,
so
it's
already
a
reach
release.
There
are
a
few
changes
that
need
to
be
communicated
properly,
feel
free
to
say
that,
like
okay,
once
we
merge
a
third
rfc,
we
need
to
like
really
like,
say:
okay,
no
more
rfcs,
because
we
have
like,
let's
say
two
weeks
or
three
weeks
until
the
end
of
the
of
of
january,
and
we
would
like
to
update
more
tools
to
support
those
new
features.
A
A
So
so
that
would
be
it
if
it
comes
to
the
day
and
what
it
means
like
to
ship
it
like
to
actually
release
it.
It's
like
yeah,
you
have
to
merge
a
a
request
from
a
release
branch
to
the
master
branch
and
the
same
order
like
with
the
release
candidate,
so
first
go
spec,
then
spec,
json,
schemas,
then
parser
and
then
the
rest
of
tooling's
tooling
can
can
follow
because
most
of
the
tools
use
parser.js.
A
A
A
We
don't
have
yet
a
decision
who
owns
all
the
social
accounts.
Who
can
do
it
so
in
january.
It's
probably
gonna
be
still
me
that
you
have
to
ping
to
to
yeah
to
make
some
official
tweets
from
the
official
account.
Actually
no
wait
so
on
on
linkedin.
I
have
to
do
it
manually,
but
on
slack
you
can
do
announcement
and
actually
on
twitter.
You
can
also
do
announcement
on
your
own.
A
A
So
let
me
make
it
smaller
a
bit,
so
we
have
a
a
workflow
and
a
document
twitter
together
where
we
describe
how
to
actually
create
thread,
request
a
tweet,
and
that
would
be
actually
the
best
way
to
to
work
on
the
tweet.
So
you
don't
just
rely
on
someone
to
tweet
it,
but
actually
upfront.
You
can
already
suggest
how
a
given
tweet
should
look
like
or
ask
someone
to
help
doing
it,
but
yeah.
A
It's
I
mean
it's
as
easy,
as
I
think
we
have
one
request
opened
from
barbano
yeah,
so
it's
just
a
pull
request
with
one
file
where
you
put
the
text
of
the
of
the
of
the
tweet
and
then
once
we
merge
it,
it's
it's
automatically
tweeted
on
twitter,
so
yeah.
If
it
comes
to
communication,
you
can
also
upfront,
prepare
twitter
communication
or
just
ask
someone
to
do
it.
A
A
A
A
So
once
we
find
the
request,
you
can
push
it
through
for
this
release
to
make
it
like
I
mean
I
don't
if
it's
improvement
to
the
release
process,
not
very
complicated.
So,
let's
let
us
just
follow
the
and
the
idea
from
from
jonas.
We
just
need
to
make
sure
that
it's
this
information
ends
up
in
the
release
process
document
for
for
next
release,.
A
A
A
No
worries
I
was
with
every
release.
I
was
doing
some
mistakes.
Some
two
quick
releases,
some
errors
with
automation,
so
these
things
happen.
So
no
worries
awesome,
okay,
so
everyone
in
the
in
the
audience
that
watched
it
thanks
a
lot
for
following
and
next
contributor.
First
is
next
week.
I
don't
know
yet
what
day
and
what
topic?
Let's,
let's
discuss
in
slack
in
the
how
to
contribute
channel.