►
From YouTube: 2021-10-13-Next 10 years of Node.js
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
So
welcome
to
the
node.js
next
10
meeting
for
october
13th
2021.
We
will
take
a
look
start
off
by
taking
a
look
at
the
agenda,
which
was
on
issue
number
94.
A
Come
on
I'm
trying
to
open
up
the
google
doc
okay,
there
we
go
if
people
can
add
themselves
to
the
agenda
here.
Let
me
add
that
to
the
chat.
A
I
guess
the
first
thing
I
will
share
is
that
the
pr
that
we
generated
from
our
discussion
so
far
in
terms
of
the
technical
priorities
is
open
and
it's
in
the
node.js
node
issue.
40235.
I'll.
Add
that
to
the
the
minutes
here
and
you
know,
there's
some
discussion
going
on
there.
A
I
think
I've
addressed
most
of
the
the
discussion
so
far,
but
you
know
I
think
it's
moving
along
in
terms
of
you
know
getting
some
collaborator
discussion
and
hopefully
getting
that
landed
so
that
we
can
use
that
as
sort
of
our
top
technical
priorities
to
then
sort
of
do
a
more
deep
dive
into
the
like
the
specifics
of
what
we
might
be
doing
on
on
particular
sections.
A
A
A
The
89
is
technical,
deep
dive
documentation
so
looking
at
like
how
we
might
improve
the
documentation,
because
that
was
one
of
the
the
technical
priorities,
the
other
one
is
deep
dive
on
maintaining
growing
the
level
of
contribution
in
in
the
future
that
one's
not
necessarily
part
of
the
technical
priorities.
A
I
don't
think,
but
it
is
something
we've
talked
about
as
being
important,
so
we
want
to
do
a
deep
dive
on
that
as
well,
and
then
I
guess
the
last
issue
on
the
agenda
was
the
the
pr
that
I
mentioned
earlier
in
terms
of
the
draft
content
right.
So
actually
it
was
the
draft
content.
So
this
one,
I
think
we
can
close
close
since
the
pr
is
opened.
A
A
This
is
a
new
time,
but
we
have
had
a
challenge
in
finding
a
time
that
works
for
people
every
every
kind
of
couple
weeks
oops,
I
should
promote
tyranny
again.
I
think
beth
had
the
suggestion
that
maybe
we
should
try
like
another
mini
summit,
so
I
that
that
makes
sense
to
me
in
terms
of
like
maybe
picking
one
of
our
deep
dive
topics,
and
then
you
know
trying
to
do
a
mini
summit
on
that
to
see
what
would
make
sense,
see,
who's,
interested
and
so
forth.
A
A
A
So
we
did
a
ten
to
two
I'm
thinking
in
that
we
could
do
like
deep
dives
into
two
sections.
Does
that
make
sense
to
people.
B
A
We
have
two
on
the
agenda
here,
which
is
like
documentation
and
maintaining
growing
the
level
of
contribution,
but
we
could
pick
any
one
of
the
like
the
technical
priorities
that
we
have
in
in
the
other
pr,
and
I'm
just
wondering
if
we
want
to
try
and
pick
a
mix
of
things
to
you
know
I
don't
know
appeal
to
a
broader
audience
or
a
broader
group
of
people
who
would
want
to
be
involved.
A
B
I'd
say,
probably
just
continuing
to
go
down
that
list
that
we
built
out
for
a
while
would
be
how
I
tried
to
approach
it.
A
C
B
So
I
I
would,
if
you're
looking
for
that,
I'd
probably
not
recommend
documentation.
I
I
think
documentation
needs
a
lot
of
work.
I
I
don't
think
it's
a
particularly
attractive
one.
Yes,.
A
B
B
Yeah,
I
think
I'm
just
going
down
this
list.
B
B
I
mean
I
care
more
about
single
single
executable
applications,
but
I
I've
seen
pretty
consistent
plus
ones
to
that,
but
I'm
not
sure.
A
I
think
I,
like
you,
know
I'm
just
listening
to
you
and
and
looking
at
the
list
too,
I'm
wondering
if
something
like
suitable
types
for
end
users
and
single
executable
applications,
because
those
are
ones
where,
like
single
single
executable
applications,
I
don't
think
they're
being
discussed.
So
things
like
observability,
I
think,
is
really
important,
but
we
do
have
the
diagnostics
working
group.
A
So
it
may
be
something
that
you
know
we
we
get
together
with
that
group
and
figure
out,
but
like
the
single
x
fuel
applications
and
the
typing,
I
I
don't
think
we've
got
any
sort
of
documented
approach
you
know
or
or
like
I
don't.
I
don't
think
I
could
point
to
anything
in
the
project
that
kind
of
gives
a
hey,
here's,
the
things
we're
working
on
and
what
we
should
be
working
on.
So
they
might.
C
A
Beth,
does
that
sound
good,
or
do
you
have
other
ones
you
think
will
be
good
better
to
start
with,
it
makes
sense
to
me
I'm
good
okay,
so
I'm
just
gonna
paste
those
two.
If
I
can
get
back
to
where's.
B
I
don't
know
I
mean
like
there's
a
lot
of
things
that
that
can
be
done.
I
don't
know
at
the
foundation
like
I
I
guess
what
do
you
mean
in
the
context
of
explore
with
the
foundation?
It's.
A
B
Mean
I
would
love
that
I
I
think
I
think
I
mean
having
you
know,
touched
the
docs
here
and
there
over
time
and
having
talked
to
people
about
them
many
times.
B
I
I
think
it's
less
like
I,
I
think,
there's
a
step
that
needs
to
happen
before
a
technical
writer
which
is
like
getting
up
some
infrastructure.
Isn't
the
right
word
but
like
making
getting
our
tooling
up
to
date
on
that
as
well
and
kind
of
having
it
be
a
little
bit
more
modern
than
than
it
is
like.
We
do
have
the
most
basic
tooling
we
can
kind
of
have
for
that,
but
there
there's
definitely
more.
That
could
be
done.
B
I
think
that
might
be
a
even
precursor
step
and
that's
my
opinion.
Maybe
maybe
I'm
wrong
with
that,
but
that's
been
what
I've
seen
a
need
for
for
do.
B
I
mean
yes,
I
think
electron
does
docks
very
well
and
I've.
I've
talked
about
this
extensively
in
the
past.
I
think
electron
does
not
very
well
they.
They
wrote
a
custom
docs
parser
that
helps
them.
Do
a
lot
of
things,
including
generate
types.
A
Would
that
take
it's
in
part
takes
like
you
know,
just
exploring
the
different
options.
It
either
takes
somebody
who's
interested
and
can
push
it
forward,
or
you
know
you
know
like
there's.
I
know
there's
been
discussions
in
the
past
of
like
you
know,
if
it's
technical
writer
side
like
maybe
that's
something
you
need
to
actually
get
some
support
to
do
right
from
say
the
foundation
or
whatever.
B
We
can
we
could
explore
them
all
at
the
same
time
as,
like
you
know
talking
the
foundation
about
that
because,
like
I
know
at
least
the
cncf
does
that
for
for
kubernetes,
although
they're
in
a
physically
different
situation,.
A
But
right,
but
I
guess
it's
kind
of
like
if
we
thought
that
was
useful
and
we
could
get
consensus
across
the
project
like
at
least
if
we
have
an
ask
like
a
specific
asp
right
and
then
like.
Maybe
it
could
be
like
we're
looking
for
sponsorship
of
this,
or
I
don't
know
we
might,
you
know,
be
able
to
explore
different
ideas
for
how
how
to
make
it
happen.
A
If
we
had
like
a
path
forward,
you
know,
I
guess,
on
the
the
reusing
it
comes
down
to
like
how
much
work
it
is
versus
how
much
disruption
right
and
in
terms
of.
A
B
I
I
think
part
of
that
is
like
getting
us
to
a
good
foundation.
So,
like
you
know,
a
technical
writer
could
definitely
help
with,
like
you
know,
making
sure
every
every
section
has
like
a
code
example
like
that's
a
good,
a
good
starting
place
like
that.
We
I
kind
of
wish
we
were
at
and
just
and
then
also
documenting,
like
you
know,
extending
our
documentation
on
like
what
should
be
included
like
the
the
meta
documentation
a
bit
of
like
how
do
you
do
this?
B
Well,
that's
a
you
know
another,
and
there
could
a
step
there
that
you
can
take
or
another
result
or
outcome
that
we
can
have
from
from
paying
someone
to
do.
This
is
like
here's
how
we
could
continue
to
make
this
better.
A
A
A
D
B
I
generally
yes,
there's
there's
been
a
lot
of
standardization
on
like
docusaurus
and
stuff
right,
but
even
that,
like
electron
switched,
docusourcing
is
still
doing
they're,
like
you
know,
linting
or
parsing.
So,
like
generally,
yes-
and
you
know,
it's
also
really
hard
to
get
docs
good,
docs
right
so
wide
spectrum
of
successes
and.
A
C
C
A
B
I
think
I
have
a
repo
that
documented,
where
I
was
exploring
if
it
worked
for
node
right.
B
I
the
the
the
challenge.
The
one
challenge
with
it
is
basically
needs
it
to
be
fundamentally
rewritten
for
node,
which,
like
a
lot
of
it's
transferable
but
the
the
problem
is,
they
expect
only
one
export
per
module
which
it
turns
out,
is
a
pretty
important
thing
but
yeah.
If
you
go
to
bnb
stocks,
parser,
oh
wait,
is
it
dark
spirit
hold
on
the
doc's
parser?
I
think
it
is
no.
It's
not
trying
to
find
yeah,
no
bmb,
slash
node.
B
I'll
put
a
link
in
the
chat
that
is
where
I
was
exploring
what's
similar
and
how
kind
of
workable
it
is
for
us.
B
I
I
they're
they're
they're
work
to
rewrite
it
they're
open
to
it.
It's
not
a
like
a
full
rewrite.
It
just
needs
to.
It
needs
changes
that
are
like
you
know,
re-hooking,
stuff,
up
and
adding
stuff
and
and
I've
I'm
interested
in
working
on
that-
and
I
know,
there's
another
microsoft,
employee
who's,
also
interested
in
working
on
that.
A
B
To
get
a
clear
picture
of
yeah,
if
you,
if
you
effectively
for
for
what
I've
seen
at
least
comparing
the
two
and
like
changing,
do
you
mean
like
starting
to
like?
Theoretically,
if
doc
sparser
worked
for
node?
What
would
that?
What
would
that
kind
of
yeah.
A
Like
what's
what's
the
win,
if
we
so
here,
I'm
just
going
to
like
bring
up
this
page
right,
so
this
is
this,
is
this?
Is
the
current
docs?
You
know
you
can
click
in
you
can
find
things
and,
like
personally
to
me
it
doesn't
look
terrible.
B
So
I
mean
technically
the
the
ui
wouldn't
change
at
all.
Right
like
it's
effectively
what
their
docs
parser
does.
Is
it's
a
linter,
it's
an
extremely
aggressive
linter
that
enforces
very
strict
rules
on
how
you
how
you
write
your
markdown
in
a
way
that
is
effectively
technical,
like
you
were
writing
an
api
in
markdown,
but
in
a
very,
very
normal
human
writing
way
like
how
humans
would
write,
documentation
right.
B
And
the
result
of
that,
for,
for
you
know
this
page
say,
is
that
you
have
a
lot
more
consistent
documentation
throughout
because
of
how
structured
it
is.
Everything
is
familiar
and
consistent
and
there's
not
like
you
know
you
can't
really.
You
can't
really
tell
who
wrote
it
like.
That's
one
thing
that
I
I
noticed
yeah
so
like
context
isolation.
There
is
a
good
one
to
look
at
probably.
C
B
C
B
I
okay,
this
is
a
guide.
Do
where
is
the
api?
Oh
click
api.
At
the
top
sorry,
api,
docs,
right
yeah,
so
like
all
of
this
is
very
it's
it's
more
consistent
in
that
the
structure
of
how
the
the
documentation
is
written
across
every
page
is
the
same
right,
which,
in
my
experience,
is
the
biggest
problem
with
node
of
everything
is
different
and
you
don't
really
know
what
you're
going
to
get
on
any
method
right.
It
just
depends
on
who
invested
in
it
right.
B
The
other
you
know
the
other
benefits
of
that
are
like
they
run
this
in.
Basically,
they
they
generate
typescript
definitions
from
this,
and
if
those
typescript
definitions
fail
on
a
build
like
on
a
pr.
So
if
those
are
wrong
that
they
automatically
spit
those
out
that
then
tells
them.
Okay,
we
need
to
update
the
docs
for
this,
so
you
end
up
over
time
having
better
docks,
because
it's
it
shifts
where
the
priority
of
docks
are
up
to
the
very
front
right.
B
A
A
C
A
And
you
know
that
that's
a
good
concrete!
It
may
take
a
long
time
right
but,
like
you
know,
it
seems,
like
you
know,
saying
the
the
code
coverage.
It
is
something
that
people
pick
up,
because
it's
very
digestible,
very
understandable
and
there's
the
tool
telling
you
whether
you
got
it
right
or
not
right
so
by
the
time
you're.
C
A
To
run
the
pr
you
can
you
you
know,
most
people
can
look
at
it
and
say:
okay,
well,
yeah
the
information
still
looks
good
and
you
know
the
the
tool
says
it's
good,
so
yeah
that
can
land.
A
B
Yeah-
and
I
guess
also
in
that
vein-
if
that
was
something
we
wanted
to
ask
the
foundation
for
help
for
there,
there
are
definitely
people
in
the
ecosystem.
Who
would
be
very
good
at
helping
with
that.
C
B
I
I
like,
I
don't
know
how
to
actually
pronounce
this
full
name,
but
like
worm,
the
the
person
who'd
maintain
titus
the
person
who
maintains
like
unified
and
stuff,
which
is
presently,
I
think
what
we
rely
on
to
some
extent.
He
I
think
he
does
contracting
and
stuff
as
well
and
he's
super
lovely.
So
that's
you
know,
that's
a
potential
avenue
of
kind
of
setting
this
up.
If,
if
that's
something
we
want
to
do
and
like
really
making
this
solid
for
us.
A
This
sounds
like
a
decent
proposal
as,
like
you
know,
in
terms
of
the
we're
kind
of
doing
the
deep
dive
on
documentation
at
least
a
little
bit
like
it
kind
of
sounds
like
there
could
be
something
that
says
like
here's,
here's,
the
first
thing
we
can
improve
in
terms
of
our
docs
right.
It's
the
consistency
like
listing
out.
What
is
it
that
we're
gonna
get?
If
we
do
this
yeah
and
then
saying
okay,
this
is
this
is
like
some
key
things
that
you
know
would
help
the
docs.
A
If
we
did
blah
blah
blah,
then
here's
actually
a
tool
that
we're
aware
of
which
will
help
us
get
there.
And
then
you
know
three.
We
think
we
can
do
this,
incrementally
here's
what
needs
to
be
done
to
sort
of
get
there.
It
sounds
like
you
know.
You
have
a
few
people
interested
in
doing
the
tooling
side
of
the
work.
D
A
A
You
know
the
there's
always
the
risk,
you
would
do
some
work
in
the
tool
and
then
when
people
say
what
see
what
the
first
page
looks
like
yeah
there's
still
discussion,
disagreement
whatever,
but
you
know,
at
least
by
you
know,
trying
to
lay
it
out
beforehand.
A
You
know
and
maybe
kick
it
off
as
a
strategic
initiative
or
whatever,
but
make
sure
it's
people
have
have
ample
time
ahead
of
time
to
say
make
sense
doesn't
make
sense,
and
then,
if
we
really
can
do
it
incrementally,
it
seems
like
you
know,
once
you
get
a
couple
in,
then
the
momentum
should
be
able
to
pick
up.
B
A
A
So
I
wonder
I
guess
the
question
is
like
do
we.
It
sounds
like
actually
on
the
the
documentation
one
we
could
actually
have
a
if
we,
we
could
have
a
fairly
more
in-depth
discussion
that
you
might
be
able
to
lead
if
people
were
interested
in
coming
to
it,
but
I'm
not
sure
if
we
want
to
do
that
or
just
try
and
write
it
down,
and
you
know
through
through
github
and
stuff
try
and
get
people
talking
or
thinking
about
it.
A
A
And
you
know,
I
guess
it's
with
the
it
sounds
like
you've
got
the
offer
to
to
work
on
the
the
electron
stuff
if
people
are
interested
right,
so
this
is
kind
of
the
proposal
to
say
this
is
what
we
think
would
is
the
next
step
we
should
take
on
the
documentation
it
provides.
These
benefits
we're
willing
to
do
this
part
of
the
work.
If
people
agree,
this
is
useful
and
interesting.
I.
B
Mean
I
will
also
say,
like
I,
don't
want
to
over
commit
for
someone.
Yeah
they've
expressed
an
interest.
I
I
don't
know
you
know
how
much
of
that
they
can
actually
commit
to.
So
I
I
definitely
want
to
be
upfront
about
that
and,
like
I'm
happy
to
pair
with
them,
and
I'm
happy
to
kind
of
do,
do
work
on
this.
I
don't,
I
don't
think
I
can
personally
take
take
on
leading
it
but
yeah.
A
Yeah,
it
could
be
like
yeah.
We
think
that
doing
this
would
make
sense,
and
then,
if
so,
it's
okay,
okay,
this
particular
piece
needs
some
work
and
then
it's
like.
Can
we
actually
make
that
work
happen,
because
it
sounds
like
any
trying
to
find
any
other
tool
that
would
do
something
similar
like
I'm,
assuming
there
isn't
any
other
one
out
there
that
we
know
of
that
would
do
the
same
job
or
a
better
job
or
anything
like
that.
B
C
A
A
So
I
think
just
having
a
like
this
is
what
we
think
the
tangible
thing
we
should
do
and
a
plan
whether
we
can
get
people
to
do
it
commit
to
do
it.
Whatever
is
sort
of
a
separate
thing,
at
least
the
for
each
of
these
areas
we
had
a
this
is
what
we
think
we
should
do,
and
it
adds
this
value
for
all
the
different
ones.
And
since
you
know,
we
could
start
with
that
one.
It's
it
maximizes
our
chance
of
actually
getting
them
to
happen
yep,
but
it's
no
guarantee
of
course,
okay.
A
So
so
it
sounds
like
on
that
one
like.
Maybe
if
you
can
write
that
up-
and
we
could
collaborate
through
through
github
a
bit
on
that
one
and
I'll
take
the
action
to
schedule,
try
and
schedule
a
mini
summit
see
if
we
can
get
that
kicked
off
to
talk
about
the
types
and
the
single
executable
applications.
C
Just
on
the
documentation
part
should
we
also
include,
let's
say
a
translate
translation
effort
on.
I
know
I
don't
know
if
electron
did
that,
but
I
know
react
and
view
and
other
community
did
translate
the
documentation
in
multiple
languages
with
the
help
of
let's
say
team
across
the
world.
Should
we
also
take
that
into
account.
B
I
think
that
is
in
by
the
way.
Can
you
hear
me?
Okay,
cool
my
gpu
crashed,
but
I
didn't
unmute
so
or
I
didn't
mute
so
yeah.
I
think
that's
kind
of
already
covered
by
the
internationalization
stuff
like
that,
can
be
relatively
separate
from
this.
I
think
from
at
least
from
the
the
the
parsing
work,
but
I'm
happy
to
to
see
how
we
can
explore
that
in
it
as
well.
A
B
A
A
C
A
C
C
A
Yeah,
like
what
I
I
don't
have
enough
expertise
to
know
like
how
much
not
having
other
translations
is
holding
us
back,
like
you
know,
is,
is
it
that
it
was
a
nice
to
have
that
there's
other.
You
know
there's
translations
or
is
it
a
oh?
You
know
we're
losing
25
of
usage
because
the
translations
aren't
there
yeah.
A
C
B
They're
pretty
good
about
that.
I
mean
java,
I
think,
is
much
more
enterprise-y,
so
they
invest
a
lot
more
into
that,
like
they
have
a
lot
more
corporate
direct
corporate
donors.
Python,
I
think,
has
also
started
doing
a
better
job,
although
I'm
not
sure.
A
A
Yeah,
so
I
mean
that's
one
data
point
right
like
if
other
languages
have
found
that
it's
important
so
where's
where'd,
you
get
the
list.
Okay,
I
see
there's
the
python
right.
So
there
are,
you
can
just
drop
down
and
say:
there's
french
yeah
chinese,
so
they
have
a
list
of
yeah
english,
spanish,
french,
japanese
korean
brazilian
simplified
for
the
chinese
and
traditional
chinese.
A
A
A
2012
there
was
somebody
saying
there
wasn't
benny
like,
like
you
know,
I
I
don't
know
what
other
people's
experiences
but
like
I,
I
worked
with
the
company
in
in
montreal
for
a
while.
So
french
was
the
language
they
would
speak
in
the
office,
but
the
technical
documentation
that
was
used
was
still
all
english.
D
A
So
I'm
it's.
C
B
That
up
yeah
there's
a
there's
a
lot
of
prior
art
here
that
I'm
sure
we
can
kind
of
lean
on.
A
B
I
think
another
thing
is
looking
at
where,
where
we're
getting
downloads,
that's
generally
a
pretty
good
map
for
us
of
of
usage,
and
it
can
also
tell
us,
you
know,
get
us
out
of
a
bit
out
of
survivorship
bias
where
we're
not
getting
downloads
right,
like
the
javascript
community
in
like
south
america,
is
amazing,
it's
largely
either
spanish
or
one
of
the
various
variations
of
portuguese.
B
B
That
that's
the
you
know
that
could
be
an
indicator.
I
mean
another
thing:
is
you
know
there
are
open
source
analytics
things?
I
know
people
have
issues
with
google
analytics,
which
is
fine,
but
so
I'm
putting
that
on
putting
that
on
the
doc
site
and
getting
information
that
way
to
help
know
you
know
browser
languages
that
are
available
and
getting
a
list
that
way
could
be
an
approach.
E
A
Yep
with
proposal.
B
A
A
A
A
So
yeah,
I
think
that's
that's,
probably
a
good
question
for
us
to
figure
out
like
as
a
project
forget
whether
we
can
you
know
the
resources
or
whatever,
but
like
do.
We
think
it's
a
key
important
thing
to
have
the
different
language
translations
or
not
right.
C
A
C
A
It
happens
right
because
like
if
it's
something
we
think
that,
like
is
you
know,
you
know,
be
key
to
success.
Then
you
know
we
should
probably
do
more
than
just
enable
right
or
the
I
mean.
As
another
data
point
I
don't
know
tierney
do
you
know,
since
you
know
a
bit
about
the
electron
one,
do
they
have
translations.
B
They
have
crowded,
we,
we,
I
think
about
their
crowd
and
stuff,
was
one
of
the
things
that
we
kind
of
based
our
crowd
and
stuff
on.
A
B
My
understanding
is
yes,
it's
worth
noting
that
this
stock
site
is
like
we're
currently
working
on
completely
revamping
it.
This
is
like
the
revamped
version
I.
A
E
A
So
yeah,
I
think
the
discussion
to
have
is
like
you
know
how.
How
key
is
this
for
the
project,
because
right
now
we're
not
re?
I
know,
though,
the
website
team
has
some
thoughts
or
discussion
on
it,
but
I
don't
think
it's
like
actively
moving
forward
so
that
I
could
say
like
next
year.
We'll
have
something
right,
yeah
in
terms
of
translating
our
api
docs
at
least
yeah.
A
So
it's
I
think
from
this
group.
It's
like
in
my
perspective
at
least,
is
you
know,
can
we
figure
out
based
on
data,
something
that
says?
Oh,
this
is
critical
or
not
to
sort
of
raise
the
the
focus
on
it.
If
it
is
something
that
we
believe
is
critical.
D
A
A
A
We
can
maybe
get
some
discussion
there
and
you
know,
maybe
I
think,
asking
like
the
foundation
for
their
experience
and
stuff
and
just
having
that
in
the
end,
if
even
if
we
end
up
just
documented
with
you
know,
well
we
thought
about
it,
but
we
can't
really
justify
more
focus
or
or
yes,
we
can
like
even
just
having
gone
through.
That
would
make
sense
on
that
front
for
sure
yeah,
okay.
Well,
I
think
that's
probably
a
decent
discussion
on
that
front
and
I
don't
think
we
have
time
to
kind
of
get
well.
A
We
only
have
five
minutes.
We
don't
have
time
to
get
into
the
next
one.
So
we
have
a
couple
of
things
to
plan
we'll
try
and
plan
a
mini
sub
summit
to
dive
into
these.
These
two
categories
that
are
priorities
that
I've
highlighted
and
you
know
through
github.
We
can
work
a
little
bit
on
the
documentation
side
of
things.
A
D
A
Thanks
bye,
bye,
oh
and
there
was
somebody
sorry
muhammad
didn't
promote
you,
but.