►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Hey
folks
welcome
once
again
to
another
episode
of
thinking
out
loud
for
those
who
don't
know
what
thinking
out
loud
is.
This
is
the
most
boring
show
as
I
used
to
say,
because
it's
not
a
show
it's
a
thinking
process
in
life
in
a
live
stream,
so
so
yeah.
B
So
what
we
do
here
is
I
usually
invite
guests
to
join
me
every
week
and
we
think
out
loud
about
a
specific
about
a
specific
issue
or
a
specific
challenge
that
we
find
in
async,
api
right
or
in
or
in
the
world
of
event-driven
architectures
as
well.
B
So
let
me
also
mention
that
if
you
prefer
to
have
closed,
captions
or
subtitles
enabled
during
the
live
stream,
please
head
over
to
our
youtube
channel
and
I
think
yeah,
so
everything
is
enabled
there.
So
you
should
be
seeing
the
closed
captions
there.
B
Please
pardon
my
pronunciation
because
from
time
to
time
we'll
you
will
see
some
weird
closed
captions
and
it's
because
I
probably
don't
pronounce
everything
perfectly
as
per
queen's
english
right.
So
so
yeah
ooh
live
stream
travels,
I'm
finding
that
my
mouse
got
out
of
battery,
so
just
them
them
them
apple
that
they
didn't
have
this
cable
that
you
can
use.
While
you
can
use
your
mouse
anyway.
Let
me
so
yeah,
so
that's
it!
You
can
go
to
our
youtube
channel
and
and
yeah.
B
So
there
you
can
see
the
the
closed
captions.
You
can
also
find
this
on
on
twitch
and
it
will
also
be
live
on
twitter
and
on
linkedin.
Honestly,
I
don't
know
how
it
looks
like
in
linkedin.
I
never
use
it
as
a
user,
so
I
hope
it's
working
well
in
case
you
you're
watching
us
there
what
else
yeah.
So
let
me
first
introduce
the
topic
for
today.
B
So,
like
I
said
every
week,
I
invite
some
guests
or
guests
to
speak
about
specific
challenge,
and
this
week's
challenge
is
about
the
specification,
basically
a
specification,
but
not
the
spec
itself,
like
with
we
used
to
discuss
in
the
first
episodes
of
thinking
out
loud,
but
this
time
is
about
the
contribution
process
and
how
we
can
improve
the
contribution
process
on
on
this
gps
specification.
B
Specifically
right.
So
not
tools,
not
anything
else,
just
the
spec
right.
So
for
those
who
don't
know
the
context
for
a
long
time,
we've
been
only
lucas
and
I,
as
code
owners
of
the
spec
code
owners,
is
like
maintainers
and
and
now
recently
we
invited
day
lane
from
ibm
to
to
join
as
code
owner,
because
he's
he's
been
doing
really
great
contributions
and
we
thought
he
would
be
joining
us
as
a
maintainer.
B
We
want
to
repeat
this
as
much
as
possible
right,
so
we're
gonna,
so
we're
gonna
discuss
ideas
here
today.
So
let
me
check
if
the
mouse
is
already
charged
at
at
least
the
the
bare
minimum
to
invite
the
guests
to
get
in
right.
And
yes,
it's
back.
So
let
me
just
okay,
so
please
welcome
lucas
and
dale,
so
yeah,
hey
guys,
welcome
to
live
stream.
I
think
you
folks
are
new
to
this
in
kpi
community
right
specific,
especially
lucas.
Nobody
has
seen
him
ever
so.
Would
you
mind.
B
D
Thanks
yeah,
my
name
is
dale,
I'm
a
developer
at
ibm,
in
particular
with
a
background
in
sort
of
event
driven
stuff,
so
in
particular
kafka.
So
I
do
to
support
customers
who
are
using
kafka
to
build
event
driven
things
and.
D
Really
interested
in
asking
kpi
for
about
the
last
year
or
two
now
in
terms
of
how
we
describe
what
we're
doing
with
kafka
so
yeah
that
was
kind
of
how
I
came
across
facing
kpi.
C
Yeah
and
excuse
me
so
I'm
I'm,
if
you
don't
know
me
yet
if
it
comes
to
asking
api
community,
then
I'm
here
for
some
time
like
two
years
I
think
or
probably
more
first
contributed
as
individual
contributor,
but
now
I'm
hired
by
postman
to
work
a
full
time
on
asking
dpi
yeah,
mainly
in
a
real
making
sure
that
the
we
have
healthy
and
scaling
community
around
the
project.
C
C
But
I
call
myself
a
community
garden
because
it
sounds
nice.
B
Okay,
I
imagine
you
with
a
you
know
with
a
how
is
it
called
with
a
spade?
Is
it
called
spade?
No
or
maybe
not,
you
know
like.
B
C
C
Not
cutting
people,
you.
B
Are
you
are
those
I
mean
you're
defending
the
the
community
you're,
the
guardian
of
the
community,
so
whoever
wants
to
mess
up
with
community
you'll
cut
their
heads?
That's
how
I
imagine
you
sword.
That's
the
yeah!
That's
the
word
that
I
was
trying
to
find
spayed
and
I
think
this
is
just
a
false
spanish,
most
friend
yeah
and
the
sword
in
the
shield
as
a
civic
set
on
the
chat.
So
yeah.
B
So
so
folks,
let
let's
get
a
little
bit
started
with
this,
because
we
can.
We
can
always
get
off
track
with
these
things
for
a
long
time,
so
so
yeah.
So
I
I
briefly
explained
what
what's
the
context
like
what's
happening,
what
has
been
happening
like
we,
we
receive
a
lot
of
contributions
to
the
tools
right,
but
we
don't
get
a
lot
of
contributions
or
regular
contributions
and
specifically
regular
contributors
on
the
on
specification.
C
In
my
case,
you
always
you
actually
have
to
pick.
I
will
never
volunteer
first,
but
I
understand
that
I
just
did
so,
like
my
opinion,
it's
like
majority
of
folks,
I
think,
especially
if
it
comes
to
to
big
corporations
and
not
sure
what's
like,
because
dale
is
also
from
big
corporation.
I
was
working
for
a
big
corporation
before
as
well,
which
was
sap,
but
I
think
that
when
you
come
to
the
adolescent
api,
I
want
to
get
something
from
the
spec
that
is
not
yet
supported.
C
You
are
always
motivated,
rather
to
just
add
this
one
single
feature
and
then
run
away
from
the
from
spec
once
you
get
it.
So
that's
that's
one
of
the
reasons
why
people
just
come
for
for
a
single
contribution
and
then
leave
and
then
one
why
people
don't
come
at
all
like.
I
don't
think
we
have
such
situation
anymore,
like
sometimes
like
recently.
C
I
have
a
feeling
that
I
don't
have
really
time
to
go
through
all
the
all
the
issues,
all
the
ideas,
all
the
contributions,
because
we
already
have
few
that
are
hanging
there
for
a
while.
C
So
I'm
not
sure
if
and
I'm
interested
what
you
think
about
it,
but
I
remember
that,
like
few
months
ago,
maybe
a
year
ago,
I
was
thinking
like
we
don't
have
enough
contribution
contributions,
but
now
it's
more
about
like
how
to
handle
them
at
a
scale.
C
D
I
wonder
if
the
vendor
extensions
in
the
spec
makes
it
easier
for
because,
like
if
the
tool
doesn't
do
something
I
need.
I
have
to
make
a
contribution
to
change
the
tool
to
add
what
I
want,
but
if
the
spec
doesn't
have
what
I
need,
I
can
just
add
it
and
carry
on
like
it's.
The
path
of
least
resistance
is
add,
a
vendor
extension
and
don't
bother
contributing
something
to
the
community,
like
the
actually
contributing
it.
D
As
a
change
to
the
spec
is
an
additional
step
that,
in
the
short
term,
isn't
going
to
benefit
an
individual
because
it
doesn't
get
them
like
the
long
term.
It
benefits,
because
if
other
people
adopt
that,
then
that
sort
of
that's
where
the
benefit
comes
from.
But
I
I
wonder
if
the
reason
why
we
see
more
activity
and
contributions
on
the
tooling
side
is
because
just
that
different
nature
of
the
fact
that
it
motivates
people
to
to
make
that
change.
B
So
I
I
that's,
that's
actually
a
good
point
like
and
I
have
another
another
thought
about
this
like
why
I
mean
another
thought
and
question
to
myself
as
well.
I
I
don't
have
the
answer
like
we
see
a
lot
of
people,
especially
junior
people
or
students.
You
know
like
people
still
in
the
new
university,
contributing
to
a
asymptote
tools,
but
they
don't
really
like
or
they
don't
they're,
not
in
the
mood
to
contribute
to
the
spec
right.
So
and
I
wonder
why
is
it
like
this?
B
I
mean
I
can
imagine
that
might
be
that
as
a
student,
you
want
to
have
the
necessary
skills
as
soon
as
possible,
so
you
get
a
job
right
and,
and
then
yeah,
usually
being
like
being
good
at
specs
is
not
usually
a
job
requirement,
but
being
good
at
javascript
typescript,
whatever
language
or
framework
react
whatever
it
is
right,
so
so
yeah,
maybe
I
don't
know.
B
Probably
I
answered
myself
my
own
question,
but
just
you
know
like
think
it
out
loud,
so
so
yeah,
maybe
can
it
be
related
to
that?
I
don't
know
it's
also
following
on
what
on
what
lucas
said
like
it's
true
like
a
few
months
ago,
we
were
in
private,
he
and
I
discussing
like
we
don't
get
enough
contributions,
enough
love
to
the
spec
and
and
suddenly
I'm
starting
to
to
see
that
we
cannot
handle
all
the
all
the
contributions
that
we
get
right.
B
So
that
is,
that
is
actually
we
cannot
handle
them
ourselves
like
lucas
and
I,
but
it
doesn't
mean
that
it's
too
much
for
a
single
person
to
handle
thing
is
that
you're
doing
other
stuff
right.
So
so
that's
why
probably
we
can't
handle
that
so
yeah.
B
So
maybe
what
do
you
think
it's
gonna
happen?
It's
gonna
happen
lucas,
since
you
brought
this
topic
like
what
do
you
think
it's
gonna
happen
with
contributions
or
contributors
in
the
next
months?
You
think
it's
going
to
continue
growing
like
this
or.
C
It's
like
I
mean
you
can
see
the
numbers
of
how
the
community
grows,
so
it
will
grow.
So
there's
no
question
about
it.
It's
just
a
matter
of
how
we
make
sure
that
we're
scaling
the
work
we
do
to
handle
such
such
a
load
of
contributions,
but
just
to
clarify
sorry
for
the
short
breaks
for
coughing.
C
So
the
thing
is
that,
like
we
have
we're
getting
two
types
of
contributions,
let's
say
like
really
simplifying,
so
we
have
a
large
number
of
people
contributing
to
tools,
especially
students,
as
you,
as
you
mentioned
already,
and
but
it's
not
for
the
spec
for
two
reasons:
they're,
probably
not
that
experienced
with
even
driven
architectures
to
really
take
on
the
spec,
and
the
second
is
like
majority
of
them
is
here
to
to
contribute
their
time,
but
in
exchange
get
some
knowledge
and
and
skills
and
yeah.
C
I
don't
think
that
putting
in
in
resume
that
you
were
editing,
a
spec
is
a
good
skill.
C
A
C
Always
targeted
contributions
like
towards
a
given
future
and
it's
both
will
grow
like
tooling
contributions
and
these
contributions
to
the
spec
to
serve
some
purpose.
They
will
grow
the
problem
that
we
will
have
and
I'm
not
really
sure
how
it's
gonna
look
like
in
next
months.
Is
it's
always
this
contribution
that
is
not
not
giving.
C
You
immediate
benefit
for
your
for
your
contribution,
like
return
for
your
efforts
in
a
way
that
you
get
a
feature
or
whatever,
so
we
have
we,
we
have
a
lot
of
needs
for
work
on
the
spec,
that
is,
let's
say
around
the
spec,
where
you
have
to
commit
more
more
of
your
free
time.
So
it's
even
the
work
and
best
example
is
the
the
work
that
is
coordinated
by
jonas
on
the
3-0
release.
C
Right
so
most
of
this
small
efforts,
this
coordination
is
majority
done
by
folks
that
can
work
100
on
the
project
and
and
that's
so
far,
just
one
just
one
company
and
and-
and
here
I
see
a
big
challenge
for
now
and
and
for
future
like
how
we
can
get
more
people
full-time
working
on
the
spec
to
to
not
just
contribute,
but
actually
have
time
to
to
review,
to
provide
feedback
and
and
and
work
on
these
contributions.
C
And
this
is
blurry
blurry
really
for
me
and
like
basing
on
my
learnings
from
last
year.
I
think
the
only
way
is
really
to
knock
the
door
of
every
single
company
that
we
know
that
using
is
using
async
api
and
ask
for
support.
B
I
wasn't
listening
sorry
what
you
said.
Thank
you
now.
Actually
I
actually
understand
what
you
mean
like
yeah
and
well
it's
it's
been
a
long,
a
long
thing.
So
there
are
many
points
in
there
like
yeah.
I
agree
like
I
think
people
having
resistance
to
contribute
because
they
don't
get
an
immediate
benefit
right
and
like,
for
instance,
people
students
don't
get
an
immediate
benefit.
So
why
bother?
B
Then
you
have
people
like,
let's
say,
professionals
already
working
on
the
spec
already
working
on
the
on
the
field
who
are
looking
for
a
specific
feature
and
as
as
as
they
will
say
it
like?
It's,
not
you
don't
get
it.
It's
not
immediate
right.
It's
a
it's
a
long
work,
so
you
probably
do
it
through
extensions
and
and
yeah.
B
So
I
I
completely
agree
with
this,
and-
and
I
think
and
to
finish
with
your
point
like
I
think
like
when
working
in
with
communities,
something
that
we
have
learned
so
far
is
when
you
voice
out
to
the
whole
community,
like
you,
just
send
a
message
to
the
to
the
whole
community,
saying,
for
instance,
hey
who
wants
to
pick
up
this
issue
or
who
wants
to
do
this,
there's
silence
like
usually
there's
a
huge
silence
like
nobody
picks
it
and
picks
it
up,
and
there
are
many
reasons
for
that.
B
Like
I,
I've
been
asking
people
proactively
like
why?
Don't
you
volunteer
to
do
this
thing,
these
things
when
we
ask-
and
I
I've
gotten
like
a
few
responses,
types
of
responses,
like
some
people,
are
afraid
they
are
not
good
enough
to
to
do
that,
like
they
think
they're
now
ones
to
do
this,
which
is
stupid.
So,
if
you're
thinking
about
it,
please
stop
thinking
about
it.
Like
everybody,
everybody
is
here,
is
capable
to
do
this
work
if
you're
not
able
to
do
it
at
first
we'll
help
out
so
so
yeah.
B
So
don't
never.
Never
think
that
you're
not
ready
to
do
this
kind
of
job,
because
if
you're
not
you'll
be
so
that's,
that's
not
the
problem
and
the
other
kind
of
response
or
or
kind
of
situation.
That
I
see
is
that
people
are
shy.
B
They
are
shy
to
speak
and
there's
not
much.
You
can
do
with
this
right
other
than
what
you
were
saying
about
companies
as
well
like
you
have
to
you,
have
to
knock
some
doors
right,
like
specifically
same
thing
with
contributions.
B
You
have
to
mention
someone
and
say:
hey:
can
you
please
take
care
of
this
and
then,
when
you
do
it,
it
usually
works
people
yeah
people
accept
it
and,
and
they
volunteer,
which
is
weird,
because
I'm
not
sure
if
it's
really
a
volunteer
or
if
you
force
them
to
to
be
volunteers,
but
but
yeah,
it
works,
and
I
don't
know
maybe
dale
from
from
your
point
of
view,
as
so
when
luca
said,
like
just
that's
just
one
company
working
full-time
right
now
on
on
this
api,
which
is
postman
right.
B
But
I
see
many
other
companies,
like
in
your
case,
ibm
like
they're,
dedicating
resources
as
in
money
and
also
people's
engineering
time,
let's
say
to
using
kpis.
So
I
wonder
if
this
this
would
be
something
that
you,
you
think
it
would
be
possible.
D
I
hope
so
I
think
I
think
luke
has
made
a
good
point
around.
It's
not
just
about
quantity
because
like
if
we
had
100
people
who
all
came
with
one
issue
and
one
pr
to
add
one
new
value
in
the
spec,
then
that
just
gives
a
you
know.
You
two
essentially
for
the
last
year,
a
hundred
pr's
to
review
and
a
hundred
issues
to
comment
on
and
it's.
D
How
do
we
motivate
people
to
not
just
not
to
only
come
with
new
ideas,
although
new
ideas
are
great
but
but
to
get
involved
in
a
discussion
about
other
people's
ideas
and
and
how
like
where's
the
sort
of
intrinsic
motivation
for
that?
Because,
if
they're
suggesting
adding
a
feature
that
you
don't
need,
it's
kind
of?
C
But
then
let
me
challenge
you
today
with
a
question
because
you're
an
example
of
a
person
that,
like
we
invited
you
to
be
a
code
owner
for
this
pack,
you're
backed
for
by
ab
ibm
but
you're,
not
working
full-time
on
asking
api
and
I'm
not
100
sure,
and
I'm
not
gonna,
ask
in
public
how
it's
set
up
in
inside
how
much
time
you
have
like.
No.
C
How
much
backing
do
you
have
from
ibm
or
not?
But
basically
what's
important
for
me?
Is
that,
like
you,
don't
work
on
the
spec
full
time,
but
we
we
basically
invited
you
because
you
you
contributed
a
lot.
You
were
involved.
You
were
on
your
own
without
being
asked
always
involved
in
npr
in
regards
of
kafka.
You
contributed
to
tools
in
regards
to
kafka.
You
added
a
feature
related
to
to
kafka,
to
the
spec
and
might
be.
I
think
it
was
your
first
contribution.
So
might
be
it's
it's.
C
It
was
because
you
needed
it
for
ibm.
I,
which
is
it's
totally
fine,
but
it
was
not
your
single
contribution.
You,
you
stayed
with
the
project.
You
were
giving
feedback,
you
even
volunteered
to
do
release
coordination,
which
means
you
did
more
than
regular
contributor
and
the
question
is
like
then:
why?
Why
did
you
do
it?
C
D
Yeah,
I'm
not
sure
it
is
it's
a
tricky
one,
and
but
I
think
that
that
time
one
is
a
tricky
thing,
because
I
think
it's
important
to
be
inclusive.
We
need
to
have
a
way
that
people
who
aren't
able
to
commit
days
and
days
a
week
to
still
feel
welcome.
So
it's
kind
of
how
do
we
get
that
balance
between?
D
If
all
you
can
spare
is
half
a
day
a
week,
then
that's
still
valuable
and
that's
still
valid
and
you
shouldn't
have
less
of
a
say
than
someone
who
can
spend
three
days
a
week
or
something
because
definitely
like
my
experience,
is
it
it.
It
goes
in
waves
right.
There
are
times
when
we're
doing,
planning
or
designing
for
our
products
where
our
products
are
using
and
exploiting
async
api.
D
So
it's
a
so
at
those
points
we're
really
interested
in
changes
to
the
spec
and
then
when
we're
in
a
phase
where
we're
sort
of
implementing
it,
then
things
quieten
down
and
the
amount
of
time
we
have
to
engage
with
expanding
and
developing.
It
goes
down
so
yeah.
So
so
I
haven't
had
a
time
where
I've
sort
of
been
able
to
devote
full
time
to
it.
B
Folks,
just
before
we
continue
so
we
get
three
messages
in
the
chat
and-
and
I
guess
like
I'm
gonna
read
them
all,
but
I
guess
they're
all
like.
Can
they
related?
Let's,
let
me
see
how
it
looks
like
yeah
looks.
Good
sorry,
lucas
you've
been
a
little
bit
hidden.
B
B
Let
me
let
me
continue
and
sergio
also
says,
like
how
cool
we
lower
down
learning
curve
from
the
contributor
point
of
view
from
zero
to
contribution
I
mean:
can
we
simplify
even
more
the
processes,
so
those
two
points
are
kinda
related
to
me
and-
and
I
think
it's
precisely
about
this,
like
so
mario's
I
mean
sergio-
is
already
like
he's
already
onboarded
into
the
spec,
so
he
already
know
how
everything
works
in
the
spec
and-
and
I
mean
everything
at
least
the
bulk
of
it
right
so
so,
yeah
and
and
he's
aware
of
it,
but
as
I
understand
marius
so
you're
recently
joined
the
community
and,
and
you
want
to
get
involved,
but
you
don't
know
how
to
get
involved
there
right
or
if
there's
something
you
can
do
to
prepare
yourself
this.
D
Think
one
way
that
could
help
is
try
to
write
an
async
api
document
for
your
application,
for
what
you're
doing,
because
I
think,
when
it
moves
away
from
being
an
abstract
thing,
that
you're
learning
about
by
just
reading
what
the
spec
is
and
you
try
to
apply
it
I
mean
a
like.
We
could
always
do
with
more
examples,
more
real
case
studies,
more
examples
of
how
different
people
are
using
it
in
the
real
world
would
be
super
helpful,
but
also
for
the
person
writing
them
it.
D
It
helps
it
solidifies
your
understanding,
if
that's
when
you
notice,
maybe
what's
missing
in
the
spec,
it
gives
you
ideas
of
of
maybe
where
the
gaps
are
and
make
sure
you
understand,
I
mean
for
I'm
not
to
bring
this
up
again,
but
for
months
I've
misunderstood
the
publish
and
subscribe,
and
it
was
only
after.
I
started
sharing
examples
of
documents,
I'd
written
that
that
came
to
light,
so
I
think
that
the
best
way
of
getting
off
the
I'm
I'm
new
and
I've
sort
of
read
about
it.
B
And
to
add
to
that
like
so,
if
you,
if
you,
if
you
write
a
nationcpa
document,
even
for
your
work
or
for
yourself
just
because
you're
playing
around
with
this
in
kpi,
you
usually
you'll
you'll,
usually
stick
to
one
or
two
protocols
at
most,
which
is
what
you
know
or
what
you
want
to
know.
Right
and
jonas
was
actually
mentioning
in
in
his
message
in
the
chat
like
saying
like.
B
B
Yes,
it's
a
lot
and-
and
I
would
like
to
add
to
that
to
what
dale
said
like
just
because
you
work
or
you
contribute
to
the
spec-
doesn't
mean
that
you
need
to
know
every
single
protocol
like
one
I
mean
with
none
of
us,
know
every
single
protocol
I
mean,
I
don't
know
about
lucas
and
dale,
but
myself
I
don't
know,
I
mean
not
even
the
majority
of
the
protocols,
so
just
a
few,
a
few
ones,
then,
let's
say
the
most
common
ones
and
that's
it
in
in
the
case
of
dale,
probably
it's
kafka
most
of
the
times
and
and
so
and
so
yeah.
B
So
what
I
would
recommend
here
is
yeah.
You
might
have
to
consider
all
these
things,
but
also,
let
me
clarify
that
you
don't
have
to
consider
all
these
things.
It's
like
we
as
a
group
have
to
consider
all
these
things.
So
if
you're
an
expert
on
kafka
or
in
we
have
another
one
who's,
an
expert
on
amqp
another
one
in
ibm,
mq
and
another
one
in
websockets.
B
So
yeah,
so
just
just
that
you
don't
you,
don't
really
need
to
to
know
all
all
the
protocols
and
all
the
technologies
right
that
someone,
the
more
people
we
have
there.
Someone
will
just
come
out
and
say,
like
hey,
that's
really
cool,
but
that
doesn't
work
for
my
case
or,
if
I'm
for
for
my
protocol
or
for
the
cases
I'm
using
so.
C
Yeah
and
what
you
just
said
leads
us
to
the
biggest
issue
that
we
have,
at
least
in
my
opinion,
is
getting
people
involved
in
reviews
getting
feedback
from
the
community
on
the
proposals
because,
as
I
said,
like
number
of
contributions,
it's
pretty
okay-
and
it's
I
mean-
maybe
it's
okay,
if
it's
not
enough,
not
many,
because
this
bag
is
fine,
but
the
thing
is
that
once
you
get
a
contribution,
and
the
best
example
is
that
the
one
we
we
have
from
ebay
about
the
security?
C
Sometimes
contribution
is
easy.
It's
just
about
optimizing
the
document
as
an
api
document.
Then
you
don't
really
need
to
think
about
like
how
it
should
how
something
should
be
placed
in
the
in
this
pack.
It's
about,
like,
I
would
say,
enabling
reusability
of
server
information
or-
or
things
like
this-
that's
easy.
That's
that
can
be
done
by
code
owners
just
as
a
review
to
to
see
how
things
should
change,
but
then,
if
it
comes
to
things
like
yeah,
let's
add
a
security
on
a
operation
level
or
on
the
channel
level.
C
All
like
the
whole
request
reply
discussion
that
community
asks
about,
like
even
the
simple
thing
like
should
this
information
but
reply
to
a
message
be
on
the
channel,
or
rather
the
operation
and
again
it's
or
the
message
or
the
message
or.
C
And
it's
these
are
things
where
making
a
decision.
It's
pretty
complex
and
I
personally
not
sure
how
you
vlogs,
but
I
personally
always
have
this
feeling
like
damn
it.
I
mean
it's,
it's
really
hard
to
decide
and
I'm.
C
Of
the
yeah
major
change
ahead,
and-
and
but
it's
mainly
because
there
are
not
many
opinion-
opinions
of
people
from
from
companies
that
actually
use
async
api
because,
like
I'm,
not
sure
again
how
you
see
our
role,
but
I
was
always
looking
at
my
role
as
a
as
a
just
a
gatekeeper,
just
making
sure
that
the
contribution
is
done
as
agreed
with
the
community.
C
There's
we
don't
violate
the
rules,
we
make
sure
people
are
involved,
it
takes
time
to
release,
etc,
etc.
But
then
I
also
understand
that
I
no
longer
work
a
hundred
percent
of
my
time
on
products.
I
no
longer
work
actively
in
even
driven.
C
B
You
actually
made
a
great
point,
like
many
people,
come
to
me
to
ask
for
advice
on
if
this
will
be
doing
using
one
protocol
or
another
or
how
this
will
be
doing.
Event-Driven
architectures
and
it's
funny
I
mean
I
got
some
experience
on
event-driven
architectures,
thanks
to
some
kpi
as
well,
but
when
I
really
learned
a
lot
about
event-driven
architectures
was
when
I
was
applying
even
driven
architectures
in
my
daily
life.
You
know
in
my
daily
work
now
that
I'm
building
tools
and
spec
and
this
community
for
event
driven
architectures.
B
I
don't
get
to
do
it
even
even
driven
architectures
anymore,
so
it
is.
It
is
funny
so
so
yeah
to
to
dale's
point
before
like
I
have
to
actually
play
with
things
invent
use
cases,
examples
here
and
there
just
to
just
to
apply
what
we're
building
to
something
something
tangible
for
me,
so
to
see
how
it
it
fits
or
it
doesn't
fit
and
and
yeah.
So
that's
so
that's
that's
really
a
great
point,
and
and
and
and
people
should
take
that
that
into
account
like
we're
now
we're
not
special
experts
on
inventory.
B
Architectures
we've
done,
we've
done
some.
Even
the
right
textures
in
the
past,
some
of
us
still
do
like
dale,
for
instance,
still
doing
inventory
architectures
on
his
his
job.
But
in
the
case
of
us
like
like
lucas
and
I
working
full-time
on
async
api,
we
don't
do
even
during
architectures
anymore
and
that's
funny
right.
So
so
yeah,
that's
like
much
needed.
In
my
opinion,
like
having
people
to
to
review
and
and
to
contribute,
I
mean
just
review
or
contribute
ideas
or
or
if
they
spot
something.
B
E
B
C
I
don't
think
the
problem
is
the
guidance.
The
problem
is
the
the
visibility,
or
rather
the
awareness
like,
because
it's
like
again
like
I
think
you
mentioned
already
about
mentioning
something
in
the
channel-
hey,
please
help
so,
of
course,.
C
To
the
specification
channel
and
tell
people
okay,
there's
an
interesting
proposal,
please
have
a
look,
then
we
can
go.
We
also
go
to
twitter.
We
go
to
linkedin
and
tell
people
that
there's
some
nice
proposal.
Sometimes
in
the
blog
post
I
was
trying
in
the
status
blog
post.
I
was
trying
to
mention
the
most
important
proposals
and
asking
people
to
be
involved,
but
it's
always
asking
large
group
and
that's
how
it
always
works
in
large
groups.
C
You
usually
think
that
maybe
somebody
else
will
have
a
look,
because
you
don't
have
time
and
again
my
learning
from
last
year.
You
have
to
poke
people
directly
and
ask
them
directly.
It
will
not
always
work,
but
I
think
it's
okay,
like
so.
First
of
all
like
do
you
think
it's
it's
bad.
If
you
ask
someone
directly
for
help,
unless
you
do
it
in
public.
B
D
I
think
the
challenge
with
some
of
these
for
a
few
of
the
issues
like
you
mentioned,
the
request
reply
one
or
the
the
security
one.
Once
there's
been
a
few
comments
like
because
there
have
been
a
few
issues
where
once
the
conversation
has
started,
it's
really
daunting,
but
you
you
click
on
it.
You
see
the
scroll
bar
shrink
and
you've
got
this
back
and
forth
like
it's.
D
I
think
there
are
some
and
it
kind
of
like
once
it
becomes
once
it's
been
around
for
a
little
while
it
becomes
really
hard
for
anyone
to
engage
with,
because
there's
that
barrier
to
entry
of
to
understand
the
current
state
of
it.
I've
got
a
lot
of
reading
to
do
because
it's
gone
back
and
forth
and
back
and
forth.
D
I
think
once
once
there's
been
a
bunch
of
discussion,
I
think
maybe
one
way
we
could
make
it
easier
for
people
to
contribute
their
opinions
is
distilling
it
down
or
summarizing
it
or
or
I
I
think
some
of
those
issues
are
not
very
consumable
like
the
ones
that
have
been
around
for
more
than
a
few
months.
I
think
trying
to
get
anyone
new
to
take
a
look
at
it
and
offer
an
opinion.
It
feels
almost
impossible
because
there's
just
too
much
backstory
for
them
to
wade
through
yeah.
D
B
B
By
default,
or
something
like
that,
so
so
it
looks
like
so.
If
you
have
a
huge
stream
of
going
back
and
forth
back
and
forth,
people
can
still
still
read
them,
but
they
have
to
click
on
them
to
expand
them.
I
think,
and
so
that
would
be
cool
like
you
get
a
submarine.
It's
like
hey.
Is
this
forget
about
this
back
and
forth?
Here's
a
summary
of
what
happened
in
this
issue.
B
So
if
you
want
to
contribute
to
this
issue,
just
read
this
or
tell
the
issue
creator
to
update
the
description,
which
is
another
good
idea
right
like
so.
You
put
it
on
the
top
and
yeah
there's
a
lot
of
discussion.
If
you
want
to
read
it,
that's
up
to
you,
but
you
didn't
have
to
that's
actually
a
great
idea.
I
think
yeah
yeah,
don't
get
scared!
Look
at
like
by
hiding.
I
don't
mean
that
people
will
not
be
able
to
read
the
comments.
B
We
need
to
be
transparent,
so
yeah,
I'm
not
meaning
that,
like
they
will
be
able
to
find
this
information.
Just
it's
not
overwhelming
at
first,
like
you
have
like
100
comments
being
going
back
and
forth
on
small
details.
You
know
some
people.
Sometimes
these
conversations
are
people
saying
the
same
thing
and
and
not
understanding
each
other,
and
that
is
yeah
like
marius
is
saying,
like
the
two
too
long
didn't
read
part
you
know
tldr
part
yeah.
B
D
Agree
yeah,
but
I
think
basically,
what
can
we
do
to
make
it
cheaper
and
less
of
a
barrier
and
easier
for
someone
to
offer
an
opinion?
I
think
that's
one
way.
I
think
not
all
some
issues
that
are
just
someone's
offered
an
idea
and
it's
kind
of
gone
quiet.
I
think
they
don't
have
that
problem,
but
the
ones
that
I
I
think
we
really
want
people
to
engage
with.
I
think
they
could
benefit
from
that.
B
And
I
also
have
another
issue
when,
when
working
with
with
the
spec,
which
usually
doesn't
happen
with
tooling-
and
is
you
know,
for
instance,
if
we
just,
I
prefer
to
discuss
in
an
issue
and
then
do
the
pull
request
once
we
agree
on
something,
because
creating
a
as
a
pull
request
on
the
spec
requires
a
lot
of
work.
You
know,
like
I
mean
like
work,
that
is
out
of
the
topic
like,
for
instance,
using
the
formal
words
repeating
some
things
here
and
there,
for
instance,
if
you're
gonna
attach
something
about
bindings.
B
There
are
many
places
in
the
spec
where
you
have
to
add
just
a
link,
for
instance,
or
something
right.
So
there
are
many
not
unrelated
things
that
distract
you
from
from
actually
creating
the
the
proposal.
An
example
is,
for
instance,
my
proposal
about
how
to
solve
public
subscribe.
B
Thing
is
that
if
I,
if
I
point
people
to
the
pull
request
and
tell
them
to
review
it,
which
is
not
there
yet
by
the
way,
it
will
be
harder
for
them
to
review
it
than
if
they
reviewed
the
issue
right
so
and
that's
funny
because
and
it's
because
it's
so
abstract,
so
the
change
is
so
abstract
and
there
are
many
moving
pieces.
B
Many
moving
parts
that,
if
you,
if
you
read
the
the
pull
request
from
top
to
bottom,
it's
hard
it's
hard
to
understand
where,
where
to
start
looking
looking
from
and
and
what
and
what's
the
order,
I
should
be
reading
the
pull
request,
because
it's
like
in
the
everything
is
like
in
the
throne
there
and
and
yeah
like
they're.
I
don't
know,
I
don't
know.
If
do
you
understand
what
I
mean
or
or
or
am
I
just
getting.
C
A
C
A
C
And
it
was
super
terrible
because,
like
all
the
examples
that
you
had,
because
you
wanted
to
have
the
description
of
the
issue
clear
and
not
overwhelming
so
the
examples
you
you
hit
them
with
this
feature,
that
github
has
for
descriptions
that
you
can
collapse,
stuff
expand
and
it
was
like
like
for
me.
It
was.
It
was
a
nightmare
to
review
the
issue
and
having
apr
would
be
like
perfect,
because
I
would
see
everything
and.
A
C
Could
navigate
through
files
but
of
course
I'm
say
speaking
from
a
perspective
of
person
that
already
knows
where
what
goes.
Where
is
the
example?
Where
is
the
aspect
et
cetera
so
but
yeah
I
would
I
would
have
like
for
me
the
experience
is
totally
different.
When
I
see
apr
for
proposal,
it's
it's
the
best
where
I
I
prefer
to
engage.
B
Yeah
so
I
I
agree
with
you
in
in
to
some
degree
here
which
is
like,
for
instance,
something
that
I
didn't
like
about,
or
I
don't
like
about
issues
is
that
usually
in
these
discussions,
complex
discussions,
you
have
like
many
threats
of
discussion.
I
mean
yeah,
you
have
like
many
threads
inside
the
same
discussion
and
and
it's
it
it
becomes
hard
to
follow
all
these
threads
right,
but
there
are
no
threads
like
in
like
in
github
discussions.
B
It's
a
github
issue,
so
you
have
a
single
thread
with
many
virtual
threads
inside
inside
the
messages
right,
so
that
will
be
easier
to
handle
on
a
pull
request.
I
agree
because
then
you
leave
comments
on
specific
lines
right,
so
that
then
you
can
have
like
a
long
discussion
on
on
this
part,
but
the
rest
of
the
things
are
clear.
B
So
that's
fine,
you
can
just
like
mark,
has
done
and
know
of
that,
and
maybe
it
is
like
something
that
sergio
has
been
doing
to
help
me
here
is
maybe
it's
because
it's
a
too
complex
issue
and
it
will
be
split
down
into
many
other
issues
or
many
pull
requests,
not
just
a
single
pull
request.
B
Just
so
it's
easier
to
review,
because
when
I,
when
I
wanted
to
create
a
pull
request,
to
be
honest,
I
was
like
I
don't
even
know
where
to
start
like
it's
this.
This
is
a
monster.
B
This
is
huge
and
if
I
don't
know
where
to
start
once
it's
done,
then
people
are
going
to
be
overwhelmed
by
the
amount
of
changes,
because
it's
literally
like
removing
huge
sections,
then
renaming
them
or
moving
them
here,
and
I
don't
know
it's
it's
a
lot
of
changes
right
because
we're
we're
creating
these
operations
section
we're
removing
publish
and
subscribe
from
channels.
B
So
this
removes
a
lot
of
huge
chunks
of
of
the
spec,
are
completely
removed
or
yeah
moved
to
another
part
and
changed,
and
then
so
yes,
it
is.
It
is
hard,
but
that's
that's
just
like
this.
I
will
say
this
is
just
this
issue:
let's
just
be
real
and
and
be
pragmatic
and
and
that's
not
usually
the
case
so
usually
contributing
to
the
spec
review
bin
is
just
it's
way
easier
right.
It's
just
a
specific
single
feature,
not
a
major
rig
right
of
the
spec,
so
yeah.
C
Is
she
playing
or
on
some
stuff
from
the
kitchen
like
hitting
something.
B
You
see
dale,
I
told
you
before.
I
know
it's
a
heater
that
I
have
here.
It's
a
heater
that
I
have
near
myself
and.
C
C
And
before
we
go
further,
aren't
you
living
in
spain?
Why
do
you
need
a
heater
in
spain
like.
C
C
C
So
I
was,
but
maybe
it's
again
it's
not
the
best
solution,
but
I
was
like
always
like.
I
was
looking
at
the
improvement
part
from
also
from
my
experience
like.
I
don't
have
time
to
look
on
the
proposals
every
day,
because
there
are
other
things
happening
in
this
pack
and
I
usually
have
it
once
once
a
week
once
every
two
weeks.
C
And
I
was
always
thinking
if
that
it
would
be
helpful
to
have
a
single
single
view
on
the
website,
like
asking
api,
slack
slack
awesome,
api
dot
com,
slash,
not
slack,
slash
whatever,
like
let
it
say
whatever,
and
then
you
get
a
list
of
of
all
the
proposals
because,
like
from
all
the
issues
that
you
have
in
spec,
not
all
of
them
are
proposals.
C
Not
all
of
them
are
issues
at
the
states
that
actually
you
can
involve
someone
to
to
do
a
review,
because
sometimes
the
proposals
are
in
a
state
where
we
just
have
to
say:
okay,
no,
you
have
to
do
this
and
that
otherwise
we
are
not
really
able
to
provide
you
any
any
feedback
at
the
moment.
So
there
would
be
just
a
view
of
all
this
only
like
issues
where
we
really
like
desperately
need
community
feedback,
because
we
know
it's
it's
really
ready
for
review.
C
We
really
need
opinion
of
of
others,
so
that
would
be
a
page
where
we
list
those
issues.
We
have
this.
What
you
said
about
like
too
long
didn't
read
summary
of
like
where
we
are
at
the
moment
with
the
given
issue
and
on
the
same
page,
we
would
have
a
clear
information
like
if
you
want
to
have
not
notifications
about
these
issues
like
have
be
added
to
some
like
distribution.
These
newsletter
lists
where
we
weekly
or
monthly,
sent
you
an
update.
C
C
It's
just
one
link
that
you
share,
and
the
second
is
that
it's
also
easy
to
share
when
we
go
directly
and
I
think
we
should
actually
start
doing
it
go
directly
to
people
that
we
know
that
use
the
spec
and
they
use
this
pack
in
production
and
and
tell
them
like,
if
you
probably
don't
want
to
have
changes
in
this
spec
that
will
break
some
flows
in
your
product.
So
you
just
go
to
this
website
or
just
submit
subscribe
for
the
newsletter
and
we're
gonna
we're
gonna.
C
Let
you
know
that
we're
making
a
change,
so
you
can
say
no
and
tell
us
why
you
think
it
should
be
done
differently
or
it
should
not
be
done
at
all
and
and
then
we
have
to
start
going
to
like,
for
example,
all
the
presenters
that
we
had
at
the
conference.
We
should,
I
mean
I
was
even
planning
to
maybe
write
to
them
as
tell
them
directly
like
hey
folks.
What
do
you
think
about
such
a
such
a
newsletter
based
approach
that
we
really
you
don't
have
to
be
on
the
slug?
C
You
don't
have
to
listen
to
like
subscribe
to
our
twitter.
We
will
make
sure
that
you
just
have
to
subscribe
to
the
single
newsletter
and
we're
gonna.
Always
let
you
know
that
change
is
happening.
B
That's
that's
a
cool
thing
yeah,
so
you
filter
a
lot
of
the
of
the
noise
that
we
make
on
slack
on
twitter,
that
they're
not
interested
in
and
and
that's
that's
really
cool
and
and
yeah,
and
you
raise
awareness
about
things
that
are
happening
and
I
will
even
go
farther
like
you
can
subscribe
to
specific
specific
issues
right.
So
so
you
don't
want
to
be
notified
about
all
the
spec
issues.
B
You
know
just
just
want
to
be
notified
about
this
one
specific
issue
that
you're
interested
in
and
yeah.
I
wonder
if
this
will,
if
this
will
lead
to
a
second
issue
or
the
second
challenge
which
is
like
they
will
be,
subscribing
to
see
how
it
evolves,
how
these
issues
evolve,
but
they
don't.
They
don't
get
involved
into
it
today,
themselves
and-
and
it's
funny
that
you
mentioned
that
because
you've
been
asking
me
about
mailchimp
these
days
now.
I
understand
why.
C
C
Different
reasons
but
related
like
so
for
example,
I'm
thinking
about
this
for
totally
different
situation,
different
reasons.
So
I
was
a
couple
of
weeks
ago.
I
was
interviewing
our
technical
student
committee
members
like
how
would
they
like
to
be
notified
about
the
need
for
their
attention
or
or
a
voting
that
has
to
happen
and
the
least
amount
of
people
were
interested
with
github
notifications
majority.
C
I
would
I
don't
remember
if
it
was
majority,
but
basically
the
answer
was:
it
should
be
either
a
slack
dedicated
notification.
That's
why
we
have
this
now.
Slam
dedicated
slack
channel
and
many
said
like
the
best
is
email,
but
it
cannot
be
github
email.
It
has
to
be
like
really
dedicated
email,
because
then
I
will
see
it
in
the
mailbox
yeah
and
and
that's
what
made
me
think.
Like
yeah,
I
mean
there
is
a
lot
of
noise,
not
just
from
using
api,
especially
for
people
that
don't
work
full-time
on
api.
C
D
Really
I
really
like
that.
I
think
that
would
be
a
good
idea.
I
I
think
my
only
concern
is
that
it
doesn't
end
up
like
becoming
you
who
has
to
write
this
so
like.
Maybe
maybe
we
have
a
rotor
and
we
take
it
in
turns
like
if
we,
if
it's
like
weekly,
then
we
have
a
calendar
and
everyone
can
put
their
name
against
which
week
they're
the
ones
who
writes
who
collates
the
newsletter.
D
C
Yeah,
I
don't
think
we
need
to
do
it
weekly,
especially
yeah.
C
So,
once
a
month,
it's
it's
like
it's,
okay
and
also
the
whole
stuff
can
be
pretty
much
automated,
even
sending
the
newsletter
collecting
issues
etc.
We
just
need
to
come
up
with
the
way
how
we
mark
those
issues
with
labels,
yeah.
D
B
So
what
else
folks
we're
four
minutes
before
we
finish,
because
by
the
way
for
people
watching
so
right
after
this,
in
five
minutes,
we'll
have
the
the
meeting
about
the
specific,
the
spec
3.0
version,
where
we
discuss
how
to
how
it
will
how
to
look
like
right.
What
goes
into
version
three
of
the
spec,
so
yeah.
D
Related,
that's
a
good
point
like
when
we
talk
about
wanting
contributions
to
the
spec.
Do
we
still
want
to
move
2.x
like?
Where
would
we
prefer
people's
time
and
effort
and
energy
to
go
into
3.x
or
2.x.
B
B
That's
yeah!
The
problem
is
that
we
might
not
be
enough
people
working
on
that
to
sustain
two
right
to
sustain
three
dot
x
and
two
dot
x,
but
yeah
we
cannot
live.
We
cannot.
We
cannot
just
reject
moving
forward
to
version
three,
let's
say,
and
solving
all
these
huge
problems
that
we
have
with
pilots
and
subscribe
and
and
and
channel
reuse,
and
we
also
cannot
break.
B
We
cannot
abandon
people
using
two
point
x
right,
so
so
yeah.
So
for
a
while,
it's
going
to
be
it's
going
to
be
a
little
bit
of
balance
right,
sometimes
we'll
be
pushing
more
than
three,
sometimes
on
two
point,
something
so
yeah
until
we
decide
that
it's
it's
been
enough
with
two
point
x,
that's
my
guess,
like
we
haven't
decided
yet
so
so
yeah
for
this
and
for
more
yeah.
Let's
join
the
the
next
call
on
spec
3.0
right.
A
C
To
mention
one
more
thing,
but
something
to
consider,
I
think,
is
the
especially
what
they've
said
about.
What's
the
english
word
inclusivity,
I
think,
what's
the
word.
A
So
inclusiveness.
C
Like
like
a
dedicated
meeting
like
a
triage
spec
proposals,
triage
public
disrupt
triage
because
we
now
do
a
lot
of
asynchronous
work,
but
might
be
that
we
should
consider
like
to
have
a
synchronous
check
once
a
month
like
where
we
divide
work
publicly,
and
we
also
make
it
open
to
others
to
join
so
they
also
meet
us,
so
they
know
who
they
will
work
with,
and
we
try
us
like.
C
And
then
it's
it's
public,
it's
a
monthly
meeting
and
I
don't
think
we
can
be
any
any
more
inclusive
than
this
like
that.
We
always
publicly
show
up.
We
always
mention
we're
open
and
we
do
our
best
to
share
the
news
so
yeah.
But
it's
something
to
discuss.
I
guess.
B
Cool
folks
so
yeah,
I
guess
it's
time
to
to
move
on
and
yeah.
So
thanks
a
lot
to
both
of
you
for
joining
for
joining
me
today
to
this
insane
or
sorry
for
saying
saying,
it
would
be
insane
like
this
weird.
B
Foolish
thinking
out
loud
thing
and
yeah
looking
forward
for
to
doing
more
together
and
and
yeah
thanks
a
lot
for
joining
the
chat
as
well
see
you
in
the
spec
3.0
meeting.
If
you
want
to
join
us
and
if
you
don't
know
how
to
join,
you
know
you
can
stay
in
the
channel
in
our
channels
in
youtube.com,
slash,
async
api
or
you
can
join
our
slack
workspace
and
I
think
you
can
you
have
a
you:
have
a
zoom
link
there
right
lucas,
I
think
for
the
meeting.
B
C
You
can
copy
it
from
the
general
channel
right
before
after
write
out
both
your
messages
message
message
from
jonas
you're.
B
B
C
I
run
to
the
meeting,
but
you
friend
also
have
to
join.