►
From YouTube: Package Weekly Sync - 2021-09-13
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
Hello,
everybody
and
welcome
this
is
our
weekly
scene
for
the
package
team.
Thank
you,
everybody
for
joining
and
we
have
a
long
agenda
team.
Do
you
want
to
start.
B
Yeah
just
a
suggestion
for
an
idea
with
some
new
people,
starting,
I
was
going
through
the
backlog
and
noticed
that
we
have
a
lot
of
issues
in
there.
There
was
like
over
a
thousand
in
in
the
project,
a
lot
of
duplicates
and
some
things
that
maybe
won't
get
done
for
a
long
time.
So
I
tried
to
move
things
to
the
icebox
or
awaiting
further
demand.
I
think
there's
some
more
cleanup
that
can
be
done.
B
I
didn't
there's
a
lot
of
technical
debt
or
backstage
issues
that
I'm
not
sure
if
they're
still
relevant
or
not.
So
the
ask
is,
if
you
could
go
through
any
lists
that
any
issues
that
you
opened
and
kind
of
just
do
a
quick.
B
Is
this
going
to
get
done
in
the
next
six
to
nine
months
and
then
put
it
into
weight
awaiting
further
demand,
and
we
can
always
revisit
it.
It's
good
to
have
them
in
the
still
around.
I
don't
want
to
close
them,
but
it
would
also
be
nice
if
we
could
have
a
trimmer
backlog.
So
we
have
more
clear
direction
on
what
we're
doing.
B
Talked
through
it,
I
kind
of
just
did
this
thing
of
like
a
priority,
one,
two,
three
or
z,
so
like
a
a
one,
is
something
oh,
we
should
get
to
this
in
the
next
milestone
or
two
two
is
like
the
next
three
to
six
three,
probably
six
months
to
a
year
and
a
z
is
like.
I
don't
even
know
where
we're
gonna
get
to
this,
so
I
think
those
can
go
into
awaiting
further
demand
pretty
safely.
B
D
E
Yeah,
so
I
was
thinking
about
because
sometimes
I
struggle
to
understand
how
future
works
or
is
implemented
on
the
real
side
without
jumping
to
the
source
code
or
following
multiple
issues
and
mrs
to
see
how
it
was
created.
E
So
I
wonder
if
we
should
have,
or
already
have
some
kind
of
technical
document
for
each
one
of
our
futures,
like
cleanup
policies,
dependency
proxy
to
detail
how
it
works
internally,
like
which
classes
are
being
used
which
cues
on
the
sidekick
side
the
database
as
well,
and
keep
that
document
up
to
date
whenever
a
change
is
made
to
to
the
to
the
future.
Because
one
of
the
one
of
the
examples
that
I
gave
here
is
the
cleanup
policies
where
the
kid
has
done.
E
A
great
job
with
the
architecture
of
the
feature
and
improvements
and
also
wrote
excellent
documentation
across
multiple
issues.
And
mrs
and
I
think
it
would
be
useful
to
have
all
of
all
that
information
in
a
single
document
in
a
single
place,
so
that
it
is
easier
for
others
when
they
have
to
review
nmrs
or
just
deal
with
debug
an
issue
or
or
just
try
to
understand
how
it
works.
E
But
also
for
us
as
engineers,
because
we
don't
have
to
repeat
ourselves
when
giving
context
and
background
to
others,
we
can
just
direct
people
to
a
document
or
a
section
of
that
document,
instead
of
repeating
ourselves
in
multiple
issues
and
mrs
because
it
becomes
repetitive
and
at
the
same
time
that
dialogue
will
change
over
time
as
the
future
changes
as
well.
So
I
think
this
could
be
a
good
idea,
and
probably
if
it
worked
for
us,
maybe
it
could
even
be
a
good
idea
for
others
as
well.
E
Yeah
architectural
prints
are
more
like
an
architecture
decision
record
which
is
used
in
many
companies,
not
at
least
but
it's
it's
our
version
of
that
and
that's
mainly
used
when
you
want
to
do
a
big
change
or
or
ship
a
really
big
thing,
and
you
need
to
justify
why
you
are
doing
it.
What
are
the
problems
and
the
cons
basically
make
a
make
a
case
for
what
you
want
to
to
achieve
and
implement,
and
in
this
case
it's
not
necessarily
about
that.
F
Okay,
I
think
that
this
discussion
should
happen
on
an
issue,
so
that
is
tracked
and
public.
So
perhaps
it's
a
good
idea
to
open
an
initial
tracker
of
the
team
and,
lastly,.
D
E
C
Yeah
I
was
going
to
mention
that
we
we
do
have
that
documentation
of
kind
of
like
how
we
attempt
to
implement
package
managers.
So
maybe
that's
a
good
place
to
start
branching
off
to
add
more
docs,
but
also
I
have
seen
other
teams
use
the
handbook
for
explaining
some
aspects
of
how
things
work.
So
I
don't
know
if
one
would
be
better
than
the
other.
C
I'd
probably
prefer
the
rails
docks,
because
it's
all
in
the
same
project
and
then
I
also
noticed
that
we
do
have
some
modules
that
have
inline
documentation
commented
in
the
code
and
I'm
not
sure.
If
that's
something
we
should
consider
for
different
areas
of
our
code
as
well
or
when
that
might
be
warranted.
E
A
Yeah,
I
think
sorry,
I'm
sorry.
I
was
going
to
jump
sorry.
So
I
think
the
important
here
is
when
you
kick
off
the
the
issue.
Let's,
let's
be
sure
that
we
are
clarifying.
A
G
G
So
the
more
we
can
rely
on
documentation
on
the
code
they
even
structured
with
jsdoc
the
better
off.
We
are
because
the
chances
that
somebody
coming
in
and
updating
something
and
then
reading
first
of
all
and
maintaining
that
kind
of
documentation
of
higher
and
it's
easier
for
a
viewer
to
actually
catch
it
and
say
you
know,
look
we
updated
this
function.
We
need
to
update
the
dock,
and
if
we
use
a
parsable
format,
we
can
also
generate
good
documentation
out
of
it.
A
D
Yeah,
I
would,
I
would
worry
about
this
document
drifting
away
from
the
implementation.
Over
time
I
mean
comments
that
are
right.
Next
to
the
code,
you
change
will
drift
away
so
having
a
document,
that's
in
another
project
and
like
completely
out
of
the
screen
when
you're
working,
I
think,
would
be
even
more
susceptible
to
this
sort
of
drift,
and
I'm
also
worried
that
someone
who
is
going
to
take
a
naive
approach
to
understanding
this
is
going
to
go
to
the
code
and
then
how
will
they
find
this
documentation
from
the
code?
D
A
I
I
would
like
just
to
close
the
like,
when
not
close
it,
but
just
clarify.
Definitely
we
need
to
clarify.
Why
do
I
want
to
have
documentation?
I
do.
I
think
I
got
the
point
from
their
own.
Why
do
we
want
to
do
it,
but
there
is
also
the
like
documentation
never
keeps
updated
if
we
do
it
in
in
the
different
in
the
not
right
approach.
F
Okay,
so
the
recordings
of
the
postgres
training
are
available.
C
As
you
can
see,
I
do
believe,
there's
an
expiration
to
how
long
they'll
be
available,
which
I
think
is
two
weeks,
but
they
will
go
away
at
some
point.
A
G
A
G
Why
do
they
expire
sorry
because
of
the
sensitivity
of
it?
It
was
just
part.
C
Of
the
contract,
when
we
set
up
with
this
consultancy,
that
was
their
terms.