►
From YouTube: Kubernetes Contributor Experience SIG 20190116
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
B
C
A
Okay
meet
our
contributors
usual
plug.
We
can
always
use
more
people
doing
that.
Paris's
has
envisioned
that
we
would
all
take
at
least
one
session
over
the
course
of
the
year.
I
am
going
to
take
that
challenge
up
sometime
this
year,
I
invite
all
of
you
to
as
well.
So
if
you
are
interested
in
doing
that,
please
reach
out
to
Paris
and
let
her
know
your
availability
for
that
and
then
the
community
meeting,
let's
see
how
we're
doing
for
hosts
for
that.
A
A
F
C
D
A
Okay,
Josh
would
I'll
let
you
throw
I'll,
let
you
check
your
calendar
and
if
you
have
an
availability
pick,
the
24th
in
the
31st
and
I
would
extend
that
invitation
to
y'all
as
well.
If
you
could
check
your
calendar,
see
if
that
works
for
you
and
if
so,
if
you
could
sign
up
in
the
spreadsheet,
I'd
be
wonderful.
A
Okay!
Moving
on
to
our
next
agenda
item,
we're
going
to
go
over
the
project
board.
A
A
G
E
G
A
D
D
Files
and
I
would
rather
see
us
use
those
more
consistently,
but
there
is
an
ask
to
add
like
more
human-friendly
information
like
who
are
the
people
in
the
owners,
files
and
I
feel
like,
rather
than
adding
additional
fields
to
60ml
I'd
love
to
see
our
automation
consume
the
owners
files
that
are
out
there
and
pull
that
information
back
so
that
it's
dry
and
it's
also
the
owners.
The
owners
file
information
is
in
places
that
are
controlled
by
those
sub
project
owners,
so
we
can
sort
of
get
away
from
an
changed.
D
Further
I
kind
of
feel
like
a
lot
of
the
concerns
over
sub-projects,
is
that
people
don't
realize
they
can
have
their
own
meetings
and
they
can,
if
there
are
concerns
on
more
than
that,
I'm
kind
of
like
kind
of
a
little
bottle.
Macky
about
this,
because
I'm
really
busy
with
release
stuff
I'm
happy
to
Shepherd
it
forward,
but
I
think
the
other
person
who
had
pushed
hardest
on
this
particular
issue
was
Steven
Gustus
who's,
also
kind
of
going
to
be
out
of
pocket
for
the
next
half
of
the
month.
D
D
It
looks
like
the
art
community
has
stepped
up
and
then
awesome
zjs
went
through
and
tried
to
take
a
best
guess
at
the
relevant
six
Nikita
has
put
together
a
PR
to
update
the
generator
to
put
stakeholder
six
in
working
group
information.
It
needs
a
reef
base
and
I
will
throw
it
through
the
steering
committee
just
to
give
them
a
glance
at
it,
but
that
my
first
glance
in
the
past
thirty
Seconds-
it
looks
okay
to
me,
so
I'll
pay
more
attention
to
that
space.
That's
the
steering
committee
meeting
is
happening
today.
A
A
Cool,
do
you
wanna
move
into
in
progress
or
down
into
the
dock?
Let's
do
something
else,
let's
move
into
the
the
open
mic
discussion,
so
who
has
this
first
item.
A
I
G
J
J
A
D
D
J
A
So
big
news,
our
charter
was
merged
so
day.
Thank
you
for
everybody
who
helped
with
that
has
been
like
a
several
month.
Endeavor
it
also.
So
if
you
haven't
read
the
turner
yet
I
would
highly
encourage
you
to
do
so,
especially
the
section
where
we
communicate
how
we
communicate
changes
to
the
rest
of
the
community.
We've
struggled
with
that
in
the
past.
You
have
programs
that
are
not
aware
of.
A
A
Moving
to
the
next
agenda
item
coop
Connie
you,
which
is
in
May
in
Barcelona.
We
are
so
I'm
going
to
open
this
up
for
discussion.
Do
we
just
want
to
do
an
intro?
Do
we
want
to
do
in
and
try
deep
dive
and
an
intro
do
want
to
have
a
merged
session?
What
makes
sense
based
on
who
is
planning
to
go
and
what
content
people
want
to
prepare
for.
A
I
C
C
C
You
know
and
all
of
the
problems
there
and
everything
else,
the
we
did,
the
one
for
cig
release
on
build
tools,
so
so
I
think
I
think
whether
or
not
we
have
a
deep
dive
should
depend
on
whether
or
not
somebody
has
something
that
they
would
like
to
do.
For
one
of
the
contributor
experience
sub
projects
for
a
deep
dive,
I
could
see
it
being
a
working
session
on
the
developer
guide
or
the
contributor
guide,
for
example,
and.
B
C
Bit
I
mean
somebody's
gonna
have
to
do
some
practically
actually
expected
meaningfully
get
people
started,
I
mean,
since
these
sessions
are
only
effectively.
What
is
there
ever?
It
is.
You
know,
35
40,
minutes
of
working
time
you
get
out
of
it,
as
you
would
get
some
additional
people
from
the
community
to
take
specific
items.
They
wouldn't
actually
do
them
just
in
and
to
sort
of
understand
the
structure
of
the
new
guides.
So
somebody
would
need
to
do
a
fair
amount
of
preparation
for
that
to
be
meaningful.
A
H
H
It's
just
just
as
a
quick
reminder
and
everybody
is
concerned,
so
just
as
a
quick
reminder
that
the
deadline
to
register
for
interim
dip
dive
session
is
February
8th.
So
we
have
a
few
weeks
before
the
deadline
to
polish
all
the
details
and
to
figure
out
what
is
our
plan
for
dip?
Definitely
for
Barcelona's
mission.
Hide
that
deadline
is
later
okay,
yeah.
D
So
hi
I
was
part
of
the
group
that
broke
ground
on
this
80
minute
working
session
thing
for
the
conformance
working
group.
So
just
to
share
our
experience,
what
happened
was
we
decided
we
kind
of
needed
a
face-to-face
version
of
one
of
these
meetings?
We
felt
that
it
was
important
because
everybody
was
going
to
be
in
the
same
place
at
the
same
time.
I
think
that
sort
of
thing
could
be
really
cool
for
Europe
or
Shanghai.
D
The
time
zones
that
don't
traditionally
get
to
participate
in
these
Pacific
friendly
meetings,
and
we
just
kind
of
did
the
usual
thing.
So
we
had
some
notes.
We
had
some
meeting
notes,
we
kind
of
had
an
agenda
and
we
had
a
note-taker
and
just
kind
of
asked
mics
around.
So
we
did
actually
walk
away
with
some
action
items.
Some
difficult
questions
got
answered.
You
know
we
didn't
come
intending
to
like
have
everybody
hack
away
at
their
laptops,
but
instead
just
with
communications,
just
another
potential
suggestion
that
might
be
lower
effort
on
the
organization
from.
A
Yeah
I'm
I,
like
the
sound
of
that
that
sounds
that
sounds
better
from
I
feel
like
everybody
who
goes
koukin
generally,
is
stretched
a
little
thin
bandwidth
wise.
Do
we
want
to
give
people
a
week
to
discuss
this
on
the
mailing
list,
their
preferences,
their
proposals
and
then
I?
Think
next
week
is
the
the
off
our
the
off
our
meeting
the
later
meeting.
So
do
we
want
to
discuss
this
the
week
after
that?
Give
people
two
weeks?
Is
that
still
going
to
be
within
the
proposal?
B
A
Speaking
of
face
to
face
meetings
as
a
sig,
we're
supposed
to
we've
talked
about
having
one
in
the
next
two
quarters.
I
know.
Last
year
we
did
it
at
index
cost
and
so
I
don't
know.
If
we
would
want
to
do
that
again.
So
do
people
feel
like
that
worked
well.
Last
time,
do
we
want
to
do
the
in-person
meeting
in
a
different
format?
C
So
you
know,
given
that
anything
that
had
a
little
bit
more
lead
time.
I
think
would
be
better
because
we
did
get
some
things
done.
So
anything
that
had
a
little
bit
more
lead
time.
I
think
would
work
better
I
do
kind
of
feel
like
if
possible,
it
would
be
nice
to
harness
it
to
another
kubernetes
event,
maybe
not
a
kook
con,
because
it's
already
so
long,
but
maybe
one
of
the
upcoming
coop
days,
so
that
we're
not
limiting
attendees
to
people
who
can
schedule
additional
travel.
L
Every
one
of
the
bigger
conferences
like
Scott,
maybe
I've,
never
even
heard
of
index
con
I,
don't.
C
H
A
Okay,
so
what
dates
were
those
again
Oh
April.
C
C
A
I'm
I'm
liking
the
April
timeframe
a
little
bit
better.
That
way,
people
have
time
to
talk
to
their
managers,
to
get
approvals
and
a
couple
months
to
book
tickets
and
hotels
and
stuff
so
I
would
I'd,
probably
I,
probably
have
a
preference
for
March
or
April.
But
if
you
all
want
to
meet
senior,
that's
cool
I'll
make
it
work.
Yes,.
B
H
And
if
merge
further
normal
well
I
was
speaking
about
cloud
necks.
Just
just
to
finish
here.
Just
to
put
my
calendar
and
note
is
that
it
happens
since
Tuesday
tail
Thursday.
So
if
people
are
planning
for
like
for
another
day
of
the
travel
for
another
day,
it
might
be
a
mine
day
option
of
Friday
option.
H
Probably
we
would
have
to
discuss
this
Paris
because
last
year,
for
example,
at
Google
necks,
there
was
a
community
day
before
the
big
next,
which
was
like
there's
Google
focus
but
versus
focused
and
given
I.
Just
was
one
at
the
target
point.
So
if
if
this
will
happen
this
time
again,
probably
most
of
us
are
likely
to
attend
this
community
day
as
well.
H
H
C
A
A
H
A
Those
were
I
think
my
two,
my
two
agenda
items,
Oh
actually
I,
have
one
more.
The
Deb
stats
sub-project
group
has
been
meeting
once
a
month
on
Tuesdays.
A
However,
attendance
has
dwindled
for
that
for
that
group,
so
I'm
wondering
if
we
should
just
talk
about
Deb
stats
more
in
the
this
general
meeting,
rather
than
having
that
separate
set
project
group
meeting
once
a
month
plus
one
are
we?
Okay
with
that?
Okay
cool?
J
Hey
sorry
about
that,
no
way!
Okay,
so
so
I
worked
at
Intel
and
we've
been
working
in
the
community
of
her
last
year
or
so,
and
part
of
what
we
did
for
our
internal
team
was
make
sort
of
like
an
internal
mentorship
program,
but
then
it
helped
guide
some
of
our
gene
engineers
through
the
community
and
get
them
familiarized
with
all
of
the
documents,
and
things
like
that
sort
of
leveraging
a
lot
of
the
pieces
that
this
script
is
contributed
to
already
and
I.
Guess:
I
just
wanted
to
come
and
kind
of
share.
J
Maybe
the
outline
of
the
program
we
can
put
together
what
we
were
talking
with
our
internal
education
team
about
doing
is
prepping
all
of
these
materials
kind
of
onto
more
professional
slide
where
and
video
content,
and
then
seeing
if
you
know
this
group
would
be
interested
in
taking
it
as
a
part
of
the
content
ecosystem.
You
know
kind
of
a
generic
mentorship
program.
We
noticed
with
the
mentorship
program
that
exists
today
is
a
little
bit
sparse
on
content,
and
so
maybe
we
could.
We
could
give
some
of
this
materials
back
to
do
that
effort.
J
A
J
We
could
walk
through
kind
of
that
outline
and
then
the
course
materials,
the
reading
materials
and
the
presentation
we
did
for
maybe
one
of
the
modules
to
give
a
walk
through.
So
I
can
put
more
time
on
for
next
week
to
go
in-depth
on
it,
but
it
sounds
like
maybe
first
classes
yeah.
If
you
have
a
bunch
of
material,
that's
good,
maybe
interested
in
in
looking
at
in
a
bit
more
yeah
I.
J
So
all
of
our
stuff-
that
now
is
in
total
Han
part
of
the
course
curriculum.
There's
a
lot
of
coverage
on
submissions
that
we
had
made
or
taps
that
we
had
submitted
and
sort
of
you
know
helping,
explain
hey.
This
went
along
with
our
tech
for
this
one
right
at
the
cap.
For
you
know,
there
was
already
prior
art,
so
there's
a
fair
amount
of
like
internal
back-and-forth.
That
I
think
we
need
to
pull
out
of
some
of
the
material.
J
The
the
wide
distribution
is
possible
until
we
have
a
chance
to
go
through
at
once,
but
if
someone's
interested
in
maybe
going
through
one
on
one
just
to
take
a
look
at
like
what
the
what
the
layout
is
or
maybe
even
help
guide
like
which
one
we
bring
in
here
to
sort
of
demo
I
could
I
could
have
somebody
look
at
it.
I
just
you
know
it's
kind
of
got
to
be
like
a
friendly
situation,
just
because
I
can't
I
don't
want
to
leak
anything
I.
A
L
A
Sorry
I'm
it's
Hotel
Wi-Fi,
so
it's
kind
of
awesome
body,
Aaron,
I,
think
you're
you're.
Next
on
the
agenda,
yeah.
D
E
D
I
feel
like
it's
related
to
say,
contributor
experience
and
how
they
yeah
the
meetings
did
win,
and
so
it's
ready
to
contribute
our
experience
and
our
changed
employment
policy,
since
the
charters
merge
diagonal
link
to
it
yay
so
I'm
gonna
share
my
screen
with
stuff
I
put
in
the
meeting
notes.
But
my
ask
here
is
because
I
have
no
more
of
those
meetings
coming
up
I,
don't
that's
the
wrong
screen
again,
so
cool
you
get
to
see.
My
private
chat
with
my
release
leads
where
I
said
we
should
stop
having
private
chats.
Look
at
that.
D
D
Much
better,
okay,
so
see
contribute.
Sig
testing
has
kind
of
a
less
wordy
deployment
policy
where
we
try
and
categorize
our
changes
into
low,
medium
or
high
risk
changes
based
on
the
potential
of
great
contributor,
where
it
flows
how
easy
they
are
to
roll
back
and
how
many
SIG's
or
repose
they
affect
kind
of
squishy
and
fuzzy.
D
It
doesn't
have
hard
numbers
part
of
that
to
like
help
us
figure
this
out
when
it's
reasonable,
and
so
the
change
that
I'm
talking
about
here
is
a
change
that
was
communicated
on
December
10th,
along
with
the
PR
that
actually
I'm,
still
sort
of
trying
to
recall
the
PR.
The
change
was
something
I
would
classify
as
a
medium
risk
chain,
because
it
did
impact
the
existing
contributor.
We're
close
I
think
it
was
easy
to
rollback
and
it
impacted
all
of
the
project
repos.
It
wasn't
intended
to.
D
This
was
an
accident,
so
the
the
policy
we
should
have
taken
was.
We
should
have
shared
the
change
with
contributor
experience
and
it
may
have
required
a
lazy
consensus
issue
with
kubernetes
stuff,
and
so
we
piloted
this
change
on
K
community
and
we
did
talk
about
this
within
the
state
contributor
experience
mailing
list
first
and
then
we
also
gave
a
broader
heads
up
to
the
kubernetes
def
mailing
list
that
we
were
going
to
deploy
this
change
to
k
community.
Now,
somehow,
between
that
note
is
going
out
on
December.
Well,
here,
let's
listen.
D
So
this
is
what
contributor
experiences
thing
is
the
reason
state
testing
talks
about
sharing
changes
with
city
contributor
experiences,
because
y'all's
change
deployment
policy
includes
a
lot
more
communication
channels.
I
appreciate
that
that's
cool
you
hit
a
bunch
of
different
mailing
lists.
You
reserve
the
right
to
brag
about
this
on,
like
the
Twitter's
and
the
community
meetings
and
the
slacks
and
the
vlogs
and
stuff.
That's
that's.
D
Cool
testing
rolls
out
many
many
many
changes
every
day,
and
so
we
don't
necessarily
feel
that
we
can
afford
the
time
to
communicate
on
all
of
those
channels
for
all
of
those
changes,
because
that
would
really
reduce
the
signal-to-noise
ratio
for
a
bunch
of
folks.
So
we
sort
of
trust
you
to
give
us
feedback
on
whether
or
not
the
change
we're
talking
about,
makes
sense
from
a
contributor
experience
perspective
and
if
you
so
feel
the
need
to
broadcast
across
all
these
mediums.
You
also
have
a
medium
risk
change.
D
You
do
have
a
high
risk
change
where
it
impacts
more
than
four
six
or
working
groups,
so
we
would
have
stepped
through
the
process
of
notifying
all
the
six
okay.
So
what
was
the
change
in
question?
Well,
let's
go
take
a
look
at
the
notification
and
that
was
sent
out.
It
was
this
also
really
small
text
I'm
sure,
so
they
blowed
up.
D
D
I
mean
any
kubernetes,
org
member
and
so
I
campaigned
really
hard
to
have
the
opposite
that
just
because
I'm
in
the
owners,
file
in
route
and
I
have
sufficient
privileges
to
approve
all
of
those
changes.
The
approved
label
shouldn't
automatically
get
implied.
The
setting
was
known
as
implicit
self
approved
false.
D
So
we
rolled
this
out
a
community
and
we
discovered
that
a
lot
of
the
contributors
within
the
community
got
confused
by
this
a
lot
of
people
just
in
practice.
It's
confusing
for
PR
authors.
They
don't
understand
why
there
PR
isn't
approved,
or
they
don't
even
know
that
they
can
approve
it
themselves.
D
So
what
we
instead
decided
to
do
was
roll
it
back
to
the
default
behavior
where,
yes,
if
I
submit
my
own
PR
I,
do
implicitly
approve
of
my
own
PR
and
yes,
theoretically,
anybody
could
drive
by
an
LG
TM
that
PR,
but
it
also
reduces
the
friction.
For
me,
there
are
a
lot
of
contributors
who
just
kind
of
know
what
they're
doing
and
want
that
extra
a
little
bit
out
of
the
way.
D
So
we
propose
that
we
were
going
to
roll
this
change
out
to
community,
and
then
we
were
going
to
roll
it
out
to
everything,
dot,
dot,
dot,
I,
don't
know
what
happened
that
change
accidentally
got
rolled
out
to
everything
without
any
further
notice,
so
I'm
trying
to
dig
up
whatever
timeline
I
can
to
explain.
So
when
did
that
change
actually
get
rolled
out
and
I
feel
like
there's.
M
M
M
One
of
the
testam
for
folks
was
like
hey
I,
want
to
go
and
set
us
up
that
these
things
that
we
discussed
are
going
to
be
in
the
future
our
new
defaults
and
be
opinionated,
unlike
there's,
there's
kind
of
two
sides.
Whenever
we're
talking
about
testing
for
changes,
there's
the
settings
that
kubernetes
and
the
kubernetes
community
uses
as
well
as
there's
the
settings
in
prowl
of
a
software
product
that
we
have
developed
internally
to
do
all
those
two
lengths,
and
sometimes
we
offer
options
that
other
folks
might
want
to
use
in
prowl.
But
we
did.
M
We
do
not
necessarily
turn
on,
and
in
many
and
in
many
cases
the
defaults
that
kubernetes,
like
the
settings
of
kubernetes
use,
are
not
the
default
for
somebody
to
playing
a
new
instance
of
prowl.
So
the
change
was
supposed
to
change
the
defaults
or
prowl
to
kind
of
match
what
the
future
the
future
of
what
we,
what
we
wanted
for
kubernetes
the
things
that
we're
driving
towards
in
kubernetes
with
the
default.
What
was
unintentional
about
the
change?
Was
it
having
an
impact
in
kubernetes
right
away?
And
there
was
a
couple
different
points
of
confusion.
M
M
If
we
hadn't
said
something
works
plus
up
that
change
was
merged
six
days
ago
and
was
deployed,
as
is
the
usual
overhead
testing
on
a
Friday
afternoon,
so
it
was
merged
and
then
went
live
and
nobody
noticed
it
over
the
weekend
and
then
this
week
started-
and
we
got
a
complaint
from
docs
folks
that
hey
there's
this
behavior
change.
We
don't
know
what
happened
that
this
wasn't
communicated,
etc.
D
So
to
complete
the
timeline
that
so
yeah,
so
that
sounds
like
six
days
ago
would
have
been
January,
9th,
I,
think
and
so
January
15th.
We
had
somebody
approached
us
and
said
testing
saying
hey:
this
doesn't
look
right.
There
was
much
discussion,
it
started
out
kind
of
of
the
form
of
why
wasn't
I
informed.
There
was
concern
that
people
were
forcibly
changing
we're
closed
without
giving
any
heads-up
or
warning.
D
You
know.
Is
this
an
honest.
Miss
part
of
me
feels
like
there's
a
careful
balance
between
being
super
conservative,
with
every
rollout
and
being
able
to
deploy
quickly
and
be
agile
and
responsive
to
the
needs
of
the
contributors
to
our
150
plus
repos,
and
so
it's
okay
for
mistakes
to
happen.
They're,
probably
not
malicious.
How
can
we
have
an
open
forum
for
transparent
discussion
on
things
like
this?
So,
for
me,
part
of
transparency
is
doing
a
retro
on
things
like
this.
D
When
things
go
wrong,
trying
to
put
together
a
timeline
I,
don't
know
that
I'm
going
to
be
the
individual.
If
you
can
put
together
this
timeline,
so
my
suggestion
would
be
maybe
Christoph
or
somebody
who's
sufficiently
motivated
could
take
what
I've
put
in
the
meeting
notes
here
into
an
issue.
So
we
can
get
the
timeline
down
and
see
what
went
wrong.
D
One
of
the
things
that's
revealed
to
me
is
that,
if
I
look
at
both
of
those
change
policies,
neither
of
them
have
any
explicitly
documented
criteria
for
what
constitutes
motivation
for
a
rollback
you
know
like
when,
should
the
fire
alarm
get
pulled?
Is
that
based
on
impact?
Is
that,
based
on
duration,
when
we
do
get
that
notice?
How
quickly
should
B
be
responding
to
that
sort
of
thing,
so
on
and
so
forth?
So
I
just
wanted
to
have
a
little
bit
of
a
discussion
about
that
here.
M
Option,
but
one
thing
that
I
can
clarify
is
the
reason
that
it
wasn't
communicated.
I
could
say
this
was
supposedly
the
reason
it
wasn't
communicated
is
because
it
was
unintentional.
It
was
unintentional
to
take
effect
right
away
and
should
was.
There
was
no
intent
to
impact
our
workflows
in
Coober.
It
is
right
now
it
it
just
had
to
do
with
like
layering
of
defaults
and
things
that
we
weren't
inspected
expecting
in
the
code.
M
D
D
Now
thinking
of
two
different
concepts:
I'm
thinking
of
crowd,
the
sub,
the
the
sub-project
aka,
the
code
base
that
we
contribute
to
and
then
I'm
thinking
of
our
proud
deployment
for
the
kubernetes
project,
aka,
proud,
Kate's,
dot,
IO
and
all
of
the
configuration
files
that
pointed
at
our
repos
and
configure
to
run
the
plugins
we
like
to
give
us
the
workflow
that
we
want.
There
are
actually
many
other
prowl
deployments
out
there.
So,
for
example,
sto
uses
their
own
prowl
deployment.
D
So
we
can
start
to
separate
the
prowl
Coface
from
the
kubernetes
prowl
configuration
because
I
think
those
are
kind
of
two
tangential
issues.
So
look
for
more
on
that,
if
you're
interested
in
that
I
could
always
use
help.
Part
of
the
difficulty
in
just
making
that
clean
break
is
the
the
dependencies
are
a
little
tangled,
because
prowl
has
lived
in
the
testing
for
repo
so
long
with,
alongside
a
bunch
of
our
other
automation.
D
There
are
things
that
depend
on
code
inside
of
the
prowl
repo
and
things
in
the
prowl
repo
that
depends
the
outside
of,
and
so
a
little
bit
of
that
untangling
has
to
happen
before
we
can
get
there.
So
there
is
a
proud
channel
that
is
dedicated
to
the
prowl
sub
project
and
the
people,
who
are
there
I'd
like
to
just
start
to
grow,
that
into
more
of
its
own
separate
thing,
and
then
maybe
we
can
live
in
a
world
where
contributor
experience
becomes
the
owners
of
the
proud
configuration
for
the
kubernetes
project
instead
of
today.
D
A
D
A
G
K
N
While
cleaning
the
devil,
folder
I
created
this
table,
let
me
show
you
so
surprised:
I
did
I
was
grouping
by
6
every
file
we
have
in
the
devil,
folder
and
I
want
to
ask
about
if
it
is
useful
to
add
a
line
like
this
one
for
files
that
are
not
part
of
a
sick
folder,
because
that
can
facilitate
this
way.
We
can
reach
out
the
owners
of
those
files
when
we
have
to
obey
them
or
just
to
discuss
anything
about
information
in
those
files,
maybe
somewhere
in
this
style
guide,.
M
The
other
thing
that's
helpful
for
us
to
do
when
that
we've
done,
I
would
need
to
pull
up.
Let
the
community
repo
and
try
remember,
hasn't
done
that
for
devel
is
sorting
things
into
folders,
because
the
other
thing
that
we
can
do
if
we
move
documents
into
folders
yeah,
we
haven't
done
that
with
devel.