►
From YouTube: K8s SIG Docs Meeting for 20210302
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
folks,
I'm
tim
bannister.
This
is
the
sig
docs
weekly
meeting.
It
is
the
2nd
of
march
2021
and
of
course,
in
this
meeting
we
are
gonna
treat
each
other
as
good
people
and
follow
the
cloud
native
computing
foundation
code
of
conduct
so
where
the
sig
docs
channel
in
the
kubernetes
slack
has
details
of
the
meeting,
including
the
agenda
so
moseon
over
there.
If
you
haven't,
got
it
or
put
a
message
in
the
chat
if
you'd
like
some
help,
otherwise
I'm
going
to
crack
on
with
the
agenda
first
up.
A
If
you
are
new
and
want
to
say
hello,
you
can
either
do
that
in
the
chat
or
just
unmute
and
start
start
talking,
hey
jim.
A
Where's
the
thing
I
want
to
leave:
okay
next
thing,
updates
and
reminders.
This
week's
pr
wrangler
is
kb
hockey,
and
next
week's
pr
wrangler
is
only
dole
who
I
think
that
works
well.
I
happen
to
know
that
works
well
for
taylor
yep.
If
you're
approver
make
sure
you
know
your
scheduled
pr
angler
shifts.
A
Approvers
and
reviewers
are
the
people
who
look
after
pull
requests
against
the
documentation
and
try
to
make
sure
that
they
get
feedback
so
that
we
can
move
them
forward
to
get
them
merged
cool.
B
Yeah,
so
still
current
status
is
yellow
and
I'll
talk
about
that.
A
little
bit
last
week's
branch
sync
was
done
in
merge
and
pr26741
integration
branch
is
still
healthy.
We
do
have
a
milestone
coming
up
of
code
freezes
coming
up
next
week
for
on
march
9th
and
after
code
freeze
is
when
the
docs
team
will
start
to
communicate
with
the
with
the
enhancement
owners.
B
The
reason
why
we're
doing
that
is
because
the
enhancement
team
is
doing
a
lot
of
the
communications
or
all
the
communications
right
now
there
are
some
enhancement
owners
that
we
will
communicate
this
week
that
the
enhancements
teams
pointed
out
that
they've
done
that
they
are
done
pinging,
so
we'll
start
paying
those
enhancement
orders.
We
had
a
few
more
doc
prs
created
securely
tracking
27
docs
out
of
65
enhancements
of
those
those
stats,
four
have
been
merged,
three
are
in
review,
sixth
draft
and
there's.
B
The
reason
why
it's
yellow
is
that
there
are
a
lot
of
unknowns
yet
and
that's
because
we
haven't
started
picking
those
enhancement
owners.
There's
35,
unknown
enhancements,
35
enhancements
that
we
don't
know
if
they
need
doc
prs
for
1.21.
A
Okay,
cool,
it
doesn't
sound
like
you,
have
any
questions
or
things
that
you
need
sig
docs
to
rally
around
help
right
now.
Is
that
correct
right.
B
There's
one
and
just
it
was
a
new
pr
just
came
in.
I
was
with
the
cube
adm,
it's
not
tied
to
any
specific
enhancement
and
it's
it
was.
The
pr
was
made
against
the
121
branch,
and
so
just
just
out
of
curiosity
just
said
because
of
I
know
qbdm
is
out
of
tree,
but
there's
they
want
to
add
some
documentation
that
will
go
into
1.21.
B
So
I'll,
probably
so,
don't
have
that
listed
on
here,
but
I'll
put
it
in
the
channel.
I
get
the
chance.
A
So
one
thing
I
will
say
is
that
sig
docs
delegates
a
lot
of
the
the
technical
review
and
workflow
around
sig
cluster
life
cycle,
documentation
to
that
sig.
A
They
do
a
great
job
of
reviewing
changes
and
proposing
changes
and
keeping
on
top
of
that
stuff
which
we're
really
happy
with.
So
I'm
happy
for
them
to
take
a
lead.
Okay,
that
sounds.
C
A
Our
role
there
is
mostly
in
terms
of
hour
six
review
process
to
to
rub
a
stamp
and
approve
stuff
which
has
already
gone
through,
editing
and
review
and
so
on,
and
we
really
have
have
reason
to
sort
of
push
back.
Okay,.
B
All
right,
I
will
ping
sick
cluster
life
cycle,
one
more
pr.
I
brought
up
last
week
and
I
sorry
I
didn't
have
this
on
the
agenda
and
last
week
we,
it
was
a
the
pod
security
policy,
pull
request
against
the
the
master
branch
to
the
on
the
api
deprecation
website
or
to
that
page
and
talk
brought
up
to
with
the
release
team
and
they,
the
consensus,
was
to
have
a
target.
The
1.21
branch
instead
of
the
master
branch.
But
I'll
put
these
in
the
notes.
A
Okay,
thanks
very
much.
To
be
honest,
it
still
sounds
like
you've
got
all
that
under
control
right.
It's
brilliant
thanks.
D
I
I
just
want
to
add
one
thing,
so
many
pr's,
that's
that's
related
to
1.21,
is
raised
against
the
main
branch.
So
I'm
just
commenting
whichever
I
see
so
I
just
want
to
let
the
folks
know
keep
an
eye
out.
Some
of
them
are
lgtms,
but
they
have
to
go
on
the
1.21
release,
but
they
are
raised
against.
They
are
the
main
branch.
So
it's
nothing
big,
I'm
just
telling
that
this
happens
every
cycle,
so
just
keep
an
eye
out
for
that.
One.
A
A
Okay,
so
yeah
that's
cool.
We
don't
need
to
talk
about
them
again.
Let's
move
on
to
talk
about
third
party
on
dual
source
content.
Now,
there's
no
named
on
this.
So
if
it
was
your
item,
I'm
handing
over
to
you.
C
So
I
believe
I
added
that
from
the
quarterly
review
it
was
brought
up
that
just
some
some
general
kind
of
checkpoint
here
so
today
I
didn't
have
much
time
to
really
get
a
good
status
point,
but
I
want
to
start
tracking
it
in
our
weekly
meetings.
As
far
as
any
third
party,
dual
source
content,
pr
to
discuss
locations
comments,
concerns
things
of
that
nature,
so
more
of
a
placeholder
today,
but
in
the
future
I
plan
on
having
more
conversation
focused
around
that
as
well.
A
Oh
yeah
yeah,
jim
you're,
currently
called
sigdocs
and
also
you've
claimed
the
host.
So
I
can't
rename
you
let
me
fix
that,
but
yeah.
So
what
jim
is
talking
about?
There
is
a
long-standing
piece
of
work
that
we
need
to
do
to
follow.
Cloud-Native
computing
foundation
policy
around
how
we
reference
third-party
content
third-party
details.
So,
for
example,
if
you've
got
a
vendor
like
azure
amazon
web
services,
google
there's
a
few
guidelines
about.
We
put
those
in
alphabetical
order
when
we
put
them
in
lists
and
essentially
the
challenges.
A
Those
guidelines
are,
we
don't
want
to
be
advertising
products
too
much
and
looking
like
we
are
endorsing
one
vendor
over
another.
We
don't
want
to
be
as
a
project
getting
involved
in
those
discussions,
but
at
the
same
time
we
do
want
to
be
sign
posting
people
to
useful
documentation
that
we're
not
maintaining,
there's
a
whole
bigger
piece
on
this
and
if
you're
interested
look
for
the
issue
about
third
party
content
in
our
issue
list
and
you'll
find
it
all.
A
A
Okay,
so
this
is
something
again
from
the
quarterly
review
and
previous
work.
We
have
a
really
fantastic
improvement
to
the
api
reference
brewing
from
philippe
martin.
The
generator
work
is
kind
of
done
it's
merged.
The
remaining
challenge
is
to
migrate
so
that
everything
that
links
to
the
existing
api
reference
links
to
the
new
api
reference.
Now
that
might
mean
changing
urls,
it
might
mean
coexistence.
A
A
Okay,
abigail
analytics.
F
Yes,
hello,
so
this
is
something
we
also
talked
about
in
the
quarterly
planning
meeting,
and
that
is
to
get
take
a
closer
look
at
our
analytics
dashboard,
because
we
we're
collecting
a
lot
of
this
information,
but
we're
not
actually
using
it.
So
part
of
that
is
to
see
if
there's
any
website
improvements
or
docs
improvements
we
can
make
based
off
of
the
analytics,
we're
seeing
and
then
also
finding
a
way
to
generate
reports
and
to
make
them
available
for
people
in
the
community.
F
I
know
the
localization
teams
have
asked
for
this,
so
getting
that
information
out
to
them
and
how
they
generate
the
reports,
and
then
the
frequency
people
want
to
see
it.
So
that's
sort
of
the
ask
here
is
what
the
community
would
like
to
see.
If
anyone
has
any
ideas
on
what
types
of
reports
they'd
like
to
see
and
how
frequently
we
should
be
sending
them
out.
So
if
anyone
has
any
ideas,
we'd
love
to
hear.
G
Yeah,
I
think
for
sorry,
so
I
think
for
for
the
localization
team,
we
can
kind
of
drop
the
message
and
then
take
a
few
people
that
actually
the
owners
of
the
respective
localization
group.
C
Basically,
what
what
are
the
most
important
pages
to
target
for
you
know.
Future
releases
future
work
things
of
that
nature,
and
so
this
has
been
on
my
plate
for
a
while
I'd
like
to
hopefully
make
some
progress
on
this.
This
quarter,
but
ultimately,
some
context
in
history
on
this
is
that
we
originally
sent
out
a
top.
C
I
think
it's
top
10
pdf
report
to
our
kubernetes
sig
docs
mailing
list
every
single
month
and
ultimately
that
was
owned
by
jared
one
of
the
chair
emeritus
and
when
jared
became
an
emeritus
or
mayor
ty
when
he
stepped
down
from
being
a
co-chair,
we
ultimately
stopped
that
report
from
getting
sent
out
because
the
general
feedback
was
it
was
noisy.
C
A
lot
of,
I
should
say
a
lot
of
folks.
There
were
a
few
folks
that
you
know
thought
that
the
the
information
was
coming
out
too
regularly
wasn't
really
worthwhile
and
you
know
throwing
a
pdf
into
everyone's
mailbox.
You
know
once
a
month
seemed
to
be
a
little
bit
unnecessary.
C
However,
with
the
recent
the
recent
comments
from
the
localization
groups
and
some
of
our
own
general
interests
and
analytics,
it
seems
like
there
is
value
in
providing
the
information
and
so
right
now.
I
think
the
general
rule
of
thumb
at
least
what
I've
heard
from
kohei
from
the
japanese
localization
team
mentioned,
potentially
sending
out
once
every
six
months,
because
this
data
shouldn't
change
at
the
rate
of
being
monthly,
potentially
just
a
six
month,
email
where
we
just
send
out.
C
You
know:
here's
the
english
localization
pdf
report,
here's
the
korean,
japanese,
all
the
various
different
languages
and
then
folks
can
set
up
filters
appropriately.
For
that,
unfortunately,
that's
that's
the
best
idea
that
I
have
I'm
open
to
other
better
ideas.
We
looked
into
originally
exposing
the
analytic
dashboard
through
some
sort
of
kind
of
unauthenticated
interface
and
that
doesn't
appear
to
exist
today,
because
that
would
be
another
model
or
another
option
is
if
we
made
it
publicly
available
wide
open
and
it's
kind
of
self-service
for
folks
who
want
to
get
that
data.
C
Unfortunately,
that
doesn't
seem
available,
at
least
without
heavy.
You
know
technical
debt
and
integration,
but
I
think
that
the
best
solution
right
now
would
be
to
not
only
send
out
a
report
every
six
months,
but
also
include
information
on
kubernetes
website
on
how
we
can
create
filters
to.
You
know,
limit
the
noise
for
folks
who
don't
want
to
and
make
it
an
opt-in
process
for
for
a
better
experience
and
sorry
that
was
a
long
rant.
But
but
that's
kind
of
where
my
thoughts
are
on
this
whole
thing
and
I'm
open
to
feedback.
F
I
think
that
that
thank
you
for
the
context
and
the
history
there.
I
think
that
that
makes
kind
of
a
lot
of
sense.
Like
you
said
it's
not
going
to
be
stuff.
That
would
change
months
a
month,
so
maybe
doing
a
six
month
would
be
really
helpful.
For
folks,
is
this
new
that
were
you
thinking
of
that
more
for,
like
just
a
localization
team
or
localization
teams,
or
is
that,
like
for
every
language,
be
sending
out
an
email
that
goes
out,
I'm
just
not
sure
how
they
would
be
grouped.
C
Yeah
definitely
so
originally,
it
was
focused
mainly
on
localizations.
Those
were
the
folks
that
were
actively
involved
with
saying
all
right.
What
is
the
popular
documentation
or
the
pages
that
I
need
to
translate,
but
I
do
think
that
that's
now
becoming
more
of
a
broader
scope
where
it's
applicable
to
you
know
the
english,
I
guess
the
english
localization
as
well.
So
originally
the
reports
were
going
to
get
sent
out
to
the
localization
team
email
address.
C
I
think
now
it
might
be
worthwhile
creating
some
sort
of
sig
docs
reporting
mailing
list-
that's
separate
from
the
various
entities,
if
you
will,
that
could
just
cover
all
the
reports.
So
the
the
other
challenge
is
is
that
you
can
send
out
a
report
that
includes
a
pdf
or
an
email
that
includes
a
pdf
of
a
summary,
that's
defined,
based
on
what
you
want
to
see
in
the
analytic
dashboard.
C
The
challenge
is,
it's
only
limited
to.
I
believe
the
limit
is
10
widgets
in
the
dashboard,
and
so
we
have
more
than
10
local
localized
languages,
and
so
we
couldn't
break
out
each
language
into
its
own
widget
and
that
data
kind
of
gets
a
little
hairy
when
you
start
to
summarize
it
at
such
a
high
level.
C
So
I
think,
unfortunately,
we're
stuck
sending
out
a
pdf
per
localization
or
per
dashboard
with
those
widgets.
I
don't
see
a
way
to
create
like
an
aggregate
where
it
sends
an
email
with
like
10
pdfs
of
all
the
different
languages.
It
would
be
10
separate
emails.
Unfortunately,
at
least
from
my
initial.
C
So
I
believe
that
google
defaults
to
a
pdf-
and
I
haven't
looked
too
far
into
this,
but
I
believe
that
the
email
itself
attaches
the
pdf
generalized
report.
The
alternative
potentially
would
be
a
public
dashboard,
but
it
seems
like
the
technical
debt
might
be
too
much
to
to
adapt
so
pretty
much
stuck
with
pdf.
As
far
as
I
can
see.
That
might
be
something
worth
investigating,
though,
just
to
confirm.
A
Abigail
with
that
in
mind,
any
more
thoughts
on
on
what
the
next
steps
might
be
and
what
you'd
like
to
promote.
F
That's
an
excellent
question,
so
I
guess
trying
to
figure
out
like
confirm
what
jim
has
said
about
the
pdfs
and
the
best
way
to
send
it
out
and
then
sort
of
creating
a
separate
email
address
that
we
can
sort
of
set
up
to
get
so
people
can
self-register
for
getting
the
analytics
information
that
they
want
would
probably
be
my
next
steps.
If
that
makes
sense
to
everybody,
we
can
kind
of
move
forward.
C
Yeah,
that
sounds
great
and
the
other
thing
too
is:
I
have
the
instructions
on
creating
the
mailing
list,
as
I
was
going
to
do
for
the
localization
reports.
I
think
that,
like
I
said,
we
might
want
to
pivot
to
more
of
a
standard,
sig
docs
reporting
group,
but
I'll
pull
that
up
and
I'll
throw
it
in
the
agenda
too,
and
we
can
definitely
synchronize
on
that.
A
Okay,
well,
that
is
the
agenda,
but
there
is
room
if
anyone
has
more
things,
they
want
to
talk
about
on
analytics
or
more
things.
They
want
to
propose
for
discussion
just
now,
and
now
is
the
right
time
to
speak.
If
that's
on
your
mind,
evie.
G
By
the
way
tim,
I
have
a
questions
regarding
the
cube
serial
cheat
sheet
that
we
we
mentioned
in
the
quarterly
meeting
before
have
we
had
a
discussion
with
six
cli
before
this.
A
So
if
it's
okay
evie,
I'm
going
to
summarize
what
I
think
the
context
is,
but
in
the
quarterly
meeting
we
discussed
an
open
issue
about
the
fact
that
there's
two
lots
of
kubratal
documentation.
There
is
a
coop
pedal
handbook
which
is
published
into
netlify,
hosted
by
the
kubernetes
project,
and
there
is
also
the
cubecuttle
documentation
inside
the
kubernetes
website.
A
Now,
sig
docs
is
have
more
heavily
involved
in
generating
and
looking
after
the
cube,
cutting
documentation
on
kubernetes,
io
and
sig.
Cli
is
more
involved
in
the
coop
cuddle
handbook,
but
I
think
the
ideal
it
feels
to
me
like
the
ideal
is
that
we
we
merge
these
and
we
have
a
discussion
with
the
cli
special
interest
group
to
find
a
common
ground
and
to
make
the
experience
for
people
visiting
your
website
smooth.
A
We
haven't
it's
a
few
days
less
than
a
week
since
that
quarterly
meeting.
So
I
don't
know
what
actions
happened.
G
Okay,
then
so
so
we
can
kind
of
like.
Should
we
come
to
the
like,
the
google
groups
and
then
mentions
these
things,
or
should
I
just
kind
of
drop
by
in
their
select
channel
and
bring
up
the
discussions
what's
usually
happen
for
this
kind
of
discussions.
A
So
what
I've
done
with
see
architecture
is,
I
started
with
slack,
so
I
I'm
going
to
do
a
similar
thing.
As
I
mentioned,
to
go
and
talk
to
sig
architecture
about
the
api
reference
and
my
approach.
There
was
to
kick
off
a
discussion
in
slack
and
actually
quite
grateful
because
it
kind
of
got
overlooked,
but
then
someone
in
cigar
came
back
and
picked
it
up
and
I
didn't
have
to.
I
dropped
the
ball
on
that
a
bit
but
yeah
following
that.
A
Up
with
you
know
a
more
formal
discussion
and
then
for
the
api
reference
I'm
going
to
join
that
sig's
meeting.
So
I
think
you
know
essentially
once
it
goes
to
the
other.
Six
weekly
meeting
feels
like
the
right
pattern.
Okay,
any
thoughts
on
that.
A
A
Maybe
I'll
ask
a
question
who
here
is
is
involved
in
substantially
in
another
special
interest
group,
one
person
we've
heard
from
already
ray
anyone
else.
A
Okay,
so
the
the
kubernetes
project,
we
is
organized
in
a
sort
of
family
of
overlapping
groups,
called
special
interest
groups.
So
this
is
the
documentation,
special
interest
groups
and
then
there's
a
group
for
api
machinery,
a
group
for
application
apis
like
deployment
and
replica
set.
There's
a
group
of
networking
and
and
others
like
it.
A
The
groups
that
we're
going
to
liaise
with
and
that
we've
talked
about
today
are
architecture
for
the
api
reference
and
cli
command
line
interface
for
the
cube,
cuddle,
documentation,
overlap.
A
So,
okay,
so
this
this
is
really
something
that
that
we
will
do
all
upstream
and
in
fact,
for
both
of
these
things,
the
the
documentation
we
talk
about
is
largely
generated.
A
So
the
the
localization
process
for
generated
documentation
is
a
bit
different.
It's
not
really
to
do
with
localization.
This
is
to
do
with
the
overlap
between
different
groups
and
having
good
communication.
A
So
the
piece
of
work
that
I'm
going
to
do,
and
that
erv
is
talking
about,
is
about
communication
between
different
groups
so
that
we
don't
work
on
in
our
own
bubbles,
basically,
and
and
so
that
we
do
end
up,
collaborating
to
provide
a
good
experience
for
the
kubernetes
community.
H
I'm
just
trying
to
get
the
the
process
in
the
right
way.
You
get
the
all
the
changes
you
get
all
the
documentation
from
the
groups
and
you
dude.
You
make
all
the
all
the
new
changes
available
in
the
documentation
and
then
the
other
groups,
the
other
sorry,
the
other
language
group
translation
groups
make
they
work.
Maybe
I
misunderstood
your
question.
H
A
Well
so
the
question
was:
is:
are
people
involved
in
different
special
interest
groups,
not
necessarily
localization
teams?
That's
a
different
thing.
I
I
do
know
there
are
people
here
who
are
involved
in
different
localizations,
but
I
was
asking
about
people
who
might
be
involved
in
different
contribution
groups,
so
people
who
write
different
bits
of
kubernetes
code,
for
example,.
A
C
I
guess
in
what
sense
I'm
happy
to
chat
about
it.
I
have
a
involvement,
sig
release
as
well
sig
docs,
but
I
guess
what
are
you
looking
for
as
far
as
the
relationship
yeah
yep.
G
Yeah,
usually
I
take
along
in
the
sick
release
or
the
country
backs
to
meetings
and
if,
let's
say
we
from
from
another
six,
have
some
some
agenda
that
need
to
be
discussed
with
them.
Then
we
can
kind
of
write
the
informations
or
issues
that
we
want
to
share
and
then
we
will
discuss
it
in
their
meetings,
so
both
of
the
six
will
kind
of
trying
to
find
solutions
for
for
the
issues
that
we
are
discussing
in
the
meeting.
G
So
basically,
we
are
trying
to
kind
of
finding
a
common
ground
on
how
to
proceed
with
that.
C
C
One
other
thing
that
I've
heard
recently
from
some
of
the
steering
committee
is
making
less
decisions
in
sig
meetings
and
more
out
in
the
open,
and
I
like
the
idea.
You
know.
I
know
that
personally,
I'm
not
always
the
best
at
not
making
making
a
decision
in
a
meeting
setting,
but
what
the
the
rule
of
thumb
is.
Is
that
don't
make
a
decision
inside
of
a
sig
meeting
but
actually
advertise
the
decisions
on
mailing
lists
and
make
sure
that
it's
widely
advertised
and
widely
communicated?
C
Just
so,
there's
more
folks
that
are
aware-
and
this
is
a
little
bit
of
a
side
tangent
more
about
the
fact
that
a
lot
of
folks
are
involved
in
multiple
sigs
and
everyone
can't
be
at
every
meeting
at
every
single
time,
and
so
by
putting
some
of
these
comments
out
in
mailing
lists,
potentially
mailing
the
various
cigs
and
copying
them
together
under
one
group,
I
think
that's
a
great
way
to
start
because
now
there's
a
record
of
the
engagement
prior
to
having
that
meeting
there.
C
So
I
guess
the
takeaway
there
is
that
these
sig
docs
meetings
in
any
of
the
other
sig
weekly
meetings
is
more
about
alignment.
General
issues
direction,
things
of
that
nature,
but
over
all
goals
and
decisions
and
major
changes
should
be
communicated
widely
and
a
tangent
on
that
tangent.
I
plan
on
sending
out
our
quarterly
meeting
on
our
mailing
list
just
for
general
awareness
for
folks
who
couldn't
attend
a
quick
summary
as.
A
Well,
so
my
summary
of
that
is
that
av
you're
gonna
look
at
reaching
out
to
the
kubeco
people.
If
there
is
a
decision,
that'll
be
probably
done
the
way
that
jim
said,
rather
than
just
in
a
during
a
weekly
call
of
one
of
those
six
and
I'm
going
to
do
a
similar
thing
with
the
migration
to
the
new
api
reference.
H
I
would
like
to
do
a
last
comment.
I
know
it
is
the
right
moment
that
this
is
what
about
jim
mentioned
about
the
analytic.
There
is
a
way
that
thing
uses
lacrosse
use
slack
to
show
the
google
analytics.
I
don't
know
if
it's
related,
I'm
just
reading,
doing
a
good,
a
big
lecture,
so
I'm
gonna
show
the
link
on
the
on
the
channel
of
slack.
H
A
Cool,
so
this
is
about
sharing
the
reports
via
slack
apparently
cool.
I'm
sharing
reports
fire
via
slack,
sounds
like
another
good
thing
that
we
could.
We
could
look
at
for
sure.
I
can
imagine
that
the
same
challenges
with
noise
might
come
up,
so
it
might
be
a
separate
channel.
It
might
be
its
own
channel.
We
could
discuss
that
in
more
detail.
J
I
think
that's
one
of
the
channels
that
was
used
before
so
I
remember
like
on
weekly
basis.
The
document
was
shared
on
6.00
and
then
forwarded
to
all
the
sig
location
teams
more
or
less
like
channels
that
were
interested.
So
was
there
a
way
to
find
out
the
communication
just
to
the
groups
that
are
interested
in
it's
a
way
to
be.
A
J
And
and
just
something
to
add
to
the
meeting
that
from
the
spanish
team
in
braille,
we
are
starting
with
the
meetings
so
to
try
to
get
everything
started.
We
have.
J
We
were
on
an
event
last
january
on
el
salvador,
it's
just
a
country
in
south
america
and
we
grew
up
out
of
people
interested
in
the
project
and
working
on
the
communication.
So
we
are
trying
to
to
get
more
people
involved,
and
I
think
that
this
weekly
meetings-
it's
a
bit
overkill
right
now,
but
it's
something
to
get
things
started.
I
just
want
to
say
that
that
so
far
it's
working
so
fingers
crossed
and
then
another
thing
related
to
the
to
the
collaboration
with
six.
J
I
am
usually
helping
also
contribute
to
experience,
and
I
think
it's
something
really
useful
for
the
local
additions
team
to
get
involved
on
bringing
new
people
that
speak
your
language
to
the
communities.
Also,
probably
we
will
work
on
some
like
documentation
on
how
to,
for
example,
run
hackathons
for
documentation
on
how
to
talk
on
events.
We
have
a
set
of
slide
decks
regarding
documentation
and
how
to
contribute
to
the
current
website,
and
we
usually
give
those
stores
in
spanish
here
at
in
spain.
J
So
we
tried
to
build
a
kind
of
framework,
so
any
localization
team
can
have
like
two
talks
regarding
his
language,
because
at
the
end
it's
the
same
thing,
just
change
the
the
language
and
that's
something
that
we
are
working
on
and
probably
when
we
have
something
more
formal.
We
will
share
with
the
rest
of
the
education
teams
and
the
six
books.
Also,
okay,.
A
Cool
that
sounds
great.
I
realized
we
didn't
actually
have
any
topic
of
localization
update
on
the
meeting.
Does
anyone
maybe
brad
want
to
give
a
really
quick
update
on
localization.
E
Oh
sure
we
had
a
meeting
just
yesterday,
our
monthly
meeting-
and
you
know,
we've
got
a
few
light.
A
few
loose
ends
to
tie
up
there's
some
some
tool,
there's
a
script
that
we
want
to
get
documented
in
the
mage
localization
page,
still
a
little
bit
of
a
concern
of
those.
I
think
they're
called
toml
files.
E
E
You
know
about
the
process
of
what
we
agreed
on
with
irve
was
that
that
the
tech
leaders
would
be
willing
to
take.
You
know,
get
slack
messages
to
say,
hey.
I
have
to
make
a
change
to
the
toml
file.
Could
you
please
expedite
a
review,
and
so
we
are
going
to
try
that,
and
I
think
there
was
just
a
suggestion
that
maybe
so,
for
example,
the
some
of
the
localization
teams,
like
the
korea
team,
were
aware
of
that
process.
E
But
I
think
we
might
need
to
document
that
hey
if
the
localization
team
needs
a
pr
to
be
expedited,
reviewed
by
one
of
the
tech,
the
sig
doc
leaders
that
had
the
ability
to
merge
that
file.
You
know
that
that
that
that
was
the
process.
So
so
we
think
we
can
make
that
process
and
irvy
can
correct
me.
If
I'm
wrong.
E
I
I
think
I
think
the
reason
why
it
was
very
difficult
to
set
up
the
permissions
so
that
the
people
in
a
particular
localization
could
actually
have
access
to
those
files
because
of
where
they're
located.
I
believe-
and
I
don't
know
if
he
remembers
the
topic.
It
was
from
a
way
back
and
we
just
talked
about
this
meeting
so
we're
just
going
to
watch
that
issue
and
make
sure
that
that's
still
manageable,
but
but
so
far,
so
good.
E
The
the
best
practices
that
we
put
in
place
putting
the
the
localization
prefix
code
in
the
subject
of
the
of
the
of
the
pr
the
pull
request,
title
people
like
that
and
they're
gonna
start
doing
it,
and
and
and
you
know
the
other
things
and
we
still
have
more
progress
to
make
irvy.
Did
you
want
to
add
anything
to
that.
G
Since
I
don't
attend,
I
didn't
downtown
yesterday
meeting.
So,
if
I
remember
correctly,
the
the
discussions
about
the
owners
files,
especially
for
the
english
one,
is,
will
be
like
a
superset
for
all
of
the
owners
of
of
other
localization
as
well.
So
that's
also
like
a
challenge.
If
you
want
to
kind
of
separate
the
approver
for
each
of
the
language
itself,.
J
I
think
that
the
problem
is
that
all
those
files
are
under
the
id
18n
folder
and
that
folder
belongs
to
the
road
owner.
So
maybe
we
can
find
a
way
to
move
this
domain
file
under
the
the
language
path,
so
it's
under
slash
s
or
space
covariance,
and
then
the
owners
of
that
folder
will
be
able
to
edit
that,
but
right
now
they
are
in
the
root
folder
and
those
stone
files
is
just
like
short
names
of
or
actions
like
feedback.
A
My
advice
is
this
sounds
like
an
issue
and
with
my
day,
job
hat
on
I'd
like
to
see
it
logged
as
an
issue
sure.
E
J
J
A
Okay,
I'm
getting
the
sense
that
we've
discussed
what
we
need
to
discuss
for
the
week.
I'll
do
another
countdown
five,
four,
three,
two
one!
That's
a
sig
meeting
people
thanks
very
much.