►
Description
B
B
You
know
the
we
could
not
get
into
a
common
consensus
that
works
for
everybody
and
secondly,
most
of
us
are
unavailable
in
the
next
week
going
to
the
node.js
interactive
and
then
I
come
on
holidays,
and
things
like
that,
so
we
thought
you
know
getting
together
and
quickly.
Discussing
some
of
these
items
before
going
off
for
one
month
would
be
something
useful
and
that's
when
this
one
happened.
A
A
My
two
cents
on
that
front,
like
I,
think
like
a
scheduled
meeting,
would
be
good
because
one
of
the
things
like,
in
addition
to
the
specific
triage
issues,
I
think
like
as
on
the
package
maintenance
front,
we
want
to
pull
out
like
and
touch
on,
what's
working,
what's
not
working
and
sort
of
what
we
can
do
in
terms
of
the
pattern
that
we're,
hopefully
gonna,
develop
as
a
good
way
to
get
engaged.
So
at
least
that
some
interval
you
know
talking
about
that
would
be
good.
Yeah.
B
C
Sounds
good
yeah,
so
so
I
definitely
agreed
that
having
some
time
set
aside
for
this
is
good.
I
would
like
to
suggest
we
figure
out
if
we
can
make
the
TC
meeting
for
Express
and
this
line
up
a
little
bit
I
think
if
we
can.
The
only
reason
that
meeting
is
scheduled
for
when
it
is
is
because
it
worked
for
the
people
who
were
at
that
time
attending
and
voted
on
the
the
thing
I
think
we'd
be
happy
to
move
it.
C
Maybe
people
be
like
oh,
but
we're
doing
all
this
work,
and
why
is
the
TC
having
the
separate
meeting
you
know,
I
want
to
make
sure
that
we're
really
trying
to
you
know
make
it
clear
that
this
is
a
group
effort.
We're
really
trying
to
bring
everybody
in
and
the
goal
would
be
that
at
some
point
everybody
has
something
to
say
during
the
TC
meeting,
not
just
whatever
the
trio
section
is
yeah.
A
I
know
that
that
sounds
like
a
really
good
idea
to
me,
like
I
mean,
like
you
said,
it'll
probably
start
it
sort
of
starts
out
with
the
two
purposes,
one
to
figure
out
the
pattern
we
can
use
for
other
projects
as
well
like
and
that's
not
maintenance
related,
but
longer
term.
Like
the
triage
stuff,
you
could
just
see
being
like
okay,
we
figured
it
out.
It's
now,
just
part
of
the
express
planning
and
so
yeah
that
somehow
lining
those
up.
It
really
sounds
like
a
great
idea,
so.
C
A
D
C
I
think
January
would
probably
be
fine.
I
think
this
particular
one
Doug
had
a
couple
of
things
going
on
that
made
it
so
that
he
wouldn't
have
been
able
to
make
the
second.
You
know
time
slot,
but
I
think
if
we're
you
know,
if
we
plan
now
for
January
I'm
sure
that
you
know
we
can
get
a
time
that
works
for
everyone.
C
C
We
changed
the
structure
of
the
TC
meeting
a
little
bit
to
to
make
it
align
more
with
the
needs
here,
which
is
why
I
think
it'll
be
a
little
bit
bigger
discussion
than
just
picking
a
time,
but
that
would
you
find
it
it'll
I
think
it'll
be
easy
for
us
to
get
consensus
on
Beck.
So,
okay,
if
for
those
of
you
who
weren't
able
to
make
our
very
impromptu
meeting,
you
know,
Doug
is
I.
Think
really
excited
for
this.
C
B
I
guess
we
had
a
bit
of
a
discussion
on
that
in
the
first
meeting
between
West
Doug
and
myself
about
opening
a
discussion,
Rocco
kind
of
thing
where
so
we
could
publicly.
You
know,
share
information
and
things
like
that,
but
yeah
we
will
talk
about
that
and
the
other
one
is
about
the
future
meeting
we
just
talked
about.
B
How
do
we
synchronize
it
with
a
TC
meeting
again,
let's
touch
base
on
that
at
the
end
and
then
the
last
one
is
about
the
community
corner
event
which
that
could
BES
is
leading
in
the
node.js
interactive
next
week.
These
are
the
items
we
want
to
discuss
anything
else.
Anybody
wants
to
bring
in
the
agenda
the.
B
C
I
can
get
I
can
just
start,
and
then
you
know
we
can
go
run
CEO
next,
so
I'm
less
working
on
the
package,
maintenance
working
group
stuff,
but
also
the
reason
I
got
involved.
That
was
because
I
work
on
Express,
so
I'm
on
the
PCs
there
and
I
have
been
sort
of
the
point
person
in
trying
to
grow
the
community
around
it.
C
You
know,
Doug
really
leads
the
project
and
his
end
is
often
you
know
the
one
involved
deeply
in
all
the
repos
doing
a
lot
of
the
technical
stuff,
but
that
sometimes
leaves
him
a
little
bit
short
on
time.
Before
doing
some
of
this
you
know
community,
building
and
and
trying
to
get
people
together.
So
my
goal
from
this
is
to
help.
You
know
make
sure
that
the
project
has
a
long
term
maintenance
plan.
That
is,
you
know,
not
a
bus
factor
of
one
or
two
I
guess,
because
you
know
I
I'm
also
participating
in
there.
C
B
B
Manage
the
you
know
just
help
repo
that
gets
a
lot
of
traffic
these
days
and
I
really
enjoy
debugging
and
diagnosing
issues.
So
my
main
motivation
in
scratch
work
is
to
see
what
kind
of
issues
the
users
are
facing
in
the
upper-level
stack
of
the
node.js
and
make
sure
that
the
ecosystem
for
me
Express,
represents
the
node.js
ecosystem,
because
that
is
the
immediate
wrapper.
I,
don't
know
this
I'm
really
happy
and
enjoying
the
work
I'm
doing
in
express
and
looking
forward
to
expand
my
skills
as
well
as
so
scope
of
engagement
in
that
space.
D
Sure
so
hi
I'm,
Beth
Gregg,
so
worker
IBM,
with
Michael
English
I'm,
also
working
me,
know:
jazz
project
I'm,
a
member
of
the
release
team
and
the
LTS
teams
underneath
the
release
working
group
and
also
a
member
of
package
maintenance
and
I'm
kind
of
more
interested
in
the
like
backporting
and
creating
tools
to
help
manage
ODS
versions
and
things
like
that
and
whether
there's
any
like
common
interest
between
how
we
manage
LCS
versions
and
node
and
how
we
both
got
things
in
note
compared
to
dependent
modules
and
Express.
So
that's
me
I.
F
Hello,
hello:
there
was
a
problem
in
the
internet
connection,
so
I
am
working
in
IBM
under
Ganesha
as
an
intern.
So
from
past
five
months,
I
started
learning,
JavaScript
and
node.js
concepts.
So
from
past
two-and-a-half
months,
I've
been
involved
in
Express
issue,
stretching
I'm
I'm
loving
the
works
which
I
am
doing
currently.
F
G
For
that
and
in
our
team
is
responsible
for
products,
Asian
and
and
interminable
release
of
Nokia's,
and
also
responsible
for
to
make
Nokia's
more
aligned
with
the
openshift
platform
and-
and
we
do
a
lot
of
different
things,
but
not
not
directly
related
to
to
application
development
and
and
and
the
Express
triage
was
was
initially,
was
something
disgusted
internally
on
our
team,
but
I'm
not
sure.
If
what
we
are
going
to
to
continue
it
with
express
efforts
directly
via
red
hot
I
mean
my
time.
G
I
can
continue
it
by
myself,
since
this
is
community,
but
but
since
the
the
less
movements
in
the
team,
I
am
not
sure
if,
if
had
happened,
allocate
a
time
for
me
to
to
continue,
but
but
anyway,
being
part
of
this
effort.
If
you
had
had
or
not
because
headaches
is
full
openness
company,
you
know
the
things
get
mix
it
at
some
time.
So
yeah.
A
B
Can
you
see
the
screen?
Yes,
okay,
so
basically
the
next
one.
We
want
to
discuss
a
bit
on
the
approach
which
we
want
to
take
on
the
tragic
front
and
then
some
of
the
some
of
the
things
which
we
experienced
myself,
Ishita
and
Helio
to
some
extent
who
have
been
doing
this
for
the
last
couple
of
months.
We
crafted
that
in
the
best
practice
document,
with
Wes
help
so.
B
Questions
bug
and
enhancement.
These
names
should
be
pretty
trivial
to
map
against,
but
the
only
caveat
here
is
that
once
the
new
issue
comes
definitely
it
goes
into
the
knees
prior
section,
but
based
on
some
reviews
and
some
interactions
with
a
copy,
it
should
fall
into
one
or
one
of
these
other
categories.
That
is
question
bug
or
enhancement.
That
would
involve
some
work.
Sometimes
it
would
be
very
obvious
in
the
first
attempt
itself.
Sometimes
you
will
need
to
do
some
work
or
some
to
and
fro
before.
B
C
E
C
Here
so
there's
a
few
other
tags
and
I
I
didn't
mention
it
when
I
just
approved
this
PR
like
30
minutes
ago,
because
I
had
already
went
through
a
few
rounds
and
I
think
it's
good
for
us
to
just
get
I
like
what's
here
and
get
it
merged,
but
I
do
think.
There's
a
few
other
tags.
We
actively
use
in
most
of
the
Express
repos
and
I'm
I'm
unsure
do
we
think
they're
worth
adding
here,
so
some
of
them
are
awaiting
more
info.
C
C
Question
is
another
one
that
I
think
we
had
had
on
a
list
previously,
but
then
didn't
make
it
into
this.
Oh
no
I
did
question
is
in
the
PR.
Okay,
my
bad,
not
question.
There
was
a
few
others.
Let's
see
good
first
contribution
and
discuss.
Those
are
the
two
wasn't
question
it
was
discussed.
That
was
the
one
I
was
thinking,
so
do
you
think
it's
worth
adding
those
ones
yeah
for
an
electro.
B
B
Yeah,
so
next
one
is
the
general
approach.
So
oh,
the
approach
which
we
took
is
first
looked
at
the
West
status
board,
which
is
absolutely
awesome
because
that
abstract
the
whole
of
95
opposed
across
the
three
organizations.
Expressjs
Pelagius
and
j
sh
t
people.
So
we
looked
at
the
number
of
stars,
the
number
of
contributors
and
open
issues
to
start
with
to
make
some
assumptions
about
what
would
be
the
good
pick
of
the
other
course.
B
So,
for
example,
if
there
are
so
many
open
issues,
then
probably
that
is
an
indication
that
you
need
to
get
engaged
in
with
some
assistance
over
there.
If
the
number
of
contributors
and,
of
course,
the
number
of
contributors
and
the
number
of
maintenance
may
not
have
a
one-to-one
mapping,
but
it
gives
an
indication
about
how
many
people
are
actively
involved
in
that
topic.
So
the
less
the
number
of
maintenance,
the
more
who
should
be
getting
on
to
the
trouble.
B
One
of
the
good
thing
which
I
liked
with
the
Express
project
that
each
of
these
proposed
represent
one
module
and
one
module,
represents
one
discrete
middleware
function
so,
for
example,
Malta
or
body
pause
session.
These
are
the
ones
which
we
came
across
and
these
exposes
one
discrete
function
and
it
is
pretty
easy
to
follow,
and
most
of
these
reports
have
one
single
page,
readme
document,
which
has
the
complete
information
about
the
whole.
The
API
is
that
the
the
module
is
exposing.
B
So
that's
a
really
good
thing
and
one
of
the
pattern
which
this
most
of
the
year
opposed,
follow
I,
believe
it's,
my
extrapolation
is
that
they
start
with
a
constructor.
That
means,
if
it's
a
session,
for
example,
you
create
a
session
object
and
then
bind
it
with
your
express
act
and
provide
all
the
configurations
and
to
nabeel's
that
is
related
to
the
session
at
the
construction
time.
The
constructor
creates
a
number
of
private
functions.
B
C
I
think
it's
a
good
high
level.
There
will
be
some
exceptions,
obviously
I
think
you're
talking
about
the
middleware
modules
you
will
also
find,
and
so
actually
this
is
maybe
a
good
point
to
make.
There's
three
organizations
the
the
way
the
modules
are
structured
under
those
organizations
was
intentional
and
it's
about
what
place
in
the
application
they
have.
So
the
highest
level
is
like
the
middleware
and
express
itself.
Those
are
in
the
expressjs
org,
the
next
level
below
that
is
sort
of
the
framework
components.
C
C
Content
type
negotiation,
etag
generation,
like
all
these
things,
that
it
takes
to
make
up
an
HTTP
framework
that
are
just
totally
generic,
so
so
the
description
Girish
provided
for
these
is
really
for
the
top-level
stuff,
the
middleware
so
session
body,
parser,
Moltar,
etc.
As
you
go
down,
the
module
list
you'll
see,
though,
that
there's
these
three,
these
two
other
orgs
those
may
follow
a
different
pattern.
C
F
C
D
C
B
B
The
other
thing
is
I
believe
most
of
the
modules
have
the
sufficiently
bug
statements
sprinkled
across
the
most
critical
control
flow.
That
essentially
means
you
could
export
the
in
debug
and
then
get
a
high
level
understanding
about
water.
What
are
the
key
control
flow
that
is
happening
in
the
application
in
case
of
something
goes
bad,
for
example,
in
session.
One
of
the
key
pattern
which
we
observed
in
this
session
module
is
session
is
not
persisted
when
the
request
is
redirected
to
another
route,
so
many
issues,
many
people
raise
the
same
issue.
B
B
Similarly
in
in
multi
mode,
you
will
be
so
one
specific
pattern
of
the
error
message
for
any
anything
that
happens
in
the
file
upload
by
the
multa
module.
If
something
goes
for
a
toss,
the
error
is
not
propagated
to
the
final
user
callback.
For
various
reasons,
historical
reasons,
the
cool
callback
is
not
designed
to
receive
an
error
type
and
because
of
that,
there
is
absolutely
no
way
for
one
middleware
to
give
back
the
error
code
into
that.
So
at
at
the
end
of
it
the
error
is
being
absorbed.
There
is
a
workaround
for
that.
B
B
And
the
other
point
I
want
to
mention,
is
you
know
how
writing
reusable
code
has
been
really
really
great?
We
did
it
a
couple
of
times.
The
whole
idea
is
look
at
the
pattern,
for
example,
in
this
session,
not
persisting
across
three
directions.
We
just
wrote
a
client's
of
a-kor
which
make
use
of
a
session
and
then
having
two
routes
and
demonstrated
how
the
session
is
persisting
between
the
three
directions
and
then
posted
it
in
a
gist
then
cross-referenced
it
in
all
the
issues
that
reported
this
particular
problem
now.
B
C
Me
just
on
that
note.
If,
if
the
team
only
wrote
reproduction
cases,
it
would
be
immensely
valuable,
obviously,
there's
tons
of
other
things
we
can
be
doing,
but
one
of
the
most
common
things
for
those
awaiting
more
information
tags
is
that
the
person
just
didn't
provide
us
enough
of
a
reproducible
case
to
understand
what
they're
doing
so
so
doing.
That
alone
would
be
very
valuable
to
us,
so
so
definitely
keep
that
top
on
the
list
of
things
to
do.
Yeah.
B
So,
in
many
cases
what
happens
is
the
opie
description
gives
you
some
understanding
about
the
problem,
but
because
of
the
fact
that
they
don't
provide
completely
running
code?
You
don't
know
what
is
actually
happening
under
the
cover.
They
may
not
be
able
to
explain
the
problem
properly.
They
may
be
making
some
mistakes
in
their
program,
but
because
they
don't
know
what
mistake
they
are
making,
they
will
not
expose
that
particular
aspect.
They
won't
explain
it
now.
B
If
at
completely
running
program
is
published,
they
can
actually
compare
that
program
with
what
they
are
doing
and
probably
he's
making
corrections
in
a
in
a
point
where
they
may
be
making
a
mistake.
So
we
have
seen
that
immensely
helpful
if
he
come
up
with
a
you
know,
a
completely
renewable
problem,
not
not
now
so.
H
C
H
C
That
interrupts,
are
you
my
good
one?
Other
thing
that
might
be
really
valuable
if
this
becomes
a
common
thing
for
us
to
do
is
to
create
a
list
somewhere
where
we
can
start
collecting
those
examples,
because
a
lot
of
times
you
know
like
well
I,
think
you're
pointing
out
people
will
reopen
the
same
issue
and
you
know-
and
it
sometimes
is
even
across
multiple
repos,
because
they,
you
know
it
kind
of
touches
on
a
few
different
things.
C
If
there
was
some
sort
of
you
know,
list
or
cookbook
kind
of
thing
that
we
could
easily
reference,
especially
you
know,
and
just
I
think
are
a
perfect
format
for
that,
especially
if
we
can
the
end
goal,
which
would
be
amazing,
I.
Think
we're
a
little
far
from
this,
though,
would
be
look
for
keywords
in
their
issue.
Report
have
tags
on
the
the
gist.
Somehow
that
then
automatically
will
respond
and
say
hey.
You
know,
it's
looks
like
you're
having
issues
with
you
know.
B
B
C
C
The
comments
so
so
you
know
it's
not
going
to
be
any
extra
burden.
You
know,
obviously,
as
this
expands
hopefully
there's
more
activity,
and
so
it
will
be
harder
and
harder
to
follow
everything,
but
I
definitely
think
when
you're,
you
know
best
judgement
is
like.
Maybe
somebody
else
should
you
know,
take
a
look
at
this
at
mentioning.
The
maintainer
is
perfectly
acceptable
and
and
good
practice.
So.
E
E
So
when
we
talk
about
package
maintenance-
and
we
say
on
you
know,
we're
addressing
licensing
versioning
support,
but
this
is
a
real,
tangible
thing,
and
these
are
the
things
we
need
to
be
done
on
there,
because
I
was
a
starting
to
write
that
today,
but
I
wanted.
It
obviously
do
this
call
and
have
discussions
with
people
before
we
did
it.
But
really,
as
you
said,
reproduction
seems
to
be
the
reproducing
error.
Cases
seems
to
be
like
one
of
the
top
asks
you
know.
C
So
so
are
you
thinking
that
we
can
so
there
was
a
few
topics
there.
I
just
want
to
make
sure
I
understand
what
you're,
what
you're
asking.
So
we
have
the
stuff
we're
going
to
be
planning
for
the
community
corner,
but
I
think
also,
you
know,
that's
a
that's
just
the
sort
of
here
and
now
that
will
be
during
that
event.
I
think
there's
also
the
other
part
of
it,
which
is
having
a
concrete
list
of
actually
actionable
things
that
people
can
start
working
on.
C
Am
I
right
to
separate
that
into
sort
of
to
two
topics?
Yes,
okay,
okay,
so
I!
My
hope
is
that
the
point
of
the
status
board
was
to
be
the
place
where
we
send
people
for
those
actionable
things.
So
my
goal
would
be
that
you
can
look
at
sort
of,
maybe
and
if
I'm
looking
at
it
now
it
might
not
serve
all
the
purpose.
C
I
think
we
need
to
make
some
improvements,
but
you
know
maybe
we
can
have
a
page
that
includes
some
of
the
information
that
Koresh
has
recently
written
about
how
to
be
a
triage,
ER
and
then
actually
on
that
page.
Also,
some
of
the
issues
that
they
should
get
started
looking
at,
because
if
you
look
here,
Help
Wanted,
the
the
issues
the
the
tags
listed
in
the
PR
here,
discuss,
help
on
it
will
need
to
add
needs
triage
one,
but
the
idea
we
could
have
a
list.
C
A
Having
that
discussion
that
says,
we've
looked
through
and
like
here's,
the
next
two
that
looked
like
they
need
the
most
help
would
be
good
and
then
you
know
because
people
could
say
watch
this
recording
or
you
know,
I
I
come
from
the
perspective
that
sometimes
it's
great
to
do
it
off.
You
know
through
github,
but
sometimes
the
personal
touch
of
like
hey
we've
talked
about
this
and
we've.
You
know
this
is
the
one
we
think
is
a
great
place
to
jump
in
will
help
people
feel
more
comfortable
to
do
that.
C
Absolutely
so
we
talked
a
little
bit
about
this
on
the
previous
call
and
I
think
you
know,
Doug
and-
and
my
sentiments
were
very
in
line
the
ones
that
that
the
team
had
already
identified
were
great
ones
to
get
started
in
I.
Think
the
actual
express
repo
is
probably
the
next,
the
next
one
that
one
probably
gets
the
largest
single
volume
of
support,
requests
and-
and
maybe
not
just
for
us,
but
you
know
people
who
don't
know
where
else
to
post
their
issue.
C
A
C
A
C
That
I
think
that
would
be
the
best
place
to
start
for
people
who,
unless
you
have
a
specific
interest
in
a
certain
niche.
That
is
another
repo
right.
So,
if
you
routing
is
your
thing
go
to
the
router
repo,
we
have
a
bunch
of
things
that
need
looking
at
if
low-level
HTTP,
you
know
spec
compliance.
Is
your
thing
go
to
JSP,
but
if
you
are
unsure
what
you
want,
definitely
start
with
the
Express
repo.
C
Then
from
there
there's
two
real
good
ways
to
find
the
right
issues.
The
one
would
be
just
search
for
these
tags
that
we
mentioned
in
the
triage
document
in
the
issues
and
PRS.
So
you
know
just
filter
down
to
needs
more
info
or
waiting
more
info
filter
down
to
discussion,
filtered
down
to
bug,
and
then
we
have
to
add
the
needs
triage
by
default
or
something
where
I
think
there's
a
way
to
do
it
by
default.
We'll
figure
that
out
so
that
all
new
issues
get
in
needs,
triage.
B
Any
thoughts
on
that
so,
as
I
said,
one
of
the
one
of
the
discussion
we
had
in
the
previous
meeting
is
to
have
a
public
ripple,
but
I
believe
that
makes
sense
once
the
triage
work
is
fully
bootstrapped,
meaning
everybody
according
to
the
corresponding
the
pose
and
they
started
working
and
they
want
to
sync
up.
But
before
that,
do
you
think
some
sort
of
an
engagement
model
makes
sense
to
sync
up
until
we
are
fully
bootstrapped
into
the
world?
I.
C
Think
that
the
easiest
thing
to
just
get
started
with
is
issues
in
the
discussions.
Repo,
those
are
fairly
low
and
not
a
lot
of
people
are
watching
the
repo,
so
it'll
be
pretty
limited
in
scope
to
the
people
who
who
care
to
to
really
follow
the
inner
workings
of
the
project
and
then
I
think
we
could.
You
know,
expand
from
there
as
we.
If
we
see
that
there's
need
I,
don't
know
if
everybody
else
likes
that
approach.
B
C
I
think
I
didn't
have
a
clear
plan
on
that.
I
think
it's
alright.
If
we
I,
if
we
make
a
new
repo,
I
I,
fear.
Well,
okay,
here's
the
thing
I
want
to
make
it
clear
that
there
is
the
goal:
is
a
path
from
I?
Don't
know
anything
about
the
project,
but
I
want
to
help
out
to
being
a
member
of
the
TC,
and
if
everything
is
happening
in
one
repo,
there's
a
lot
clearer
path
there,
because
it's
we're
all
again
we're
just
part
of
one
team
trying
to
improve
the
project.
C
So
I
think
the
discussions
repo
has
been
that
in
the
past
I.
Don't
see
strong
reason
to
change
that.
That
said,
I
do
think
it
would
be
helpful
for
us
to
have
maybe
issue
types
or
again
tags
that
help
us
filter
to
the
different
conversations
we
care
about.
So
maybe
having
a
triage
tag
in
the
discuss.
Repo
would
would
solve
that.
C
B
Yeah,
the
pros
and
cons
which
I
see
is
like
the
the
advantage
is
that
you
don't
need
that
another
hope
and
everything
in
one
single
place.
The
disadvantage
is
from
the
tribes
perspective,
who
who
wants
to
scope
themselves
in
the
roles
of
triages,
who
are
not
interested
in
other
part
of
the
project?
For
example,
I
just
want
to
limit
my
conversation
only
on
the
badging
topics,
but
if
you
start
watching
the
discussion,
rapport
I
get
everything.
A
lot
of
them
are
noises
as
well.
C
C
We
could
just
tag
at
triage
errs
because
that's
the
whole
way
that
we're
structuring
the
actual
functioning
of
this
is
when
you
submit
yourself
as
the
triage
ER
you'll
get
added
as
a
triage
member
of
the
team
on
all
the
different
orgs,
and
so
all
we
need
to
do
is
use
the
tag
there
in
the
conversations
that
that
apply,
and
then
you
don't
have
to
follow
the
whole
repo
you
just
get.
You
know.
B
C
H
C
Yeah
I
think
we
need
a
new
section
in
here
before
we
merge
this,
that
talks
about
opening
the
PR
to
add
yourself
to
the
list
and
what
and
then
what
we
do
when
when
that
happens,
rush
I
know
you
open
the
PR
for
yourself
and
we
were
gonna
link
to
that
in
the
example.
But
could
we
maybe
add
that
to
a
link
and
then
a
description
of
what
to
do
to
that,
the
other
the
documentation
PR.
H
C
B
A
C
C
Why
we're
trying
to
do
it,
and
you
know
the
guidelines
like
crushed,
laid
out
for
in
the
PR,
but
also
in
this
meeting
and
then
help
people,
you
know,
filled
their
questions
but
also
help
people
open
their
PRS
to
join
the
triage
team,
and
then
the
goal
would
be
that
you
know
we're
there.
We're
live,
merging
them
and
adding
them
to
the
groups
so
there,
as
far
as
presentation
goes,
I
I
don't
think
there's
much
to
prepare.
C
C
So
I
don't
know
it
would
be
kind
of
nice
of
who's.
After
my
talking
but
I,
don't
it's
not
dependent,
so
my
talk
is
going
to
cover
a
bunch
of
other
things.
I
was
going
to
very
quickly
mention
the
triage
thing
and
then
obviously,
hopefully,
if
it
was
after
my
talk
that
I
could
say,
please
come
to
the
community
corner
but
I,
don't
know
what
the
schedule
looks
like.
So,
oh.
B
C
H
C
The
way
I
think
about
this
and
the
way
I
was
thinking
of
phrasing.
It
is
something
like
Xbox
is
one
of
the
most
highly
impactful
projects
in
the
node
ecosystem.
Any
contribution
you
might
do
be
that
you
know
helping
other
users
or
providing
examples
or
actually
committing
code
to
the
project
will
affect
millions
of
users.
You.
C
B
C
Definitely
and
then
from
the
project
side
I
wanted
to-
and
this
is
where
Mike
a
lot
of
this
stuff
will
be
covered.
In
my
talk,
we
are
very
impactful
as
a
project,
yet
it
is
maintained
effectively
by
one
single
person
in
most
cases
and
so
I.
Think
from
the
project's
perspective,
I
want
to
make
it
clear
that
you
know
Doug
myself
and
then
you
know
I.
The
other
members
haven't
been
as
involved
in
this
process,
but
I
think
you
know
they're
all
on
board.
C
Is
we
really
want
to
make
sure
that
there
is
a
healthy
ecosystem
of
people
willing
to
step
up
when
when
they
can
help,
and
so
fostering?
That
means
we
need
people
to
have
a
good
on-ramp.
So
this
is
the
first
step
of
that
on-ramp
is
you
know
just
watching
the
issues
triaging
the
issues,
understanding
what
the
community's
questions
are
and
and
bugs
that
think,
are
you
know
and
and
how
that
is
and
again
like
I
said
this
is
actually
part
of
my
talk
is
that's
how
I
started
you
know
and
and
then
now
I'm.
C
You
know
actively
working
on
maintaining
the
project.
There
is
a
story
for
people
who
want
to
have
that
kind
of
involvement
and
impact
to
go
from.
You
know
this
new
program
of
triaging.
You
know,
to
being
you
know,
a
key
figure
in
the
community,
so
that's
sort
of
where
I
want
to
position
the
project
side
of
it
you
know,
is
like
we
we've
got
too
few
people
maintaining
too
many
modules
that
have
too
much
importance.
C
E
Worth
we're
such
I
think
we
should
start
off
tree
robbing
doom
and
gloom
cents,
a
positive
thing
at
the
beginning,
like
package
maintenance
committee.
This
is
why
we
exist
for
addressing
you
know
like
things
like
you
know,
deprecation
ghost
in
license
and
just
giving
two
or
three
minutes-
and
this
is
our
first
use
case
and
and
rather
than
say
it's
the
right
I'd
be
careful
this
because,
rather
than
say
it's
the
big
ones
of
the
biggest
things
used
in
the
node
ecosystems,
I
would
actually
say
it's.
E
Rather
it's
one
of
the
the
biggest
modules
modules
in
the
ecosystem,
because
our
front
end
herbs
are
very
delicate,
snowflakes
and
and
because,
if
you
look
at
the
open,
jurors
foundation,
all
of
those
those
things
that
yeah
this
is.
This
is
more
like
our
type
of
thing
expressed,
but
there's
a
whole
bunch
of
people
out
there
that
we
want
to
bring
in,
and
it's
like
that,
it's
the
more
to
assistance
when
it
comes
down
to
it's.
Just
it's
just
some
variants
of
JavaScript
yeah.
C
Also
covered
in
my
talk.
A
little
bit
is
one
of
the
the
things
that
I
don't
think
people
understand
is
the
Express
project.
Has
this
huge
umbrella?
And
if
you
take
any
individual
piece,
you
will
actually
find
that
it
is
used
in
a
whole
bunch
of
different
other
ecosystems,
so
so
making
those
connections
for
people
is
I
think
really
important
because
they
may
be.
You
know
a
front-end
dev,
but
if
they
use
react,
router
they're
using
pests,
regex,
that's
an
express
module
right.
So,
like
there's
these
connections
that
people
are
missing.
C
So
that's
actually
like
a
key
feature
of
the
talk
that
I'll
be
giving
is
how
some
of
the
stuff
connects
and
how
you
know.
Even
if
this
is
not
quite
your,
you
know,
you're,
not
writing
known
servers.
You
might
still
be
touching
the
Express
ecosystem
and
you
know
you
should
we
would
love
to
have
you
participate.
You
know,
in
whatever
makes
you
know,
involves
your
your
work
and
your
passions
so
I
think
a
lot
of
that
will
be
covered
there
and
I
don't
want
to
hache
too
much
like
I
want
to
share.
C
It
depends
on
the
scheduling
kind
of.
If
the
talk
is
first,
then,
hopefully,
a
lot
of
those
people
will
be
able
to
just
you
know
have
that
baseline
understanding
of
why
they
might
want
to
be
involved.
I
guess.
If
the
talk
is
second,
then
it
might
change
the
way
I
say
might
be
more
of
a
sales
pitch
for
the
talk.
It's
actually.
E
An
open
question
to
either
how,
because
last
time
when
I've
seen
notes,
they
basically
talks
in
the
coffee
area,
they
stood
up
and
said,
win
an
overeater
technical
steering
committee.
Will
that
actually
be
a
room?
That's
the
thing,
and
we
need
to
get
that
answered
to
know
quite
what
the
presentation
or
community
corner
would
be.
E
B
E
E
B
E
Asked
I
just
posted
something
in
the
chat
with
a
link
to
Michael's
and
with
this
exact
question
they're
asking
us:
how
long
do
we
want
and
I've
posted
a
question
saying
what
is
the
format
if
it's
just
like
in
a
coffee
area?
It's
gonna
be
like
50
and
that's
just
from
what
my
previous
of
observations
I,
don't
know
so
yeah.
That
needs
to
be
answered
before
I
think
we
can
answer
that
the
question:
what
are
we
going
to
do
well.
C
Well,
I
think
that
the
the
triage
er
section
of
the
community
corner
I
think
he
is
perfectly
suited
or
a
coffee
thing
I
mean
that
there's
not
going
to
be
all
my
group
on
that
side.
On
the
package:
maintenance
working
group
I,
you
know
that's
sort
of
your
what
you,
what
you
think
is
yeah
separate,
I
guess
from
from
this
conversation,
but.
E
E
C
C
It's
the
Express
is
one
of
our
pilot
families
for
the
package,
maidens
workgroup,
so
I'm,
not
trying
to
say
that
they're
separate
I,
just
mean
I
have
a
very
specific
I
would
like
the
triage
or
part
to
be
very
specifically,
here's
exactly
what
the
triage
role
is,
what
we
hope
to
get
out
of
it
and
then
have
people
open
up
their
laptops
and
submit
PRS
to
become
triage
nurse,
which
is
a
little
bit
different
than
you
know.
Let's
just
discuss
all
of
these
other
things
that
we
have
in
in
motion
in
the
package.
C
Maintenance
working
group
right,
so
I
actually
don't
see
a
problem
with
them
going
on
together
at
the
same
time
and
people
moving
back
and
forth
between
them
because
again,
I
might
be
like
I'm.
You
know
myself
aggression
and
whoever
else
wants
to
help
are
helping
people
open
their
PRS,
and
then
those
people
go
over
and
start
talking
about
package
maintenance
things.
It's
like
I
think
perfectly
fine,
I.
C
E
A
And
I
do
have
like
twelve
twenty
on
the
first
day
is
my
talk
where
I'm
talking
about
the
work
of
the
the
group
so
depending
on
when
we
find
out
when
those
community
corner
ones
on
I'll,
try
and
point
to
those
two
as
well
and
not
talk,
yeah
awesome,
like
certainly
I,
was
gonna
mention.
You
know
your
talk,
which
is
the
next
day,
which
is
good,
so
I
was
gonna,
say
hey.
B
C
A
C
That's
a
good
point:
I'll
open
that
issue
like
today
or
this
weekend
and
make
sure
that
we
get
a
time
nailed
down.
I,
don't
think
it's
again,
I,
don't
think
it
should
be
too
hard
to
to
schedule
now
that
we've
gone
through
this
effort
to
see
what
time
zones
everybody's
in
for
this
one
so
I'll
yeah
I'll
make
sure
that
that
happens
before
next.