►
From YouTube: Spec 3.0 meeting (March 15, 2023)
Description
B
A
I
just
have
a
question:
do
you
have
any
links
to
a
node
or
anything
that
I
should
be
looking
at
for
this
or
not
really.
B
A
Oh
perfect,
this
is
exactly
what
I
was
wondering
about.
I
hadn't
noticed
the
the
topics
that
you
added.
Sorry
about
that
thanks.
B
Thank
you.
Anyone
else
have
anything
hi.
So
we
do
have
a
few
items
on
the
agenda.
I
think
I
want
to
rotate
some
things
around.
So
my
suggestion
is
that
we
start
with
the
old
some
of
the
things
that
need
to
be
revised
or
discussed
that
we
previously
talked
about,
and
then
we
jump
into
some
of
the
new
stuff
such
as
stocks.
B
Is
everyone
cool
with
that
cool
all
right,
so
I'm
going
to
start
with
the
release
schedule
and
then
heiko
maybe
give
an
update
on
the
request
for
player
stuff
and
what's
missing
what
you
need
help
with,
and
then
we
can
talk
about
the
schema
stuff
reference
and
then
we
end
with
Docs
all
right.
So,
regarding
the
release
schedule
last
meeting,
we
proposed
that
at
least
two
more
items
are
in
the
works
and
should
be
accepted
as
changed
to
the
spec
3.0.
B
So
far,
nobody
has
objected
to
that.
So
I
would
assume
that
we've
by
now
can
accept
that
this
is
the
code
freeze.
This
is
what
is
included
in
Spec
3.0.
We
do
have
an
outstanding
regarding
the
schema
stuff,
but
let's
see
how
that
discussion
goes,
but
otherwise
I
am
assuming
that
this
will
take
effect
as
of
right
now,.
B
B
Cool
all
right,
moving
on
requests
will
play
stuff.
C
B
Yeah
so
as
fast
I
can
tell
we
have
we
have
a
PR
for
the
Json
schema
files
that
magic
created.
We
do
not
have
any
proposed
changes
to
the
parser
itself.
That
adds
these
requests
for
pi
stuff
I
go.
Is
that
something
that
you
are
planning
on
doing
or
something
you
need
help
with.
C
B
D
B
All
right
so
we'll
need
to
figure
out
who
want
to
help
there.
I'll
throw
up.
I
might
just
create
an
issue
there
in
the
parser
that
we
need
to
change
or
add
the
feature.
Now
that
it's
been
added
for
the
spec
itself
and
that's
ping
Magic
on
the
Json
schema
files
and
see
how
active
he
is
on
that
or
someone
else
has
to
take
it
to
the
finish
line.
B
A
Yep,
can
you
remind
me,
is
there
already
a
Target
date
for
releasing
three
expect
three.
B
B
A
D
Yeah
I
know
all
the
things
that
that
we
should
probably
now
focus
on
on
getting
speculation,
schemas
and
and
the
parts
are
anticipated
and
and
that's
it
I
think
that
should
be.
You
know
for.
D
Go
you
don't
have
to
do
it,
though,
so
what
I'm
saying
is
like
we
should
be.
We
should
be
doing
it,
but
you
don't
have
to
do
it
if
you
don't
want
to.
If
you
want
to
have
a
look
at
the
at
the
other
at
the
622.
That's
completely
fine,
but
you
know
like
we
still
have
to
as
a
community.
We
should
look
into
doing
it
as
well
right,
but
I
don't
feel
like
you
have
to
do.
It
I
mean
usually
the
same
person
that
Champions
the
spec
issue,
Champions
the
other
ones,
but.
C
B
That's
it
he's
not
saying
that
you
that
you
shall
not
do
it.
So
if
you
want
to
yeah.
D
D
C
C
C
B
D
C
E
C
Format
and
contains
the
schema.
Therefore
I'm
gone
one
step
further
and
created
an
pull
request,
910
for
exactly
this
one
here
so
yeah
now,
I
need
you
to
review
and
comment
and
see
what
we
can
do.
I
will
do
now,
a
little
introduction
of
it.
C
Schema
yeah.
What
we
have
here
now
is
this
is
a
message
object.
A
message.
Object
has
a
payload
and
yeah.
The
payload
needs
to
be
in
some
kind
of
schema,
so
it
makes
no
sense.
Sorry,
I
I'm
not
done
with
all
of
the
examples.
I
need
to
find
in
in
good
one
sorry
not
available.
C
It
types
gamma
as
just
two
Fields
the
schema
format
and
again
schema
I,
don't
know
if
it's
the
best
name
but
yeah
this
one
here
is
now
of
type
any.
So
you
can
say:
hey
it's
an
Asic
API
schema.
So
this
one
here
is
default.
You
don't
need
to
set
it.
You
can
say
hey.
Those
are
my
I
think
API
schema
as
defined
before
so
the
this
one
is
the
Json
schema
with
the
extended.
C
C
Okay
yeah,
if
I
defined
here,
protobuf,
2,
3
and
XML
for
a
beginning,
so
maybe
there
are
other
requirements
or
other
protocols
we
need,
maybe
not
so
if
soon
as
you
have
yeah
so
and
generally
I
talk
what
we
put
no
Lucas
provided
us
here
and
took
it
one
step
further,
because
you
can
have
with
the
schema
inline,
but
in
general
you
want
using
dollar
refers
in
the
schema.
So
you
cannot
simply
tell
this
here
anymore.
Just
only
schema.
C
B
C
B
Stop
all
right,
so
my
first
one
is
that
you're
mixing
two
things
together
here.
The
first
one
is
you're
mixing
allowing
referencing
to
protobuf.
That's
a
whole
issue
in
itself.
It
has
nothing
to
do
with
having
a
component
section,
be
able
to
reference
other
ski
or
having
other
schema
formats
within
the
component
section.
B
C
You
can
say:
okay,
I,
have
a
message:
I
have
a
paid
message:
I
have
a
payload
and
the
payload
is
schema
protobuf
and
it's
text.
So
you
can
also
say
yeah,
it's
my
Proto
and
then
just
going
to
be
this
one
here.
My
portal.
C
C
Okay,
this
is
the.
E
C
I,
don't
remember
adjustable
components,
my
product
and
saying,
hey,
and
here
is
this.
One
is
sorry
this
is
my
Proto
I
hate
it.
This
is
housing.
C
C
E
D
C
E
C
C
F
But
can
you
like
why
can't
why
do
you
I,
I,
honestly,
don't
get
why
you
need
async
API
schema?
Why,
whatever
you
have
under
us,
an
API
schema
can't
be
just
they're
under
schemas.
What's
the
I
don't
see
the
difference.
B
C
Okay,
let
me
try
to
understand
what
you
want:
I
think
it's
called
Foo,
so
if
just
try
to
do
it,
so
you
want
to
do
this
one
here
if
I'm
right.
C
F
We
talked
about
it,
I
think
in
the
past,
when
mache
was
championing
this
idea,
and
he
planned
to
like
actually
actually
discussed
this.
This
case
of,
like
referencing
different
schema
under
the
other
schema
format,
but
we
said
like
in
the
end
it's
just
about
writing
in
the
spec
that
it's
not
allowed
like.
You
should
not
mix
schemas
and
who
would
like.
Who
would
really
do
it?
Who
would
mix
Json
schema
with
Avro
in
the
end
like.
A
I
have
a
question
yep
just
to
make
sure
I'm
following
so
I
believe
that
different
people
in
the
community
might
want
to
use
different
kind
of
schemas.
However,
am
I
understanding
correctly
that
what
you're
saying
right
now
that,
in
the
same
application,
you
should
only
use
one
kind
of
schema.
Is
that
what
you're
saying
no.
A
D
So,
in
any
case,
hikers
what
you
showed
showed
up
as
before
having
asyncps
schema
on
their
components.
With
this
example,
you
can
still
mix
schema
types
right
because
in
the
dollar
ref
I
can
point
to
to
to
the
schemas
side.
You
know
I
can
still
mix
right,
so
that's
not
prevented
on
the
other
example.
So
that
will
always
happen
right.
C
D
F
D
Do
it
yeah
at
least
we
don't
have
a
bunch
of
different
weird
names
like
async,
kids,.
C
C
D
Requests
or
maybe
yeah
that
was
an
issue,
maybe
so
what
he
proposed
was
probably
the
same
or
very
similar
to
this.
So
so
yeah.
F
No,
it's
actually
it's
actually
the
same,
because
I
I
made
the
summary
the
last
time.
The
only
difference
is
that,
in
my
summary,
there
was
we
I
did
not
discuss
the
the
option.
That
schema
can
be
also
a
string
like
with
this
Proto
example,
because
I
I
didn't
care
about
Proto
then,
but
it
makes
sense,
of
course,.
B
E
I
mean
I
I.
This
is
Jesse.
I
do
think
that
it's
worth
worth
considering
it
because
you
know
I,
think
everybody's
recognized
that
XML
is
important.
Certainly
we
see
a
lot
of
clients
who
are
using
XML
and
then
I
think
adding
Pro
buff
into
it
is
another
non-json
format.
That's
really
really
important,
so
I
think
it's
considering.
B
Agree
by
the
way,
I
completely
agree,
I
just
don't
think
that
we
should
mix
adding
those
capabilities
of
non-json
stuff
into
async
API,
alongside
also
changing
or
having
this
conversation
of
how
we
should
have
schemas
and
components
where
we
couple
the
schema
and
schema
format
together.
I,
don't
believe
that
conversation
should
be
happening
at
the
same
time,
because
it's
it's
too
complex.
In
my
opinion,
yeah.
D
So
so
conversation
is
one
thing,
but
I
also
want
to
remark
that
this
is
already
possible,
so
people
can
already
use
products
on
the
spec
right,
so
you
just
cannot
use
it
inside
component
schemas,
but
you
can
go
to
the
message
payload
and
specify
a
schema
format
of
prod
above
and
then
use
the
payload
as
a
string
as
as
Haiku
is
doing,
and
you
can
already
do
this
right.
So
in
lighting
it's
already
accepted
because.
D
B
E
D
So
what
I
mean
is
by
by
spec
this
is
allowed,
but
in
practice
this
is
not
because
because
your
practice
is
not
yet
implemented.
If
you
want
right,
so
we
never,
we
never
implemented
it
right.
Nobody
implemented
it,
but
like
many
other
things
like
there,
there
are
many
other
situations
in
that
might
work
as
per
spec,
but
they're
not
working
well
on
tooling,
because
it's
not
well
implemented,
or
it's
not
really
implemented
at
all.
So.
E
Yeah
but
think
the
difference
is
sorry
Frank
I
think
the
difference
here
is
that
it's
not
working
first
back
because
it
just
sort
of
you
know
defining
it
as
a
Json
any,
but
it's
really
on
Json
at
all
is
really
sort
of
twisting
Json.
So
it's
not
like
it's
just
not
implemented
because
we
haven't
gotten
around
to
it.
It's
not
implemented
because
it's
really
not
technically
sound
I
think
those
two
things
are
different.
D
D
D
What
I
mean
is
that
this
is
this
is
already
possible
if
you
implement
it,
for
instance,
I
think
you
you
have
your
parser
at
Solace.
If
you
implement
it
in
your
parser,
then
your
recently
documents
will
be
able
to
have
it
right
because
there's
nothing
stopping
in
the
spec,
stopping
you
in
respect
to
to
have
schema
with
a
string
with
product
buff
inside
right.
There's,
nothing
stopping
you
that
only
tools,
so
you
only
have
to
build
a
tool.
D
That's
the
only
thing
we
didn't
want
to
get
into
this
and
implemented
this
on
the
tools
yeah.
Precisely
for
for
the
reason
that
Jonas
was
mentioning
to
not
mix
the
conversations
right,
because
we
don't
want
to
mix
the
conversations
of
this
being
supported
alongside
with
dollar
rev,
pointing
to
a
product,
buff
file
right
or
an
xsd
file.
So
we
want
to
separate
two
things
right
and
I
think
this
is
cool
yeah
in.
E
D
End
I
think
it's
cool
that
we
can
mention
that
you
can
move
these
things
here
under
component
schemas.
Now
you
can
have
product
above
XC
Opera,
whatever
you
want
to
have
here
right,
I,
wouldn't
showcase
it
with
xsd
and
protobuf.
Yet
I
will
showcase
it
with
Abra,
maybe
and
other
versions
of
distance
schema,
maybe
just
to
not
complicate
the
conversation
more
and
then
once
we
have
dollar,
ref
or
ref
or
whatever
you
want
to
call
it
support
to
point
to
to
protoba
for
xsd
documents.
D
C
One
we
need,
we
need
F4
non-json,
so
we
so
we
need
to
add
examples
for
non-json
based
schemas
to
show
that
it
works
and
the
second
one
is
I.
Do
the
the
championship
here,
because
I
need
product
after
support
mm-hmm.
D
D
Is
that
it's
okay
to
add
these
examples
when,
but
this
this
specific
issue
was
not
about
introducing
non-json
schema
support,
it
was
more
about
being
able
to
have
what
we
were
in
support
under
component
schemas,
so
again,
I'm
not
against
it
I'm,
just
saying
that
which
would
probably
mix
this
we
sold
them
mix.
This
conversation,
this
com,
these
two
conversations
because
then
and
and
I'm
and
I'm
saying
it
because
of
precisely
I,
don't
know
how
to
say
it.
B
D
Yeah
to
make
to
minimize
the
complexity,
the
one
thing
is
about
moving
what
we
already
support
in
in
tools
and
everything
under
component
schemas
and
then
another
thing
is
like:
okay,
that's
already
done.
That's
already
launched.
Okay,
let's
put
one
more
example:
now,
let's
get
into
embedding
inlining
protobuf
there
in
the
document
and
and
access
the
in
showcasing,
how
you
could
do
it,
but,
as
Jesse
said
before,
like
yeah,
if
tools
are
not
supporting
it,
then
it's
not
really
supported
right.
D
A
So
I
actually
want
to
step
in
here
a
little
bit
because
I
feel
like
we're
accidentally
just
repeating
ourselves
a
lot
so
I
will
say
this
I
completely
understand
that
you
know
we
have
a
schedule
to
keep
and
we
only
have
26
minutes
left
to
this
meeting.
So
we
got
to
stay
on
topic.
However,
this
confusion
brings
up
a
very
important
point.
We
can
already
tell
that
the
community
in
general
will
be
confused
when
this
starts.
A
You
know
being
discussed
more
and
people
start
wanting
to
implement
this,
not
just
in
their
component
schemas,
but
also
in
tooling,
because
people
are
going
to
ask
the
same
questions
that
Jesse
just
asked.
So
what
I
would
recommend
in
this
scenario
is
we
want
to
make
sure
that
there's
at
least
some
basic
rough
documentation
stating
that
we're
branching
out
and
allowing
this
and
looking
into
this
for
component
schema,
while
adding
clarifying
notes
in
the
documentation
that
this
is
still
in
progress
and
not
yet
available
in
expanded
to
tools
and
parsers.
C
B
B
F
Folks,
like
actually
I
I,
disagree,
I
just
checked
again
the
spec,
because
in
the
past
I
had
similar
discussion,
not
about
protobuf,
actually
about
Avro.
Why
people
cannot
just
pass
a
a
string
instead
of
instead
of
they,
they
have
to
do
a
file,
a
reference
or
whatever
and
I
just
checked,
and
this
bag
is
pretty
clear
and
there's
a
clear
example
when
it
says
okay,
payload
is
any,
but,
for
example,
Avro
should
be
inlined
as
either
a
yaml
or
Json
object,
not
a
string
to
be
parsed
to
yamu
or
Json.
F
It's
not
an
example.
It's
a
text.
D
Which
can't
what?
What
would
we
say
there
on
the
spec
is:
don't
put
it
as
a
string,
because
you
can
put
it
as
a
full
Json
object
there.
So
don't
don't
make
it
a
string
that
we
will
have
to
parse
we're
just
telling
people
hey.
This
is
how
you
should
be
using
it,
but
that
doesn't
apply
to
all
the
other
formats.
If
you
want
to.
E
Exactly
which
is
the
whole
problem,
so
I
mean
I,
I,
think
exactly
I
think
that's
a
bit
waving
our
hands
like
if
we,
if
I,
think,
if
it
really
wasn't
the
problem
to
just
inline
Avro,
we
would
just
said:
go
ahead
and
add
an
inline
abro,
but
the
problem
is
I,
I,
think
I'm
with
haiko
and
Lucas.
That
I
think
there
is
a
significant
problem
with
it.
I
don't
know
if
it's
necessarily
even
at
a
you
know,
just
the
tooling
doesn't
support
it.
C
C
F
D
D
Be
passed
and
the
string
is
valid.
Json
a
string
is
valid
Json.
Are
we
confusing
Json
with
Json
objects,
because
I
don't
mean
that
a
number
is
validation?
A
Boolean
is
validation,
yeah
validation.
So
if
you
have
a
a
string
with
that
syntax
product
thing
inside
that's
validation,
that's
okay!
That's
completely
validation.
What
I'm
suggesting
here
is
that
and
and
it's
on
the
spec
right
or
in
if
it's
not
consistent,
for
whatever
reason
we
can
fix
it,
but
what
I
mean
is
that
you
can
you
you
can
do
it
like
this?
D
B
D
Convert
it
to
a
string
to
a
multi-line
string
right
so
when
we
convert
it
back
to
yaml,
this
is
going
to
be
a
single
line,
a
single,
a
string
with
a
single
line
with
lots
of
Slash
n
at
the
end
right
for
the
multi-line
and
all
stuff,
and
what
I
mean
is
that
it's
gonna
be
serialized
as
Json
right,
because
that's
what
the
spec
supports,
because
if
we
don't
serialize
it
that's
Jason
I
mean
we
just
drop
it
there.
D
C
Sure
that's
my
point:
yeah,
that's
totally!
Okay,
but
what
I
a
little
bit
fear
is.
If
you
write
this
back
Json,
let's
make
yamas
whatever
the
whole,
you
call
it.
You
will
face
a
problem
because
we
link
now
spec
format
and
the
expected
schema
type.
So
in
case
of
protobuf,
we
expect
a
string
to
be
a
protobuf
if
it's
I
think
API
schema.
We
expect
here
an
object
structure
in
Isaac
API,
schema
format.
So
is
it
possible
to
spec.
B
C
I
think
API
is
back
yaml
spec
Json.
You
create
the
spec
of
this
bag.
So
not
the
text,
one,
the
machine,
readable
one.
Is
it
possible
to.
B
B
C
B
D
Need
the
schema
parser,
that's
the
thing
you
need
your!
You
need
a
protobuf
schema,
parser
and
right
now.
Nowadays,
as
it
is
right
now
without
adding
or
altering
the
spec
at
all,
you
can
create
a
prod
above
schema
parser
in
line
the
whole
the
whole
product
file
inside
string,
as
you
think
here,
and
that
will
work.
D
D
Forget
about
component
schemas
what
I
mean
is
inside
message.
Failure
if
you
do
this
inside
message,
payload
as
it
is
right
now,
that's
gonna
work.
So
if
you
really
need
that
urgently
for
product
to
work,
don't
wait
for
this
go
and
make
it
an
inside
message.
Failure
specify
schema
format
there
and
the
payload
to
be
a
product
file
implement
the
tool
that
you
need.
We
can
add
it
to
the
parser.
D
It
is
about
keep
supporting,
let's
say
only
Json
schema
because
still
as
it
is
right,
Json
based
schemas,
but
under
component
schemas
right.
D
As
Jonas
was
saying,
if
we
keep
mixing
the
conversation,
then
look
at
this,
for
instance,
we
should
be
discussing
if
we
structure
this
like
like
this
or
like
that,
but
instead
we're
discussing
about
product
buff
here
when
we
show
them
be
discussing
protobuf
today
it
will
be
about
something
else:
okay,
yeah.
That
thing
said
so
that's
my
point,
but
it's
normal
it's
because
the
conversation
gets
really
complex
and
and
Tangled,
and
then
it's
like
it's
complicated
to
to
to
understand
and
And
to
clarify
what
what
we
mean
right.
D
So
this
this
issues
will
then
be
about
protoba
for
xsd.
It
should
be
about
moving
what
we
are
in
support
in
the
tools
and
everywhere
right
to
to
under
components
and
schemas,
and
then
we
can
create
another
one
and
say
like
okay,
so
now
that
it's
under
component
schemas,
let's
start
showcasing
or
as
Alejandra
said,
for
instance,
let's
make
it
clear
now
it
was
possible
before
now
it's
even
more
possible
because
you
can
reuse.
D
You
can
inline
things
here
like
protobuf
NXT,
but
our
tools
are
not
supporting
it
yet
so
yeah,
it's
still
in
the
works.
A
A
Do
you
want
me
to
start
working
on
it
with
you?
How
can
I
best
support
this.
C
B
C
A
E
C
C
Too
much
issues-
damn
yeah
I
found
this
one
here.
This
is
what
it's
all
about.
Referring
to.
Afro
schemas
was
already
defined
in
2.0
of
using
API.
E
C
E
C
F
C
Nope
as
I
understand
the
Json
reference
document
or
yeah
request
for
comment
correctly,
it's
only
allowed
to
ref
to
other
other
API
specs,
not
to
complete
external
specs.
B
D
That's
completely
fine
suggestion
reference,
Json
pointer,
sorry,
not
just
in
references,
one
centation
pointer
as
well.
That's
another
thing,
so
so
Json
references
are
allowed
to
include
there
before
the
the
hashtags
or
the
pound
sign
yeah.
Before
that
you
can
have
a
URL
or
a
file.
You
know
like
it
can
be
whatever
you
want,
something
that
you
know
a
resolvable
address.
If
you
want,
can
be
yeah.
C
D
Has
sent
yeah,
it
can
be
file,
columns
less
whatever
that's.
Actually,
this
is
pretty
common
and
and
yeah,
and
the
last
part
there's
some
pointer,
like
hashtag
user,
create
it's
because
this
the
resulting
that
Json
file
that
you're
pointing
there,
because
it's
an
Android
file,
but
it's
average
Json
as
I
said.
C
D
B
I'm
gonna
suggest,
let's
start
a
meeting
only
for
discussing
this
product
of
stuff.
None
Json,
stuff,
I'm
gonna
propose
a
meeting
from
either
next
week
or
next
week
again
and
then,
let's
just
discuss
only
that
because
it's
it's
just
a
huge
Co,
so
yeah
yeah.
Let's
do
that.
I'm
gonna,
make
sure
to
schedule.
Yeah.
C
And
I
will
just
to
ensure
that
this
link
thing
here
is
not
a
breaking
one,
because.
C
Wait
for
for
the
room.
D
A
B
B
We
have
some
unified
reference
Behavior
where,
instead
of
using
a
simple
string,
we
use
dollar
ref.
We
have
some
common
metadata.
Fields,
that's
been
added.
We
have
moved
some
properties
around,
then
we
split
out
a
property
into
two
parts
and
then
we
added
some
more
reusable
objects
within
component
section.
B
A
Start
get
the
process
as
organized
as
possible,
so
what
I'll
do
today,
for
example,
because
I'm
assuming
you
haven't
created
issues
for
this
yet
is
I,
want
to
create
a
the
GitHub
version
of
an
epic
for
Spec,
3
documentation
and
then
inside
that
epic
issue.
I
will
outline
all
of
these
tasks
that
you
have
already
documented
here
and
I
will
refrain
from
adding
the
last
two,
because
you
just
mentioned
that
you're
still
up
in
discussion
about
whether
or
not
we're
going
to
include
this
with
the
Spec
3
release.
A
So
after
you
confirm
we
can
add
those
extra
tasks
and
then
we
can
work
individually
on
each
task
and
you
know
start
writing
editing
whatever.
So
I
will
do
that
today
and
I
will
tag
I'm
assuming
minimum
Jonas
and
haiko
haiko.
Can
you
please
give
me
your
GitHub
handle
here
in
the
chat
that'll
help
me
find
you
easily
and
who
else
should
I
tag
in
there.
E
A
A
Okay,
Lucas,
do
you
want
me
to
tag
you
I,
assume
I.
A
Okay,
does
anyone
else
in
this?
Current
call
want
me
to
tag
them
specifically
or
no?
Okay,
good,
so
I'll
do
that
today
to
start,
and
then
I
just
wanted
to
confirm,
because
I
want
to
make
sure
that
I
do
my
best
to
try
to
help
this
effort.
A
So
I
want
to
understand
how
it
could
be
the
most
helpful
useful.
Do
you
want
to
start
writing
the
documentation
and
then
Loop
me
in?
Do
you
want
me
to
start
writing
it
with
you
like?
What
do
you
want.
B
I
think
we
should
I
I
would
suggest
that
we
start
by
figuring
out
what
changes
need
to
be
done
for
what
changes
and
respect,
because
I
have
a
feeling
that
it
it
varies
a
lot
where
and
how
we
adapt
the
documentation
because,
for
example,
request
Supply,
that's
a
whole
new
feature.
It
might
need
a
whole
new
section
in
the
documentation
it
might
need,
like
it
hasn't
been
described
before,
for
example.
B
So
there's
probably
not
a
lot
of
changes
that
need
to
happen,
but,
for
example,
for
a
change
of
perspective
with
no
it's
like
with
this
new
operation,
action
and
decoupling
of
operation
channels,
I'm,
assuming
there's
a
lot
of
already
existing
dots.
We
need
to
change
so
I
have
a
feeling
we
have
to
go
through
each
one
of
them
create
an
issue
where
each
actionable
item
is
like
each
change
need
to
happen
in
order
to
split
them
up
even
more.
A
B
A
A
F
Don't
think
it's
in
case
of
docs,
it's
better!
It's
it's
good
to
follow
this
structure,
I!
Think
it's
more
to
follow
the
structure
of
the
dogs
because,
like
in
the
end
like
when
you're
gonna
fix
some
tutorial,
it
may
attach
to
different
topics
from
the
list
as
well.
So
so
like
basically
looking
from
the
from
the
docs
perspective
and
the
content
buckets
that
we
have,
there
might
be
that
in
case
of
Concepts,
there's
not
much
to
change
the
only
things
are
additions,
maybe
concept.
A
F
A
F
Then
it's
probably
one
ticket
or
one
issue
or
like
one
issue
per
per
document.
So
that's
why
I'm
saying
that
it's
not
necessarily
this.
What
is
now
shared
on
the
screen
will
be
super
useful
for
you
in
the
structure
of
the
issues.
That's
what
I
mean
so.
A
What
I'm
think
is
honestly
pretty
similar
to
what
you
just
described:
I,
don't
really
know
that
we
need
to
see
if
GitHub
has
the
ability
in
their
UI
for
subtasks
subjects,
I
more
think
that
each
one
of
these
points
correlate
to
changes
we
need
to
make
and
there
could
be.
As
you
know,
we
just
discussed.
Each
point
could
be
five
changes.
Maybe
one
point
is
only
one
change
like
we
don't
know
so.
A
I
think
that
each
task,
converted
to
an
issue
will
probably
have
more
than
one
pull
request
in
different
areas
that
we're
changing,
but
I
think
that
you
know
just
to
keep
things
organized
I
think
that
it
everyone
will
understand
that
this
issue
is
specifically
for
any
changes
to
request
for
apply
functionality
and
that
could
be
tutorials,
Concepts
Etc,
the
spec
for
sure
so
I
think
that's
the
most
organized
thing.
A
B
F
What
about
this
concept
of
open,
not
open
of
the
office
hours?
You
had
that?
Yes,
these
meetings,
we
actually
should
have
regular
office
hours,
so
people
can
jump
in
ask
questions.
What
changes
are
coming
in
so
docs
could
be
also
addressed
because,
like
especially
that,
like
Alejandra
will
not
solve
all
our
issues.
Alejandra
will
guide.
I
bet
a
lot
of
community
members
that
will
contribute
so
having
an
open,
regular
meeting.
It's
also
going
to
be
a
good
place
for
these
contributors.
B
F
Are
not,
for
example,
today
on
the
meeting
that
they
will
be
able
to
jump
in
and
ask
any
questions
they
want
like,
for
example,
like
hey
I
got
a
task
from
Alejandra
and
I'm
gonna
work
on
whatever
document
a
b,
any
guidance,
and
then
we
can
like
we
shared
what
we
know.
It's
recorded,
it's
good
input
for
dogs.
A
Yeah
I
see
your
point:
I
mean
yeah,
I,
guess
the
also
the
nice
thing
about
it
doing
it.
That
way
is
that
it
helps
recruit
more
contributors
for
docs,
which
is
of
course
great
Community.
Building
efforts
for
Community
Building
efforts,
I
mean
yeah,
sure
I'll
help
one
yeah
I
can't
think
it's
too
early
words.
A
I
can
join
a
new
meeting
to
help
out
and
I
guess.
Just
let
me
know
when
I'm
more
awake.
What
you
need
for
me
for
those
meetings.
A
Nine
is
great,
ninth
is
great
I.
Just
have
you
know
a
lot
of
dogs,
they
keep
me
busy
all.
B
Right,
let's,
let's
try
to
keep
it
in
this
meeting
then
and
then
slowly
transition.
This
meeting
into
Community
discussion,
type
thing
where
people
can
get
help
with
spec
free
punches.
A
So
is
to
make
sure
I
understood
you
correctly.
My
follow-through
is
to
Simply
join
you
in
the
next
Factory
meeting.
A
F
Yeah
just
final
link
again
from
the
content
buckets
perspective
of
the
docs
in
case
of
reference
docs
like
so
for
you
for
your
information
Alejandra.
We
already
like
publish
this
pre-release
async
API
spec.
Oh.
D
No
just
one
thing:
I'm
gonna,
add
one
more
thing
to
the
specific
zero
now
that
I'm
realizing
so
one
more
change
just
to
prevent
four
zero
to
happen.
Three
months
later
so.
D
If,
at
some
point
we
want
to
have
product
buff
and
access
the
reference
support,
then
we
probably
should
not
use
dollar
ref.
We
still
use
something
else
right,
so
I'm
gonna
propose
that,
except
inside
Json,
schemas
everywhere
else,
where
we
use
dollar
ref,
we
rename
it
to
ref,
for
instance,
without
a
dollar.
So
it's
just
our
ref,
not
the
Json
skill,
not
the
decent,
schema,
rep
dollar
ref,
so
we
Define
the
behavior.
D
D
No,
no,
no
just
saying
that
I'm
gonna
I'm
gonna
do
this!
I'm
gonna
propose
this
because
I
think
it's
a
I
think
it's
gonna
be
important
to
you.
B
D
I,
don't
I
probably
didn't
explain
it
correctly.
Sorry,
so
what
I
mean
is
not
so
much
about
new
Behavior
or
anything
like
that.
Just
renaming
renaming
it
right.
So
in
the
future
it
doesn't
break.
That's
it
so
same
behavior
same
everything,
everything's
the
same
just
not
called
dollar
ref.
That's
it!
It's
gonna!
It's
gonna
be
a
lot
of
problems,
including
I'm,
anticipating.
B
B
All
right
thanks
everyone,
let's
see,
let's
see
French
proposal
and
otherwise
I'll
see
you
next
time.
Thanks
for
participating,
bye-bye.