►
From YouTube: AsyncAPI SIG meeting 36 (November 24, 2020)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #36.
Attendees:
- Fran Mendez
- Jonas Lagoni
- Lukasz Gornicki
- Pavel Bodiachevskii
- Waleed Ashraf
Agenda & Notes: https://github.com/asyncapi/asyncapi/issues/462
Chat:
00:14:50 Fran Méndez: Logos: https://drive.google.com/drive/folders/17XAR-6D8Le7iQT3Y6laKNBsaGj_8DStF?usp=sharing
00:36:18 Fran Méndez: Shape Up repo: https://github.com/asyncapi/shape-up-process/issues
00:36:32 Fran Méndez: Landing: https://shapeup.asyncapi.io/
01:00:37 Lukasz Gornicki: I think I’m behind
01:00:38 Lukasz Gornicki: proceed
01:00:38 Lukasz Gornicki: I see you are freezed
01:01:38 Jonas Lagoni: Had to rejoin, dont think zoom is having a good day :D
01:01:53 Lukasz Gornicki: Ufff, I though it is just me again :D
A
Good
morning,
everyone
or
afternoon
whoever's
watching
it
at
what
kind
of
hour
it's
passing
api
open
meeting.
We
have
four
people
joining
the
call.
So
it's
it's
me
fran.
We
have
wallet
after
some
time
joining
us
hey,
and
we
have
also
pavel
that
created
a
a
a
project
outside
asking
api
organization.
That
is,
let's
say
that
to
summarize
why
he
joins
today.
Let's
say
it's
going
to
be
a
first
code,
first
tool
that
we
will
host
on
our
asking
api
organization.
A
A
A
C
A
A
E
A
A
C
C
A
I
think
that's
all
okay
cool
so
yeah,
again
again
you
so
the
first
topic
on
the
on
the
agenda.
Is
this
java
asking
api
project
that
you
want
to
move
to
asking
api?
So,
as
we
discussed
on
on
slack,
the
most
important
for
us
was
to
get
the
the
license
file
into
the
project.
You
did
it.
So
that's
that's
done
and
the
second
stuff
is
yeah.
A
We
need
to
find
a
a
name
for
the
repo,
because
if
it's
going
to
be
moved
to
async
api
organization,
then
name
java,
async
api,
it's
going
to
be
super
generic,
so
we
have
to
figure
out
the
name
of
the
project
and
then
the
next
stuff
like
extending
readme
or
adding
the
release
pipeline
and
all
the
other
asking
api.
Let's
say
generic
content,
that's
like,
in
my
opinion,
that's
not
something
that
has
to
be
done
before
the
move,
because
we
anyway
have
many
projects
in
async
api
that
are
still
not
super
mature.
A
A
C
C
A
F
A
F
A
A
G
C
H
C
A
A
C
Yeah,
I
I
agree
with
that.
I
will
not
split
it
early
in
the
process
like
I
will
just
continue
working
there,
async
api
core
is
in
kpa
plug-in,
then,
probably
or
or
you
can
structure
this
differently.
If
you
want
yeah
and
then
at
some
point,
if
it
becomes
a
problem
or
some
parts
of
it
becomes
a
problem,
then
we
can
split
it.
C
Otherwise,
if
you,
because
if
you
look
at
it
from
the
context,
if
you
move
this
to
a
sync
api
organization
and
look
at
it
from
the
context
of
the
organization,
then
we
will
have
a
single
tool
split
into
many
into
many
packages
right.
This
is
the
same
as
we
did
with
the
with
generator,
so
the
generator
started
as
a
single
repository
with
all
the
templates
inside
and
now
it's
a
while
when
it
became
a
problem,
then
we
started
splitting
out
the
templates
into
their
own
repositories
right
so
so
yeah.
So
I
guess
that's.
A
That
would
be
the
best
and
and
even
at
start,
the
name
is
not
really
that
problematic.
It's
just
a
matter
of
having
an
issue
that
addresses
the
the
problem
and
let's
asynchronously,
discuss
it
over
there
in
the
issue,
because
if
we
think
that
because
of
having
plugins
in
the
same
repo,
it
might
be
a
problem
for
having
a
a
good
name
for
it,
then
let's
just
I
mean
in
general,
just
no
rush.
No
there's
there
are
no
like
strict
deadlines.
We
have
to
finish
it
before
the
end
of
the
week
or
what's
whatsoever.
A
Okay,
cool
then
awesome
like
welcome
on
asking
apr
organization.
Then,
after
the
call
I'm
gonna
write
to
you,
let's
I
I
think
you're
gonna
have
to
give
me
a
I
admin
right
to
the
repo,
so
I
can
perform
the
the
move
because
it
has
the
best
if
it's
the
best,
when
the
move
is
done
with
github
functionality,
because
github
when
I
move
it
from
your
project
to
our
organization,
will
also
set
up
redirects.
A
A
G
H
C
Okay,
okay,
okay,
I'm
sure
you
can
see
my
screen
right,
so
so
so
cool.
So
let
me
explain
what
is
it
about
at
async
kpi
we've
been
working
in
or
trying
to
work
in
different
ways,
as
you
might
know,
and
lucas,
and
I
we've
been
trying
to
coordinate
the
the
best
way
possible,
but
the
team,
because
the
team
is
growing
right.
C
So
this
is
a
a
spoiler
that
I'm
gonna
do
not
gonna,
say
much
more
yet,
but
I'm
just
gonna
say
that
jonas
lagoni,
who
is
on
the
call,
is,
is
joining
us.
It's
janine's
on
amazing
kpi.
So
we
are
now
three
we're
looking
at
so
welcome,
janice
and
and
also
we
have
magic-
and
let
me
help
me
here-
lucas
wukash,
to
pronounce
his
surname,
because
I
don't
really
know
how
it
is:
magik,
urban,
sikh,
urbanczuk,
urbanchek,
okay,
so
somatek
is
a
machik.
C
Is
a
creator
of
the
react
component
of
the
async
api
react
component
and,
and
so
we
thought
that
it
would
be
great
to
have
him
with
us
and
joining
us
and
so
yeah.
So
we
just
doubled
the
team
all
of
a
sudden
we're
now
four
right.
So
welcome
matic
and
and
yeah,
so
this
is
gonna
keep
happening
during
the
next
half
of
the
year
next
year
and
and
of
course,
that
means
that
that
means
that
we
have
to
work
differently
right.
C
It's
not
lukas,
and
I
anymore
or
and
eva-
and
I
anymore,
and
that's
why
and
that's
why
we
we
have
to
basically
rearrange
the
work
and
and
work
a
little
bit
different.
So
that
said,
we've
been
looking
at
scram
metal
methodologies,
agile,
and
all
of
that
I
mean
we've
been
looking.
We
have
been
doing
this
for
for
years
ourselves
in
different
companies,
luckily
and
unlikely,
I
had
all
kind
of
experiences
with
scram
good
ones
where
usually
when
we
were
only
two
or
three
in
the
team.
C
C
C
It
has
like
a
clear
focus
on
on
speed
right
like
that's
why
it's
called
sprint
right,
yeah
you
have
sprints
and,
and-
and
you
have
and
that's
why
you
have
also
also
these
estimations
right
like
you
want
to
be
sure
that
the
time
you
have
or
or
during
the
sprint
you're
able
to
deliver
deliver
deliver
this
as
many
things
as
possible
right,
but
an
async
api
things.
A
little
are
a
little
bit
different
because
here
we're
not
on
harass
like
what
ugas
just
said.
C
That
doesn't
mean
that
we
are
going
to
work
slow,
but
what
it
means
is
that
we
don't
have
to
be
delivering
a
thing
every
two
weeks
or
every
week
we
have
to
be
delivering
high
quality
things
right.
So
it's
more.
The
focus
for
us
is
more
on
the
quality
than
in
the
quantity
on
the
long
term,
quality
right,
because
so
far
we've
been
doing
the
opposite.
So
far,
we've
been
doing.
C
We've
been
following
this
approach
of
deliver,
deliver
delivery,
even
if
it's
not
perfect-
and
this
has
changed
like,
for
instance,
one
of
the
things
one
of
the
main
pain
points.
So
far,
it's
been
the
spec
and
how
the
spec
is
is
structured
and
walid
was
facing
the
other
day.
One
of
the
issues,
which
is
the
schema
where
the
schema
is
located.
How
do
we
update
the
schema?
How
would
we,
how
do
we
release
a
new
version
of
the
spec?
C
You
know
like
it
was
impossible
for
us
to
handle
everything
at
that
speed,
because
the
tooling
was
demanding
as
also
speed
right.
So
it's
like.
If
and
and
it's
obvious
that
if
we
change
the
spec,
then
we
have
to
update
all
the
tooling
so
he's
like
none,
let's
not
touch
the
spec.
For
now,
let's
make
some
good
tooling
with
what
we
have
so
far
and
then
we'll
come
back
to
the
spec.
But
that's
gonna
change
right!
That's
gonna
change!
C
C
C
On
their
daily
work
at
the
base
camp
right
and
it's
been
proved
to
work
for
them.
I
think
it
makes
sense
for
us
as
well.
It's
a
little
bit
different,
so
I'm
gonna
explain
what
it
means.
It
means
that
we're
gonna
work
on
cycles
of
six
weeks
right
instead
of
two
weeks
or
like,
like
sprints
in
in
in
scram,
so
we
are
gonna
work
on
cycles
of
six
weeks.
C
C
What
happens
after
the
cycle
this
cycle
of
six
weeks
finish?
We
enter
a
two
weeks
cooldown
period.
This
is
the
name.
What
does
it
mean
cool
down
period,
so
it
means
that
we
stopped
working
on
whatever
we
were
doing
during
this
six
weeks.
Things
have
to
be
delivered
in
this
six
weeks
cycle
and
in
the
in
the
two
weeks
cycle
or
cool
down
period.
If
you
want.
C
We
can
work
on
whatever
we
want,
so
everyone
can
work
on
whatever
we
they
want,
like
fixing
a
back
here
and
there
there's
now
clear
thing
to
do
like
anyone
can
be
contributing
the
way
they
want
and
we'll
be
talking
a
little
bit
more
in
the
next
months
about
these
two
weeks
cooldown
period,
because
we
plan
to
help
other
open
source
projects
in
in
this
time.
So
I
think
this
this
will
be
interesting
for
many
projects,
so
coming
back
again
to
the
next
to
the
cycle
to
the
six-week
cycle.
C
C
Ph
right,
so,
for
instance,
this
is
one
sorry.
This
is
one
of
the
pitches
that
we're
gonna,
that
we've
been
working.
We're
gonna
be
working
on
this
week's
this
six
week
cycle
and,
as
you
can
see
there
is.
This
is
not
like
a
simple
issue
right.
There
has
been
some
investigation
before
some
try,
some
tryouts
before
we
created
this.
C
This
speech
right
I'll
I'll,
follow
explaining
what
it
is,
why
we
call
it
pitch,
and
then
this
is
another
one
like
data
models.
Generation
like
this
is
also
a
common
problem
for
the
generator
and
template
authors.
As
you
can
see,
this
is
not
right.
There
has
been
some
investigation
without
entering
the
details
of
what's
written
here,
just
open,
it's
open
by
the
way,
there's
there's
some
there's
some
degree
of
investigation
before
creating
this
right
so
yeah.
By
the
way
you
can
find
this.
C
C
You
will
be
able
to
follow
how
we
are
progressing
on
our
current
cycle
yeah.
This
started
yesterday.
So,
as
you
can
imagine,
we
we're
just
figuring
out
how
we're
gonna,
how
we're
gonna
create,
how
we're
gonna
progress,
how
we're
gonna
do
the
task
and
complete
the
task,
but
these
dots
here
are
gonna,
be
eventually
moving
forward
right
until
the
end
of
the
of
the
hill
of
the
hill
chart,
right,
which
it
means,
then,
that
the
the
task
or
the
scope,
which
is
called
scope,
is
completed.
C
So
what
is
a
pitch
again?
So
a
pitch
is
just
an
idea
that
anyone
can
submit
with
a
previous
consensus
like
with
the
community,
let's
say
so,
for
instance,
the
way
we
follow
this
is
we
create
an
issue
on
the
master
related
repository,
for
instance,
react
as
a
generator
engine
was
one
of
them,
which
is
this
one.
C
C
C
This
is
something
that
you
pitch
so
imagine.
For
instance,
lucas
wants
to
pitch
for
something
like.
I
want
an
async
api,
ui
library,
because
I
need
it
for
whatever
reason
he
can
pitch
about
it
and
he
has
to
provide
like
lots
of
details
about
how
how
to
make
it
work
or
how
to
make
it
happen,
and
then,
usually
the
two
weeks
or
the
week
before
the
cycle,
the
six
week
cycle
start
we
get
to
decide
what
goes
into
the
next
cycle.
C
We
prioritize
like,
what's
what's
good,
what's
gonna
get
into
the
cycle
at
that
time,
whenever
we
decide
what's
going
to
get
into
the
cycle,
it's
it's
a
bet
for
us.
That's
why
you
see
bets
here
right
so
at
that
time
it's
not
anymore.
Your
pitch
is
our
bet
right
and
we're
betting
on
it.
We
bet
that
we're
gonna
finish
it
by
the
on
on
the
next
six
week
cycle.
So
it's
our
bet
that
we're
gonna
face
it.
C
We're
gonna,
finish
it
and
then
like,
as
you
can
imagine
this
six
week
cycle
is
a
long
period.
So
these
tasks,
usually
these
bets,
have
are
monsters
right,
are
usually
monsters,
big
ones.
These
are
the
so-called
epics
right.
So
what
we
do
is
that
we
divide
these
bats
into
smaller
chunks
that,
at
the
same
time,
these
smaller
chunks
can
be
divided
into
smaller
ones.
So
let
me
let
me
clarify
this.
C
A
bed
can
be
divided
into
smaller
chunks
of
related
tasks,
which
is
what
we
call
scopes
right,
and
this
scopes
is
what
you
see
the
the
dots
here
moving
like.
I
don't
want
to
enter
so
much
in
the
details
of
of
of
how
shape
app
work
works,
because
if
you,
if
you
come
here
and
you
click
here-
learn,
learn
more,
you
will
see
there
is
a
a
work
explaining
this
a
little
bit
more
and
there's
even
a
link
to
the
base
camp.
Sorry,
not
here
this
one!
C
If
you
come
here,
you
will
be
able
to
see
the
the
book
they
have,
you
can
buy
it
or
you
can
read
it
online
for
free.
So
I
really
recommend
this
reading.
Even
if
you're
not
going
to
follow
this
process,
it's
it's
inspiring,
at
least
like
there's,
there's
another
way
to
work
in
an
agile
way,
so
so
yeah.
So
this
is
basically.
C
C
Only
part
that
was
a
little
bit
challenging
for
us
is
that
this
is
open
source
shape
up
base
camp.
You
know
all
these
tools
like
gyra
or
jita.
I
don't
know
how
you
call
it
they're
all
meant
to
be
working
in
private
and
we
wanted
to
keep
using
github
right.
So
we
had
to
adapt
it
a
little
bit
for
us
to
work
on
on
github
on
the
public.
So
you
all
can
see
our
progress
and
participate
as
well.
C
If
you
want
so
so
yeah,
that's
that's
pretty
much
it
from
my
side
like
this
is
what
we're
gonna
be
doing
this
this
website.
Shapeup.Exe
kpi.io
will
be
improving
over
time
with
more
and
more
information.
You
will
see
on
the
history
here
below.
You
will
see
that
as
we
make
progress,
you'll
see
history
points
there,
how
we're,
making
progress
and
and
yeah
just
to
make
it
clear
what
this
hill
chart
is.
C
C
C
We
need
to
create
a
a
reactive,
renderer,
a
custom
reactive
renderer
like,
for
instance,
like
you,
have
renders
for
creating
pdfs
using
react.
You
have
trenders
to
to
create
for,
for
mobile
applications,
react
native,
and
you
have
react
for
the
cli
as
well
with
custom
renderers
right.
So
these
are
renderers
that
are
not
working
on
the
web.
That's
why
you
have
react
dom
as
a
separate
package.
D
C
Sure
so
one
thing
workers
will,
I
think,
we'll
keep
working
on
them
from
time
to
time
fixing
some
bugs
and
small
issues
and
all
of
this
stuff,
and
after
this
six
week
cycle,
we
have
two
weeks
right
where
people
can
work
on
whatever
they
want.
We'll
pick
these
issues,
these
small
issues,
packs
small
features
and
we'll
use
these
two
weeks
to
to
improve,
let's
say
to
to
to
keep
progressing
there
right
if
at
some
point
they
become
something.
C
When
I
say
that
this
huge
task,
I
don't
mean
that
the
task
has
to
be
huge
in
in
the
sense
of
of
time,
like
maybe
it's
something
that
you
will
implement
in
one
week,
but
it
has
to
be
like
clearly
defined
and
you
have
to
investigate
beforehand
what
it
means
right
or
what
it.
What
does
it
take
to
complete
this
task
so,
and
we
have
a
lot
of
them
like
we
have
a
lot
of
these
big
ones,
let's
say
right,
but
we
can
always
like
group
them
by.
C
D
C
D
You,
if
you
group
things
together
and
there
are
like
three
of
them
and
you
completed
two
of
them,
but
couldn't
make
the
last
one
that
would
stop
the
pitch
as
not
completed,
even
if
you
did
so,
I
would
prefer
keeping
them
separate
and
finishing
up
and
then
just
getting
rid
of
it
rather
than
grouping
them,
and
then
it
just
goes.
It
just
takes
more
time.
C
So,
whenever,
whenever
I
understand,
but
whenever
we
say
grouping
things
here,
whenever
we
make
a
peach,
we
first
make
sure
with
the
team
that
this
is
something
we
can
finish
during
the
six-week
cycle
right.
Otherwise,
we
don't.
We
don't
put
it
in
the
cycle
and
it's
not
like
an
estimation.
This
is
not
like.
I
want
people
to
estimate
how
much
or
how
long
this
is
going
to
take
we're
not
going
to
be
doing
estimations.
C
I
don't
know
small
issues
somewhere
small
issue
that
might
take
you
five
days
to
complete
the
issue,
but
we
can
say
that
we
have
an
appetite
of
six
weeks.
That
means
that
we
are.
We
will
be
happy
to
spend
six
weeks
on
this,
because
we
want
this
fixed
now
right.
We
we
don't
care.
If,
if
it
takes
five
days
we're
if
needed,
we
will
be
able.
We
will
be
happy
to
dedicate
six
weeks
to
this.
That's
what
it
means
right,
that's
as
opposed
to
to
estimation,
but
that's
why
I
was.
C
So
I
feel
a
few
things
that
that
can
be
challenging
and
a
few
things,
and
also
that
can
be
rabbit
holes
rabbit
holes
in
the
in
the
in
the
sense
of
this
is
something
that
you
might
spend
out
of
time
digging
into
without
being
able
to
complete
it
and,
and
that
can
threat.
Let's
say,
let's
say
that
can
threat
the
the
the
bet
from
being
finished
right
and
also
there's
another
section
which
is
out
of
bounds,
which
is
like
we
don't
go.
We
don't
want
to
go
there.
It's
like
we
will
we
will.
C
C
If,
after
a
few
days,
you
don't
know
how
you're
going
to
implement
something,
then
this
task
is
likely
going
to
fail
right.
That's
why
that's
why
this
is
this
chart
is
important
in
this
case.
Right,
like
I,
I
understand
the
fear
that
if
we
group
things
together,
you
might
complete
two
and
not
the
third
one
but
yeah.
C
That
will
not
be
the
case.
If
that's
the
case,
then
we
always
have
these
two
weeks
period,
cooldown
period,
where
we
can
just
finish
this,
the
remaining
one
and
and
reevaluate
what
happened
and
then
for
the
next
one.
We
will
be
more
careful,
of
course,
so
the
perfect
solution
either
like
there's,
no
perfect
solution.
D
C
They
have
to
like
everything,
has
to
be
a
smaller
issue
first
and
then
from
there.
You
might
not
have
to
write
a
pitch
at
any
time
like
you
might
just
submit
an
issue
like
you
say
like.
I
would
love
this
to
happen.
I
have
an
idea,
maybe
or
not.
I
just
want
this
to
happen,
and
then,
if
we
think
this
is
something
we
want
to
work
on,
maybe
I
don't
even
ask
you
to
work
on
this.
D
C
Yeah,
so
that's
just
sorry
just
to
make
it
clear
this
process
is
for
us
it's
for
the
team
working
full
time
on
snk
api.
It's
not
it's
not
for
the
for
the
whole
community!
Sorry
for
the
for
the
confusion,
so
you
can
just
submit
any
pull
request
anytime
right.
It's
not
like
you
can
pick
one
of
the
issues
and
say
like
hey,
okay,
okay,
I'll
take.
A
A
F
A
C
It's
because
we're
still
figuring
like
dividing
the
beds
into
smaller
scopes.
That's
what
we're
doing
right
now
right!
So
in
the
next
days
you
should
you
should
start
seeing
more
dots
appearing
here
right,
like
all
the
all
the
groups-
and
this
is
just
for
us
to
like
lucas
said
this-
is
just
for
us
to
be
transparent,
with
the
community
of
what
we're
doing
and
how
we're
progressing
right.
We
don't
want
to
use,
base,
camp
or
or
jira
or
trello,
or
anything,
that's
private,
and
it's
a
nice
invitation.
C
We
we
want
to
keep
using
github,
which
is
transparent,
and
you
don't
need
an
invitation
to
see
how
how
we're
doing
right
and
this
this
whole
dashboard
is
powered
by
by
the
github
issues.
So
there's
no
there's
no
database
behind
the
scenes
or
anything
it's
all.
It's
all
using
the
github
api
and
the
send
half
api
as
well
so
yeah.
D
C
C
A
Okay,
so
last
question
for
this
topic:
was
five
minutes
left,
so
my
last
question
from
my
side
front:
did
you
plan,
I
mean
once
we
finally
can
openly
say
why
we
grow
from
two
to
four:
how
we
did
it
did
you
plan
in
this
announcement,
or
maybe
rather
in
a
separate
blog
post,
to
describe
this
this
this
workflow
did
you
plan
to
do
it?
Maybe.
C
A
C
A
C
D
A
D
Yeah,
my
my
my
questions
are
around
how
how's
the
release
process
and
for
for
the
schema
itself,
and
why?
Why
don't
we
roll
out
changes
if
they
don't
have
any
impact
or
if
we
do
like
how
do
we?
How
do
we
tackle
that?
I
know
there
could
be
some
side
effects
and
these
things,
but
if
we
know
about
bug,
fixes
or
features
requests
which
are
coming
in,
which
don't
have
side
impacts
or
which
are
ready,
why?
How
do
we
hold
them
or
why
do
we
hold
them
for
how
long
like,
what's
the
whole.
C
C
H
H
C
C
So
I
would
say
that
so
the
thing
is
that
it
was
a
matter
of
bandwidth
like
we're
focused
on
the
on
releasing
parser
version,
one
during
the
version,
one
on
my
side,
I'm
not
doing
a
lot
of
code
or
spec
or
anything
because
I'm
in
the
process
of
you
know
this
transformation
where
we
start
hiding
out
of
people.
So
I'm
I'm
almost
not
available
for
coding
and
and
in
or
I
have
I
haven't
been
in
the
last
months
right.
C
C
The
way
we
are
attaching,
let's
say
or
contributing
to
the
spec
right
now,
it's
super
grown
because
we're
we're
modifying
the
the
2.0.0
version
right
directly
and
at
some
point
this
needs
to
be
split.
Like
okay
2.0.0,
it's
finished,
it
cannot
be
attached.
This
is
what
it
is,
and
maybe
we
start
working
on
2.0.1,
which
is
a
fix
of
this
one
right,
and
for
this
we
don't
need
to
release
any
tooling
or
anything.
This
is
just
a
fix
on
the
on
the
spec
itself.
Right,
that's
how
I
see
it.
C
But
again
we
don't
have
this
process
in
place
yet
because
we
had
we
hadn't.
We
had
now
time
to
to
work
on
this,
basically
and
and
also,
for
instance,
the
change
you
did.
The
other
day
was
introdu,
wasn't
introducing
a
breaking
change,
but
it
was
introducing
a
new
feature.
So
so
it's
not
a
it's,
not
a
patch
version.
It's
a
minor
version
that
should
be
increased.
It's
2.1
right,
not
2.0.
C
C
It
was
just
myself
last
year,
sim
cycle
like
a
lifetime,
but
it
was
like
last
yes
last
year,
so
so
now
we
have
to
really
change
this,
this
process
and
probably
automate
it
as
well
and
and
yeah,
and
this
will
be
like
a
review
process
whenever,
whenever
you
add
a
a
patch,
that's
fine,
because
it
shouldn't
have
an
impact,
but
whenever
you
add
minor
version
that
will
be
reviewed
and
probably
there's
there
will
be
some
people,
some
designated
people
which
we
don't
know.
Yet.
C
Who
will
be
that
review
of
this
change
right,
like
a
committee
or
technical
committee,
or
something
that
knows
about
the
spec
and
especially
if
we
can
have
some
people
that
are
users
of
the
spec
and
have
a
look
at
this
new
feature
and-
and
you
know
that
they
can,
they
can
communicate
if
they
they
like
the
picture
as
it
is,
or
there
should
be
something.
This
would
be
something
different
because
they
have
the
same
need
but
slightly
different.
You
know
this.
C
This
must
be
something
that
we
we
work
on
say
as
a
team
right.
It's
not
just
someone
comes
propose
a
new
feature
and
it's
added
immediately,
because
it's
a
spec,
if
it's
if
it
was
if
it
was
a
tool
it
wasn't,
it
would
not
be
that
difficult.
But
if
you
had
to
spec,
then
you're
committed
to
maintain
support
to
this
spec
for
long
time.
Right
like
we
will.
C
If
we
make
a
mistake
on
the
spec,
then
we
will
have
to
maintain
this
mistake
for
a
long
time
right
or
you
know
what
I
mean
so,
and
I
didn't
have
time
to
really
evaluate
your
proposal
like
in
a
good
way
like
let's
sit
down,
let's
put
some
real
use
cases
and
see
how
it
fits
so
yeah.
It
was
like
yeah,
it's
nice
that
you
proposed
it.
C
D
Makes
make
sense
to
me
I'll
just
wrap
up
when
I
wanted
to
stand
up
with
my
team,
so
one
thing
was
not
clear
to
me:
is
that
if
there
are
some
other
things
which
I
know
like
these
are
the
things
we
need
to
have
for
2.1
and
then
work
on
that
and
help.
You
also
release
that
if
it's
like
some
clear
points,
the
second
thing
is
that
I
don't
want
other
requirements
or
the
requested
features
to
blocking
something
which
is
ready.
D
D
It
needs
a
lot
of
work,
so
I
don't
want
other
things
which
have
somewhat
required
to
block
keep
blocking
something
we
got
done.
We
I
want
us
to
be
keep
keep,
releasing
some
minor
versions
and
getting
reviews,
but
I
like
your
idea
that
we
don't
want
to
release
a
version
until
it's
it.
We
get
enough
feedback
from
the
community,
because
maybe
people
are
not
that
much
active
like
this.
Usually,
people
are
not
developments
active
about
the
open
source
projects
until
they
face
they
should
until
they
start
using
it.
D
When
it's
reviewed,
they
are
not
there
at
that
time
and
later
on
later
on,
they
show
up
and
say,
like
yeah,
do
you
did
this
and
we
don't
know-
and
this
does
not
solve
our
this
use
case
of
that
use
case-
is
there?
Is
there
could
be
there'll
be
a
way
we
can
do?
2.1,
slash
beta,
2.1,
slash
alpha
and
people
start
using
it,
and
then
yeah
we'll
be
able
to
get
some
feedbacks
of
people
and
adjust
it
and
then
release
a
2.1
which
is
more
spilling.
C
Yeah,
so
that's
that's
actually
the
way
we
will
proceed
with
this,
because
with
release
candidates
and
or
beta
or
alpha
or
whatever,
for
the
minor
and
major
versions
for
the
patch
versions.
I
don't
think
we
need
to
be
releasing
anything.
It's
just
a
patch,
so
this
will
happen
like
immediately
right,
like
you
find
something
we
patch
it.
C
There
should
be
something
that
triggers
a
new
release
of
the
spec
and
we
don't
have
to
be
releasing
manually
this
and
making
a
whole
event
that
we
release
a
new
version
of
the
spec,
because
it's
just
a
patch,
it's
probably
a
typo
on
the
text
or
something
like
this
right,
but
for
minor
and
major
versions.
We
probably
so
my
thought,
keeping
it
short
is
we.
I
think
we
should
have
like
a
calendar
like
a.
D
The
one
thing
is
I
was
thinking
is:
if
we
don't,
if
we
don't
release
the
release
candidates
or
alpha
beta,
we
may
not
get
even
enough
feedback
until
the
actual
date
comes.
So
I
also
want
us
to
us
keep
releasing
some
minor
versions
as
release
candidates,
which
are
which
the
users
clearly
know
that
this
is.
C
That's
true,
and
one
of
the
things
that
we
want
to
put
in
place
is
that
probably
myself
and
maybe
jonas
as
well
will
be.
We
will
be
working
on
a
set
of
use
cases.
Real
real
world
use
cases
where
we
will
test
the
the
spec
against
right.
So
whenever
we
have
a
new
version,
we'll
try
to
test
the
spec,
the
new
version
of
the
spec
against
these
real
use
cases
this
they
will
be
available
on
the
on
the
website
and
and
that
that
means
that
we'll
be
working
on
the
spec.
C
It
is
following
a
release
process
similar
to
the
lgs,
so
where
we
only
maintain
some
versions
on
the
long
term,
for
instance
the
the
the
even
versions
the
even
numbers
are
long-term
support
and
the
odd
numbers
are
not
long-term
supported
so
that
we
can
instead
of
release
candidates
right.
So
you
just
you
can
just
start
releasing
releasing
releasing,
and
you
only
have
to
make
sure
that
two
points
something
needs
to
be
stable
and
four
point.
C
D
But
make
sense
I
I
would,
I
would
prefer
if
we
could
do
release
candidates
somehow
that
would
be
super
helpful
and
for
this
specific
message,
id
thingy
the
the
requested
feature,
so
it
would
be
useful
for
us
already.
I've
been
like
doing
a
hack
around
it
for
two
years
or
one
year,
and
then
another
guy
who
actually
created
an
issue
in
the
tool
was
also.
D
I
wanted
to
have
this
thing
within
the
tool.
Then
I
was
like
no,
this
is
something
schema
should
do
and
then
I
opened
it
and
then
took
us
also
another
issue
already
in
within
the
sync
api,
where
someone
was
asking
for
support.
So
we
already
have
some
use
cases
where
people
are
interested
in
having
this
thing.
So.
D
C
D
C
A
C
C
C
I
don't
know
if
you
notice,
but
the
only
repo
that's
missing
this
process
is
actually
the
spec
all
the
tooling
is
already
has
already
this
all
this
process,
automated
semi
semi
automated,
like.
I
think
there
is
almost
that
there's
just
a
few
things
missing,
but
but
it's
almost
automated
there
and
we
need
to
figure
out.
What's
what
will
be
the
process
for
the
spec?
That's
it
because
it
impacts
the
whole
project.
If
we
change
the
spec
suddenly,
it's
like
shaking
the
whole
project
like
like.
D
Right
there
can
you
create
an
issue
to
track
the
progress
like
have
a
way
of
releasing
release
candidates
or
like
have
these
candidates
to
put
an
issue.
We
discuss
it
there
we
finalize
it
and
then
we
and
then
we
start
releasing
these
candidates
for
the
schema
and
people
can
use
it
experiment
with
it
and
then
also
document.
Some
of
the
stuff
about
dates,
like
you
said,
like
every
six
months,
will,
will
try
to
release
a
minor
version.
D
D
C
Yeah
it's
I
still
remember
the
times
when,
when
we
were
like
five
in
the
channels,
so
yeah
it's
something
it's
already
something
so
yeah,
and
this
is
I
mean
it
to
me.
I
I
don't
have
the
data,
but
to
me
it
feels
that
it's
growing
faster.
So
we
get
more
and
more
users
every
day,
yeah
or
every
week.
Let's
say
so,
yeah,
that's
the
feeling
I
get,
but
I
don't
have
the
data.
To
be
honest,.