►
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
A
I
have
worked
in
the
node.js
community
for
a
number
of
years
and
was
a
part
of
the
group
who
helped
merge
the
J's
Foundation
and
the
node.js
foundation
into
the
now
open,
J's
Foundation,
which
happened
a
little
over
a
year
ago
and
I.
Currently
am
the
chairperson
of
the
cross
project
Council,
which
is
the
top
Technical
Advisory
Committee
within
the
foundation,
and
we
work
in
the
CPC.
The
cross
project.
A
Council
to
you
know,
help
help
projects
to
be
successful
whatever
that
means
for
them
and
support
them
with
infrastructure
or
security
or
standards,
or
you
know,
code
of
conduct
in
moderation,
processes.
Things
like
these
I'll
also
just
add
real
quickly
that
we
meet
every
Tuesday
across
project
Council
and
we
have
lots
of
work
to
do.
A
If
you
have
any
interest
in
the
work
that
we
are
doing,
please
join
us,
you
can
find
more
information
on
the
open,
JSF,
dot,
org
site,
slash
collaborate
gives
you
links
to
slack
and
the
github
repos
and
and
the
calendar
and
a
variety
of
things.
That
may
be
helpful.
So
you
know
that's
a
little
bit
about
me.
Let's,
let's
talk
about
contributing
to
open
source
I
want
to
mention
at
the
outset.
A
That's
the
kind
of
center
of
the
road
here
for
this
journey
is
talking
about
new
contributors,
but
I
hope
that
you
know
I'll
also
raise
things
that
will
be
helpful
for
maintainer,
x'
or
other
seasoned
open-source
contributors
along
the
way,
as
well
so
to
get
things
started.
I
think
it
makes
sense
to
talk
about
etiquette
and
kind
of
how
you
approach,
open-source
and
and
contributing
to
or
repositories
in
the
open-source
space.
I
know
that
this
can
in
some
instances,
V
be
very
daunting.
A
A
I'll
also
add
that
it's
when
you're
interacting
with
folks
in
open
source,
remember
to
be
courteous,
don't
be
afraid
to
ask
questions,
always
assume
good
intentions.
I
would
recommend
that
you
take
some
time
to
read
documentation
around
contributing
and
the
processes
that
are
in
place
for
contributing
to
different
repositories.
Well,
whether
they
be
you
know,
code
style,
linting
or
commit
message,
format
and
things
like
that,
make
sure
you
put
a
little
effort
upfront.
So
you
understand
what
the
project
is
expecting
of
new
contributors.
A
A
It's
really
I've
found
the
best
way
to
learn
and
to
engage
with
with
with
folks
around
open
source,
because
there
really
drives
you
to
you
know,
think
through
things
thoroughly
and
to
think
about
edge
cases
and
testing
and
and
all
these
sorts
of
things
so
remember
that's
most
of
the
people
and
open-source
of
humans,
and
you
should
assume
good
intentions
and
you
know
just
dive
in
and
it's
it's
typically
a
good
experience.
So
I
encourage
you
to
to
do
that.
A
Similarly,
on
the
opposite
side
for
maintained
errs
and
collaborators
in
projects,
remember
that
it
is
daunting
for
new
contributors,
so
be
kind.
Be
gentle.
Remember,
assume
good
intentions
on
on
both
sides
right
there.
There
are
no
dumb
questions.
Let's
be
courteous
to
each
other,
be
sure
that
you
are
contributing
guidelines
and
the
things
that
go
along
with
that
are
clearly
documented,
like
what
you
expect
from
commit
messages.
If
you
are
particular
about
that
sort
of
thing.
A
Lacking
blockers
to
get
involved
right,
so
one
place
that
I
would
start
to
encourage
folks
to
look
at
is
the
community
health
of
a
project.
So
if
you
know
a
particular
project
that
you
are
considering
getting
involved
in
I
recommend
you
go
to
that
repository
and
you'll
notice
in
the
tabs
along
the
top.
There
is
an
insights
tab
and
if
you
click
on
that,
there's
a
community
sub
tab,
I
guess
you'd
call
it
and
within
that
community
view
into
the
project,
you'll
find
links
to
the
code
of
conduct
contributing
guidelines
license.
You
know
a
few.
A
A
few
metrics
that
github
has
determined
are
good
indicators
of
a
project's
health
as
it
relates
to
the
community
and
particularly
new
contributors.
So
those
are
some
important
things
to
check
out.
Of
course,
you'll
want
to
look
at
the
license
and
make
sure
that
that's
that
works
for
you
and
if
you're,
unsure
about
license
ease
lysed
licenses
choose
a
licensed.
A
Org
I
think
it
is,
is
a
great
resource
for
learning
more
about
the
different
types
of
licenses
and
what
they
mean
as
I've
mentioned,
checkout
contributing
guidelines
and
such
which
are
referenced
in
the
community
health
view
there,
but
probably
most
importantly,
the
the
first
place
that
I
would
go
and
look.
Is
the
code
of
conduct
so
make
sure
that
there
is
a
code
of
conduct
in
place?
Make
sure
that
you
are
comfortable
with
it
to
make
sure
that
it
is
extensive
enough?
That's
that
it
covers.
A
You
know
the
different
areas
that
you
may
be
concerned
with.
There
is
a
contributors
covenant,
that's
a
lot
of
projects
use
and
that
that's
great,
a
lot
of
folks
have
have
landed
on
that.
I
know
that
there
are
a
couple
others,
but
definitely
just
make
sure
that
something
like
that
is
in
place.
So
there
there
aren't
any
issues
down.
A
The
road
I
think
having
a
good
code
of
conduct
is
a
good
indicator
that
the
project
takes
these
sorts
of
things
seriously
and
is
welcoming
to
new
contributors
and
I
would
also,
on
the
flip
side,
again
encourage
maintainer,
z'
and
collaborators
to
also
view
this
page
and
see
how
your
repository
stacks
up.
There
I'll
mention
that
if
you
go
and
look
at
github,
comm,
slash,
nodejs,
slash,
node
and
look
at
the
community
health
profile,
it's
in
pretty
good
shape.
The
I
mean
I,
think
it's
actually
in
great
shape.
There
is.
A
It
looks
like
it's
saying
that
the
code
of
conduct
I
believe,
is
so
the
code
of
conduct
or
is
it
the
contributing?
Maybe
the
contributing
guidelines
are
not
fully
in
place,
but
if
you
click
through
to
it,
you'll
actually
find
that
the
nodejs
project,
through
its
years
of
work,
has
really
developed
robust
processes
and
guidelines
around
things
like
code
of
conduct
and
moderation
and
contributing
the
documentation.
There
is
very
well
fleshed
out
and
I
think
that
you
should
find
that
very
helpful
and
very
encouraging.
A
These
are
things
that
we've
been
working
on
for
a
long
time.
So
if
the
community
health
profile,
you
know,
looks
a
little
lacking
just
make
sure
to
click
through
and
and-
and
you
know
double
check
for
yourself-
that
the
computers
have
got
everything
correctly
so
moving
on
from
from
well,
you
know,
let
me
let
me
say
actually
I
wanted
to
also
highlight
this
neat
trick.
That's
I
found
someone
posted
on
on
Twitter
a
few
months
ago.
Perhaps
that,
if
you
go
to
a
repository,
say,
for
example,
nodejs
slash
node,
which
is
the
node
core
repo.
A
First
issues
and
I
suspect
that
there's
there
are
some
like
documentation
issues
in
there,
I
don't
know
how
it
does
it,
but
it
seems
like
it
tries
to
pull
out
issues
that
it
thinks
would
be
good,
good,
first
issues,
even
if
they
don't
specifically
have
that
label
on
them.
So
that's
a
neat
trick.
Definitely
check
that
out.
A
So
moving
on,
we
have
talked
about
the
process
that
a
project
may
have
in
place
to
contribute
and
you'll
definitely
want
to
spend
some
time
going
through
the
this
documentation
so
that
you
can
be
successful
in
your
contributions.
So
you
know
I
think
we've
mentioned
a
couple
times
now
like
get
commit
messages.
Some
larger
projects
are
very
particular
about
how
you
may
format
these
messages
code
style,
guide,
documentation,
style
guide.
A
There
are
a
number
of
things
that
you'll
want
to
just
make
sure
you're,
aware
of
at
the
very
least
may
want
to
reference
again
before
you
open.
Your
first
poll
request
that
you
are
in
line
with
with
what
is
expected
and
I
did
notice.
Today,
that's
from
the
node
contributing
guidelines.
There's
this
really
helpful
paragraph
that
says
and
I'll
read
this
directly.
If
you
are
new
to
contributing
to
node.js,
please
try
to
do
your
best
at
conforming
to
these
guidelines,
but
do
not
worry
if
you
get
something
wrong.
A
One
of
the
existing
contributors
will
help
get
things
situated
and
the
contributor
landing.
The
pull
request
will
ensure
that
everything
follows
the
project's
guidelines.
So
these
are
guidelines
that
are
in
place,
but
you
know
don't
feel
like
it's
such
a
barrier
that
you
won't
get
involved,
because
there
are
people
there
that
can
help
you
now.
Another
thing
to
be
mindful
of
are
any
prerequisites
that
may
exist
for
projects.
A
You
know.
Node
has
some
when
you
first
get
started
and
you
are
running
node
locally.
There
are
some
things
you
need
to
be
aware
of,
and
this
can
be
tooling.
This
can
be
like
underlying
dependencies,
but
also
it
could
be
like
concepts
so,
for
example,
es
lint,
which
is
another
open,
JS
foundation
project,
it's
largely
based
on
the
ast,
the
abstract
syntax
tree
and
so
having
a
good
understanding
of
how
that
works
will
be
beneficial
to
you
getting
involved
in
a
project
like
that.
A
So
there
may
be
some
upfront
learning
that
you
may
want
to
do
depending
on
the
project.
So
now
I'd
like
to
take
a
moment
and
talk
about
like
the
typical
github,
open
source
contributing
flow
and
what
that
looks
like
and
it's
it's
basically,
you
know
fork
clone
set
your
upstream
branch.
Make
changes.
Add
those
changes
commit
create
a
pull
request,
so
that's
kind
of
the
TLDR
really
quickly,
but
I'll
just
go
into
each
of
those
for
a
moment
for
folks
that
are
new
to
this
process.
A
A
If
you
don't
have
git
configured
correctly,
you'll
want
to
add
your
username
and
your
email
with
git
config
username
and
the
value
and
get
config
you
sort
out,
email
and
the
value.
So
there's
a
couple
of
ways
to
get
things
set
up.
It's
it's
best
practice
to
create
a
branch
when
you're
contributing
to
an
open
source
repository,
and
this
way
you
know,
if
you
have
a
couple
of
different
pull
requests
that
may
be
open.
They
don't
step
on
each
other
right.
A
A
A
Try
to
avoid
larger
requests
that
may
touch
on
a
variety
of
things.
You
want
to
definitely
keep
it,
as
you
know,
as
tightly
knit
as
possible
as
small
and
focused
as
possible.
So
once
you
make
your
changes,
you'll
add
those
files
get
commit,
I'm
sorry
get
add,
and
then
your
files
or
get
add
period
is
what
I
usually
use
when,
when
I'm
just
focused
on
one
little
thing
in
a
branch,
get
commit
I
typically
add
my
commit
message
in
line
whatever
works
for
you
and
then
you'll
get
push
origin.
A
Your
branch
right,
so
that's
kind
of
the
typical
flow
get
your
repository
local
make
your
changes.
Get
add,
git
commit
git
push
with
a
project
that
has
a
lot
of
moving
parts,
a
lot
of
things
changing.
You
may
also
want
to
get
rebase
your
changes
from
upstream,
so
that
when
you
create
your
pull
request,
it's
in
sync
with
what
is
the
latest
and
you
may
need
to
do
that
on
an
ongoing
basis
basis.
A
While
your
pull
request
is
open,
but
you
can
do
that
with
git
fetch
all
get
rebase
upstream
master
and
then
get
push
force
or
force
with
lease.
A
note
that's
while
rebase
is
is
my
friend.
I
think
it
should
be
your
friend
to
you,
but
you
need
to
be
aware
that
when
you
push
something
with
with
force,
it
rewrites
history,
so
it
can
be
dangerous,
but
you
know
just
use
it
wisely.
I
use
it
all
the
time,
so
that's
kind
of
the
typical
flow
I
within
that
tool
that
I
mentioned
earlier
hub.
A
You
can
create
a
pull
request
directly
from
the
command
line,
and
you
know
it's
a
simple:
it's
a
good
workflow
to
to
be
using
when
you're
contributing
to
open
source,
but
I
wanted
to
highlight.
That's.
Not
all.
Contributions
are
code.
Right
there
are
a
number
of
ways
to
contribute
to
open
source
projects
and
I
think
that
this
is
important
to
call
out
so
just
in
general,
documentation
is
always
a
good
place
to
to
get
involved.
A
In
fact,
when
a
few
months
ago,
I
was
working
on
at
Gatsby
site
and
I
found
some
discrepancies,
some
things
that
weren't
particularly
clear
to
me
and
I
just
went
and
clone
the
repo
brought
it
down
and
created
a
pull
request,
and
the
gentleman
that
leads
that
project
his
name
is
escaping
now
is
was
really
very
courteous.
Very
appreciative
and
I
was
happy
to
contribute
a
really
good
experience
there,
so
that
docks
are
great.
A
If
you
have
interest
in
building
websites,
you
know
a
website
for
the,
for
the
project
may
be
in
place
and
you
can
help
their
project.
Management
frankly,
is
something
that
is
always
needed
in
an
open
source
repository,
and
then
there
could
be
other
things
like
social
media
community
outreach,
those
sorts
of
things
and
I'll
touch
on
that
more
in
a
moment.
I'll
just
also
add
to
that.
With
with
projects
like
node-red,
which
is
another
open,
J's
foundation
project,
you
can
contribute
nodes
to
the
programming
interface.
A
Loopback
is
another
open
source
project
that
I've
contributed
the
datasource
connectors
to
and
done
work
outside
of
core
that
that's
helpful.
So
there
are
a
number
of
ways
that
you
can
contribute
that
aren't
just
the
core
code
or
even
code
and
at
all
so
another
few
ways
that
you
can
do
that
with
a
node
is
that
we
have
these
concepts
of
initiatives
and
teams
and
working
groups.
A
So
so
some
examples
are
the
the
release
team,
which
involves
code
for
sure
because
you're
you
may
be
back
porting,
some
things
to
different
release
lines,
but
but
but
that's
always
a
very
active
team
that
that's
you
can
get
involved
with
the
build
working
group
is
another
team
with
a
node.
There
is
a
website
redesign
team,
that's
been
active
for
a
while
and
that's
a
great
place
to
get
involved
too
for
a
node
you're
writing
more
kind
of
front-end
code
for
the
website.
Internationalization
is
another
great
place.
A
There's
there
are
not
only
the
translations
that
are
needed,
but
also
the
underlying
work
that
supports
the
translation
effort,
the
the
internationalization
efforts.
So
those
are
those
are
a
couple
of
good
places
and
then
I
mentioned
in
social
community
outreach.
Node
has
a
newly
formed
social
team.
Also
there'll
be
a
group
of
us
that
are
actually
managing
the
social
media
presence.
A
There's
you
know
in
the
past
have
been
community
and
outreach
programs
as
well,
that
are,
that
are
great
ways
to
get
involved
and
then
there's
a
new
initiative
recently
started
for
examples.
So
good,
straightforward,
simple
examples
for
a
lot
of
common
use
cases.
So
that's
another
place,
that's
we'd
love
some
more
contributions
and,
speaking
of
of
all
these
things,
I
want
to
mention
that
the
collaborator
summit
has
been
was
on
Monday
and
is
happening
again
on
Thursday
and
Friday.
A
So
that's
another
great
place
to
to
get
involved
in
open
source
and
the
work
that
we're
doing
in
the
foundation
and
such
so.
A
lot
of
people
will
ask
me:
you
know
how
do
I,
how
does
one
get
their
company
to
get
more
involved
in
open
source
and,
as
I
mentioned
at
the
beginning,
you
know
iBM
is
very
supportive
of
my
work
and
open
source
and
Allah.
A
We
have
a
lot
of
folks
in
IBM
that
are
working
almost
exclusively
on
an
open
source,
but
I've
worked
in
a
variety
of
other
companies
where
you
know
it
was
a
little
bit
more
of
a
struggle
to
get
company
time
to
be
involved
in
open
source,
and
there
is
an
initiative
called
open
source
Fridays.
That
I
think
is
maybe
started
by
github.
A
It's
a
good
website
that
that
kind
of
is
helpful
in
trying
to
do
more
of
the
stuff
and
particularly
like
dedicating
Fridays
to
it.
What
I
found
successful
at
my
time
at
Behance
and
Adobe,
was
that
we
were
doing
a
lot
of
work
in
open
source.
We
relied
on
a
lot
of
open
source
tooling,
and
so
we
took
the
friday
approach,
but
we
alternated
between
one
Friday
would
be
like.
A
We
would
call
it
a
bug
bash
and
we
would
just
try
to
clear
out
you
know
in
our
in
our
backlog
we
wouldn't
focus
on
sprint,
work
and
feature
work.
We
would
just
try
to
knock
out
bugs
and
then
the
other
Friday
we
would
alternate
would
be
an
open
source
Friday.
So
you
know
one
Friday's
bug
bash
next:
Friday's
open
source
bug,
bash
open
source,
and
so
that
was
a
really
great,
like
kind
of
middle-ground
compromise.
That
I
think
could
work
for
a
variety
of
development
teams.
A
So
you
may
want
to
consider
that
I'll
also
point
out
a
couple:
more
resources
for
getting
started
in
open
source.
There's
the
great
for
new
contributors,
showcase
that
that
github
has
there's
the
open
source
guide,
which
is
great.
It
has
a
whole
how
to
contribute
section,
there's
also
a
first-timers
only
website,
that's
a
good
resource
as
well,
and
then
I'll
do
a
little
shameless
plug
as
well.
I've
started
in
open
office
hours,
bi-weekly
meeting
for
the
open,
J's
foundation
and
we
meet
every
other
week,
and
sometimes
it's
just
the
open
office
hours.
A
On
a
few
occasions
we
brought
in
project
maintainers
someone
from
Express,
yes,
lint,
internationalization
and
nodejs.
We
have
a
few
more
that
were
lining
up
after
the
event
and
that's
a
I
think
a
really
good
place
for
folks
to
come
and
ask
questions
and
to
learn
about
how
to
get
involved
in
particular
projects.
A
So
if
you
go
to
github.com,
slash,
open
Jas
foundation,
slash
open
office
hours,
you
can
see
more
there
and
that's
my
talk.
I
hope.
That's
you
all
get
involved
in
open
source
and
I
hope
that
it's
a
really
great
experience
for
you
and
my
Twitter
DM
z--
are
open,
so
feel
free
to
message
me
or
if
you
join
the
open,
J's
slack
feel
free
to
message
me.
There
I
try
to
spend
some
time
helping
new
contributors
get
involved,
so
just
reach
out
and
I'd
be
happy
to
help
you
Cheers.