►
Description
Originally recorded during the Berlin Developers Meetings from July 9-13, 2018.
A
So
we
were
sort
of
focused
on
looking
at
some
of
the
maintainer
ship
issues
of
the
like
perpetually
growing
number
of
modules
and
the
growing
community
and
small
number
of
people
who
are
maintainer
and
trying
to
ease
some
of
that
burden.
We're
focused
more
particularly
on
the
JavaScript
side
of
things
down
on
the
NGO
side
of
things
partially,
because
this
comes
out
of
an
issue
that
was
posted
focused
on
the
JavaScript
side,
partially
also
because
nobody
was
that
focused
on
ghosts
that
showed
up.
A
So
that's
the
big
caveat
for
all
of
this
and
there's
I
think
it's
is
it
ipfs
notes?
273,
that's
the
that's
the
issue
that
this
comes
off
of
and
these
super
rough
notes
are
posted
back
there
and
it's
my
job
later
today
to
post
a
much
more
nicely
written
version,
but
so
here's
sort
of
our
new
work
plan
and
list
of
things
that
we
thought
was
important
to
do
and
who
needs
to
do
them
that
we
came
up
with
some
are
fairly
vague
and
some
are
very
specific.
A
So
one
thing
that
we
think
is
really
important
right
off
the
bat
is
that
what's
already
happening
in
jail
and
which
is
that
every
module
needs
to
have
a
clear,
maintainer
or
owner
in
one
of
the
first
things
that
maintainer
owner
needs
to
do
is
pick
a
reasonable
level
of
code
coverage,
which
is
less
than
a
hundred
percent.
But
it
does
need
to
be
something
that
they
think
is
a
reasonable
level
to
make
sure
to
maintain
and
make
sure
to
use
the
coverage
tools
that
now
all
modules
are
running
in
CI.
A
The
next
thing
that
kind
of
needs
to
happen
is
that
we
need
to
start
doing
automated
releases
for
a
lot
of
modules.
We
have
serious
issues
about
our
capability
to
do
that,
for
some
of
the
bigger
ones
like
JSI
PFS
as
a
whole,
so
we're
going
to
start
doing
it
ASAP
with
the
smaller
ones
like
jeaious,
repo
or
ones
like
that
or
like
multi,
address
or
and
then
sort
of
scale
it
up
from
there.
A
And
the
next
thing
is
that
Michael
is
going
to
start
working
on
are
actually
already
working
on
trying
to
document
a
project
lifecycle,
because
we
think
there
are
a
large
number
of
practices
that
are
really
important
to
ease,
maintain
ership
as
projects
mature
that
are
anti
helpful
when
projects
are
really
young
and
so
that
lifecycle,
the
part
of
its
goal,
is
to
sort
of
define
that
and
define
how
we
make
those
transitions,
and
part
of
that
is
so
kind
of
defining.
What
are
those
requirements
at
a
given
point
in
a
projects
maturity
level?
A
Another
part
of
that
is
making
sure
projects
live
in
the
right
place.
We
have
a
huge
number
of
repos
that
sit
in
ipfs
org
or
the
shipyard
org.
That
kind
of
just
sit
empty
or
are
maybe
deprecated
or
dead
and
an
important
practice.
We
can
do
to
ease
burdens
is
make
sure
that
those
don't
live
in
those
sort
of
more
official
places
until
something
like
jeaious
ipfs
or
go
at
pathos
or
whatever
it
is
actively
depending
on
them
in
part
of
the
pull
request.
A
To
add
that
dependency
is
the
movement
of
that
experimental
repo
from
your
personal
place
or
whatever
into
the
ipfs
org
or
into
the
shipyard
org.
There
are
some
exceptions
like
when
we're
extracting
say:
go
IP
NS
out
of
go
where
it's
fairly
solid
straight
from
the
get-go,
but
for
most
other
things
we
need
to
be
clear
about
not
putting
it
in
a
very
official
place
straight
off
the
bat,
because
that
creates
burdens
that
we
should
shouldn't
be
enduring.
A
A
On
the
JavaScript
side,
we
can
test
to
ensure
that
there's
comments
for
everything
that
is
exported,
not
necessarily
that
we're
going
to
generate
those
Docs,
but
ensuring
that
somebody
is
writing
them
in
thinking
about
them
from
day
one,
because,
having
that
clear
documentation
for
something
really
immature
can
create
an
impression
that
it's
more
solid
than
it
is.
But
we
need
somebody
to
writing
and
thinking
about
those
docs
to
that
when
it
flips
over
to
a
more
mature
state.
A
It's
not
like
there's
this
giant
pile
of
work
that
is
undone
and
then
gets
poorly
done,
and
then
there's
some
other
things
that
are
very
Jaya
specific
sort
of.
We
need
to
have
a
unified
story
around
how
we
deal
with
a
sink
type
stuff.
So
that's
single,
call-and-response
stuff,
like
call
backs
versus
promises
versus
async/await
and
also
longer
things
like
stream
sources,
pool
streams
versus
async
generators.
A
Part
of
the
issue
is
not
that
we
support
all
of
those
things
and
it's
important
to
continue
supporting
all
those
things
at
the
top
level
like
in
the
JSI
PFS
api,
but
for
all
the
sub
modules
and
subpages.
We
should
pick
one
and
not
worry
about
those
ones,
exposing
an
interface,
that's
cross-compatible
everywhere.
A
We
just
need
to
ease
the
burden,
and
this
is
the
way
everything
works
internally
and
even
externally
for
those
sub
packages
that
aren't
the
main
public
package
and
there's
a
few
more
of
these
things
more
using
github
checks
and
more
buffs
for
things
using
branch
protection
everywhere,
always
on
all
repos.
In
looking
at
on
the
oh
and
the
other,
really
big
thing
is
we
have
these
two
contributor
guides
in
community,
one
of
which
is
long
and
the
other
of
which
is
unbelievably
long
names
contributors
too,
which
is
very
confusing
to
lots
of
people.
A
We
need
to
rename
that
to
maintainer
or
committers
or
more
involved.
You
know
sort
of
team
members
and
for
the
first
one,
which
is
still
long.
We
need
it
needs
the
TLDR
section
at
the
top.
That
just
says:
do
this?
Do
this
do
this
and
then
all
the?
Why
explanation
that
it's
got
blue.
That
few
other
things
look
at
the
issue
for
all
the
more
details,
but
those
are
the
critical
things
we
thought
were
important
to
do,
to
increase
maintainability.